一、Web安全漏洞：
1、跨站脚本攻击XSS：Cross Site Scripting，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS
恶意攻击者往Web页面里插入恶意script代码，当用户浏览该页面时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。在不同场景下，XSS有相应不同的表现形式，主要分为反射型、存储型、DOM型的跨站脚本攻击，所造成的映像主要是窃取用户的登录凭证（Cookies）、挂马攻击、页面访问挟持等
手工测试：
1.1、反射型XSS测试：（相当于get请求页面：url里面输入）对提交页面的各个参数依次进行SQL注入测试，判定是否存在注入
比如正常访问的地址是 http://www.ccc.com/xss.jsp?id=1&name=2，依次对2个参数进行XSS测试
1.1.1、提交 http://www.ccc.com/xss.jsp?id=1”><script>alert(/xxx/)</script><!--&name=2，根据返回页面是否弹出包含xxx字符串的窗口判断是否存在反射型XSS
1.1.2、提交 http://www.ccc.com/xss.jsp?id=1&name=
‘><script>alert(/xxx/)</script><!—
“ onerror=alert(/xxx/) t=”
“ onmousemove=alert(/xxx/) t=”
‘><img src=# onerror=alert(1)>
‘><iframe src=http://www.baidu.com><’
同样的判断返回页面是否弹出包含xxx字符串的窗口判断是否存在反射型XSS
1.2、存储型XSS测试：（页面输入框进行操作）在页面表单提交测试中，依次对提交参数进行XSS测试
提交参数语句
‘><script>alert(/xxx/)</script><!—
“ onerror=alert(/xxx/) t=”
“ onmousemove=alert(/xxx/) t=”
‘><img src=# onerror=alert(1)>
</textarea><script>alert(123)</script><!--
‘><iframe src=http://www.baidu.com><’
根据返回页面是否弹出包含xxx字符串的窗口判断是否存在存储型XSS
1.3、 修复建议
对用户所有输入的数据进行过滤，在输入页面就进行拦截处理，就尽量不要进入到数据库层面进行交互了。例如："<" ">"、"script"的关键字等
对系统输出的内容进行编码处理。例如：HTML Entity。
2、任意文件上传
任意文件上传漏洞主要是由于程序员在开发文件上传功能时，没有考虑对文件格式后缀的合法性进行校验，或只考虑在应用前端（Web浏览器端）通过javascript进行后缀校验，攻击者可上传一个包含恶意代码的动态脚本（如jsp、asp、php、aspx文件后缀）到服务器上，攻击者访问该脚本时服务器将对包含恶意代码的动态脚本解析，最终执行相应的恶意代码。该漏洞最终将可能直接影响应用系统的服务器安全，攻击者可通过所上传的脚本完全控制服务器。
手工测试：对文件上传页面进行测试
2.1、直接上传（上传格式进行客户端校验）：在上传过程中，直接选择动态脚本后缀的文件，如asp、php、jsp、aspx等文件格式，观察是否上传成功
2.2、绕过JS上传（上传格式进行服务器端校验）：可以用charles或burpsuite工具进行测试，详细使用方法可百度或看我抓包工具的博客
当上传页面在前端采用javascript进行文件后缀限制时，可通过HTTP抓包工具进行改包上传，将文件后缀修改为动态脚本后缀并上传提交，如果响应中显示上传成功，并且数据库里也多了一条材料数据，则需要修改
2.3、截断后缀上传：上传处理将识别到%00，并对后缀.png截断删除，如果最终显示微信.aspx文件上传成功，并且数据库里新增了数据，则需要修改
部分上传功能在对后缀名进行验证时存在缺陷，导致在文件写入过程中产生错误，导致可通过十六进制截断符（%00）对后缀进行截断
比如上传一个文件360.asp%00.jpg，上传处理时检测到%00并对.jpg字符串进行截断删除，最终导致360.asp动态脚本成功上传到了服务器
2.4、不允许绕过Content-Type检查上传：只识别了文件类型，并没有看文件格式，导致可通过改包的方式上传动态脚本到服务器上
比如Content-Type的参数值为image/jpg，程序会认为本次提交的为图片格式类型，并没有对文件格式进行后缀验证，最终成功绕过Content-Type检查，将aspx动态脚本到服务器上
2.5、 修复建议
禁止上传任意文件。对上传的文件后缀进行限制
3、 任意文件下载或读取
由于应用系统在提供文件下载或读取功能时，在文件路径参数中直接指定文件路径的同时，并没有对文件路径的合法性进行校验，导致攻击者可以通过目录跳转（..\或../）的方式下载或读取到原始知道路径之外的文件，攻击者可以通过该漏洞下载或读取系统上的任意文件，比如数据库文件，应用系统源代码，密码配置等敏感信息，造成系统的敏感信息泄露。
手工测试：
对存在文件下载或文件读取功能的页面进行测试，查看所提交的参数中是否包含文件名或文件目录，尝试提交参数值查看是否可下载或读取其他目录的文件内容；
比如：原始下载功能路径为http://www.ccc.com/donwload.jsp?filename=test123456789.pdf
其中文件路径参数为filename，通过../对路径进行跳转尝试下载其他目录下的文件，修改filename参数为../../WEB-INF/web.xml尝试下载JSP网站的配置文件（测试过程中需适当增加../跳转字符串）；如提交
http://www.ccc.com/donwload.jsp?filename=../../WEB-INF/web.xml
查看是否成功下载web.xml文件。
另一种情况如下：
http://www.ccc.com/donwload.jsp?filepath=uploadfile&filename=test123.pdf
该功能通过filepath以及filename指定下载目录以及下载文件名，可修改filepath参数值进行路径跳转，同时修改filename值指定文件名；如提交
http://www.ccc.com/donwload.jsp?filepath=../../WEB-INF&filename=web.xml
查看是否成功下载web.xml文件。
4、信息泄露
信息泄露主要是由于开发人员或运维管理人员的疏忽所导致。如未及时删除调试页面、未关闭程序调试功能、未屏蔽程序错误信息、备份文件未删除、数据库备份文件未删除、未屏蔽敏感数据信息等多个方面所导致的不同严重程度的信息泄露。攻击者可通过所掌握的信息进一步分析攻击目标，从而有效发起下一步的有效攻击。
手工/工具测试：
通过目录扫描工具扫描查看是否存在敏感路径；
通过文件扫描工具扫描查看是否存在敏感文件；
通过HTTP抓包工具观察请求响应中是否包含敏感的信息返回；
通过手工提交畸形的参数名或参数值尝试引起程序跑出异常，如提交单引号，超长字符串，异常编码字符串等方式；
修复建议
禁止使用服务器的绝对路径进行文件类的操作。
二、业务逻辑安全漏洞
5、未授权访问（直接在未登录情况下操作登录成功之后的页面）
应用系统对业务功能页面并未进行有效的身份校验，在未登录且获知业务功能页面的访问地址前提下，可直接操作该页面下的功能，将可能对应用系统的恶意破坏
手工测试：
成功登录后记录各个功能页面的URL，重启浏览器并直接访问所记录的各个URL，查看是否可访问成功；
最后在项目实例中发现：后台URL添加单引号直接显示了后台的部分功能，应修改
6、登录时验证码缺陷
常见于应用系统在登录处理流程过程中，当用户登录失败后并未对当前验证码进行注销并重新刷新验证码，攻击者可至始至终提交初始的验证码发起攻击穷举攻击；同时部分应用系统验证码只在客户端浏览器验证，并未经过服务器远程验证，将可能存在绕过验证码缺陷，另一方面，在生成或获取验证码的过程中存在缺陷，攻击者将可能成功预测验证码内容或直接解析验证码内容，从而使验证码失去原有意义，最终导致一系列的穷举或遍历数据攻击。
手工测试:
账号密码如果后台设置了密文，抓包工具获取到的是否密文展示
对存在验证码的功能页面进行刷新，观察验证码生成是否具有足够的随机性；
对存在验证码的功能页面进行刷新并通过HTTP抓包工具抓取当前请求包，查看验证码的获取过程，分析获取过程中是否存在缺陷可导致验证码被解析破解；
对存在验证码的功能页面进行数据提交，并通过HTTP抓包工具抓取当前请求包，最后重新对该请求数据包进行重放，查看是否请求失败或提示验证码错误，如请求成功，即验证码并未进行有效的刷新；
7、任意手机号注册：
常见于应用系统在登录处理流程过程中，当用户登录失败后并未对当前验证码进行注销并重新刷新验证码，攻击者可至始至终提交初始的验证码发起攻击穷举攻击；同时部分应用系统验证码只在客户端浏览器验证，并未经过服务器远程验证，将可能存在绕过验证码缺陷，另一方面，在生成或获取验证码的过程中存在缺陷，攻击者将可能成功预测验证码内容或直接解析验证码内容，从而使验证码失去原有意义，最终导致一系列的穷举或遍历数据攻击。
8、密码爆破