Web安全性测试

常见Web应用安全问题

      经过上两篇（《Web安全性问题的层次关系》及《解读Web应用安全问题的本质》）关于Web安全及Web应用安全概念性知识的宏观介绍 ，相信大家已经有所感知了。从今天开始，我将陆续给大家介绍常见的Web应用安全性问题。
Web应用程序的安全性问题依其存在的形势划分，种类繁多，这里不准备介绍所有的，只介绍常见、比较常见和有点常见这种级别的。我相信从Web应用安全角度来说，会比你从网上搜的要全面的多。以下是这些安全性问题的列表：

   １、跨站脚本攻击(CSS or XSS, Cross Site Scripting)
２、SQL注入攻击(SQL injection)
３、远程命令执行(Code execution，个人觉得译成代码执行并不确切)
４、目录遍历(Directory traversal)
５、文件包含(File inclusion)
６、脚本代码暴露(Script source code disclosure)
７、Http请求头的额外的回车换行符注入(CRLF injection/HTTP response splitting)
８、跨帧脚本攻击(Cross Frame Scripting)
９、PHP代码注入(PHP code injection)
１０、XPath injection
１１、Cookie篡改(Cookie manipulation)
１２、URL重定向(URL redirection)
１３、Blind SQL/XPath injection for numeric/String inputs
１４、Google Hacking

下面我们来看看它们的概念由于时间与篇幅原因，本文只介绍第一到第二，后面将在后续文章中介绍：

 跨站脚本攻击(CSS or XSS)
２００６年全球网络安全弱点Top10排名当中，它荣登榜首！为什么它有如此之大的影响力呢？个人觉得原因有三：其一、攻击难度小。不管是技术还是实现攻击的成本上都比较容易；其二、它存在的载体（浏览器）使用极其广泛；其三、它所依赖的技术被广泛的应用与支持（Javascript,VB Script, HTML,ActiveX, Flash）。说了这么多，它到底是什么呢？
XSS是一种存在Web应用中，允许黑客以最终用户的身份向Web应用注入恶意脚本，以愚弄其他用户或获取其他用户重要数据和隐私信息为目的的一种攻击形式。XSS可使用的技术有JavaScript、VBScript、 ActiveX、 或 Flash， 且通常通过页面表单提交注入到web应用中并最终在用户的浏览器客户端执行。例如，一个没有经过安全设计并实现的论坛，当你在跟贴时在正文输入这样的代码：
<script>alert(document.cookie);</script>
当其它用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的cookie串。试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚本，当用户浏览此帖时，cookie信息就可能成功的被攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。说到这，一些初学者可能还不太清楚它的危害到底在哪里，不用着急，我会在后续的文章中详细给大家介绍有关“Web工作原理”内容，到时你就会很清楚的理解这些了。有关ＸＳＳ的攻击实例、手段和方法是多种多样的，你的脚本技能加上你的安全知识决定了你对其理解的深度。顺便提一句：你可能无法成为XSS安全弱点的攻击专家，但是你可以成为安全检测专家。因为从安全检测角度来说，你无需证明问题的严重性细节，只需要证明此类问题存在就可以了。

