常见WEB安全漏洞及整改建议

常见WEB安全漏洞及整改建议1.HTML表单没有CSRF保护1.1问题描述：

CSRF（Cross-siterequestforgery），中文名称：跨站请求伪造，也被称为：oneclickattack/sessionriding，缩写为：CSRF/XSRF。

CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。1.2整改建议：

CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。有以下三种方法：

(1).CookieHashing(所有表单都包含同一个伪随机值)：

(2).验证码

(3).One-TimeTokens(不同的表单包含一个不同的伪随机值)1.3案例：

1.服务端进行CSRF防御

服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。1.3.1CookieHashing(所有表单都包含同一个伪随机值)：

这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败.

//构造加密的Cookie信息

$value=“DefenseSCRF”;

setcookie(”cookie”,$value,time()+3600);

?>

在表单里增加Hash值，以认证这确实是用户发送的请求。

$hash=md5($_COOKIE['cookie']);

?>

”>

然后在服务器端进行Hash值验证

if(isset($_POST['check'])){

$hash=md5($_COOKIE['cookie']);

if($_POST['check']==$hash){

doJob();

}else{

//…

}

}else{

//…

}

?>

这个方法已经可以杜绝99%的CSRF攻击了，那还有1%….由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。1.3.2验证码

这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，这个方案可以完全解决CSRF，但在易用性方面似乎不是太好，还有是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。1.3.3One-TimeTokens(不同的表单包含一个不同的伪随机值)

在实现One-TimeTokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。

以下实现:

1).先是令牌生成函数(gen_token())：

functiongen_token(){

//这是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。

//这个可以参考写的Findbugs笔记中的《Randomobjectcreatedandusedonlyonce》

$token=md5(uniqid(rand(),true));

return$token;

}

2).然后是Session令牌生成函数(gen_stoken())：

functiongen_stoken(){

$pToken=“”;

if($_SESSION[STOKEN_NAME]==$pToken){

//没有值，赋新值

$_SESSION[STOKEN_NAME]=gen_token();

}

else{

//继续使用旧的值

}

}

?>

3).WEB表单生成隐藏输入域的函数：

functiongen_input(){

gen_stoken();

echo“<=""p=""style="padding:0px;margin:0px;font-size:12px;font-family:宋体;">

value=\””.$_SESSION[STOKEN_NAME].“\”>“;

}

?>

4).WEB表单结构：

session_start();

include(”functions.php”);

?>

5).服务端核对令牌：2.jQuery跨站脚本漏洞2.1问题描述

jQuery是继prototype之后又一个优秀的Javascrīpt框架。

jQuery1.6.3之前版本中存在跨站脚本漏洞。当使用location.hash选择元素时，通过特制的标签，远程攻击者利用该漏洞注入任意web脚本或HTML。2.2整改方法

目前厂商已经发布了升级补丁以修复此安全问题，补丁获取链接：

/usn/USN-1722-1/2.3整改案例

升级jQuery版本。3.跨站脚本编制3.1问题描述：

跨站脚本攻击是通过在网页中加入恶意代码，当访问者浏览网页时恶意代码会被执行或者通过给管理员发信息的方式诱使管理员浏览，从而获得管理员权限，控制整个网站。攻击者利用跨站请求伪造能够轻松地强迫用户的浏览器发出非故意的HTTP请求，如诈骗性的电汇请求、修改口令和下载非法的内容等请求。

风险等级：高

风险范围：

任何存在输入/输出方法（包括GET与POST）的页面皆可能存在恶意符号输入缺陷，主要影响应用包括留言板、在线通讯信息、文章发布页面等。3.2整改建议：

对用户输入的参数执行严格检测：

1、对产生漏洞模块的传入参数进行有效性检测。int类型的只允许0-9的整型数字；string等字符类型的只允许(1-9，a-z，A-Z)的英文字母；

2、当客户端输入限定值意外的字符后，立即转向自定义的错误页，而不能使用服务器默认的错误输出方式；

