1.客户端确认－－服务器没有采用确认检查
2.数据库交互－－SQL注入
3.文件上传与下载－－路径遍历漏洞，保存型跨站点脚本
4.显示用户提交的数据－－跨站点脚本
5.动态重定向－－重定向与消息头注入攻击
6.社交网络功能－－用户名枚举，保存型跨站点脚本
7.登录－－用户名枚举，脆弱密码，能使用蛮力破解
8.多阶段登录－－登录缺陷
9.会话状态－－可推测出的令牌，令牌处理不安全
10.访问控制－－水平权限和垂直权限提升
11.用户伪装功能－－权限提升
12.使用明文通信－－会话劫持，收集证书和其它敏感数据
13.站外连接－－Referer消息头中查询字符串参数漏洞
14.外部系统接口－－处理会话与／或访问控制的快捷方式
15.错误信息－－信息泄露
16.电子邮件交互－－电子邮件与命令注入
17.本地代码组件或交互－－缓存区溢出
18.使用第三方应用程序组件－－已知漏洞
19.已确定的Web服务器软件－－常见配置薄弱环节，已知软件程序缺陷
避开客户端控件:
客户端提交的每一项数据都应该被视为危险和潜在恶意的
隐藏表单字段：
隐藏的HTML表单字段是一种表面看似无法修改．可以通过代理工具拦截修改提交请求．
HTML代码片段
<form method="post" aciton="Shop.aspx?prod=1">
Product: iPhone 5 <br/>
Price: 449 <br/>
Quantity: <input type="text" name="quantity"> (Maximun quantity is 50)<br/>
<input type="hidden" name="price" value="449">
<input type="submit" value="Buy">
</form>这段代码，如果使用Burp 拦截提交的表单，修改price的值在发送给服务器，就可以随意修改隐藏的表单的数据．在购物站点，如果把价格修改为负数能成功，不但能收到商品开可以得到退款．
手里的Java项目:
使用burp拦截数据 修改在提交价格 隐藏的表单
POST /shopping/add_goods_cart.htm HTTP/1.1
Host: 192.168.1.102:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.102:8080/shopping/goods_32769.htm
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 36
Cookie: JSESSIONID=67EA32EBA03BE77B6BAC9D1160420D3A; bdshare_firstime=1537270511344
Connection: close
＃id=32769&count=1&price=208&gsp=19%2C
id=32769&count=1&price=-100.0&gsp=19%2C
返回消息：
HTTP/1.1 200
Set-Cookie: cart_session_id=e3ddc347-7532-47cf-9f95-0dc7e2f3ffdc; Domain=192.168.1.102
Cache-Control: no-cache
Content-Type: text/plain;charset=UTF-8
Content-Length: 32
Date: Tue, 18 Sep 2018 11:49:13 GMT
Connection: close
{"total_price":-100.0,"count":1}HTTP cookie:
和隐藏表单字段一样，http cookie不显示在屏幕上，也不能由用户直接修改．如果程序信任cookie值可拦截修改．
URL参数：
web程序常常使用预先设定的URL参数通过客户端传送数据
http://192.168.1.102:8080/shopping/goods_list.htm?gc_id=3&store_id=1
有时候并不希望普通用户查看或者修改URL参数．
包含参数的URL加载嵌入图片，URL加载框架内容，表单使用POST方法并且预设定参数，弹出的窗口等．
Referer消息头：
浏览器使用消息头指示当前请求的页面URL或提交了一个表单，或引用其它资源．referer消息头可用于准确判断某个特殊的请求由那个URL生成．
Referer: http://192.168.1.102:8080/shopping/goods_98460.htm
当用户重设置密码的时候，使用referer消息头验证请求，使用代理服务器拦截消息修改为需要的值，就能轻易篡改成功．
模糊数据：
传送的数据被加密或某种形式的模糊处理，价格保持原样，就很难去看懂了．拦截各大电商平台的数据就可以看到价格都被加密了．提交表单后服务器将会检查模糊字符串的完整性或进行解密处理．
<form method="post" aciton="URL">
Product: iPhone 5 <br/>
Price: 449 <br/>
Quantity: <input type="text" name="quantity"> (Maximun quantity is 50)<br/>
<input type="hidden" name="price" value="449">
<input type="hidden" name="pricing_token" value="加密">
<input type="submit" value="Buy">
</form>可以尝试模糊处理所使用的模糊算法进行解密，可以找一个价格低的数字，比如找一个价格便宜的产品加密后的价格复制过来，放入发给服务器．还可以提交畸形字符串，测试不同字符集错误的字符串，尝试攻击负责对模糊数据进行解密或去模糊处理的服务器端逻辑．
攻击验证机制:
Web应用中最常用的验证机制是使用HTML表单获取用户名和密码，将数据提交给应用程序．绝大部分都采用这种机制．
暴力破解用户名密码：
一般站点登录输入用户名和密码后会提示密码错误或者没有这个用户等信息，在没有做防御暴力破解的机制下，就可以使用破解攻击导入字典进行攻击，如今这种情况不是没有只是特别少了，而且防护机制有可能会对cookie的值进行递增处理，到达某个值后会进行拒绝访问．有些情况即便是锁定了账户，服务器也会做出响应．
例如：后台管理页面有些根本不会对登录做验证码或者保护机制的处理．
还可以对用户名进行枚举，枚举几个用户名发给服务器，看服务器做出的响应是否出现差异．
证书传输易受攻击：
使用非加密的HTTP连接传输登录证书，处理网络适当位置就可拦截这些证书．即便使用HTTPS，如果应用程序处理证书的方式不安全，证书有可能会泄露．
密码修改功能：
web程序中有些站点，不允许用户修改密码．在页面中不提供密码修改功能连接．
无效的用户名，修改密码中新密码和确认密码进行比对，发给服务器的数据，进行差异的比对．
旧密码比对新修改的密码，做出的响应．若有提示，可确定密码．
忘记密码功能和修改密码一样，忘记密码功能设计方面的缺点是逻辑中最薄弱的环节．
忘记密码可能回设置问题，比如：纪念日，生日，喜欢的颜色，某某的姓名等等．猜测这些问题相比去猜测密码简单了许多．
有些人的信息比如生日什么的，有可能会公开在互联网上，比如个人资料的显示等等．
记住密码功能容易受到本地和其他计算机用户的攻击，记住功能通过一个简单的cookie操作，设置的cookie其中并不包含用户名，而是使用一个持久会话标识符，提交这个标识符就可避开登录过程．即便cookie中保存用于重新识别用户信息得到保护，通过跨站点脚本等漏洞，也可轻易获得信息．
用户伪装功能：
web应用程序允许特权用户伪装成其他用户，在该用户权限访问．
例如：银行Web程序允许服务台操作员口头验证电话用户，将银行程序会话转到该用户的权限下，以便提供帮助．
伪装功能通过隐藏功能的形式执行，不受常规访问控制管理．判断用户是否进行伪装，应用程序可能会信任由用户控制的数据．
证书确认不完善：
验证机制强制要求密码满足各种要求，大小写，密码的长度不能少于几位，加字符数字组合等等．一些不佳的验证机制并没有对这些做处理．不严重字符的大小写，对密码截断处理等．
使用一个账号，尝试去验证，删除最后一个字符，改写字符大小写等等．从而利用得到的信息就可以避免一些多余的测试，提高成功率．
非唯一性用户名：
自我注册的应用程序允许用户指定他们自己的用户名，不强制要求用户使用唯一的用户名．极其少见，不是没有可能出现．
注册阶段或修改密码的过程，共享一个用户的两个用户可能碰巧选择相同的密码．导致登陆后共享了数据．
尝试使用不同的密码两次注册用一个用户名．出现注册成功就存在这一漏洞．
可预测的用户名：
应用程序根据某种可以预测的顺序自动生成用户名．如果以这种方式运转，弄清用户名顺序就可以很快获得全部有效用户名．
测试提交几个用户名，让程序自动生成，进行比对看是否有顺序，如果可行便可以使用蛮力攻击．
可预测的初始密码：
一些应用程序一次性大批量创建用户，并自动指定初始密码．以某种方式将密码发给用户．这种生产密码的方式可以能预测其他用户的密码．如果出现根据用户名相关的信息，就可推断相应其他用户的初始密码．
证书分配不安全：
许多应用程序并不在用户与应用程序正常交互的过程中分配新建账号的证书，通过邮件或其他方式．
这种分配方式有时带来安全风险，例如：发送邮件中包含用户名密码，没有给邮件设置使用的时间限制，没有要求用户登录后修改密码，如果邮箱被访问，会导致任何人使用此账号．
有时会方式一个激活账号的URL链接，如果发给用户的URL出现某种顺序，就可以通过注册几个紧密相连的用户找到其中的顺序．尝试使用同一个URL看是否会遭拒绝．
故障开放登录机制：
在JAVA程序中如果做异常处理，如果用户不输入用户名密码，出现空指针异常，用户就可以成功登录．出现几率低，但不是不可能．也有可能出现类似的Bug.
多阶段登录机制中的缺陷：
web程序中使用设计好的多阶段登录机制，可能出现逻辑上的缺陷．第一阶段出现验证通过，第二阶段中没有验证通过，有可能直接跳过第二阶段验证，直接在第三阶段验证通过．或者在第一阶段验证出错，而第三阶段通过．
不安全的证书存储：
web应用程序常常以危险的方式将用户证书存储在数据库中，经过MD5加盐等操作或另一种加密方式．
虽然到了密码安全性，但或许可以利用其他的漏洞进行访问这些证书，例如：SQL注入
攻击会话管理:
状态要求:
从本质上讲,HTTP协议没有状态.它基于一种简单的请求响应模型,其中对每对消息带一个独立的事务.早期的web程序是任何人都可以查阅的静态HTML页面.
执行会话最简单,最常见的方法是向每名用户发布一个唯一的会话令牌或标识符,用户在随后向服务器请求都提交这个令牌.
多数情况下,都是使用HTTP cookie作为服务器与客户端传送这些会话令牌的传输机制.服务器对新客户端的请求响应中set-cookie.客户端随后的每次请求中都会包含set-cookie的值.
这种标准的会话非常容易遭受攻击.可以劫持绘画,由此伪装成这名用户.漏洞主要分为两类:会话令牌生成过程中的薄弱环节和在整个生命周期过程中处理会话令牌的薄弱环节.
会话替代方案:
并非每一种web程序都会使用会话,一些具备验证机器,功能复杂的安全性至关重要的应用程序选择使用其他技术管理状态.常见的会话替代方案有两种:HTTP验证和无会话状态机制.
如果使用HTTP验证,可能不执行会话管理机制,分析任何可能是令牌的数据的作用.
如果使用无会话状态机制,向客户端发布的可能令牌的数据相当长100B或超过100B,请求的响应,查看是否有新令牌数据.提交多个相同数据的请求,看是否遭到拒绝.
令牌有一定含义:
一些会话令牌通过用户名或电子邮件地址转换而来,或者使用与其相关的其他信息创建.对这些数据进行模糊处理或进行编码.可对其解码查看.
令牌可预测:
会话令牌中不包含与用户有关的任何有意义的信息,但它们由包含某种顺序,可通过几个令牌样本进行分析,推断最近发布的其它有效令牌.或许尝试几百次到几千次找到或找不到有效令牌.寻找有效令牌会受服务器容器,其他用户的活动,带宽,网络延长等因素影响.会话令牌通常来自3个方面:隐含序列,时间依赖,生成的数字随机性不强.
加密令牌:
令牌中包含用户有意义的信息,向用户发布令牌之前对令牌加密处理来避免出现明显问题,看是稳妥.但有时候不需要对令牌解密就可直接篡改令牌中有意义的内容.
加密令牌使用对称加密算法ECB,出现问题的主要原因是明文分组与密文分组完全对应所致.
在日志中泄漏令牌:
web程序为管理员和其他人员提供监控和控制程序运行状态的功能,在日志中暴露令牌的原因是RUL查询字符串,不使用HTTP cookie或POST请求主体来传输令牌.google查询inurl:jsessionid
攻击访问控制:
访问控制可分为三大类:垂直访问控制,水平访问控制和上下文相关的访问控制.
用户能够访问他无权访问的功能或资源,访问权限控制存在缺陷.分配给他的角色不具有这种权限,就会出现垂直权限提升漏洞.如果用户有资格查看或者修改文件,就会出现水平权限提升漏洞.用户利用程序中的漏洞获得关键资源的访问权限,就会出现业务逻辑漏洞.
完全不受保护的功能: 敏感功能和数据可以被任何相关的URL访问例如:http://www.xxx.com/admin/ phpmyadmin/ 等等.许多程序使用javaScript在客户端动态建立用户界面中使用一些状态标记.
例如:
if (isAdmin){
adminMenu.AddItem("/admin/admin.jsp"....);
}直接访问方法:程序在使用远程调用API方法的URL参数,这类漏洞通常出现在Java中.访问权限没有受到严格控制,可通过参数直接访问方法.
例如:
http://www.xxx.com/public/admin/getAllUser, getAllRoles, getAllUsers, getCurrentUserPermissions等等基于标识符的功能:
访问某个特殊的资源时,请求资源的标识符常常以请求参数的形式在URL查询字符串或POST请求主体中提交给服务器.
如果权限控制不完善,请求相应的URL用户都可以查看无权访问的内容.
http://www.xxx.com/index.php?id=12323432静态文件:
很多情况下,用户都是通过在服务器上执行动态页面发布请求来访问受保护的资源.每个动态页面负责执行适当的访问控制检查,确认用户拥有的权限.有些时候,用户会直接向服务器Web根目录下不受保护的静态资源提出请求.就会导致严重的访问权限漏洞.
例如在购买电子书的站点: www.xxx.com/download/1223423.pdf 知道这个URL的用户都可以访问下载该资源.
配置错误:
一些应用程序在Web服务器或应用程序平台使用控件来控制访问,程序会根据用户的角色来限制对特点URL路径的访问,如果用户不属于管理员,访问/admin路径会受到拒绝,如果配置错误,就会造成为授权访问.
GET方法的最初目的是检索信息,POST方法是执行更改应用程序的数据或者状态.
如果程序级脚本并不验证对此功能的所有请求是否使用POST方法,就可以通过使用GET方法提交同一请求来避开这种控制.
访问控制方法不安全:
基于参数的访问控制:程序在用户登录时决定用户的角色或访问级别,http://www.xxx.com/login/index.jsp?admin=true
基于Referer的访问控制:Referer消息头完全由用户控制,可以修改任何值
基于位置的访问权限:使用位于所需位置的Web代理服务器,使用在所需位置终止的VPN,使用支持数据漫游的移动设备,直接修改客户端用于确定地理位置的机制.