到目前为止，对于跨站点脚本攻击具有很大的威胁这一点大家并无异议。如果您很精通 XSS 并且只想看看有什么好的测试方法可供借鉴，那么请直接跳到本文的测试部分。如果您对此一无所知，请按顺序认真阅读！如果某个怀有恶意的人（攻击者）可以强迫某个不知情的用户（受害者）运行攻击者选择的客户端脚本，那么便会发生跨站点脚本攻击。“跨站点脚本”这个词应该属于用词不当的情况，因为它不仅与脚本有关，而且它甚至不一定是跨站点的。所以，它就是一个在发现这种攻击时起的一个名字，并且一直沿用至今。从现在开始，我们将使用它常见的缩写名称“XSS”。

         XSS 攻击的过程涉及以下三方：
        • 攻击者
        • 受害者
        • 存在漏洞的网站（攻击者可以使用它对受害者采取行动）

　　在这三方之中，只有受害者会实际运行攻击者的代码。网站仅仅是发起攻击的一个载体，一般不会受到影响。可以用多种方式发起 XSS 攻击。例如，攻击者可通过电子邮件、IM 或其他途径向受害者发送一个经过经心构造的恶意 URL。当受害者在 Web 浏览器中打开该 URL 的时侯，网站会显示一个页面并在受害者的计算机上执行脚本。

      XSS 漏洞是什么样的呢？

　　作为一名 Web 开发人员或测试人员，您肯定知道 Web 应用程序的技术基础是由 HTTP 和 HTML 组成的。HTTP 协议是 HTML 的传输机制，可使用代码设计 Web 页面布局和生成页面。如果 Web 应用程序接受用户通过 HTTP 请求（如 GET 或 POST）提交的输入信息，然后使用输出 HTML 代码在某些地方显示这些信息，便可能存在 XSS 漏洞。下面是一个最简单的例子：

       1. Web 请求如下所示：
      GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

       2. 在发出请求后，服务器返回的 HTML 内容包括：
       <h1>Section Title</h1>

　　可以看到，传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中并且由 Web 应用程序插入到 <h1> 标记中。通过提供输入内容，攻击者可以控制 HTML。

　　3. 现在，如果站点没有在服务器端对用户输入加以过滤（因为总是可以绕过客户端控件），那么恶意用户便可以使用许多手段对此漏洞加以滥用：

       攻击者可以通过摆脱 <h1> 标记来注入代码：
      http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title</h1><scrīpt>alert(‘XSS%20attack’)</scrīpt>

      这个请求的 HTML 输出将为：
      <h1>Section Title</h1><scrīpt>alert(‘XSS attack’)</scrīpt>

      即便是这个最简单的例子，攻击者也可以利用此连接完成数不清的事情。让我们看看会有哪些潜在的威胁，然后讨论一些更高级的测试方法.
 
      XSS 攻击的威胁有多么严重？

　　由于能够在生成的 Web 页面中注入代码，能想到的威胁有多么严重，就可以有多么严重的威胁。攻击者可以使用 XSS 漏洞窃取 Cookie，劫持帐户，执行 ActiveX，执行 Flash 内容，强迫您下载软件，或者是对硬盘和数据采取操作。只要您点击了某些 URL，这一切便有可能发生。每天之中，在阅读来自留言板或新闻组的受信任的电子邮件的时侯，您会多少次地单击其中的 URL？网络钓鱼攻击通常利用 XSS 漏洞来装扮成合法站点。可以看到很多这样的情况，比如您的银行给你发来了一封电子邮件，向您告知对您的帐户进行了一些修改并诱使您点击某些超链接。如果仔细观察这些 URL，它们实际上可能利用了银行网站中存在的漏洞，它们的形式类似于 http://mybank.com/somepage?redirect=<scrīpt>alert(‘XSS’)</scrīpt>，这里利用了“redirect”参数来执行攻击。如果您足够狡猾的话，可以将管理员定为攻击目标，您可以发送一封具有如下主题的邮件：“求救！这个网站地址总是出现错误！”在管理员打开该 URL 后，便可以执行许多恶意操作，例如窃取他（或她）的凭证。好了，现在我们已经理解了它的危害性 -- 危害用户，危害管理员，给公司带来坏的公共形象。现在，让我们看看本文的重点 -- 测试您的网站是否存在这些问题.

        测试 XSS 漏洞