简要的解决方案（等Web工作原理部分讲完再深入）：
不管是上述的哪一种技术实现的ＸＳＳ攻击，最终都离不开两点：其一是浏览器的解析，其二是脚本语法，其三是脚本需要一定的长度。对于浏览器的解析是不在话下了，我不能因为这各类型问题的存在就改写浏览器使其不支持脚本解析。所以，能做就是控制脚本注入的语法要素。比如：javascript离不开：“<”、“>”、“(”、“）”、“;”…等等，所以我们只需要在输入或输出时对其进行字符过滤或转义处理就可以了。一般我们会采用转义的方式来处理，转义字符是会使用到HTML的原始码（Web工作原理中会介绍），因为原始码是可以被浏览器直接识别的，所以使用起来非常方便。允许可输入的字符串长度限制也可以一定程度上控制脚本注入。比如：页面表单中姓名，我可以只允许你输入５个字符，请问你还有办法进行Javascript的脚本注入吗？显然不行了。还需要您注意的是：我这里所述的过滤、检测、限制等等策略，一定一定要在Web Server那一端去完成，而不是使用客户端的Javascript或者VBScript…去做简单的检查。因为真正的攻击者不会仅仅依赖于浏览器去做攻击，而更多的往往是借助于第三方工具，根本就可以绕过你精心设计制作的客户端Javascript进行过滤、检测或限制手段的。

SQL注入攻击(SQL injection)
早在十几年前，基于数据库的Web应用刚刚盛行的时候，几乎所有的开发商都忽略了ＳＱＬ注入弱点，导致当时绝大多数的网站的登录入口形同虚设！为什么呢？先给一个小小的例子，假如以下ＳＱＬ代码是用来在网站登录入口入执行用户验证时的查询代码：
SELECT count(*)
FROM users_list_table
WHERE username=’USERNAME’
AND password=’PASSWORD’
以上的USERNAME就是我们登录时提供的用户名，PASSWORD就是我们登录时提供的密码。当用户输入正确的用户名和密码时，这条语句的执行结果将为真（True），否则为假（False），当然为真时我们就认为认证通过，为假时就认为认证失败，即非法登录。试想一下，如果我在输入用户名和密码的时候输入如下的内容：
用户名：a’ or ‘a’=’a
密码：a’ or ‘a’=’a    
用代入法把用户名和密码输入值代入到上述的ＳＱＬ脚本里结果如下：
SELECT count(*)
FROM users
WHERE username=’a’ or ‘a’=’a’
AND password=’a’ or ‘a’=’a’
相信稍懂一点儿ＳＱＬ语句的人都知道，这条语句的执行结果就永远是真了！此时你不需要有帐号，就直接登录成功了！你对此漏洞理解的深度同样取决于你的对ＳＱＬ语句的技能和web安全知识能力。一个具有良好技能的攻击者可能利用此漏洞获取后台ＤＢ的结构并逐步获取ＤＢ的信息。
总结一下：ＳＱＬ注入弱点是存在基于数据库的Web应用中，黑客利用精心组织的ＳＱＬ语句，通过Web接口（通常指我们的Web页面的表单）注入的Web应用中，从而获取后台ＤＢ的访问与存取权的一种安全弱点。

简要的解决方案：
刚刚介绍了ＸＳＳ，在这里关于ＳＱＬ Injection我想就无需多说了，都是过滤、合法性检查和长度限制等通用方法。
有没有注意到，ＸＳＳ和SQL Injection，虽然名字不一样，但它们似乎都属于我前一篇文章《解读Web安全性问题的本质》中的第一部分，即输入／输出验证。下面将要介绍的远程命令执行、目录遍历和文件包含同样也是输入/输出验证问题。

远程命令执行(code execution)

先不解释它的概念，我们先假设这样一个用户使用场景：

有一个站点的管理入口功能非常强大，大到什么程度呢？可以重启Web服务器。你能想出来它是如何实现的吗？我们知道不管是PHP还是JSP，我们都可以在服务器通过Shell调用系统(Linux or Windows)命令，等命令执行后，将执行结果返回给客户端。其实我们通过Web Page的管理入口管理服务器端的各种服务就是通过类似这种渠道完成的。这里会有什么问题？比如我们要重启apache，假如系统是通过这个命令来完成的：/$path/./apche -restart。这里的$path是Web应用程序的基准路径（比如：apache上的documentroot），它的实现方式是这样的：通过用户浏览器客户端传送一个命令串，给Web server，web server通过调用shell来执行传过来的命令。试想，如果我通过浏览器客户端强行传送一个：restart, shutdown之类的命令给server，结果会是什么样子？这只是起一个小小的破坏作用，那如果我传送一个：mail abc@abc.abc</etc/passwd，执行结果是什么？结果是将linux系统的passwd文件（linux系统用户信息）发送到指定的邮箱abc@abc.abc。是不是很可怕呢？这就是远程命令执行漏洞的一个小小的典型例子。至于它的更深远的安全隐患在哪里还需要你有更多的相关基础知识才能够得以深入理解和运用(比如：Web server OS, Web Service-apache/weblogic/tomcat…相关的使用技能)。

  总结一下：远程命令执行漏洞一般发生在Web系统允许用户通过Web应用接口访问与管理Web服务器且没有经过严格的输入验证与过滤的情况下的一种Web应用安全漏洞。
 简要的解决方案：
１、严格限制运行Web服务的用户权限。就是说你的Web应用可以访问你的服务器系统的用户权限。一般情况一下，我们应该以白名单的形式介定Web应用可以访问服务器系统的权限。这样控制可以从系统级达到安全防范的效果。
２、严格执行用户输入的合法性检查。注意这里的输入不一定是你通过表单从键盘输入，往往是Web应用已经内定了某一些操作供您选择，而此时你可以通过Http抓包的方式获取Http请求信息包经改装后重新发送。详细理解这一部分，请关注我后续将来介绍的《Web工作原理》部分的Http协议原理。

原文链接：https://www.cnblogs.com/qmfsun/p/3943894.html