web端常见安全漏洞测试结果分析-- appscan

基于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加密

九、不充分的账户封锁

手工验证：在输入正确账号后，多次输入错误密码。看账号是否会被封。

整改建议：错误登录次数设置。

十、登录错误消息枚举

手工验证：输入错误登录名或密码、看系统给出的错误提示是否一样。若一样，则无该漏洞。若不同，则存在漏洞。

整改建议：将输入错误用户名或密码的提示语设置相同。