截屏显示了一个页面的解析信息。URL Encoded下面用椭圆括住的数据是用于user_login和user_password的变量。Parsed下面用圆圈包围的数据是用于地址和站点cookie的。
需要注意的是，上面圈起来的是用于user_login和user_password的变量值，即‘) or 1=1--。接下来需要注意的是，地址已经从http://localhost:3000（主页）变为http://localhost:3000/lobby/games，看上去用户已经成功登录了。这又意味着什么呢？ 它意味着你的站点是易受攻击的。因为‘) or 1=1--是一个SQL字符串，所以站点容易受到SQL注入的攻击。使用Next按钮滚动结果，并查找那个值。注意，这里的地址保持为http://localhost:3000。由此结果可知，插入这种类型的字符串不会导致成功的登录尝试，所以站点不易受这种类型的攻击的影响。
Paros Proxy
进行安全性测试的时候，另一个常用的工具是Paros Proxy。 就像WebScarab一样，Paros也能捕获浏览器和服务器之间的会话来用于分析。您还可以使用它来检查站点中的安全漏洞。为了运行Paros，您必须更改浏览器的代理设置所使用的端口号。对于WebScarab，您使用的端口号是8008；但是运行Paros之前，需要将这个端口号改为8080，否则Paros就无法正常工作。对于本文来说，我们使用WebGoat——另一款来自OWASP的安全工具。就像Hacme Casino一样，WebGoat使用Tomcat服务器作为本地主机。对于本文来说，使用Paros扫描WebGoat所找到的漏洞比Hacme Casino发现的安全漏洞要更多一些。
使用多个扫描器
凡是对自己站点进行过测试的人可能都知道，同一个站点，使用不同的扫描器会得到不同的扫描结果。这就是为什么专业渗透测试人员工作中会使用多种工具的原因。
更改端口之后，打开Paros，并执行下列步骤：
1. 在WebGoat文件夹中，双击WebGoat.ba以启动Tomcat。
2. 打开浏览器，然后在地址栏输入http://localhost/WebGoat/attack。
3. 在用户名和口令中输入guest。
4. 单击Start WebGoat。
现在，返回到Paros，并开始扫描WebGoat站点。当然，您也可以通过在地址栏输入相应的地址来测试您自己的网站。
在Paros中，展开Sites文件夹，您就会在文件树中看到http://localhost。继续展开这个文件夹以调出WebGoat。高亮显示WebGoat，然后单击Analyse Scan。这样就会马上开始扫描这个站点。对于大型站点来说，所需时间会较长，但是扫描这个站点仅需几秒就够了。一旦启动扫描，底部窗格会自动变为Alerts选项卡。如图7所示。当扫描完成时，在通知您报告所在位置的弹出窗口中单击OK按钮。
图 7. 查看警告信息
警告屏幕展示了一个典型的IDE风格的分割式窗口，在左上部的窗格中带有一个站点树，同时提供在右上方窗格中所选条目的详细信息，另外，在底部窗格中还提供了一个警告树。
为了更详细地展示警告细节，您可以展开它。您还可以查看报告提供的更多信息。然而，您应当首先保存扫描结果，方法是单击File > Save As，选择文件名和存放位置，最后单击Save即可。
要想查看一个报告，单击Report > Last Scan Report，在弹出窗口中单击OK按钮，这时一个新的浏览器选项卡会打开扫描结果，如图8所示。这份报告为检测到的每个安全漏洞都提供了相应的信息，包括指向处理该特定攻击的OWASP页面链接。
图 8. Paros的报告
这个Paros报告的截屏显示了一个警告总表，并为每个警告提供了详细信息。
测试中的误报
虽然使用扫描器是查找网站潜在的安全漏洞的一个好方法，但是最优秀的安全公司总是通过手工方式对这些潜在的安全漏洞进行排查，之所以这样做是为了防止误报。这时，需要对报告有潜在的漏洞利用的网站的各处进行测试，即向站点本身插入SQL代码或者脚本来观察它的反应，然后使用各种攻击程序对站点进行测试。大型公司经常雇用精通此类测试的专业程序设计员，但是作为开发人员，您可以自己进行一些这样的测试。这不仅能够提高当前站点的安全性，而且对将来开发站点时也很有帮助。
与SQL注入有关的误报
我们来看看使用Hacme Casino站点时，WebScarab发现的安全漏洞：在登录时出现SQL注入漏洞。运行Hacme Casino，在站点的登录输入区输入WebScarab得手的SQL代码，即‘) or 1=1--。当您单击Login时，帐户Andy_Aces被打开，因为1=1总为真，这是SQL注入最常见的手法。就Andy而论，他的运气真是不怎么样，因为它是这个数据库中的第一个帐户。
它是如何得手的？ 在后端，这个数据库运行了一个如下所示的查询：
SELECT * FROM users WHERE (username=username AND password=password)
通过登录框注入的代码转变为有效的查询：
SELECT * FROM users WHERE (username=’’) or 1=1—AND password=’’)
这个查询返回的结果是允许站点的第一个用户成功的登录，而不幸的是这个用户恰恰就是Andy。
当然，这个例子仅仅是针对SQL注入的，即使如此，如果某些人在攻击网站方面非常老道，那么他或她实际上就能够利用这个安全漏洞来创建用户、修改口令甚至从网站上提取敏感数据。保护站点免受这些攻击时，还需采取以下步骤：
使用参数化查询或者存储过程而不是使用字符串拼接来访问数据库。参数化查询要求您定义所有的SQL代码，然后传入每个参数来进行查询。这使得数据库能够区分代码和数据，所以用户提供的输入内容的类型就不会引起问题。这一点上存储过程类似于参数化查询，它也要求您首先定义SQL代码，然后传入参数。区别是，用于存储过程的SQL代码是在数据库本身内定义和存放的，然后供应用程序调用。
通过白名单方式对用户输入进行消毒处理。如果要求使用名称，那么只允许使用字母a-z和A-Z。对于电话号码，只允许使用字符0-9。您可以利用你的数据库支持的相应验证技术来达此目的。
通过数据库设置字符转义方案，对用户提供的输入进行转义处理。对特殊字符进行转义就是告诉数据库，查询中的这些字符是数据，而非代码。如果对用户提供的所有的输入都进行正确的转义处理的话，就不会受到带有SQL代码的用户输入的威胁了。
不要给攻击者任何帮助。应确保错误信息不会提供可以用来攻击站点的任何有用信息。
与XSS有关的误报
为了演示XSS攻击，我们重新回到WebGoat。单击Cross Site Scripting > LAB: Cross Site Scripting > Stage 1: Stored XSS启动我们的站点。登陆到演示站点Goat Hills Financial，这里使用的用户名为Larry Stooge，口令为Larry。现在，攻击者将需要查找可以输入恶意脚本的地方。Search Staff功能具有一个文本框，人们可以在此输入一个名称，单击Search后来显示有关结果，如图9所示.
图9. XSS入口点
Goat Hills Financial Human Resources处的XSS入口点的截屏，它为我们显示了一个文本字段，我们可以在此输入用户名称并通过FindProfile按钮来查找用户。
在Name框中，输入alert("You got me with XSS");。 这个脚本只是一个警告框，如图10所示，但是您可以设想如果这个脚本将用户重定向到一个伪造的、要求访问者输入其社会保险号、家庭地址、银行信息等的虚假人力资源站点时后果会有多么严重。实际上，只要修改与OK按钮有关的动作就能做到这一点。对于真正有创造性的恶意黑客来说，只要用户信任他们，那么就基本上没有什么做不到的。
图 10. 一次成功的xss攻击
上面是一个带有警示信息的警告框。
为了防止xss攻击，需要对所有的用户输入进行严格的过滤处理。如果输入随后被用作操作系统命令、脚本和数据库查询的参数，那么更要严格检查。为了对用户输入进行清洗，可以在将其插入HTML元素和HTML普通属性之前，对不可信的数据进行转义处理。OWASP建议对所有ASCII值小于256的字符都进行换码。JavaScript 数据值、HTML风格的属性值和HTML值属性也可进行转义。当然，对输入数据进行转义之前，请确保已经对网站的所有输入进行了验证。如果所需期望的是特定的输入值、数字、字母、电子邮件地址等等，那么就只允许这种类型的数据并且拒绝任何其他类型的数据。
结束语
本文中，我们考察了许多针对网站的常见攻击，重要的是，通过阅读本文您会对这些攻击的工作原理有一个深入的理解。如果知道了攻击者正寻找哪些安全漏洞，以及这些漏洞的预防措施，那么您就能防止攻击者攻陷网站。通过掌握在本文中介绍的攻击与防御原理，能够为将来构建安全Web站点和应用打下一个良好的基础。
