本文主要针对web安全的评估方法建立标准流程，以互联网用户，在非拥有源码的身份下，提出安全测试的方法。
安全测试之前，需要搜集目标web应用相关信息定义，应至少包括如下信息：
ü 各web系统url地址
ü 后台管理地址
ü 服务器软件版本、后端数据库版本、中间件版本、是否使用相关应用插件
对目标应用进行基本了解后，需要对每个应用的功能进行深度测试。同时，需要整理整个应用的全部报文。报文分析使用burpsuit，操作如下：
1）浏览器中设置代理IP与端口
2）Burpsuit中开启网卡并监听浏览器中的代理端口
3）初次整理，关闭burpsuit的拦截模式，手动对应用系统各功能与页面进行操作，记录报文。
4）借住burpsuit的spider功能，自动爬行更多的url
1.3.1 WVS扫描
整理基本信息之后，需要对目标进行全面的漏洞扫描，使用工具能快速对目标应用的安全状况进行评估。WVS扫描器检测主要进行两次。
(一) 默认扫描
安装默认的配置，直接进行全面扫描
(二) 嗅探后扫描
与burpsuit抓包类似，开启浏览器代理，在WVS中设置监听
然后开启嗅探，并保存嗅探日志
从站点架构中，导入嗅探日志
编辑站点，对指定的url进行扫描检测
1.3.2 Appscan扫描
针对后台语言为JSP的，推荐使用appscan进行扫描检测，默认配置，对漏洞级别高、中、低进行扫描即可。
1.3.3 Burpsuit扫描
要解决登录后扫描，上述两种扫描器在实际使用过程中，都存在不少问题，而burpsuit则天然使用在当前会话中实时扫描。
更新当前session保证有效的前提下，选择主动扫描
在全局的漏扫结束后，需要针对细节和变量进行深度测试与漏洞验证。上述三种扫描器都提供相应的功能，但使用burpsuit框架更小巧和方便。
本地安装sqlmap，对应检测SQL注入。在burpsuit中安装CO2扩展，选择报文，发送到sqlmapper，对各个可能出现注入的位置进行安全检测。
对burpsuit中收集到的报文，依次进行XSS检测分析。对每个报文发送到repeater视图下，对变量更改值为“‘/>;script>alert(“kc”)/script>”，查看响应。
xss的基准检测在于我们插入的关键字如何回显在反应漏洞是否存在。但存储型xss返回页面不存在，需要结合应用的流程与功能进行测试。基于快速的基准测试，可以结合burpsuit的插件xssValidator。步骤为：
1) 下载phantomjs
2) 在xssValidator插件目录中，执行phantomjs xss.js
3) 在burpsuit中选择报文，发送到intruder，payload选择插件
4) 在OPTIONS中设置与插件约定的关键字即可。
2.3.1 会话令牌在URL中传输
查看报文分析，是否在url中传输session等类似会话令牌
2.3.2 并行会话可行
使用火狐浏览器登录应用，打开插件CM（cookie管理器），复制当前应用的会话cookie。在虚机中，使用复制的cookie操作业务应用。如果两台机器未出现被迫下线，可同时在线操作，则存在并行会话漏洞。
2.3.3 COOKIE的脆弱性设置
使用火狐浏览器的CM插件，查看目标应用下的cookie设置，在httponly与secure标签中的设置情况，为false则存在漏洞。
2.3.4 会话令牌的随机性
检测目标站点的会话令牌是否符合随机性要求，否则将造成“串号”现象。
步骤：
Ø 代理拦截请求，找到第一次赋值会话的页面，如下
Set-Cookie: JSESSIONID=f1a955bd7401afa1f8c7e29c2707; Path=/per
Ø 发送到burpsuit的sequencer功能页，开始捕获令牌
Ø 在足够的令牌捕获下，查看分析结果，在sunmary中查看总体质量，对比字符分析，查看每位字符的变化，如下图，前3位字符随机性很低。
2.4.1 横向越权
检测此种类型漏洞，需要提前准备的是：两个同一级别的账户、两笔交易（相关交易信息、交易订单号、会话）
可预测的唯一标志获取其它用户相关信息如整理报文，探索查询用户信息用手机号判断：
/test?mobilePhoneNo=18646543600&ifStaging=0&orderNo=&installCnt=&ifAllPayments=1&currTotalConsumeAmt=0.00&currInterest=0.00&currFee=0.00&currNotRepaymentAmt=0.00
更换手机号重放报文，获取任意用户信息；
进行转账或添加好友功能的业务应用，输入预测的ID号或手机号，检测是否明文显示对应关系（手机号、姓名等）。同时检测，是否可批量获取（大量重放报文），查看目标应用是否对单位时间内的查询进行限制。
更换交易订单，任意退货、支付、查看交易信息
检测目标应用的全部功能，当更改关键信息为第三方信息时，查看是否可正常越权操作，如更换交易订单号，是否可对其它账户的信息进行任意退货、任意支付，或者查看其它用户的交易订单信息
个人用户身份认证功能越权
测试时，分析A用户修改密码、修改个人信息、重置密码，测试修改报文中的身份鉴别信息，查看是否可在A用户的会话中修改B用户密码、个人信息、重置密码。
2.4.2 纵向越权
2.4.3 TOKEN互用
测试目标应用是否存在钓鱼的可能，在A、B用户交易时，如果产生TOKEN值，查看该TOKEN值是否可互用。
测试方式：修改报文中，A用户的token为B用户的TOKEN，查看请求结果是否正常。
2.4.4 密码重放
检测目标应用，登录密码、支付密码是否可重复使用。通常密文每次变化，但后台不一定会取消之前的密文校验。
检测方式：burpsuit分析密码提交报文，在repeater模块中重放，检测是否正常响应。
另一种类型的密码重放攻击，叫做“撞库”。当使用已有的账户与密码进行一次性登录验证时，对应的措施使用安全控件的一次一密增加黑客组织密文的难度也很难抵御这种攻击。好的方式是：
1） 使用安全控件，增大自动化获取密文的难度
2）建议在所有需要登录的地方首次便启用图形验证码，已登入的情况下重放支付密码等时，则可不使用图形验证码，可防一次性撞库
3）登录操作有邮箱或者短信提醒
4）最优的方式，则废弃使用图形验证码，检测终端设备的行为，如一个设备标志单位时间内使用任意用户请求验证次数（设备标志包括ip、浏览器指纹、硬件设备指纹）
在应用首次验证不需要图形验证码时，还必须检测“撞库”攻击的防护能力：
² 依次使用不同的用户名密码进行登录，检测应用是否在错误输入密码3次左右后，即不允许在当前环境下，继续尝试任意用户名密码登录。
2.4.5 密码暴力认证系列
登录密码暴力破解
暴力破解密码需要使用到burpsuit的inturder模块，通用性较强。一般的测试方法如下：
1）找到所有需要登录的验证报文，依次发送到intruder进行破解，此处需要注意的是，如果对方存在密码控件等方式对密码进行加密，需要找到最终提交密文（需要检测目标是否为一次一密）
2）在inutrder模块中，选择需要暴力认证的变量，并选择变量认证的方式
这里需要注意的是，变量可以选择任意，但是payload却有具体个数限制。四种暴力认证方式的定义如下：
Ø Sniper：只能选择一个payload，通常也只会定义一个变量进行测试，所有变量的payload相同，但会从变量1开始遍历整个payload的值，其它变量不变，然后再用变量2遍历
Ø Battering ram：只能选择一个payload，各变量值会同步依次遍历payload所有值
Ø Pitchfork：每个变量对应一个payload，最高支持20个payload，各变量会同步遍历各自payload的值，总测试次数依赖于最短的playload数量。
Ø Cluster bomb：相对于pitchfork，本方案会依次遍历每个变量的payload，非同步方式即一个变量在更新payload时，其它变量保持不变，依次进行直至每个变量遍历完成。
3）定义攻击的认证方式后，选择对应的测试值，即payload集合。暴力破解一般测试可选用自定义的密码文件列表。
4）判断结果，需要结合burpsuit的模块comparer来比较密码正确与密码错误的返回对比。实际情况中，可以根据关键字在grep-match中匹配结果
支付密码暴力破解
支付密码的暴力认证与登录密码测试方法相同，主要在于测试的时候要寻找到支付密码提交认证的报文，并正确处理返回结果为正确或者错误的报文。
辅助手段的逻辑检测
目标应用往往增加图形验证码来防止暴力破解，但是需要检测逻辑先后问题。随意填写图形验证码，填写错误的密码提交报文，如果提示密码错误，随即提交正确密码时，返回图形验证码错误，则逻辑存在漏洞。可暴力破解，只要返回图形验证码错误，则可判断密码正确。
2.4.6 短信验证码暴力认证
检测目标应用，涉及短信验证码的报文。分析如何验证短信验证码，有以下几种方式使得暴力验证成为可能：
1）验证时只校验短信验证码，无其它辅助的随机字段
2）短信验证码为4-6位纯数字
3）短信验证码失效时间较长（2分钟内失效的破解度较低）
4）单位时间内不限制请求验证次数，不限制错误次数
测试方法：
参照密码暴力认证建立intruder，选择暴力破解，payload选择数字，自定义长度，控制线程数即可。
2.5.1 短信炸弹
分析目标应用，发送短信验证码的全部报文，依次分析：
Ø 是否可重放报文
Ø 是否有时间限制（前台js时间限制还是后台判断时间间隔）
Ø 是否对每个手机号有条目数限制
Ø 是否只允许发送给受限制的手机号（如当前会话用户）
依次将报文发送到burpsuit的intruder中，在url中增加变量kc，对其暴力赋值，这样对手机号的短信发送条目依赖于变量kc的payload数量。对不同手机号，可再增加手机号payload即可。
2.5.2 公开的敏感接口
独立的用户验证功能可批量获取用户信息
分析报文中，对用户名、手机号等个人身份信息关联参数的报文。提交不同的个人信息，查询返回结果是否包含敏感信息。
测试方式：如下报文
POST /per/validateUser.htm HTTP/1.1
name=13220596975
更改name变量重放报文，查看返回信息包含的内容。通常用来查询：目标应用的用户名、姓名、手机号。
独立的接口未授权访问获取信息
检测目标应用，需登录后，才能查询当前登录用户的相关信息的功能。依次分析是否可查询未登录用户信息、其它账户信息（更改id等关联号码）
限制的功能url
需要登录或满足一定条件、或先后顺序的功能url，未进行访问控制。进行测试的方式为按正常逻辑进行功能测试后，跳过前期的验证，直接访问后期的功能URL，如
² 跳过购买等待，直接进入购买页面进行购买
² 需短信验证或银行绑卡验证的功能页直接访问
后台功能暴露
目标应用的一些付费功能或选项，可测试不满足条件，直接进行后续操作，可能的漏洞测试如：
² 需积分或其它条件方能下载的功能，其实最终下载只判断下载uid，绕过下载限制
² 付费的下载项，在付费后的下载功能url，公开了互联网接口可免费直接使用
² 分析请求报文中的敏感明文变量，特别是1与0，TURE与FALSE等变量，尝试直接取反，检测是否能直接控制后台功能，如是否启用加密、验证码、安全控件的变量值在前台JS控制
JS中“注释”的隐藏功能
开发在测试环境中的功能脚本，在生产环境中，仅在JS中对功能的变量进行注释，但后台功能未删除。因此，可直接提交隐藏变量，使用隐藏功能。下例中，隐藏的变量isCheckImage=false，则后台接受参数会不检测图形验证码。
2.5.3 不安全的HTTP功能
对敏感功能，如登录或支付时，未使用HTTPS传输数据，测试时，观察报文协议即可。
2.5.4 危险的HTTP请求方法
HTTP协议支持一些特殊的调试方法，允许控制服务器资源。测试方式：对不同URL进行OPTIONS的请求，查看返回结果。
如果响应中allow显示允许 PUT、DELETE、PATCH等方法，则存在直接对服务器进行文件上传与删除的可能。
2.6.1 短信验证码绕过系列
基于前台JS验证
此类漏洞发生根本在于，目标应用判断短信验证码与其它逻辑独立判断。后续操作将根据返回的response值来进行判断。
开启burpsuit拦截请求与响应：
在响应页面，通过判断短信验证码正确时的返回，修改response的值即可。
Response返回中，显示短信验证码
在请求发送短信验证码之后，使用burpsuit拦截响应，查看响应页面是否存在验证码。
2.6.2 图片验证码绕过系列
检测目标应用的图片验证码，首先判断图形验证码对后续逻辑的影响，如果判断的逻辑为前台验证，可参照短信验证码绕过的方式，修改response即可。
如果图形验证码为最终逻辑，检测其是否可重复使用。通过导入burpsuit中的repeater模块，重放报文。
2.6.3 支付方式绕过系列
针对金融业务，在信用卡支付与储蓄卡支付存在时，检测是否可更改逻辑，在储蓄卡支付时，更改可使用信用卡支付。
分析信用卡支付、储蓄卡支付的不同响应，通过更改response中的响应来互换支付方式
如下代码
Response中更改fastpayway的变量值来绕过支付方式
修改请求，在请求中，修改支付类型
在支付填写银行卡号时，直接burpsuit拦截报文，修改卡号为需要转换的卡种号码
2.6.4 前台敏感信息修改系列
此类漏洞产生主要在于使用JS判断一些规则，或后台直接从页面取值。通常检测的目标在于：金额、时间等等
检测方式
Ø 时间延长或退后、金额加大或缩写、金额为负数，提交报文查看后续的处理结果。
Ø 分析所有发送短信的报文，检测是否发送短信内容从前台获取数据，尝试插入钓鱼数据进入报文。如：手机号金额等后跟钓鱼网址。
实际测试点汇总：
ü 选择分期消费时，分期的期数、还款日、每期还款金额、首期还款金额
ü
2.7.1 软件版本漏洞
此类问题为版本漏洞，通常应在信息收集的步骤中，收集目标应用详细的软件信息。对比最新的组件漏洞信息即可完成测试。通常容易出现的漏洞组件为：
ü Jquery
ü Tomcat
ü Struts2
ü Jboss
ü SSL v3
ü IIS
收集信息的方式，通过查看报文中的header，或者进行报错信息查看提示。
2.7.2 图形验证码的自动识别
测试目标应用的图形验证码的健壮性，通常拟定一个基准。使用tesseract项目，对目标验证码扫描测试，如果判断结果正确率基本为0，则认为目标应用满足基本要求。测试方式：
1）下载tesseract
2）下载图形验证码，使用tesseract进行各种语音与模式的尝试
3）对比正确结果
备注：验证码强度，主要比对在灰度及二值化后被通用引擎检测成功的概率为准，主要检测：是否扭曲与大干扰线、倾斜，即满足基线要求。
2.8.1 基本信息泄漏
测试基本信息泄漏，只需要对目标应用进行常规漏洞扫描即可，或手动查看报文中JS的内容是否清除掉相关版本或其他敏感信息、邮箱是否采用@替换为##来进行模糊处理。此举措主要是检测目标应用是否对互联网爬虫进行防范。
2.8.2 HTML页面中泄漏内网敏感信息
通常扫描器会自动发现内网IP地址的泄漏，深度测试时，需手动分析报文的响应信息，查看是否存在内网IP地址及URL等。
2.8.3 报文中包含敏感信息
通常在涉及银行卡、或者个人身份信息、认证信息时，无论使用HTTP或者HTTPS，都应检测报文中的敏感信息是否进行加密（包含请求与响应）。使用burpsuit分析拦截所有报文即可。通常格式为json的返回。
2.8.4 报错信息
强制目标应用报错，获取目标业务的敏感信息，测试方式：
Ø 更改HTTP的请求方法，在get与post之间互换报错
Ø 修改header中的cookie、token等敏感值
Ø 强制查找不存在的页面、图片或受限账户请求高权限账户的功能
Ø 强制修改变量内容异常报错（空值、正负数、乱码、特殊符号、burpsuit拦截修改已经加密编码过的值）
2.8.5 隐藏字段泄漏用户信息
测试隐藏字段，可在burpsuit中搜索全部报文响应，查看hidden关键字，通常应用使用hidden关键字隐藏的信息都为用户的敏感信息。
同时可在burpsuit分析应用时，勾选在响应里 unhide hidden from fields
在火狐浏览器的firebug插件中，对测试页面进行关键字搜索亦可。
| 状态码 |
简记 |
说明 |
| 1xx |
（临时响应） |
表示临时响应并需要请求者继续执行操作的状态代码 |
| 100 |
（继续） |
请求者应当继续提出请求 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分 |
| 101 |
（切换协议） |
请求者已要求服务器切换协议，服务器已确认并准备切换 |
|
|
|
| 2xx |
（成功） |
表示成功处理了请求的状态代码 |
| 200 |
（成功） |
服务器已成功处理了请求 通常，这表示服务器提供了请求的网页 |
| 201 |
（已创建） |
请求成功并且服务器创建了新的资源 |
| 202 |
（已接受） |
服务器已接受请求，但尚未处理 |
| 203 |
（非授权信息） |
服务器已成功处理了请求，但返回的信息可能来自另一来源 |
| 204 |
（无内容） |
服务器成功处理了请求，但没有返回任何内容 |
| 205 |
（重置内容） |
服务器成功处理了请求，但没有返回任何内容 |
| 206 |
（部分内容） |
服务器成功处理了部分 GET 请求 |
| 207 |
(多状态） |
扩展码；表示返回xml消息，且根据子请求返回独立的响应 |
|
|
|
| 3xx |
（重定向） |
表示要完成请求，需要进一步操作 通常，这些状态代码用来重定向 |
| 300 |
（多种选择） |
针对请求，服务器可执行多种操作 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择 |
| 301 |
（永久移动） |
请求的网页已永久移动到新位置 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置 |
| 302 |
（临时移动） |
服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求 |
| 303 |
（查看其他位置） |
请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码 |
| 304 |
（未修改） |
自从上次请求后，请求的网页未修改过 服务器返回此响应时，不会返回网页内容 |
| 305 |
（使用代理） |
请求者只能使用代理访问请求的网页 如果服务器返回此响应，还表示请求者应使用代理 |
| 307 |
（临时重定向） |
服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求 |
|
|
|
| 4xx |
（请求错误） |
这些状态代码表示请求可能出错，妨碍了服务器的处理 |
| 400 |
（错误请求） |
服务器不理解请求的语法 |
| 401 |
（未授权） |
请求要求身份验证 对于需要登录的网页，服务器可能返回此响应 |
| 403 |
（禁止） |
服务器拒绝请求 |
| 404 |
（未找到） |
服务器找不到请求的网页 |
| 405 |
（方法禁用） |
禁用请求中指定的方法 |
| 406 |
（不接受） |
无法使用请求的内容特性响应请求的网页 |
| 407 |
（需要代理授权） |
此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理 |
| 408 |
（请求超时） |
服务器等候请求时发生超时 |
| 409 |
（冲突） |
服务器在完成请求时发生冲突 服务器必须在响应中包含有关冲突的信息 |
| 410 |
（已删除） |
如果请求的资源已永久删除，服务器就会返回此响应 |
| 411 |
（长度要求） |
服务器不接受不含有效内容长度标头字段的请求 |
| 412 |
（未满足前提条件） |
服务器未满足请求者在请求中设置的其中一个前提条件 |
| 413 |
（请求实体过大） |
服务器无法处理请求，因为请求实体过大，超出服务器的处理能力 |
| 414 |
（请求的 URI 过长） |
请求的 URI（通常为网址）过长，服务器无法处理 |
| 415 |
（不支持的媒体类型） |
请求的格式不受请求页面的支持 |
| 416 |
（请求范围不符合要求） |
如果页面无法提供请求的范围，则服务器会返回此状态代码 |
| 417 |
（未满足期望值） |
服务器未满足”期望”请求标头字段的要求 |
|
|
|
| 5xx |
（服务器错误） |
这些状态代码表示服务器在尝试处理请求时发生内部错误 这些错误可能是服务器本身的错误，而不是请求出错 |
| 500 |
（服务器内部错误） |
服务器遇到错误，无法完成请求 |
| 501 |
（尚未实施） |
服务器不具备完成请求的功能 例如，服务器无法识别请求方法时可能会返回此代码 |
| 502 |
（错误网关） |
服务器作为网关或代理，从上游服务器收到无效响应 |
| 503 |
（服务不可用） |
服务器目前无法使用（由于超载或停机维护） 通常，这只是暂时状态 |
| 504 |
（网关超时） |
服务器作为网关或代理，但是没有及时从上游服务器收到请求 |
| 505 |
（HTTP 版本不受支持） |
服务器不支持请求中所用的 HTTP 协议版本 |
kn1ghtc's blog 