最近碰到的一些WEB安全问题
近来paperen总想写点东西但又写不出来，每月一篇还真"月经"似的……最近对公司的WEB项目进行一些安全测试，又提及到一些WEB安全的问题，改了那个烂摊子差不多半年了才终于来到了安全测试的份上，阿叔用了不少软件来检测这个web项目，结果正如paperen想象中一样，N多漏洞提示。之前的代码写得确实不太严谨呢，对一些参数就明显没有过滤，这样导致的问题会比较严重，比如一个叫Cross Site Scripting的漏洞(就是一个能注入javascript的漏洞无论在URL还是提交的表单里面注入)，严重的是SQL Inject漏洞(sql注入是在参数中构造特殊的字符串从而爆出数据库重要信息或者能执行一些危险的操作)，除了程序本身导致的漏洞外还有一些服务器配置的漏洞也需要修复，但是60%的漏洞主要是由程序导致的，这确实是程序员要明白的，一个好的web程序不应该只是从可运行性上去分析，重视质量你会得到更多。
阿叔使用了好几个测试工具，其实测试出来的结果基本都是差不多的，以下的漏洞主要是使用一个叫iiscan(亿思公司的)的来扫描站点得到的漏洞报告，还是蛮不错的。
在此说下碰到的几个漏洞。
1.Cross Site Scripting(红色漏洞)
跨站脚本漏洞，即XSS，通常用Javascript语言描述，它允许攻击者发送恶意代码给另一个用户。因为浏览器无法识别脚本是否可信，跨站漏洞脚本便运行并让攻击者获取其他用户的cookie或session。
如果觉得听起来貌似有点让人摸不着头脑，不妨可以思考一下paperen下面写的一个页面。
<?php
setcookie('test', 1234);
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>How to use Css</title>
</head>
<body>
<script type="text/javascript">
var yourcookie = document.cookie
alert(yourcookie);
//您可以使用ajax将cookie传送到另一个地方接收从而偷取了相关的信息
</script>
</body>
</html>
或者您会想怎么可能会让入侵者在文件中放入这样一段JS呢？想想你站点上的表单任何允许信息提交的地方。
<?php
setcookie('test', 1234);
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>How to use Css</title>
</head>
<body>
<?php
$username = isset( $_POST['username'] ) ? $_POST['username'] : '';
echo $username;
?>
<form method="post" action="">
<p><input type="text" name="username" style="width:300px;padding:3px;" /> <input type="submit" value="提交" /></p>
</form>
<!-- 试试在提交中输入再提交看看<script>var yourcookie = document.cookie;alert(yourcookie);</script> -->
</body>
</html>
如果这里的username数据是要存入数据库的话可想而知能执行这段script的地方就不只局限在本页面了，任何查看到这个username的地方都会执行这段script。您在想想如果您是管理员登陆了后台并记录了cookie作为身份验证的标志，然后查看能显示这个username的信息的页面时，就不知不觉间泄漏了自己的cookie信息了。这段js可以使用ajax向其他地方传输一些数据从而实现了入侵者的目的。
很明显这个漏洞是由程序没对提交的信息进行过滤造成的，其实php中内置的好几个函数就可以对数据进行过滤htmlspecialchars，htmlentities，干脆点的就用strip_tags。将接收数据的地方稍微一改就可以了。
$username = isset( $_POST['username'] ) ? htmlspecialchars( $_POST['username'] ) : '';
当然你可以在站点初始化时使用一个迭代将所有的全局变量$_GET,$_POST进行一下过滤。
function shtmlspecialchars($string) {
if(!is_array($string)) return htmlspecialchars($string);
foreach($string as $key => $val) $string[$key]=shtmlspecialchars($val);
return $string;
}
$_GET = shtmlspecialchars($_GET);
$_POST = shtmlspecialchars($_POST);
但是对GET与POST全局变量进行过滤需要根据自己需求弄吧，有时候如果有个编辑板的话可能就不需要对html过滤，不过也可以过滤一下存数据库在输出的时候再使用htmlspecialchars_decode或者html_entity_decode还原回来。反正自己看着办吧。
2.PHPSESSID session fixation(黄色漏洞)
通过注入一个客户的PHPSESSID就可能修改PHP session cookie.通常攻击者会操作cookie值去通过网站的认证。
paperen自己稍微查了一下资料 http://hi.baidu.com/chendezh2/blog/item/16059a37aa0dc985a71e1227.html?
session.use_cookies 设置是否使用cookie来存储session_id，session.use_only_cookies 设置是否只使用cookie来存储session_id
设置session.use_cookies=0将不使用cookie存储session_id,此时可能会使用URL来传递session_id(是否只用URL传递要看session.use_only_cookies的设置)
如果session.use_only_cookies被设置成1,则只能使用cookie存储session_id。如果同时设置session.use_cookies=0则无法传递session_id,这将导致无法使用SESSION功能
如果session.use_only_cookies被设置成0,则即使session.use_cookies=0,也能用URL来传递session_id,不过可能带来安全问题(例如：截获别人的url链接来获取别的用户的权限等)
paperen这里也找了一篇文章有兴趣可以看看 http://www.cnblogs.com/BearsTaR/archive/2010/08/24/URL_SESSION_ID_LEEK.html
而具体怎样实现paperen也未能了解，所以这里没有弄一个实例玩玩，paperen自己对"URL来传递session_id"这个没能理解，不知道是怎样实现的捏？待研究~要记得修改完要重启一下apache。
3.Directories with LIST permissions enabled(浅蓝色漏洞)
服务器可显示文件目录列表，这个是不推荐的，因为可能有些文件不希望被显示在web网站上，网站上不存在这些文件的链接。类似下图所示
paperen觉得这个应该要划为中等的，在本地测试倒是没什么问题，但是放到服务器上还是这样配置就有点说不过去。能看到站点的文件目录列表这个有点太可怕了，至少可以让入侵者将站点的目录理清得一清二楚，也就不用去猜测文件夹的名称了。
解决办法：修改apahce的httpd.conf中的Directory<Directory /path/to/directory>
Options -Indexes
</Directory>
然后重启apache，更多设置你可以参考 http://lamp.linux.gov.cn/Apache/ApacheMenu/index.html
4.Possible sensitive directories(绿色漏洞)
一个可能的敏感目录，其实意思很多人都是用这个名字的文件夹或者文件来放同一些功能，导致的结果是，入侵者可能会去猜测到你这个路径或者文件，为他的入侵提供方便。
而报告中的建议是"限制对该目录的访问或者删除该目录"，paperen认为这个可以根据各人实际情况吧，如果将文件名或文件夹的名称搞得十分特别也不是很好，可以使用这种敏感的名称，但写程序的或者是架构那个一定要想到某些文件被直接访问时应该发生什么情况，哪些文件你能直接访问什么文件你只能通过站点程序的调用。
paperen认为你况且可以在index.php中定义一个常量然后在其他视图啊什么的文件中去判断这个常量是否已经被定义了，没定义则exit掉。
define('INRUN', 1);
if ( !defined( 'INRUN' ) ) exit();
5.TRACE Method Enabled(绿色漏洞)
如果不必须的话可以禁用TRACE方法，关于trace的描述 http://www.cgisecurity.com/questions/httptrace.shtml
解决方法 http://blog.superyu.com/article.asp?id=2113，在httpd.conf文件最后加入TraceEnable off然后重启apache
报告中的漏洞就上面4种了，关于更多的漏洞不妨可以去 http://www.iiscan.com/ 的主页，点击"强大功能"看那个fusioncharts的报表，列了各种漏洞，点击各自的能进入查看具体描述。
虽然它没有扫描出存在SQLinjection漏洞的，但是paperen还得要自己去试试到底这个项目中存不存在这个漏洞。关于SQLinjection漏洞paperen日后也会写一篇文章说说的，想了解的可以期待一下~~
在此也同时说说另一个不算得上是漏洞的但是也最好避免的，就是当访问站点不存在的路径时显示的信息问题。
看到下面一行了么？将apache的版本与运行平台还有php版本都报出来了，有点不是很好，至于要隐藏它很简单。同样是修改httpd.conf中的ServerSignature参数，改为Off，然后重启apache，ok。又或者您可以自定义404错误页面同样是修改httpd.conf，将#ErrorDocument 404 /missing.html的#去掉并在后面修改为您要重定向的页面URL，保存后重启apache就ok，如果站点www目录中包含其他web应用的话在各自文件夹中加入.htaccess文件里面写上ErrorDocument 404 /missing.html就可以针对该应用进行404自定义。
关于SQLinjection的漏洞下回再说说吧，对于网站开发人员与运营者来说是个恶梦，对于hacker们来说是个宝藏，偶尔玩玩还是挺有益身心。
評論
0沒有任何評論