网站漏洞处理经验总结

最近本人在兰州理工大学制作了几个二级网站。但是最近甘肃省教育厅对于各大高校的网络安全问题十分重视,要求必须解决掉网站的高危漏洞。本人web应用虽然做了不少,但是没有这么系统地修改过安全漏洞问题。在修改过程中,我们使用的软件是:

  • 安全漏洞检测软件:绿盟网站安全检测系统
  • 网络攻击模拟软件: burpsuite

以下将遇到的问题和解决方案整理罗列如下:

一. apache服务器配置相关高危漏洞

1.目标服务器启用了TRACE方法

详细描述 TRACE方法是HTTP(超文本传输)协议定义的一种协议调试方法,该方法使得服务器原样返回任何客户端请求的内容。
启用TRACE方法存在如下风险:
1、恶意攻击者可以通过TRACE方法返回的信息了解到网站前端的某些信息,如缓存服务器等,从而为进一步的攻击提供便利。
2、恶意攻击者可以通过TRACE方法进行XSS攻击。
3、即使网站对关键页面启用了HttpOnly头标记和禁止脚本读取cookie信息,但是通过TRACE 方法恶意攻击者还是可以绕过这个限制读取到cookie信息。
解决办法 1、2.0.55以上的Apache服务器,在httpd.conf的尾部添加:TraceEnable off。
2、如果使用的是Apache:
- 确认rewrite模块激活(httpd.conf,下面一行前面没有#):
LoadModule rewrite_module modules/mod_rewrite.so
- 在各虚拟主机的配置文件里添加如下语句:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

2. SSLv3存在严重设计缺陷漏洞(CVE-2014-3566)

此漏洞是我们部署https协议导致的。本想用https增加安全性,谁知因此被检测出更多漏洞。

详细描述 SSLv3漏洞(CVE-2014-3566),该漏洞贯穿于所有的SSLv3版本中,利用该漏洞,黑客可以通过中间人攻击等类似的方式(只要劫持到的数据加密两端均使用SSL3.0),便可以成功获取到传输数据(例如cookies)。
针对此漏洞,需要服务器端和客户端均停用SSLv3协议。
解决办法 临时解决办法:
修改apache配置文件,使其不支持SSLv3协议:
/etc/apache2/vhosts.d/00_default_ssl_vhost.conf
在SSLCipherSuite HIGH:!ADH:!aNULL
上面添加:
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
保存后,重启apache。

3. SSL/TLS存在Bar Mitzvah Attack漏洞

此漏洞是我们部署https协议导致的。本想用https增加安全性,谁知因此被检测出更多漏洞。

详细描述 该漏洞是由功能较弱而且已经过时的RC4加密算法中一个问题所导致的。它能够在某些情况下泄露SSL/TLS加密流量中的密文,从而将账户用户名密码、信用卡数据和其他敏感信息泄露给黑客。
解决办法 详细解决方案:http://www.freebuf.com/articles/network/62442.html 

1、服务器端禁止使用RC4加密算法。
2、客户端应在浏览器TLS配置中禁止RC4。

具体到apache服务器配置上,应该打开配置文件

$ sudo vi /etc/httpd/conf.d/ssl.conf

修改配置后重启apache

SSLCipherSuite
HIGH:MEDIUM:!aNULL:!MD5;!RC4
$ sudo /etc/init.d/httpd restart

二、代码相关高危漏洞

本人自己写的web应用都采用了参数化查询、输入验证等内容,可以避免大多数代码漏洞。但是使用第三方开源CMS系统搭建的网站就不一定了。需要通过更新网站代码版本,或者修改网站代码解决。

1.目标URL跨站漏洞

目标URL跨站脚本注入漏洞是常见的代码注入类漏洞。在我们使用第三方开源CMS系统搭建的网站中出现。后经过CMS系统升级后解决。

详细描述 跨站脚本攻击(也称为XSS)指利用网站漏洞从用户那里恶意盗取信息。用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时,通常会点击其中的链接。攻击者通过在链接中插入恶意代码,就能够盗取用户信息或在终端用户系统上执行恶意代码。
解决办法 要防止黑客在URL或者其他输入框中输入能够注入执行的HTML代码。为此,要在代码层面仔细验证所有URL输入和正确编码所有输出。具体措施如下: 

  • 定义允许的内容。确保web应用对所有输入参数(cookies、头、查询字符串、表单、隐藏字段等)验证严格定义的预期结果。
  • 检查POST和GET请求的响应,确保返回内容是预期的且有效。
  • 通过编码用户提供的数据从用户输入中删除冲突字符、括号、单双引号。这可以防范以可执行的方式向终端用户发送注入的脚本。
  • 如果必须允许站点用户使用HTML标签,如允许用户使用的格式化标签的公告栏,则应限制可使用的标签。创建可接受标签的列表,如粗体字、斜体字或下划线,并仅允许使用这些,拒绝任何其他标签。以下是一些可帮助检测跨站脚本的正则表达式。

简单跨站脚本攻击的正则表达式:
/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/ix

测试案例
  1. 构造URL:
  2. http://IP地址/index.php/article/c37.html?'%20onmouseover=dfbhmg(6464)%20 ;
  3. 设置参数 为 '%20onmouseover=dfbhmg(6464)%20 ;
  4. 在响应头及响应内容中匹配: onmouseover.*?dfbhmg(6464) 。
  5. 如果浏览器能够执行注入代码,则认为存在该漏洞。

2. sql注入漏洞

sql注入是常见的代码注入类漏洞。在我们使用第三方开源CMS系统搭建的网站中出现。后经过CMS系统升级后解决。

详细描述 本漏洞属于Web应用安全中的常见漏洞,属于OWASP TOP 10 (2007)中的注入类漏洞。 

很多WEB应用中都存在SQL注入漏洞。SQL注入是一种攻击者利用代码缺陷进行攻击的方式,可在任何能够影响数据库查询的应用程序参数中利用。例如url本身的参数、post数据或cookie值。

正常的SQL注入攻击很大程度上取决于攻击者使用从错误消息所获得信息。但是,即使没有显示错误消息应用程序仍可能受SQL注入的影响。

总体上讲,SQL注入是对web应用而不是对web服务器或操作系统本身的攻击。正如其名称所示,SQL注入是对查询添加非预期SQL命令从而以数据库管理员或开发人员非预期的方式操控数据库的行为。如果成功的话,就可以获得、修改、注入或删除有漏洞web应用所使用数据库服务器的数据。在某些环境下,可利用SQL注入完全控制系统。

解决办法 防护建议包括部署分层安全措施(包括在接受用户输入时使用参数化的查询)、确保应用程序仅使用预期的数据加固数据库服务器防止不恰当的访问数据。 

参数化查询:COOKIE注入源于攻击者控制查询数据以修改查询逻辑,因此防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔,这可以防止执行从用户输入所注入的命令。这种方式的缺陷是可能对性能产生影响(但影响很小),且必须以这种方式构建站点上的每个查询才能完全有效。只要无意中绕过了一个查询,就足以导致应用受COOKIE注入的影响。以下代码显示的是可以进行COOKIE注入的COOKIE语句示例:
$name=$_COOKIE['name'];
$sql="select * from tables where name='$name'";
下面的例子使用了参数化的查询,不受SQL注入攻击的影响
$name=$_COOKIE['name'];
$mysqli=new mysqli("localhost", "user", "pass", "database");
$stmt=$mysqli->prepare("select * from tables where name=?");
$stmt->bind_param("s", $name);
$stmt->execute();

验证输入:可通过正确验证用户输入的类型和格式防范大多数SQL注入攻击,最佳方式是通过白名单,定义方法为对于相关的字段只接受特定的帐号号码或帐号类型,或对于其他仅接受英文字母表的整数或字母。很多开发人员都试图使用黑名单字符或转义的方式验证输入。总体上讲,这种方式通过在恶意数据前添加转义字符来拒绝已知的恶意数据,如单引号,这样之后的项就可以用作文字值。这种方式没有白名单有效,因为不可能事先知道所有形式的恶意数据。 过滤sql字符的正则表达式罗列如下:

  • 删除SQL元字符的正则表达式:/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
  • 传统SQL注入攻击的正则表达式:/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
  • 删除有UNION关键字的SQL注入攻击的正则表达式:/((\%27)|(\'))union/ix(\%27)|(\')
  • 可为其他的SQL查询(如select、insert、update、delete、drop等)编写类似的正则表达式。
  • 在MS SQL服务器上检测SQL注入攻击的正则表达式:/exec(\s|\+)+(s|x)p\w+/ix

3. 系统命令注入漏洞

这是一个类似sql注入的漏洞。主要是在http请求的参数中加入一些系统命令。如果web应用没有对http请求参数做很好的过滤,那么有可能执行这些注入命令。

详细描述 应用程序为了和操作系统交互需要调用系统命令并返回执行结果。如果应用程序接收用户输入而没有做充分过滤便执行系统命令,导致攻击者可以以当前用户权限执行任意系统命令。
解决办法 对http请求的参数做白名单过滤,例如下面的代码中,只允许http参数device有desktop和mobile两个值,其他值都作为非法请求作废:
if(isset($_GET['device'])){
$device = $_GET['device'];
if($device !='desktop' && $device != 'mobile')
die;
$app -> clientDevice = $device;
}
测试样例 1、构造URL: http://202.201.39.48/index.php/search-index-/.htpasswd ;
2、设置请求参数 device 为: ;ping -c 26 127.0.0.1; ;
3、修改所ping次数,如ping 16 , ping 26 ;
4、查看多次响应所耗费的时间之差是不是 10 。

三、apache相关中危漏洞

apache http server本身的一些漏洞,可以通过升级apache或者去apache官网下载安装补丁解决。

  Apache HTTP Server日志内终端转义序列命令注入漏洞(CVE-2013-1862)
  Apache Portable Runtime和HTTP Server 'fnmatch()'栈消耗漏洞(CVE-2011-0419)
  Apache HTTP Server mod_proxy反向代理模式安全限制绕过漏洞
  Apache HTTP Server远程拒绝服务漏洞(CVE-2013-1896)
  Apache HTTP Server balancer_handler函数跨站脚本漏洞
  Apache HTTP Server Scoreboard本地安全限制绕过漏洞
  Apache mod_proxy_http模块超时处理信息泄露漏洞
  Apache HTTP Server mod_cache和mod_dav模块远程拒绝服务漏洞(CVE-2010-1452)
  Apache HTTP Server mod_proxy_ajp模块拒绝服务漏洞
  Apache HTTP Server多个拒绝服务漏洞(CVE-2013-6438)
  Apache HTTP Server mod_lua模块输入验证漏洞(CVE-2015-0228)
  Apache HTTP Server多个模块主机名和URI跨站脚本漏洞(CVE-2012-3499)
  Apache HTTP Server “ap_pregsub()”函数本地权限提升漏洞
  Apache HTTP Server mod_proxy_ajp拒绝服务漏洞
 Apache HTTP Server多个拒绝服务漏洞(CVE-2014-0098)