3、对穿入参数进行危险字符过滤，禁止('、"、+、%、&、<>、（）、;、,.等)特殊字符的传入。3.3案例：

加固范例（一）：

/*将login.jsp中[Stringu=request.getParameter("u");]替换为如下内容：*/

Stringu=request.getParameter("u");

u=u.replace('＜','_');

u=u.replace('＞','_');

u=u.replace('"','_');

u=u.replace('\'','_');

u=u.replace('%','_');

u=u.replace(';','_');

u=u.replace('(','_');

u=u.replace(')','_');

u=u.replace('&','_');

u=u.replace('+','_');

加固范例（二）：

/*更积极的方式是利用正则表达式只允许输入指定的字符：*/

/*在[Stringu=request.getParameter("u");]后代入以下isValidInput函数作辨别*/

publicbooleanisValidInput(Stringstr)

{

if(str.matches("[a-z0-9]+"))returntrue;

elsereturnfalse;

}4.URL重定向钓鱼4.13.1问题描述：

通过构建URL，攻击者可以使用户重定向到任意URL，利用这个漏洞可以诱使用户访问某个页面，挂马、密码记录、下载任意文件等，常被用来钓鱼。4.23.2整改建议：

对输入参数进行做处理，建议过滤出所有以下字符：

[1]|（竖线符号）

[2]&（&符号）

[3];（分号）

[4]$（美元符号）

[5]%（百分比符号）

[6]@（at符号）

[7]'（单引号）

[8]"（引号）

[9]\'（反斜杠转义单引号）

[10]\"（反斜杠转义引号）

[11]<>（尖括号）

[12]()（括号）

[13]+（加号）

[14]CR（回车符，ASCII0x0d）

[15]LF（换行，ASCII0x0a）

[16],（逗号）

[17]\（反斜杠）4.33.3案例：

对输入参数进行做处理。

加固范例（一）：

/*将login.jsp中[Stringu=request.getParameter("u");]替换为如下内容：*/

Stringu=request.getParameter("u");

u=u.replace('＜','_');

u=u.replace('＞','_');

u=u.replace('"','_');

u=u.replace('\'','_');

u=u.replace('%','_');

u=u.replace(';','_');

u=u.replace('(','_');

u=u.replace(')','_');

u=u.replace('&','_');

u=u.replace('+','_');

加固范例（二）：

/*更积极的方式是利用正则表达式只允许输入指定的字符：*/

/*在[Stringu=request.getParameter("u");]后代入以下isValidInput函数作辨别*/

publicbooleanisValidInput(Stringstr)

{

if(str.matches("[a-z0-9]+"))returntrue;

elsereturnfalse;

}5.不安全存储5.1问题描述

不安全存储，在页面上显示密码。5.2整改建议

加密密码或不在页面及源码上显示密码。5.3案例

一切涉及敏感信息读写操作的页面，如登陆页面、登陆处理页面等。

风险范例：

/*Add_user.jsp*/

Stringsql;

sql="insertintouser(username,password)values("+Username+","+Password+")";

Statementsm=cn.createStatement();

sm.executeUpdate(sql);

sm.close();

加固范例：

/*在生成sql变量内容前加入对Password变量的加密处理：*/

<%@pageimport="java.security.*"%>

<%@pageimport="java.util.*"%>

…

publicStringbyte2hex(byte[]b)//二行制转字符串

{

Stringhs="";

Stringstmp="";

for(intn=0;n<b.length;n++)<p="">

{

stmp=(java.lang.Integer.toHexString(b[n]&0XFF));

if(stmp.length()==1)hs=hs+"0"+stmp;

elsehs=hs+stmp;

//if(n<b.length-1)hs="hs+":";</p">

}

returnhs.toUpperCase();

}

…

java.security.MessageDigestalg=java.security.MessageDigest.getInstance("SHA-256");

alg.update(Password.getBytes());

byte[]digest=alg.digest();

Password=byte2hex(digest);6.错误的页面信息6.1问题描述：

错误/警告消息，可能会泄露敏感信息。6.2整改建议：

在编码阶段开发者对敏感页面缺乏授权保护，导致相关URL页面敏感信息泄露。建议修改错误信息。

一切敏感或需要权限方可浏览的页面，包括：敏感信息中转处理页面、上传页面、管理平台页面、用户自管理页面等。6.3案例：

风险范例：

/*风险范例为一切需要敏感但编码阶段没有进行授权鉴别的页面*/

加固范例：

if((session.getValue("UserName")==null)||(session.getValue("UserClass")==null)||(!session.getValue("UserClass").equals("系统管理员")))

{

response.sendRedirect("err.jsp?id=14");

return;

}7.已解密的登陆请求7.1问题描述：

用户名、密码输入字段未经加密即进行了传递。7.2整改建议：

确保所有登录请求都以https加密方式发送到服务器。7.3案例：

方法一：配置SSL加密传输

【概念理解】keystore是一个密码保护的文件，用来存储密钥和证书

(1)生成一个keystore文件（包含证书），文件位置/usr/local/tomcat/conf/.keystore

#cd/usr/local/jdk/bin/

#./keytool-genkey-alias

tomcat

-keyalgRSA-keystore/usr/local/tomcat/conf/.keystore

输入密码、提供你的信息即可。如果不是用来“玩”的话，请如实的填写自己以及单位的信息吧。

【注意】它会在前后问你两次密码，第二次直接回车就行了，如果两个密码不一样，将会出现java.io.IOException错误。详情请见：[url]/bugzilla/show_bug.cgi?id=38217[/url]

(2)修改tomcat/conf/server.xml

启用这一段：

<=""p="">

maxThreads="150"scheme="https"secure="true"

clientAuth="false"sslProtocol="TLS"/>

并修改为：

<=""p="">

maxThreads="150"scheme="https"secure="true"

keystoreFile="/usr/local/tomcat/conf/.keystore"

keystorePass="snailwarrior"

clientAuth="false"sslProtocol="TLS"/>

(3)重启Tomcat

#/usr/local/tomcat/bin/shutdown.sh

#/usr/local/tomcat/bin/startup.sh

(4)防火墙开启8443端口

浏览器输入：[url]0:8443/[/url]

方法二：把text="password"这个用其他的代替，就可以解决已解密的登录请求，仅共参考

·密

码：<=""p=""style="padding:0px;margin:0px;font-size:12px;font-family:宋体;width:146px;height:18px;">

nkeypress="javascript：hiddenPass(event)"onkeyup="this.value=this.value.replace(/./g,'*');"/>·

·

js代码

functionhiddenPass(e){

e=e?e:window.event;

varkcode=e.which?e.which:e.keyCode;

varpass=document.getElementByIdx_x("password1");

varj_pass=document.getElementByIdx_x("password");

if(kcode!=8)

{

varkeychar=String.fromCharCode(kcode);

j_pass.value=j_pass.value+keychar;

j_pass.value=j_pass.value.substring(0,pass.length);

}

}

获取密码：document.getElementByIdx_x("password").value;8.HTTP拒绝服务8.1问题描述

HTTP存在DOS漏洞。

如果远程攻击者使用发包工具向Apache服务器发送了不完整的HTTP请求，服务器会打开连接等待接受完整的头，但如果发包工具不再继续发送完整请求而是发送无效头的话，就会一直保持打开的连接。这种攻击所造成的影响很严重，因为攻击者不需要发送很大的通讯就可以耗尽服务器上的可用连接。也就是说，即使低带宽的用户也可以攻击大流量的服务器。8.2整改方法

临时解决方法：

更改默认的TimeOut选项少于7000ms，或使用mod_limitipconn模块限制单个IP地址的连接数。

厂商补丁：

ApacheGroup

目前厂商还没有提供补丁或者升级程序，我们建议使用此软件的用户随时关注厂商的主页以获取最新版本：8.3案例

关于HTTP版本低漏洞信息，如下：

1）.漏洞的描述

/NewsInfo/124/17205.Html

2）.TOMCAT官网说这个不是一个漏洞，没有打算出补丁，只有缓解方法

详细可以看，

http:///security-6.html#Not_a_vulnerability_in_Tomcat

查找CVE-2012-5568会看到官网说明。

缓解方法

通过server.xml内定义的连接器的connectionTimeout属性，配置一个合适的超时时间。

/jyrivirkki/entry/web_server_7_meets_slowloris

3）.但CVE的漏洞还是所有版本也存在。下面是一个CVE的详细信息地址，此页面最后更新为2013-03-07，当时6.0.35为最新版本。

/cve-details.php?t=1&cve_id=CVE-2012-5568

4）.公开的漏洞测试代码

/slowloris/slowloris.pl9.跨站点请求伪造

同“1.HTML表单没有CSRF保护”。10.应用程序错误信息

同“6.错误的页面信息”11.SQL注入11.1问题描述

受外部影响的输入来构造SQL命令的全部或一部分，但是它对可能在所需SQL命令发送到数据库时修改该命令的特殊元素未正确进行无害化处理。如果在用户可控制的输入中没有对SQL语法充分地除去或引用，那么生成的SQL查询可能会导致将这些输入解释为SQL而不是普通用户数据。这可用于修改查询逻辑以绕过安全性检查，或者插入其他用于修改后端数据库的语句，并可能包括执行系统命令。11.2整改建议

publicstaticStringfilterContent(Stringcontent){

Stringflt="'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,";

Stringfilter[]=flt.split("|");

for(inti=0;i<=""p="">

{

content.replace(filter[i],"");

}

returncontent;

}

参考信息：/index.php/Top_10_2010-A112.HTTP版本过低12.1问题描述

Apache/IIS等版本过低存在众多安全漏洞。12.2整改建议

升级Apache/IIS等到最新版本。13.微软IIS波状目录枚举13.1问题描述

攻击者可以利用“~”字符猜解或遍历服务器中的文件名，或对IIS服务器中的.NetFramework进行拒绝服务攻击。13.2整改建议

升级netframework至4.0以上版本。14.未加密的__VIEWSTATE的参数14.1问题描述

可能会收集有关Web应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置。14.2整改建议

在Web.Config文件的

元素之下，添加下面这一行：

15.Unicode转换问题15.1问题描述

Unicode编码未指定15.2整改建议

在源码内指定编码类型即可解决如：UTF-816.证书泄漏16.1问题描述

发现SSL证书信息16.2整改建议

使用公认第三方如CA的签名证书。17.目录列表17.1问题描述

可能会查看和下载特定Web应用程序虚拟目录的内容，其中可能包含受限文件。17.2整改建议

[1]将Web服务器配置成拒绝列出目录。

[2]根据Web服务器或Web应用程序上现有的问题来下载特定安全补丁。部分已知的目录列表问题列在这个咨询的“引用”字段中。

[3]利用“CERT”咨询中的变通方法（在这项咨询的“引用”字段中）来修订短文件名（8.3DOS格式）问题：

a.想要完全由Web服务器来保护的文件仅用8.3标准短文件名。在FAT文件系统（16位）上，您可以启用“Win31FileSystem”注册表键（设为1，注册表路径：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\）来强制这一点。

b.在NTFS（32位）上，您可以启用“NtfsDisable8dot3NameCreation”注册表键（设为1，注册表路径：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\）来禁用创建长文件名文件的8.3标准短文件名。不过，这个步骤可能会引起与16位应用程序的兼容性问题。

c.使用基于NTFS的ACL（目录或文件级别的访问控制表）来扩增或替换基于Web服务器的安全。18.备份文件18.1问题描述

存在不必要的备份残留文件，可能会被信息采集进入步深入渗透。18.2整改建议

删除不必要的备份文件。19.ASP.NETpaddingoracl攻击19.1问题描述

使用.NETFramework所编译的ASP.Net应用中没有正确地实现加密，攻击者可以解密并篡改敏感数据。

如果要理解这个漏洞，首先要了解加密系统中的提示机制，当你提出问题时提示机制会给出某种形式的答案。此漏洞涉及到ASP.NET对加密信息中填充数据的提示，攻击者可以通过向Web服务器发送特定的密文文本，然后通过检查所返回的出错代码来判断数据是否被正确解密。通过反复上述操作，攻击者就可以收集到足够的信息用来解密剩余部分的密文文本。19.2整改建议

打上MS10-070漏洞补丁。20.用户得凭证信息以明文发送20.1问题描述

不安全明文传输登录请求。20.2整改建议

使用SSL加密。21.Web应用防火墙检测从HTTPHTTPS后不安全的过渡形式21.1问题描述

不安全明文传输方式。21.2整改建议

使用所以页面通过SSL加密。22.struts2漏洞22.1问题描述

struts2框架版本过低，存在远程任意命令执行漏洞。22.2整改建议

升级struts2框架到最新版本。23.弱口令23.1问题描述

使用如：123456、test等弱口令。23.2整改建议

按电信密码规范要求配置口令。24.文件包含24.1问题描述

可能会在Web服务器上运行远程命令。这通常意味着完全破坏服务器及其内容。24.2整改建议

假定所有输入都是恶意的。使用“接受已知善意”输入验证策略：严格遵守规范的可接受输入的白名单。拒绝任何没有严格遵守规范的输入，或者将其转换为遵守规范的内容。不要完全依赖于将恶意或格式错误的输入加入黑名单。但是，黑名单可帮助检测潜在攻击，或者确定哪些输入格式不正确，以致应当将其彻底拒绝。

执行输入验证时，请考虑所有潜在相关属性，包括长度、输入类型、可接受值的完整范围、缺失或多余输入、语法、跨相关字段的一致性以及业务规则一致性。以业务规则逻辑为例，“boat”可能在语法上有效，因为它仅包含字母数字字符，但如果预期为颜色（如“red”或“blue”），那么它无效。

对于文件名，请使用限制要使用的字符集的严格白名单。如果可行，请仅允许文件名中出现单个“.”字符以避免CWE-23之类的弱点，并排除“/”之类的目录分隔符以避免CWE-36。请使用允许的文件扩展名的白名单，这有助于避免CWE-434。25.源代码暴露25.1问题描述

源代码暴露。25.2整改建议

删除源代码文件或对需要的未解析的源代码进行解析。26.SSL证书无效26.1问题描述

SSL证书过期或SSL证书不合法等。26.2整改建议

重新生成配置SSL证书。27.SSL加密方式弱27.1问题描述

SSL证书加密方式弱，导致加密信息可能被解密。27.2整改建议

重新生成SSL证书，加密算法选择如：RSA-1024等。28.Http请求头的额外的回车换行符注入28.1问题描述

攻击者可能注入自定义HTTP头。例如，攻击者可以注入会话cookie或HTML代码。这可能会进行类似的XSS(跨站点脚本)或会话固定漏洞。28.2整改建议

这种现象往往表现在带有参数传递的网页，只要合理的过滤好就OK啦，提供PHP代码：

$post=trim($post);

2$post=strip_tags($post,"");//清除HTML如

等代码

3$post=ereg_replace("\t","",$post);//去掉制表符号

4$post=ereg_replace("\r\n","",$post);//去掉回车换行符号

5$post=ereg_replace("\r","",$post);//去掉回车

6$post=ereg_replace("\n","",$post);//去掉换行

7$post=ereg_replace("","",$post);//去掉空格

8$post=ereg_replace("'","",$post);//去掉单引号29.CRLF注入/HTTP响应拆分

同上：Http请求头的额外的回车换行符注入。30.MBean提交密码字段中使用GET方法30.1问题描述

使用GET方法MBean提交密码字段。30.2整改建议

更改为POST提交方法。31.JBoss类漏洞31.1问题描述

发现JBoss框架登录管理后台等信息。31.2整改建议

限制JBOSS控制台等目录访问权限。32.ApacheTomcat版本低32.1问题描述

ApacheTomcat版本过低32.2整改建议

升级ApacheTomcat到最新版本。33.ApacheTomcat类漏洞33.1问题描述

发现存在ApacheTomcat的示例文件、控制台等信息。33.2整改建议

删除ApacheTomcat的示例文件及控制台相关文件。34.临时应急加固方法35.非公众访问类35.1问题描述

发现系统、数据库类等漏洞没法加固或暂时无法加固。35.2整改建议

关闭不必要的应用或使用系统防火墙限制非公众使用的端口进行来源绑定访问。36.WEB类36.1问题描述

发现XSS、SQL等漏洞的应急加固办法。36.2整改建议

apachecommons-lang工具包里的类，可以在工程中写一个过滤器，使用该工具类去实现敏感字符的过滤。

过滤器示例1参考地址：/mousai/blog/88832

过滤器示例2如下：

使用JAVA过滤器对攻击特征进行过滤如：

一。写一个过滤器

代码如下：

packagecom.liufeng.sys.filter;

importjava.io.IOException;

importjava.io.PrintWriter;

importjavax.servlet.Filter;

importjavax.servlet.FilterChain;

importjavax.servlet.FilterConfig;

importjavax.servlet.ServletException;

importjavax.servlet.ServletRequest;

importjavax.servlet.ServletResponse;

importjavax.servlet.http.HttpServletRequest;

importjavax.servlet.http.HttpServletResponse;

publicclassIllegalCharacterFilterimplementsFilter{

privateString[]characterParams=null;

privatebooleanK=true;

publicvoiddestroy(){

//T