Web漏洞检测及修复

更新时间：2023.08.18

Web漏洞是指以各种语言（PHP、JSP、C++等）开发的CGI/Web Service中存在的安全漏洞。下面是漏洞的定义，检测方法以及修复方案。

# 1. 注入漏洞

# 1.1 SQL注入漏洞

名称： SQL注入漏洞（SQL Injection）

描述：Web程序代码中对于用户提交的参数未做过滤就直接放到SQL语句中执行，导致参数中的特殊字符打破了SQL语句原有逻辑，黑客可以利用该漏洞执行任意SQL语句。

检测方法：通过修改参数来判断是否存在漏洞。

修复方案：

针对ASP.NET的防XSS库，Microsoft有提供统一的方法，具体可以参见如下链接:http://www.cnblogs.com/hcmfys/archive/2008/07/11/1240809.html (opens new window)
针对其它语言如下细分：在代码级对带入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的校验规则 (opens new window)判断OpenID和OpenKey是否合法，且判断其它参数的合法性，不合法不返回任何内容。
严格限制URL参数输入值的格式，不能包含不必要的特殊字符（ %0d、%0a、%0D 、%0A 等）。
针对ASP.NET的防XSS库，Microsoft有提供统一的库，具体可以参见如下链接微软官网：http://msdn.microsoft.com/en-us/library/aa973813.aspx (opens new window)

具体的js方法如下：

（1）对于用户输入的参数值展现在HTML正文中或者属性值中的情况，例如：

 展现在html正文中：&lt;a href='http://www.contoso.com'&gt;Un-trusted input&lt;/a&gt;

 展现在属性值中：&lt;input name="searchword" value="Un-trusted input"&gt;

 此时需要将红色的不可信内容中做如下的转码(即将< > ‘ “ ` 转成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= X-foo: bar (opens new window)

抓包时发现：

修复方案：

在设置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函数：

# 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 测试页面泄露在外网漏洞

名称：测试页面泄露在外网漏洞

描述：一些测试页面泄露到外网，导致外界误传公司被黑客入侵。如下图所示：

检测方法：检测页面内容，看是否是测试页面。

修复方案：删除测试页面，例如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无法防御。
最简单的办法就是查阅该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请修改为自己指定的站点）：

# 4.3 flash标签配置不当漏洞

名称：flash标签配置不当漏洞

描述：网页在引入flash的时候，会通过object/embed标签，在设置的时候，如果一些属性配置不当，会带来安全问题：

allowScriptAccess：是否允许flash访问浏览器脚本。如果不对不信任的flash限制，默认会允许调用浏览器脚本，产生XSS漏洞。 always（默认值），总是允许；sameDomain，同域允许；never，不允许
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漏洞的攻击。

文档是否有帮助

更多支持

开发者社区微信开放平台微信公众平台腾讯客服

Web漏洞检测及修复

# 1. 注入漏洞

# 1.1 SQL注入漏洞

# 1.2 XSS漏洞

# 1.3 命令注入漏洞

# 1.4 HTTP响应头注入漏洞

# 1.5 跳转漏洞

# 1.6 XML注入漏洞

# 2. 信息泄露漏洞

# 2.1 PHPInfo()信息泄露漏洞

# 2.2 测试页面泄露在外网漏洞

# 2.3 备份文件泄露在外网漏洞

# 2.4 版本管理工具文件信息泄露漏洞

# 2.5 HTTP认证泄露漏洞

# 2.6 管理后台泄露漏洞

# 2.7 泄露员工电子邮箱漏洞以及分机号码

# 2.8 错误详情泄露漏洞

# 3. 请求伪造漏洞

# 3.1 CSRF漏洞

# 3.2 JSON-hijackin漏洞

# 4. 权限控制漏洞

# 4.1 文件上传漏洞

# 4.2 crossdomain.xml配置不当漏洞

# 4.3 flash标签配置不当漏洞

# 4.4 embed标签配置不当漏洞

# 4.5 并发漏洞

# 4.6 Cookie安全性漏洞

# 4.7 Frame-proxy攻击漏洞

关于我们

服务支持

友情链接

客服帮助