　　多年以来，我一直是一名全职的安全顾问，已经做过无数次的这种测试了。我将好的测试计划归结为两个字：彻底。对于你我来说，查找这些漏洞与能够有机会在 Bugtraq 或 Vulnwatch 上吹嘘一番没有任何关系；它只与如何出色完成负责的工作有关。如果这意味着对应用程序中所有的单个查询字符串参数、cookie 值 以及 POST 数据值进行检查，那么这只能表明我们的工作还不算太艰巨。显然，一次完整的安全性检查所涉及的内容通常远远超出寻找 XSS 漏洞那样简单；它需要建立整体的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和授权错误。好在执行这样彻底的工作时，各个领域之间都存在重叠。比如，在测试 XSS 漏洞时，经常会同时找出错误处理或信息泄漏问题。

　　我假设您属于某个负责对 Web 应用程序进行开发和测试的小组。在这个幸运的位置上，您可以混合使用黑盒和白盒方法。每种方法都有它自己的优点，结合使用时甚至能相互提供支持。

       1. 按顺序准备您的工具包
　　测试工作也可以是自动化的，但是我们在这里只讨论手动操作。手动测试的必备工具包括：

    • Paros proxy (http://www.parosproxy.org)，用于截获 HTTP 通信数据
 
    • Fiddler (http://www.fiddlertool.com/fiddler)，用于截获 HTTP 通信数据
 
    • Burp proxy (http://www.portswigger.net/proxy/)
 
    • TamperIE (http://www.bayden.com/dl/TamperIESetup.exe)，用于修改 GET 和 POST
 
　　我们以上至少列出了三种 Web 代理软件。也可以寻找其他不同的类似产品，因为每种产品都有它自己的独到之处。下面，您需要在 Web 浏览器发出 HTTP 请求之前截获这些请求，并修改它们以注入 XSS 测试代码。上面所有这些工具都可以完成这项任务，某些工具还会显示返回的 HTML 源代码（如果您选择了截获服务器响应）。截获客户端发出的 GET 和 POST 请求非常重要。这样可以绕过所有的客户端 javascrīpt 输入验证代码。我在这里要提醒所有 Web 开发人员 -- 客户端安全控制是靠不住的。应该总是在服务器端执行有效性验证。
 
       2. 确定站点及其功能 -- 与开发人员和 PM 交流
　　绘制一些简单的数据流图表，对站点上的页面及其功能进行描述。此时，可以安排一些与开发人员和项目经理的会议来建立威胁模型。在会议上尽可能对应用程序进行深入探讨。站点公开了 Web 服务吗？是否有身份验证表单？有留言板吗？有用户设置页面吗？确保列出了所有这些页面。
 
       3. 找出并列出所有由用户提供输入的点
　　对站点地图进行进一步细化。我通常会为此创建一个电子表格。对于每个页面，列出所有查询字符串参数、cookie 值、自定义 HTTP 标头、POST 数据值和以其他形式传递的用户输入。不要忘记搜索 Web 服务和类似的 SOAP 请求，并找出所有允许用户输入的字段。 分别列出每个输入参数，因为下面需要独立测试每个参数。这可能是最重要的一个步骤！如果阅读下面的电子表格，您会看到我已经在示例站点中找出了一大堆这样的东西。如 forwardURL 和 lang 这样的查询字符串。如 name、password、msgBody、msgTitle 和这样的 POST 数据，甚至某些 Cookie 值。所有这些都是我们感兴趣的重要测试内容。

4. 认真思考并列出测试用例
　　使用已经得到的电子表格并列出各种用来测试 XSS 漏洞的方法。我们稍候将讨论各种方法，但是现在先让我们看看我的电子表格的屏幕截图，请注意，我列出了页面上允许的每个值以及每个值的所有测试类型。这种记录测试的方法仅是我自己的习惯，您可以使用自己的方法。我喜欢记录所有东西，以便我能知道已经做了哪些工作和哪些工作没有做。

      5. 开始测试并注意输出结果
　　在查找漏洞的过程中，最重要的部分并不是您是否找到了漏洞。而是您是否真正知道究竟发生了哪些事情。对于 XSS，只需检查 HTML 输出并看看您输入的内容在什么地方。它在一个 HREF 标记中吗？是否在 IFRAME 标记中？它在 CLSID 标记中吗？在 IMG SRC 中吗？某些 Flash 内容的 PARAM NAME 是怎样的？我会检查所有这些情况，如果您对所输入内容的目的十分了解，可以调整您的测试来找出问题。这意味着您可能需要添加一个额外的封闭括号“>”来让某个标记变得完整，或者添加一个双引号来关闭标记内的一个元素。或者，您可能需要使用 URL 或 HTML 来编码您的字符，例如将双引号变为 %22 或 "。嗯，并不那么容易，这个站点看来防范比较严密。现在该怎么办呢？那么，也许您的简单测试用例 <scrīpt>alert(‘hi’)</scrīpt> 并不能产生期望中的警告对话框。仔细想想这个问题并在可能的情况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会过滤“scrīpt”这个词。重新研究为何输入会产生这样的输出，并理解每个值（查询字符串、cookie、POST 数据）的作用。“pageId=10”这样的查询字符串值可能对输出没有影响，因此不值得花费时间测试它。有时，最好试着注入单个字符（例如尖括号、双引号标记或者圆括号），看看应用程序是否过滤这些字符。然后，便可以知道您面对的过滤级别究竟如何。接着，可以调整测试方法，对这些字符进行编码并重试，或者寻找其他注入办法。

      改变测试用例

　　我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产生输出，那么不要在它们上面浪费时间。如果可以，请进行研究，因为您需要根据输出对测试进行相应的修改。我使用了各种变化形式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：

    1. >"'><scrīpt>alert(‘XSS')</scrīpt>
 
    2. >%22%27><img%20src%3d%22javascrīpt:alert(%27XSS%27)%22>
 
    3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
 
    4. AK%22%20style%3D%22background:url(javascrīpt:alert(%27XSS%27))%22%20OS%22
 
    5. %22%2Balert(%27XSS%27)%2B%22
 
    6. <table background="javascrīpt:alert(([code])"></table>
 
    7. <object type=text/html data="javascrīpt:alert(([code]);"></object>
 
    8. <body ōnload="javascrīpt:alert(([code])"></body>
 
　　有许多变化形式可以尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些例子所展示的，常见的变化形式经常是在脚本代码前面加上 “>””，以尝试封闭网站可能在输出中生成的标记。还可以对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，因为尖括号“<>”通常会在输入时被过滤和从输出中删除，所以还必须尝试不需要尖括号的 XSS，例如 ”&{alert('XSS')};”

       持久和动态

　　找出一个成功的 XSS 颇费周折，因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例子，如果向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会立即看到脚本代码被执行。但是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其作为脚本代码执行。这种情况被称作持久性 XSS 攻击，如果包含脚本代码的值将被保存到客户端或者后端系统并在稍候的时间被执行，便会发生此种攻击。而与此相对的是动态 XSS 攻击，这种攻击会立即执行并只发生一次。比如，如果某个链接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码，那么在点击链接后会立即显示输出。

  总结

　　XSS 测试通常只是整个 Web 应用程序安全性审查工作的一小部分，但是在执行测试时必须细致和彻底。在多年的工作中，我一直强调使用电子表格或其他方式来记录站点的所有页面，以及每个页面接受的输入值（查询字符串、cookie、POST 数据、SOAP），这是在测试前必须进行的一个重要步骤。与此同等重要的是，理解输入以及它在输出的 HTML 页面上的呈现方式。如果您知道了应用程序处理输入的方式，就会非常迅速地完成许多工作。不要浪费时间测试那些不会作为输出显示的输入。与开发人员和 PM 进行交流，并在开始测试前建立完善的威胁模型。

 

   对于一个安全的Web服务器来说，对Web内容进行恰当的访问控制是极为关键的。目录遍历是Http所存在的一个安全漏洞，它使得攻击者能够访问受限制的目录，并在Web服务器的根目录以外执行命令。

　　Web服务器主要提供两个级别的安全机制：

　　访问控制列表——就是我们常说的ACL
　　根目录访问
　　访问控制列表是用于授权过程的，它是一个Web服务器的管理员用来说明什么用户或用户组能够在服务器上访问、修改和执行某些文件的列表，同时也包含了其他的一些访问权限内容。

　　根目录是服务器文件系统中一个特定目录，它往往是一个限制，用户无法访问位于这个目录之上的任何内容。

　　例如：在Windows的IIS其默认的根目录是C:\Inetpub\wwwroot，那么用户一旦通过了ACL的检查，就可以访问C:\Inetpub\wwwroot\news目录以及其他位于这个根目录以下的所有目录和文件，但无法访问C:\Windows目录。

　　根目录的存在能够防止用户访问服务器上的一些关键性文件，譬如在Windows平台上的cmd.exe或是Linux/Unix平台上的口令文件。

　　这个漏洞可能存在于Web服务器软件本身，也可能存在于Web应用程序的代码之中。

　　要执行一个目录遍历攻击，攻击者所需要的只是一个web浏览器，并且有一些关于系统的一些缺省文件和目录所存在的位置的知识即可。

　　如果你的站点存在这个漏洞，攻击者可以用它来做些什么?

　　利用这个漏洞，攻击者能够走出服务器的根目录，从而访问到文件系统的其他部分，譬如攻击者就能够看到一些受限制的文件，或者更危险的，攻击者能够执行一些造成整个系统崩溃的指令。

　　依赖于web站点的访问是如何设置的，攻击者能够仿冒成站点的其他用户来执行操作，而这就依赖系统对Web站点的用户是如何授权的。

　　利用Web应用代码进行目录遍历攻击的实例

　　在包含动态页面的Web应用中，输入往往是通过GET或是POST的请求方法从浏览器获得，以下是一个GET的Http URL请求示例：

　　http://test.webarticles.com/show.asp?view=oldarchive.html

　　利用这个URL，浏览器向服务器发送了对动态页面show.asp的请求，并且伴有值为oldarchive.html的view参数，当请求在Web服务器端执行时，show.asp会从服务器的文件系统中取得oldarchive.html文件，并将其返回给客户端的浏览器，那么攻击者就可以假定show.asp能够从文件系统中获取文件并编制如下的URL：

　　http://test.webarticles.com/show.asp?view=../../../../../Windows/system.ini

　　那么，这就能够从文件系统中获取system.ini文件并返回给用户，../的含义这里就不用多说了，相信大家都会明白。攻击者不得不去猜测需要往上多少层才能找到Windows目录，但可想而知，这其实并不困难，经过若干次的尝试后总会找到的。

利用Web服务器进行目录遍历攻击的实例：

　　除了Web应用的代码以外，Web服务器本身也有可能无法抵御目录遍历攻击。这有可能存在于Web服务器软件或是一些存放在服务器上的示例脚本中。

　　在最近的Web服务器软件中，这个问题已经得到了解决，但是在网上的很多Web服务器仍然使用着老版本的IIS和Apache，而它们则可能仍然无法抵御这类攻击。即使你使用了已经解决了这个漏洞的版本的Web服务器软件，你仍然可能会有一些对黑客来说是很明显的存有敏感缺省脚本的目录。

　　例如，如下的一个URL请求，它使用了IIS的脚本目录来移动目录并执行指令：http://server.com/scrīpts/..%5c../Windows/System32/cmd.exe?/c+dir+c:\

　　这个请求会返回C:\目录下所有文件的列表，它使通过调用cmd.exe然后再用dir c:\来实现的，%5c是web服务器的转换符，用来代表一些常见字符，这里表示的是“\”

　　新版本的Web服务器软件会检查这些转换符并限制它们通过，但对于一些老版本的服务器软件仍然存在这个问题。

　　如何判断是否存在目录遍历漏洞?

　　最好的方式就是使用Web漏洞扫描器，Web漏洞扫描器能够遍历你Web站点的所有目录以判断是否存在目录遍历漏洞，如果有它会报告该漏洞并给出解决的方法，除了目录遍历漏洞以外，Web应用扫描还能检查SQL注入、跨站点脚本攻击以及其他的漏洞。

 

   观察近来的一些安全事件及其后果，安全专家们已经得到一个结论，这些威胁主要是通过SQL注入造成的。虽然前面有许多文章讨论了SQL注入，但今天所讨论的内容也许可帮助你检查自己的服务器，并采取相应防范措施。

SQL注入攻击的种类

        知彼知己，方可取胜。首先要清楚SQL注入攻击有哪些种类。

1.没有正确过滤转义字符

        在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞：

statement := "SELECT * FROM users WHERE name = '" + userName + "'; "

        这种代码的设计目的是将一个特定的用户从其用户表中取出，但是，如果用户名被一个恶意的用户用一种特定的方式伪造，这个语句所执行的操作可能就不仅仅是代码的作者所期望的那样了。例如，将用户名变量(即username)设置为：

a' or 't'='t，此时原始语句发生了变化：

SELECT * FROM users WHERE name = 'a' OR 't'='t';

        如果这种代码被用于一个认证过程，那么这个例子就能够强迫选择一个合法的用户名，因为赋值't'='t永远是正确的。

        在一些SQL服务器上，如在SQL　Server中，任何一个SQL命令都可以通过这种方法被注入，包括执行多个语句。下面语句中的username的值将会导致删除“users”表，又可以从“data”表中选择所有的数据(实际上就是透露了每一个用户的信息)。

a'; DROP TABLE users; SELECT * FROM data WHERE name LIKE '%

        这就将最终的SQL语句变成下面这个样子：

SELECT * FROM users WHERE name = 'a'; DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';

        其它的SQL执行不会将执行同样查询中的多个命令作为一项安全措施。这会防止攻击者注入完全独立的查询，不过却不会阻止攻击者修改查询。

2.Incorrect type handling

        如果一个用户提供的字段并非一个强类型，或者没有实施类型强制，就会发生这种形式的攻击。当在一个SQL语句中使用一个数字字段时，如果程序员没有检查用户输入的合法性(是否为数字型)就会发生这种攻击。例如：

statement := "SELECT * FROM data WHERE id = " + a_variable + "; "

        从这个语句可以看出，作者希望a_variable是一个与“id”字段有关的数字。不过，如果终端用户选择一个字符串，就绕过了对转义字符的需要。例如，将a_variable设置为:1; DROP TABLE users，它会将“users”表从数据库中删除，SQL语句变成：SELECT * FROM DATA WHERE id = 1; DROP TABLE users;

3.数据库服务器中的漏洞

        有时，数据库服务器软件中也存在着漏洞，如MYSQL服务器中mysql_real_escape_string()函数漏洞。这种漏洞允许一个攻击者根据错误的统一字符编码执行一次成功的SQL注入式攻击。

4.盲目SQL注入式攻击

        当一个Web应用程序易于遭受攻击而其结果对攻击者却不见时，就会发生所谓的盲目SQL注入式攻击。有漏洞的网页可能并不会显示数据，而是根据注入到合法语句中的逻辑语句的结果显示不同的内容。这种攻击相当耗时，因为必须为每一个获得的字节而精心构造一个新的语句。但是一旦漏洞的位置和目标信息的位置被确立以后，一种称为Absinthe的工具就可以使这种攻击自动化。

5.条件响应

        注意，有一种SQL注入迫使数据库在一个普通的应用程序屏幕上计算一个逻辑语句的值：

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1

        这会导致一个标准的面面，而语句

        SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2在页面易于受到SQL注入式攻击时，它有可能给出一个不同的结果。如此这般的一次注入将会证明盲目的SQL注入是可能的，它会使攻击者根据另外一个表中的某字段内容设计可以评判真伪的语句。

6.条件性差错

        如果WHERE语句为真，这种类型的盲目SQL注入会迫使数据库评判一个引起错误的语句，从而导致一个SQL错误。例如：

SELECT 1/0 FROM users WHERE username='Ralph'。显然，如果用户Ralph存在的话，被零除将导致错误。

7.时间延误

        时间延误是一种盲目的SQL注入，根据所注入的逻辑，它可以导致SQL引擎执行一个长队列或者是一个时间延误语句。攻击者可以衡量页面加载的时间，从而决定所注入的语句是否为真。

        以上仅是对SQL攻击的粗略分类。但从技术上讲，如今的SQL注入攻击者们在如何找出有漏洞的网站方面更加聪明，也更加全面了。出现了一些新型的SQL攻击手段。黑客们可以使用各种工具来加速漏洞的利用过程。我们不妨看看the Asprox Trojan这种木马，它主要通过一个发布邮件的僵尸网络来传播，其整个工作过程可以这样描述：首先，通过受到控制的主机发送的垃圾邮件将此木马安装到电脑上，然后，受到此木马感染的电脑会下载一段二进制代码，在其启动时，它会使用搜索引擎搜索用微软的ASP技术建立表单的、有漏洞的网站。搜索的结果就成为SQL注入攻击的靶子清单。接着，这个木马会向这些站点发动SQL注入式攻击，使有些网站受到控制、破坏。访问这些受到控制和破坏的网站的用户将会受到欺骗，从另外一个站点下载一段恶意的Javascrīpt代码。最后，这段代码将用户指引到第三个站点，这里有更多的恶意软件，如窃取口令的木马。

        以前，我们经常警告或建议Web应用程序的程序员们对其代码进行测试并打补丁，虽然SQL注入漏洞被发现和利用的机率并不太高。但近来攻击者们越来越多地发现并恶意地利用这些漏洞。因此，在部署其软件之前，开发人员应当更加主动地测试其代码，并在新的漏洞出现后立即对代码打补丁。

防御和检查SQL注入的手段

1.使用参数化的过滤性语句

        要防御SQL注入，用户的输入就绝对不能直接被嵌入到SQL语句中。恰恰相反，用户的输入必须进行过滤，或者使用参数化的语句。参数化的语句使用参数而不是将用户输入嵌入到语句中。在多数情况中，SQL语句就得以修正。然后，用户输入就被限于一个参数。下面是一个使用Java和JDBC API例子：

PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE PASSWORD=?");

prep.setString(1, pwd);

        总体上讲，有两种方法可以保证应用程序不易受到SQL注入的攻击，一是使用代码复查，二是强迫使用参数化语句的。强迫使用参数化的语句意味着嵌入用户输入的SQL语句在运行时将被拒绝。不过，目前支持这种特性的并不多。如H2 数据库引擎就支持。

2.还要避免使用解释程序，因为这正是黑客们借以执行非法命令的手段。

3.防范SQL注入，还要避免出现一些详细的错误消息，因为黑客们可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。

4.使用专业的漏洞扫描工具。但防御SQL注入攻击也是不够的。攻击者们目前正在自动搜索攻击目标并实施攻击。其技术甚至可以轻易地被应用于其它的Web架构中的漏洞。企业应当投资于一些专业的漏洞扫描工具，如大名鼎鼎的Acunetix的Web漏洞扫描程序等。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找网站上的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。

5.最后一点，企业要在Web应用程序开发过程的所有阶段实施代码的安全检查。首先，要在部署Web应用之前实施安全测试，这种措施的意义比以前更大、更深远。企业还应当在部署之后用漏洞扫描工具和站点监视工具对网站进行测试。

        Web安全拉警报已经响起，安全形式异常严峻，企业绝对不应当草率从事。安全重于泰山!