基于appscan测试结果分析：
一、XSS跨站脚本
指的是攻击者往Web页面里插入恶意html代码，通常是JavaScript编写的恶意代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。是最常见的Web应用程序安全漏洞之一
JavaScript可以用来获取用户的cookie、改变网页内容、URL调转，存在XSS漏洞的网站，可以盗取用户cookie、黑掉页面、导航到恶意网站
攻击的主要途径:
1.对普通的用户输入，页面原样内容输出
2.在代码区里有用户输入的内容(代码区中，绝对不应含有用户输入的东西)
3.允许用户输入HTML标签的页面
攻击解决办法：（过滤输入和转义输出）
1.在输入方面对所有用户提交内容进行可靠的输入验证，不要信赖客户输入（URL、查询关键字、http头、post数据等）
2.在输出方面，在用户输内容中使用<XMP>标签。标签内的内容不会解释，直接显示。
3.严格执行字符输入字数控制。
4.在脚本执行区中，绝不可以让用户输入
Eg：
1、用户名、密码等敏感输入字段未经加密就进行了传递
整改建议：在被测应用与服务器交互过程中，对密码等敏感信息进行加密传输。
2. 未对用户输入正确执行危险字符清理
整改建议：在被测应用与服务器交互过程中，对所有用户提交内容进行可靠的输入验证或编码。
二、URL 重定向包含网络钓鱼
重定向：客户端跳转之后浏览器URL改变，并且服务器无法传递参数。客户端跳转通常会使用response.sendRedirect()方法，也可以使用JavaScript跳转
攻击预防：
1.严格判断包含中的参数是否外部可控
2.路径限制：限制被包含的文件只能在某一文件夹内，一定要禁止目录跳转字符
3.包含文件验证：验证被包含的文件是否是白名单中的一员
4.尽量不要使用动态包含，可以在需要包含的页面固定写好
Eg：
1、Web 应用程序执行指向外部站点的重定向
整改建议：在被测应用与服务器交互过程中，参数外部不可控或可控禁止目录跳转字符或加密。
三、注销后会话未失效
测试响应与原始有效响应完全相同，注销后仍有可能访问受保护资源，用的是“会话固定”技术，会强制用户的会话标识变成显式值
Eg：
1.用户注销时使相关会话标识失效
手工验证：退出系统后，点击浏览器上的后退按钮，看是否可以退到系统中。
整改建议：注销后，浏览器后退按钮改为不可用或设session失效。
四、会话标识未更新
“会话标识未更新”是中危漏洞，AppScan会扫描“登录行为”前后的Cookie，会对其中的JSESSIONOID（JSP）或者 ASP.NET_SessionId（ASP）进行记录。在登录行为发生后，如果cookie中这个值没有发生变化，则判定为“会话标识未更新”漏洞
攻击方式：
在于攻击者通过某种方式（如XSS）将自己的Id置入了被攻击者的浏览器，将会话标识改为某个攻击者预设的值，被攻击者正常登陆，若服务器接收了这个预设值，那么相当于攻击者获得了被攻击者登录后的权限。
攻击预防：
1.始终生成新的会话，供用户成功认证时登录。
2.防止用户操纵会话标识。不要接受用户浏览器登录时所提供的会话标识
3.在登录按钮点击后，确认登录前，加入3行代码对Cookie进行清空已达到重置SessionId的效果。
protected void btnLogin_Click(object sender, EventArgs e)
{
//重置SessionId
Session.Clear();
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
//登录判断
if (check(txtName.Text,txtPassword.Text))
{
FormsAuthentication.SetAuthCookie("admin", false);
Response.Redirect("Default.aspx");
}
Eg：
1.登录之后未更改会话标识符值
手工验证：用fiddler抓取登录前后的包。对比两边的cookie值。如相同，则存在漏洞，如不同，则无漏洞。
整改建议：在被测应用与服务器交互过程中，不要采用登录前的cookie值，要更新。
五、CSRF漏洞
CSRF：是指跨站请求伪造，攻击者在用户未察觉的情况下，迫使用户的浏览器发起未预见的请求，其结果往往损害用户本身的利益。CSRF攻击大多利用web应用的XSS漏洞，也有很多CSRF攻击没有利用XSS而是利用了HTML标签的特性
当网站同时存在XSS、CSRF漏洞时，Token防御机制将会失效，攻击者可以通过JavaScript获取Token值
攻击预防：
1.使用post，不使用get修改信息
2.二次确认
3.Token认证
Eg：
1. 应用程序使用的认证方法不充分
手工验证：burpsuite抓包，修改包后发送，看服务器返回是否为200。若为200，则存在漏洞。
整改建议：在被测应用与服务器交互过程中，二次确认。
六、SQL注入
注入：往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行
注入漏洞分类：数字型和字符型
攻击者对数据库注入归为：
查询数据
读写文件
执行命令
防止SQL注入：
1、严格的数据类型
2、特殊字符转义
3、使用预编译语句
4、框架技术
5、存储过程
七、上传漏洞
上传漏洞与注入相比，风险更大，只要Web应用程序可以上传文件，就有可能存在文件上传漏洞
上传漏洞形成：
1.目录过滤不严，攻击者可能建立畸形目录
2.文件未重名，攻击者可能利用Web容器解析漏洞
防止上传漏洞：
客户端检测：客户端使用javascript检测，在文件未上传时，就对文件进行验证
服务器端检测：服务端脚本一般会检测文件的MIME类型，检测文件扩展名是否合法，是否嵌入恶意代码
八、已解密的登录请求
整改建议：通过SSL传输密码或用MD5加密
九、不充分的账户封锁
手工验证：在输入正确账号后，多次输入错误密码。看账号是否会被封。
整改建议：错误登录次数设置。
十、登录错误消息枚举
手工验证：输入错误登录名或密码、看系统给出的错误提示是否一样。若一样，则无该漏洞。若不同，则存在漏洞。
整改建议：将输入错误用户名或密码的提示语设置相同。