SQL注入
成因
程序未对用户的输入的内容进行过滤，从而直接代入数据库查询，所以导致了sql 注入漏洞 。
思路
在URL处可以通过 单引号 和 and 1=1 and 1=2 等语句进行手工测试sql注入 。
Post 注入
比如后台登录框输入单引号测试注入，报错的话说明存在注入可以直接抓包，用工具来完成注入。（ 在HTML中关于提交类型代码，尤其是后台登录和留言这些，都是需要 post 形式来提交的，而且 post 提交方式也是不会像 get 形式在 URL 中显示的。）关于SQL注入 还有 ，Cookie注入 盲注 爆错注入 等等...
实例
输入单引号，进行初步判断，如果报错就说明可能存在注入。
然后我，猜想出真正执行的SQL语句应该是： select * from info where fid=623继续输入 and 1=1 ， and 1=2 来看下是否可以手工注入，就是查看页面是否存在显示性错误，而不是单引号式的错误。
由于我是转贴的，所以就没有这个截图，但是成功的报错了。而 and 1=1 和 and 1=2 在SQL 语句中是这样的：
这样的语句在数据库查询中是可以查询成功的 ， 623 and 1=1 而这里的 and 是一个逻辑判断符，623是正确存在的，而 1=1 这个也是正确的啊！所以 正确 and 正确 ，就会查询 623 这个，所以页面也就返回正常了，而 1=2 这肯定不对等，所以 正确 and 错误，就会查询错误，所以报错 。
既然存在注入了，懒的手工就直接扔 sqlmap 了。
XSS 漏洞
原理
web 程序解析了用户的HTML代码操作。说白了，就是程序员在设计网站中输入输出的部分的时候，没有对用户输入的内容进行过滤，从而导致用户输入恶意代码时，这些代码会被 web 程序给执行了。
Xss分类
反射型，存储型，DOM型，FLASH（DOM，FLASH不常用）
反射型xss ：存在输入输出的地方，不具备转存数据库这一步，只是一个简单的输入输出。一般这类的漏洞危害比较小，因为它的传播方式需要恶意用户把他构造好的恶意 URL 发给你，你点击才会触发的，一般有安全意识的很少会中招。
存储型xss ：没有对用户输入的东西，进行过滤，就直接存储到数据库中。一般这类的漏洞是危害最大的，而且可以运用在很多方面上，只要你知识牢固，思维广阔，这个漏洞，可以玩出很多花样来，不过该漏洞，目前运用最广的就是在网站留言板这一类的，输入恶意代码，让网站管理员查看后，并中招，从而窃取 cookie 。
反射型实例
反射型（查看url）大白话总结：吃什么吐什么
发现php？S=24 (下面的输出内容为1，测试下)
发现把s的内容替换之后 页面的内容也随之替换，则此处应该存在xss反射漏洞。
那我们构造下一个常用的 java 的弹窗代码，再看下效果 。
回车一下 。
通过测试，我们发现这是一个典型的反射型 XSS 漏洞。
储存型XSS实例
这是一个存在储存型 XSS 漏洞钓鱼网站 。
然后，我们鼠标右键简单的查看下网页源代码 。
在查看源代码时，我们发现 当领取码不等于98的时候 就返回true，及领取码等于98。
我们随便输入领取码之后，就是弹出一个领取奖品页面，在这个页面，我们其实就可以盲打一下试试。
那么在开始之前，我们先随便找一个 XSS 平台，复制一段盗取 cookie 的恶意代码。
Xss
Xss插入的地方大多为标题跟内容（一切可以输出文本内容的都可以插入），然后我们试着插入下。
插入到联系地址里面测试下能不能插入，（前面加个”)以防万一闭合下前面的标签。
#（这里，我其实不推荐这样的插入，因为这个的格式，字数限制都是一些 html 这个层面的限制，建议进行抓包插 XSS 代码，这样被打到的几率更大。）
到这里就提交成功了，那就等管理员上钩就是了。
看来这个钓鱼网站的管理员也是个时时关注信息，认真负责的管理啊！不像某些公司的那些运维们，大半年的后台都不进，我记得我一个朋友，前段时间，发了一个说说，大概内容是 mlgbz ，两年前插的一个留言板，我今天竟然收到这个 cookie 了。。。
解析漏洞
利用web中间件自身的漏洞，对畸形脚本格式进行了解析。
这个不多解释，程序自身研发时的问题。
IIS 6.0
常见组合：server 2003+IIS6(IE6.0)
1. 正常解析格式包括：asp,asa,cer
2. 正常解析 1.asp;.jpg | 1.asa;.jpg | 1.cer;.jpg | 1.asp;xxxx.pdf3. 正常解析 1.asp文件夹下的任意文件: 比如说网站目录中有一个文件夹名为1.asp ，那么这个文件夹下的任意文件，比如1.jpg,1.pdf,1.doc,1.abc 都会解析成asp脚本文件。再比如有一个链接：
https://www.zhutougg.com/abc.asp/1.pdf
如果该站的中间件为IIS6.0,那么这个链接就会解析成asp脚本。
备注：在利用上传漏洞的时候，如果不能上传asp格式文件，先尝试上传asa,cer格式，然后再尝试上传1.asp;.jpg格式文件，如果可以控制上传后的目录，就上传test.jpg图片大马到1.asp目录下。
IIS 7.5
常见组合：server 2008+IIS7/IIS7.5
如果目标能解析PHP脚本，则可以尝试上传1.jpg,然后访问 %00.phpAPACHE 2.2.*
常见漏洞版本为2.0.*到2.2.*
apache 文件解析方式
文件名由右往左解析。即 1.jpg.pdf apache 会先识别 pdf格式，然后再识别 jpg 格式，因为 apache 能够识别 pdf 格式，所以这里它不会解析 .jpg 格式。再比如 1.jpg.abc apache 先识别 .abc 格式，再识别 .jpg 格式，这里 apache 不认识 .abc 格式，所以这里 apache 将其解析成 .jpg 格式 。
利用
上传1.php.abc 1.jpg.abc.php.123.rar(?)
NGINX 0.5.* | 0.6.* | 0.7-0.7.65 | 0.8-0.8.37
如果目标能解析PHP脚本，则可以尝试上传1.jpg,然后访问 %00.php
备注：在碰到 nginx 中间件时候，先找到网站的图片链接比如 ,然后直接在链接后面加上 %00.php
其它常见的中间件
asp , aspx： iis5.0 , iis6.0 , iis7.0 , iis7.0 , iis8.0
php: apache , nginx , fast-cgi
jsp: tomcat , weblogic , jboss , jetty , GlassFish , Resin , IBM Websphere
aspx的兄弟格式： ashx
jsp: jspx
实例:asp解析漏洞
进入网站之后随手测试下注入点（https://xxx/detail_industry_news.asp?id=6）手工测试之后发现存在sql注入 ，然后就扔注入工具里 。
但是没有注入出来表单，后来又换了多个注入工具进行注入，结果一样，都没有表单数据 。
然后使用目录扫描器进行扫描，发现有一个webdata二级目录，自己猜测会不会是数据库文件了？
然后，继续扫描二级目录发现 webdata/webdata.mdb 这个数据库文件，下载之后发现账号，密码。
既然，账号密码都有了，那就找后台吧 。
目录扫描器，扫后台没找见 = =！ 那好吧，手工慢慢找 。。。
最后在一个旁站的 robots.txt 文件里，发现一个特点，就是它这个旁站的后台是域名格式的后台，那主站是不是也是这个了？搞！
没想到还真是 xx.xx/xx.xx 这样后台 。。。
那就进后台 。
一股浓浓的南方站的味道，就像吃老干妈的感觉一样，那就先找数据库功能吧 。
额，没有数据库备份这个功能，看来数据库备份拿 shell 这个方法是不行了。。。
不过这个站是 IIS6.0 的，存在解析漏洞，还好日 ，那就找上传点吧 。
找到一个上传点，先传个正常图片看看，看这个上传点是不是坏的，还有会不会出来路径 。
既然不是坏的，那就上传个 asp DAMA 吧 。
看来不能直接上传，那好吧，抓包上传吧 。
由于，我们事先知道了上传路径 /bookpic/ ，所以我们直接利用 IIS 6.0 的解析漏洞，也就是（1.asp;.xx）{xx是上传文件的名字} 在文件夹后面加上 1.asp; 试试可以上传成功并解析吗。
抓包 ，改包 ，来先看看 。
来，看看我们能不能连上这个 DAMA 。
结果很不赖，被解析了，从而，也就拿下这个站了。
上传漏洞加绕过方法
客户端检测
程序员一般使用 Java 来拒绝非法文件上传。
绕过方法
FireBug插件：将用于检验文件扩展名的onsubmit事件删除。
中间人攻击：使用Burp Suite。首先把木马扩展名改为一张正常图片的扩展名，比如JPG扩展名，在上传时使用Burp Suite拦截上传数据，再将其中的扩展名JPG修改为PHP，就可以绕过客户端验证。（可能还需要相应地修改Content-Length）任何客户端验证都是不安全的。客户端验证是防止用户输入错误，减少服务器开销，而服务器端验证才可以真正防御攻击者。
服务器端检测
白名单与黑名单验证
黑名单过滤方法：定义不允许上传的文件扩展名
黑名单的绕过方法
1.攻击者可以从黑名单中找到Web开发人员忽略的扩展名，如：cer
2.对文件的后缀名进行大小写转换，比如黑名单中有php，可以将文件的后缀改为pHp，仅限windows平台
3.在windows系统下，如果文件名以“.”或者空格作为结尾，系统会自动删除“.”与空格，利用此特性也可以绕过黑名单验证。（asp.或asp_）
白名单过滤方法：定义允许上传的文件扩展名
白名单的绕过方法
结合Web容器的解析漏洞
MIME验证
php 中通过 $_FILE['file']['type'] 来检验
绕过方法：可以在Burp Suite中更改Content-Type的内容为image/jpeg
目录验证
在文件上传时，程序通常允许用户将文件放到指定的目录中，如果指定的目录存在，就将文件写入目录中，不存在的话则先建立目录，然后写入。
比如：在前端的HTML代码中，有一个隐藏标签input type="hidden" name="Extension" value="up"/
在服务器端有如下代码：
if(!is_dir($Extension)){ //如果文件夹不存在，就建立文件夹mkdir($Extension);
}
攻击者可以利用工具将表单中value的值由“up”改为“pentest.asp”，并上传一句话图片木马文件。
程序在接收到文件后，对目录判断，如果服务器不存在pentest.asp目录，将会建立此目录，然后再将图片一句话密码文件写入pentest.asp目录，如果Web容器为IIS 6.0，那么网页木马会被解析。
00截断上传
在ASP程序中最常见，也就是%00将后面的字符都截断了，比如上传文件名为1.asp%00xxser.jpg。
实际操作过程中，利用Burp Suite的Repeater中的HEX选项卡可以进行这样的操作。
截断上传漏洞不仅出现在ASP程序上，在PHP、JSP程序中也存在这样的问题。
0x00不是针对所有基于白名单的后缀名检查都能绕过，代码的实现过程中必须存在截断上传漏洞。
逻辑漏洞分类
欺骗密码找回功能（任意密码重置等）
程序根据一个验证码来确定是用户本人，攻击者可以通过抓包改包，暴力破解，等方法来进行绕过。（漏洞产生的原因：前端验证，数据包中含CODE等）
思路：fuzz模糊测试来进行漏洞挖掘
实例：某学院存在任意密码重置漏洞
第一步（先找回密码） 查看源代码
跟一下 nextDo2
关键在跳转第二步
如果data.status 等于0 那么跳转第二步，如果不等于0 那么就提示验证码不正确！
只要 status 等于0 它就跳转第二步，那么通过burp去修改它的 Response放包之后就会发现直接绕过验证改密，这样就形成了任意密码重置漏洞。
预防思路：response数据内不包含验证码，验证方式主要采取后端验证。
任意金额修改
可以通过篡改数据报，使得购买的商品价格为负数等（金额数据通过明文传输，没有后端验证等一系列都可以产生任意金额修改漏洞）
实例
注册下单，支付，选择拉卡拉支付
截断 http 请求，更改post金额数据 。
到达支付页面发现 ，
发现金额被修改，也未提示该修改无效 。
预防方法：后端验证，数据包加密后进行传输 。
越权漏洞
主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定（仅限于存在漏洞功能对应的数据）
思路：
可能出现越权漏洞的地方（对数据库进行操作的都可以）。
查看代码 当id=数组里面的数为则显示账号密码，否则输出信息出错。
当知道管理员的id的时候可以任意更改url查询到账号密码。
当然越权漏洞存在很多种cookie绕过等等。
好了，完结！
作者：GeekC0s
来源：i春秋
链接：https://bbs.ichunqiu.com/thread-21386-1-1.html
炼石信息安全培训春季班开招
咨询QQ群：495066536
敬请持续关注……
