Web漏洞检测及修复
更新时间：2024.11.27Web漏洞是指以各种语言（PHP、JSP、C++等）开发的CGI/Web Service中存在的安全漏洞。
下面是漏洞的定义，检测方法以及修复方案。
1. 注入漏洞
1.1 SQL注入漏洞
名称： SQL注入漏洞（SQL Injection）
描述：Web程序代码中对于用户提交的参数未做过滤就直接放到SQL语句中执行，导致参数中的特殊字符打破了SQL语句原有逻辑，黑客可以利用该漏洞执行任意SQL语句。
检测方法：通过修改参数来判断是否存在漏洞。
修复方案：
针对ASP.NET的防XSS库，Microsoft有提供统一的方法，具体可以参见如下链接:
针对其它语言如下细分：
在代码级对带入SQL语句中的外部参数进行转义或过滤：
（1）对于整数，判断变量是否符合[0-9]的值；其他限定值，也可以进行合法性校验
（2）对于字符串，对SQL语句特殊字符进行转义(单引号转成两个单引号，双引号转成两个双引号)。关于这点，PHP有类似的转义函数mysql_escape_string和mysql_real_escape_string。
建议：
（1）使用腾讯CMEM存储方案；
（2)对与数据库进行交互的用户请求数据，要先做过滤，防止SQL注入。
1.2 XSS漏洞
名称：XSS注入漏洞（Cross-site Scripting）
描述：Web程序代码中把用户提交的参数未做过滤就直接输出到页面，参数中的特殊字符打破了HTML页面的原有逻辑，黑客可以利用该漏洞执行恶意HTML/JS代码、构造蠕虫传播、篡改页面实施钓鱼攻击等。
检测方法：通过修改参数来判断是否存在漏洞。
比如用户输入内容：’<u>a</u>”的时候，合法的显示是： ’<u>a</u>” ，合法的显示的源码是：
而存在漏洞的页面显示却是：’a”
源码是：
修复方案：
开发者应该严格按照
openid和openkey的校验规则判断openid和openkey是否合法，且判断其它参数的合法性，不合法不返回任何内容。
严格限制URL参数输入值的格式，不能包含不必要的特殊字符（ %0d、%0a、%0D 、%0A 等）。
针对ASP.NET的防XSS库，Microsoft有提供统一的库，具体可以参见如下链接
具体的js方法如下：
（1）对于用户输入的参数值展现在HTML正文中或者属性值中的情况，例如：
展现在html正文中：<a href='http://www.contoso.com'>Un-trusted input</a>
展现在属性值中：<input name="searchword" value="Un-trusted input">
此时需要将红色的不可信内容中做如下的转码(即将< > ‘ “ ` 转成html实体)：
（2）对于用户输入落在<script>的内容中的情况，例如:
需要将红色的不可信内容中做如下的转码: [a-zA-Z0-9.-_,]以及ASC值大于0x80之外的所有字符转化为\x**这种形式，例如：
1.3 命令注入漏洞
名称：命令注入漏洞（Command Injection）
描述：Web程序代码中把用户提交的参数未做过滤就直接使用shell执行，攻击者可以执行任意系统命令。
检测方法：通过修改参数来判断是否存在漏洞。
修复方案：在代码级调用shell时，对命令行中的特殊字符进行转义（|、&、；等），防止执行其他非法命令。
PHP中可使用escapeshellarg、escapeshellcmd来转义。
1.4 HTTP响应头注入漏洞
名称：HTTP响应头注入漏洞（HTTP-Response-Splitting，HTTP_header_injection）
描述：Web程序代码中把用户提交的参数未做过滤就直接输出到HTTP响应头中，攻击者可以利用该漏洞来注入HTTP响应头，可以造成xss攻击、欺骗用户下载恶意可执行文件等攻击。
另外根据国际安全组织司acunetix统计，以下apache存在header injection漏洞：1.3.34/2.0.57/2.2.1。
检测方法：通过修改参数来判断是否存在漏洞。
比如国内某著名网站曾经出现过header注入漏洞，如下url：
http://www.YYYYYYYYY.com/YYYYWeb/jsp/website/agentInvoke.jsp?agentid=%0D%0AX-foo:%20bar
抓包时发现：
修复方案：
在设置HTTP响应头的代码中，过滤回车换行（%0d%0a、%0D%0A)字符。
不采用有漏洞版本的apache服务器，同时对参数做合法性校验以及长度限制，谨慎的根据用户所传入参数做http返回包的header设置。
1.5 跳转漏洞
名称：跳转漏洞
描述：Web程序直接跳转到参数中的URL，或页面引入任意的开发者URL。
检测方法：修改参数中的合法URL为非法URL。例如测试一下如下URL：
http://***.qq.com/cgi-bin/demo_es.cgi?backurl=http://www.***.com，看是否会跳转到注入的http://www.***.com站点。
修复方案：在控制页面转向的地方校验传入的URL是否为可信域名。
例如以下是一段校验是否是腾讯域名的JS函数：
function VaildURL(sUrl)
{
return (/^(https?:\/\/)?[\w\-.]+\.(qq|paipai|soso|taotao)\.com($|\/|\\)/i).test(sUrl)||(/^[\w][\w\/\.\-_%]+$/i).test(sUrl)||(/^[\/\\][^\/\\]/i).test(sUrl) ? true : false;
}
1.6 XML注入漏洞
名称：XML注入漏洞
描述：Web程序代码中把用户提交的参数未做过滤就直接输出到XML中。
检测方法：通过修改参数来判断是否存在漏洞。
修复方案：在代码级输出时对XML特殊字符（“<”、“>”、“>]]”）进行转义。
2. 信息泄露漏洞
2.1 PHPInfo()信息泄露漏洞
名称：PHPInfo()信息泄露漏洞
描述：Web站点的某些测试页面可能会使用到PHP的phpinfo()函数，会输出服务器的关键信息。如下图所示：
检测方法：访问http://[ip]/test.php 以及http://[ip]/phpinfo.php看是否成功。
修复方案：删除该PHP文件。
2.2 测试页面泄露在外网漏洞
名称：测试页面泄露在外网漏洞
描述：一些测试页面泄露到外网，导致外界误传公司被黑客入侵。如下图所示：
http://parts.baby.qzoneapp.com/
http://parts.baby.qzoneapp.com/test.php
http://other.baby.qzoneapp.com
检测方法：检测页面内容，看是否是测试页面。
修复方案：删除测试页面，例如test.cgi，phpinfo.php，info.pho， .svn/entries等。
2.3 备份文件泄露在外网漏洞
名称：备份文件泄露在外网漏洞
描述：编辑器或者人员在编辑文件时，产生的临时文件，如vim自动保存为.swp后缀、UltrlEditor自动保存.bak后缀等，这些文件会泄露源代码或者敏感信息。如下图所示：
泄露源代码可以让黑客完全了解后台开发语言、架构、配置信息等。下图是国内某著名网站曾经出现过的源代码泄露漏洞：
检测方法：在cgi文件后面添加.bak、.swp、.old、~等后缀探测。
修复方案：删除备份文件。
2.4 版本管理工具文件信息泄露漏洞
名称：版本管理工具文件信息泄露漏洞
描述：版本管理工具SVN和CVS会在所有目录添加特殊文件，如果这些文件同步到Web目录后就会泄露路径等信息。如下图所示：
检测方法：访问http://[ip]/CVS/Entriesp 以及http://[ip]/.svn/entriesp看是否成功。
修复方案：删除SVN各目录下的.svn目录；删除CVS的CVS目录。
2.5 HTTP认证泄露漏洞
名称：HTTP认证泄露漏洞
描述：Web目录开启了HTTP Basic认证，但未做IP限制，导致攻击者可以暴力破解账号密码。如下图所示：
修复方案：限制IP访问该目录。
2.6 管理后台泄露漏洞
名称：管理后台泄露漏洞
描述：管理后台的账号和密码设计过于简单，容易被猜测到，导致攻击者可以暴力破解账号密码。如下图所示：
修复方案：
将管理后台的服务绑定到内网ip上，禁止开放在外网。
如果该管理后台必须提供给外网访问，则未登录页面不要显示过多内容，防止敏感信息泄露，登录账号需经过认证，且密码设置规则尽量复杂，增加验证码，以防止暴力破解。
2.7 泄露员工电子邮箱漏洞以及分机号码
名称：泄露员工电子邮箱漏洞以及分机号码
描述：泄露员工内部电子邮箱以及分机号码相当于泄露了员工内部ID，可以为黑客进行社会工程学攻击提供有价值的材料，同时也为黑客暴力破解后台服务提供重要的账号信息。
修复方案：删除页面注释等地方中出现腾讯员工电子邮箱以及分机号码的地方。
2.8 错误详情泄露漏洞
名称：错误详情泄露漏洞
描述：页面含有CGI处理错误的代码级别的详细信息，例如sql语句执行错误原因，php的错误行数等。
检测方法：修改参数为非法参数，看页面返回的错误信息是否泄露了过于详细的代码级别的信息。
修复方案：将错误信息对用户透明化，在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因。
3. 请求伪造漏洞
3.1 CSRF漏洞
名称：CSRF漏洞（Cross Site Request Forgery）
描述：用户以当前身份浏览到flash或者开发者网站时，JS/flash可以迫使用户浏览器向任意CGI发起请求，此请求包含用户身份标识，CGI如无限制则会以用户身份进行操作。
检测方法：
在实际的测试过程中，测试人员需要判断操作是否为保存类操作，是否强制为POST方式传输参数。
判断方式是通过抓包工具把所有的POST参数都改成GET方式提交。
需要注意的是，这种方法只可防止图片跳转式CSRF漏洞，如果页面上有XSS漏洞话，CSRF无法防御。
2.最简单的办法就是查阅该cgi是否带有无法预知的参数，例如随机字符串等。
修复方案：可使用以下任意办法防御CSRF攻击：
在表单中添加form token（隐藏域中的随机字符串）；
请求referrer验证；
关键请求使用验证码。
3.2 JSON-hijackin漏洞
名称：JSON-hijackin漏洞
描述：CGI以JSON形式输出数据，黑客控制的开发者站点以CSRF手段强迫用户浏览器请求CGI得到JSON数据，黑客可以获取敏感信息。
检测方法：
检查返回的json数据是否包含敏感信息，例如用户ID，session key，邮箱地址，手机号码，好友关系链等。
确认提交是否带有无法预知的参数，例如随机字符串等。
修复方案：可使用以下任意办法防御JSON-hijackin攻击：
在请求中添加form token（隐藏域中的随机字符串）；
请求referrer验证。
4. 权限控制漏洞
4.1 文件上传漏洞
名称：文件上传漏洞
描述：接受文件上传的Web程序未对文件类型和格式做合法性校验，导致攻击者可以上传Webshell（.php、.jsp等）或者非期望格式的文件（.jpg后缀的HTML文件）
修复方案：文件上传的CGI做到：
上传文件类型和格式校验；
上传文件以二进制形式下载，不提供直接访问。
4.2 crossdomain.xml配置不当漏洞
名称：crossdomain.xml配置不当漏洞
描述：网站根目录下的文件crossdomain.xml指明了远程flash是否可以加载当前网站的资源（图片、网页内容、flash等）。
如果配置不当，可能带来CSRF攻击。如下图所示：
检测方法：
访问http://[domain]/crossdomain.xml 修复方案：对于不需要外部加载资源的网站，crossdomain.xml中更改allow-access-from的domain属性为域名白名单。
修复大致样本参考如下（备注：示例中的app10000.qzoneapp.com,app10000.imgcache.qzoneapp.com请修改为自己指定的站点）：
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from secure="false" domain="*.qq.com"/>
<allow-access-from secure="false" domain="*.soso.com"/>
<allow-access-from secure="false" domain="*.paipai.com"/>
<allow-access-from secure="false" domain="*.gtimg.cn"/>
<allow-access-from secure="false" domain="*.pengyou.com"/>
<allow-access-from secure="false" domain="app10000.qzoneapp.com"/>
<allow-access-from secure="false" domain="app10000.imgcache.qzoneapp.com"/>
</cross-domain-policy>
4.3 flash标签配置不当漏洞
名称：flash标签配置不当漏洞
描述：网页在引入flash的时候，会通过object/embed标签，在设置的时候，如果一些属性配置不当，会带来安全问题：
allowScriptAccess：是否允许flash访问浏览器脚本。如果不对不信任的flash限制，默认会允许调用浏览器脚本，产生XSS漏洞。
always（默认值），总是允许；sameDomain，同域允许；never，不允许
2.allowNetworking：是否允许flash访问ActionScript中的网络API。如果不对不信任的flash限制，会带来flash弹窗、CSRF等问题。
all，允许所有功能，会带来flash弹窗危害；internal，可以向外发送请求/加载网页；none，无法进行任何网络相关动作（业务正常功能可能无法使用）
修复方案：对于不信任flash源，allowScriptAccess设置为never，allowNetworking设置为none（业务需要可以放宽为internal）。
4.4 embed标签配置不当漏洞
名称：embed标签配置不当漏洞
描述：网页会通过embed标签引入媒体文件（如rm、avi等视频音频），这些媒体文件中如有脚本指令（弹窗/跳转），如果没有限制就会出现安全问题。
检测方法：检查embed标签中是否有invokes标签。
修复方案：添加属性invokes值为-1。
4.5 并发漏洞
名称：并发漏洞
描述：攻击者通过并发http/tcp请求而达到次获奖、多次收获、多次获赠等非正常逻辑所能触发的效果。
下面以简化的例子说明在交易的Web应用程序中潜在的并行问题，并涉及联合储蓄账户中的两个用户（线程）都登录到同一账户试图转账的情况：
账户A有100存款，账户B有100存款。用户1和用户2都希望从账户A转10分到账户B.
如果是正确的交易的结果应该是：账户A 80分，账户B 120分。
然而由于并发性的问题，可以得到下面的结果：
用户1检查账户A （ = 100 分）
用户2检查账户A （ = 100 分）
用户2需要从账户A 拿取10 分（ = 90 分） ，并把它放在账户B （ = 110 分）
用户1需要从账户A 拿取10分（仍然认为含有100 个分）（ = 90 分） ，并把它放到B（ = 120 分）
结果：账户A 90 分，账户B 120 分。
检测方法：发送并发http/tcp请求，查看并发前后CGI 功能是否正常。例如：并发前先统计好数据，并发后再统计数据，检查2次数据是否合理。
修复方案：对数据库操作加锁。
4.6 Cookie安全性漏洞
名称：Cookie安全性漏洞
描述：cookie的属性设置不当可能会造成其他SNS游戏的运行出错等安全隐患。
检测方法：抓取数据包查看cookie的domain属性设定是否合理。
修复方案：对cookie字段的domain属性做严格的设定，openkey以及openid的domain只能设置到子域，禁止设置到父域qzoneapp.com。如下图所示：
4.7 Frame-proxy攻击漏洞
名称：Frame-proxy攻击漏洞
描述：在一些老版本浏览器（比如IE6）下，Frame-proxy攻击可以把非常驻XSS漏洞以常驻型的方式做攻击。
修复方案：qzoneapp.com域名下的应用不能再通过iframe嵌入qq.com域名下页面。
原理如下图所示，假设域名xiaoyou.qq.com底下没有任何xss漏洞，然后xiaoyou.qq.com通过iframe嵌入了一个xxx.qzoneapp.com域名。
假设qq.com的某个子域vul.qq.com存在一个非常驻的xss漏洞，那么当xxx.qzoneapp.com通过iframe嵌入vul.qq.com时，访问xiaoyou.qq.com域名的用户将受到常驻型XSS漏洞的攻击。
