1、 1 / 35WEB 十大安全隐患OWASP TOP 10-2010开放式 Web 应用程序安全项目（OWASP，Open Web Application Security Project）是一个组织，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。http:/www.owasp.orgOWASP 发布了最新的 Web 应用脆弱性的 top 10，这是继 2007 年 OWASP 对TOP10 进行修订后进行的又一次更改，该版本暂定为 OWASP TOP 10- 2010。在新版本的 OWASP TOP10 中主要由以下变化：
2、1. Top10 的命名发生了变化。原先的 Top10 全称为“The top 10 most critical web application security vulnerabilities”，即“Web 应用的十大关键脆弱性” ，现在 Top10 的全称为“The top 10 most critical web application security risks”，即“Web 应用的十大关键 风险”2. OWASP Top 10 的风险评估方法此次 Top 10 的评估是依据 OWASP 的风险评估方法来对 OWASP TOP10 排序的。3. 替换了 2 个风险此次 Top 10
3、与 2007 年的 Top 10 相比， 在内容上去掉了“Malicious File Execution”(恶意文件执行)和“Information leakage and improper error handling”(信息泄露及不恰当的错误处理)，增加了“Security misconfiguration”(错误安全配置) 和“Unvalidated redirects and forwards”(未验证的重定向和传递)。OWASP TOP10 2007 OWASP TOP10 2010A2-注入 A1-注入A1-跨站脚本（XSS ） A2-跨站脚本（XSS ）A7-错误的认证和会话管
4、理 A3-错误的认证和会话管理A4-不正确的直接对象引用 A4-不正确的直接对象引用A5-伪造跨站请求（CSRF ） A5-伪造跨站请求（CSRF ）A6-安全性误配置A10-限制远程访问失败 A7-限制远程访问失败A8-未验证的重定向和传递A8-不安全的加密存储 A9-不安全的加密存储A9-不足的传输层保护 A10-不足的传输层保护A3-恶意文件执行 A6-不安全的通讯 2 / 35OWASP 风险评估方法OWASP 所选取的 10 大风险是依据 OWASP 的风险评估方法，我们从标准的风险模型开始，即风险= 可能性*后果，下面我们以以下步骤来说明某个风险的严重程度：第一步：识别风险识别风险
5、作为评估的第一步，我们必须找到与这个风险相关的威胁、相应的攻击方法、隐含在里面的脆弱性以及最终可能造成的后果，当然可能存在多种攻击方法和多种后果，在评估时我们往往会采用最坏选择，这样就能更客观的反应该风险的最终评级；第二步：考虑影响可能性的因素通常，我们不可能很精准的说出某个风险的可能性数值，所以我们一般用高、中、低来表示，而且影响某个风险的可能性的因素有很多，对于每个因素我们用 0 到 9 的数值来表示。类别 因素 分项 分值无需技能 1需要一些技术 3高级的计算机用户 4需要网络和编程技术 6技能要求安全渗透技术 9很低或无益 1可能会有回报 4成功攻击后攻击者的益处高回报 9需要很大资源
6、或高权限访问 0需要特定的访问权限和特定的资源4需要一些访问权限和资源 7所需资源或机会无需权限或资源 9开发者 2系统管理员 2内部用户 4威胁所需的攻击者的角色合作伙伴 53 / 35认证用户 6匿名 Internet 用户 9技术上不可行 1困难 3容易 7发现该弱点的难易度可用自动化工具发现 9只是理论上的 1困难 3容易 5利用该弱点的难易度可用自动化工具实现 9不为人知 1隐藏 4明显 6该弱点的流行度公众皆知 9应用程序主动检测 1记录日志并审核 3记录日志未审核 8脆弱性入侵被察觉的可能性无日志 9第三步：考虑影响后果的因素在考虑攻击后果的时候，我们会考虑两种后果，一种是应用的
7、“技术后果” ，它所使用的数据，提供的功能等等，另一种就是它的“商业后果” ，显然后者则更为重要，但往往后者难以估量，所以我们需要尽可能从技术上去考虑，进而来估计后者的数据。类别 因素 分项 分值很少的非敏感的数据泄漏 2很少的敏感数据泄漏 6大量的非敏感数据泄漏 6技术后果 保密性损失大量的敏感数据泄漏 94 / 35A1-注入注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行。常见的注入包括 SQL 注入，OS Shell，LDAP ，Xpath，Hibernate 等等，而其中 SQL 注入尤为常见。这种攻击所造
8、成的后果往往很大，一般整个数据库的信息都能被读取或篡改，通过 SQL 注入，攻击者甚至能够获得更多的包括管理员的权限。防范 SQL 注入 编程篇SQL 注入往往是在程序员编写包含用户输入的动态数据库查询时产生的，但其实防范SQL 注入的方法非常简单。程序员只要 a）不再写动态查询，或 b）防止用户输入包含能够破坏查询逻辑的恶意 SQL 语句，就能够防范 SQL 注入。在这篇文章中，我们将会说明一些非常简单的防止 SQL 注入的方法。我们用以下 Java 代码作为示例：String query =SELECT account_balance FROM user_data WHERE user_n
9、ame =+ request.getParameter( customerName);try Statement statement =connection.createStatement( );ResultSet results =Statement.executeQuery(query);在以上代码中，我们可以看到并未对变量 customerName 做验证，customerName 的值可以直接附在 query 语句的后面传送到数据库执行，则攻击者可以将任意的 sql 语句注入。防范方法 1：参数化查询参数化查询是所有开发人员在做数据库查询时首先需要学习的，参数化查询迫使所有开发者首先要
10、定义好所有的 SQL 代码，然后再将每个参数逐个传入，这种编码风格就能够让数据库辨明代码和数据。参数化查询能够确保攻击者无法改变查询的内容，在下面修正过的例子中，如果攻击者输入了 UsrID 是“or 1 =1”，参数化查询会去查找一个完全满足名字为 or 1 = 1 的用户。5 / 35对于不同编程语言，有一些不同的建议：Java EE使用带绑定变量的 PreparedStatement()；.Net使用带绑定变量的诸如 SqlCommand()或 OleDbCommand()的参数化查询；PHP使用带强类型的参数化查询 PDO（使用 bindParam()） ；Hibernate 使用带绑
11、定变量的 createQuery()。Java 示例：String custname = request.getParameter(customerName);String query =SELECT account_balance FROM user_data WHERE user_name= ?;PreparedStatement pstmt = connection.prepareStatement(query);Pstmt.setString1,custname();ResultSet results = pstmt.executeQuery();C# .Net 示例：String q
12、uery =SELECT account_balance FROM user_data WHERE user_name = ?;Try OleDbCommand command = new OleDbCommand(query,connection);command.Parameters.Add(new OleDbParameter(customerName,CustomerName.Text);OleDbDataReader reader = command.ExecuteReader(); catch (OleDbException se)/error handling防范方法二：存储过程
13、存储过程和参数化查询的作用是一样的，唯一的不同在于存储过程是预先定义并存放在数据库中，从而被应用程序调用的。Java 存储过程示例：String custname = request.getParameter(customerName);try CallableStatement cs = connection.prepareCall(call sp_getAccountBalance(?);6 / 35cs.setString(1,custname);Result results = cs.executeQuery();catch(SQLException se)/error handlin
14、gVB .Net 存储过程示例： TryDim command As SqlCommand = new SqlCommand(sp_getAccountBalance,connection)command.CommandType = CommandType.StoredProcedurecommand.Parameters.Add(new SqlParameter(CustomerName ,CustomerName.Text)Dim reader As SqlDataReader = command.ExecuteReader()Catch se As SqlExceptionerror h
15、andlingEnd Try防范方法三：对所有用户输入进行转义我们知道每个 DBMS 都有一个字符转义机制来告知 DBMS 输入的是数据而不是代码，如果我们将所有用户的输入都进行转义，那么 DBMS 就不会混淆数据和代码，也就不会出现 SQL 注入了。当然，如果要采用这种方法，那么你就需要对所使用的数据库转义机制，也可以使用现存的诸如 OWASP ESAPI 的 escaping routines。ESAPI 目前是基于 MySQL 和 Oracle 的转义机制的，使用起来也很方便。一个 Oracle 的 ESAPI 的使用示例如下：ESAPI.encoder().encodeForSQL(n
16、ew OracleCodec(),queryparam);那么，假设你有一个要访问 Oracle 数据库的动态查询代码如下：String query =SELECT user_id FROM user_data WHERE user_name = +req.getParameter(userID)+ and user_password = +req.getParameter(pwd)+ ;try Statement statement = connection.createStatement();ResultSet results = statement.executeQuery(query)
17、 ;7 / 35那么，你就必须重写你的动态查询的第一行如下：Codec ORACLE_CODEC = new OracleCodec();String query =SELECT user_id FROM user_data WHERE user_name = +ESAPI.encoder().encodeForSQL(ORACLE_CODEC,req.getParameter(userID)+ and user_password = +ESAPI.encoder().encodeForSQL(ORACLE_CODEC,req.getParameter(pwd)+ ;当然，为了保证自己代码的可
18、读性，我们也可以构建自己的 OracleEncoder：Encoder e = new OracleEncoder();String query =SELECT user_id FROM user_data WHERE user_name = + oe.encode(req.getParameter(userID) + and user_password = + oe.encode(req.getParameter(pwd)+;除了上面所说的三种防范方法以外，我们还建议可以用以下两种附加的方法来防范SQL 注入：最小权限法、输入验证白名单法。最小权限法：为了避免注入攻击对数据库造成的损害，我们
19、可以把每个数据库用户的权限尽可能缩小，不要把 DBA 或管理员的权限赋予你应用程序账户，在给用户权限时是基于用户需要什么样的权限，而不是用户不需要什么样的权限。当一个用户只需要读的权限时，我们就只给他读的权限，当用户只需要一张表的部分数据时，我们宁愿另建一个视图让他访问。如果你的策略是都是用存储过程的话，那么仅允许应用程序的账户执行这些查询，而不给他们直接访问数据库表的权限。诸如此类的最小权限法能够在很大程度上保证我们数据库的安全。输入验证白名单法：输入验证能够在数据传递到 SQL 查询前就察觉到输入是否正确合法，采用白名单而不是黑名单则能在更大程度上保证数据的合法性。防范 SQL 注入 测试
20、篇对于测试人员来说，如何测试 SQL 注入漏洞是否存在呢？首先，我们将 SQL 注入攻击能分为以下三种类型：Inband：数据经由 SQL 代码注入的通道取出，这是最直接的一种攻击，通过 SQL 注入获取的信息直接反映到应用程序的 Web 页面上；8 / 35Out-of-band：数据通过不同于 SQL 代码注入的方式获得（譬如通过邮件等）推理：这种攻击是说并没有真正的数据传输，但攻击者可以通过发送特定的请求，重组返回的结果从而得到一些信息。不论是哪种 SQL 注入，攻击者都需要构造一个语法正确的 SQL 查询，如果应用程序对一个不正确的查询返回了一个错误消息，那么就和容易重新构造初始的查询
21、语句的逻辑，进而也就能更容易的进行注入；如果应用程序隐藏了错误信息，那么攻击者就必须对查询逻辑进行反向工程，即我们所谓的“盲 SQL 注入”黑盒测试及示例：这个测试的第一步是理解我们的应用程序在什么时候需要访问数据库，典型的需要访问数据库的时机是：认证表单：输入用户名和密码以检查是否有权限搜索引擎：提交字符串以从数据库中获取相应的记录电子商务站点：获取某类商品的价格等信息作为测试人员，我们需要列对所有输入域的值可能用于查询的字段做一个表单，包括那些 POST 请求的隐含字段，然后截取查询语句并产生错误信息。第一个测试往往是用一个单引号“” 或是分号“ ；”，前者在 SQL 中是字符串终结符，如
22、果应用程序没有过滤，则会产生一条错误信息；后者在 SQL 中是一条 SQL 语句的终结符，同样如果没有过滤，也会产生错误信息。在 Microsoft SQL Server 中，返回的错误信息一般是这样：Microsoft OLE DB Provider for ODBC Drivers error 80040e14MicrosoftODBC SQL Server DriverSQL ServerUnclosed quotation mark before the character string ./target/target.asp, line 113同样可用于测试的还有“-”以及 SQL
23、中的一些诸如“AND”的关键字，通常很常见的一种测试是在要求输入为数字的输入框中输入字符串，会返回如下的错误信息：Microsoft OLE DB Provider for ODBC Drivers error 80040e07MicrosoftODBC SQL Server DriverSQL ServerSyntax error converting the varchar value tester to a column of data type int./target/target.asp, line 113类似上面这样的出错返回信息能让我们知道很多数据库的信息，通常不会返回那么多信息
24、，会返回诸如“500 Server Error”的信息，那就需要“ 盲 SQL 注入” 了。注意，我们需要对所有可能存在 SQL 注入漏洞的输入域进行测试，并且在每个测试用例时只变化一个域的值，从而才能找到真正存在漏洞的输入域。9 / 35下面我们看一下标准的 SQL 注入测试是怎样的。我们以下面的 SQL 查询为例：SELECT * FROM Users WHERE Username=$username AND Password=$password如果我们在页面上输入以下的用户名和密码：$username = 1 or 1 = 1$password = 1 or 1 = 1那么整个查询语句就
25、变为： SELECT * FROM Users WHERE Username=1 OR 1 = 1 AND Password=1 OR 1 = 1假设参数值是通过 GET 方法传递到服务器的，且域名为 ，那么我们的访问请求就是：http:/ update users set password = password; select *后面则显而易见，用户的所有密码都被更改且得到了报表信息。A2-跨站脚本（XSS）排在 OWASP TOP10 第 2 位的是 Cross Site Scripting（XSS），翻译成中文即“跨站脚本攻击”。它指的是恶意攻击者往 Web 页面里插入恶意 html 代
26、码，当用户浏览该页之时，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意用户的特殊目的。XSS 属于被动式的攻击，因为其被动且不好利用，所以许多人常忽略其危害性。以下内容转自百度空间的一篇关于 OWASP 的文章，个人觉得基本已经把跨站脚本攻击的内容阐述的比较清楚。如何寻找 XSS 漏洞，XSS 攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs 的 showerror.asp 存在的跨站漏洞。另一类则是来来自外部的攻击，主要指的自己构造 XSS 跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一
27、个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开，然后利用下面的技术得到一个 shell。如何利用传统的跨站利用方式一般都是攻击者先构造一个跨站网页，然后在另一空间里放一个收集 cookie 的页面，接着结合其它技术让用户打开跨站页面以盗取用户的 cookie，以便进一步的攻击。这种方式太过于落后，对于弊端大家可能都知道，因为即便你收集到了cookie 你也未必能进一步渗透进去，多数的 cookie 里面的密码都是经过加密的，如果想要cookie 欺骗的话，同样也要受到其它的条件的限约。而另一种思路，则从一定程度上解决上述的问题。比较成熟的方法
28、是通过跨站构造一个表单，表单的内容则为利用程序的备份功能或者加管理员等功能得到一个高权限。下面将详细的介绍这种技术。寻找跨站漏洞13 / 35如果有代码的话比较好办，我们主要看代码里对用户输入的地方和变量有没有做长度和对”,”;”,”等字符是否做过滤。还有要注意的是对于标签的闭合，像测试 QQ 群跨站漏洞的时候，你在标题处输入alert( test)，代码是不会被执行的，因为在源代码里，有其它的标签未闭合，如少了一个，这个时候，你只要闭合一个，代码就会执行，如：你在标题处输入alert(test)，这样就可以弹出一个 test 的框。如何利用 跨站脚本(Cross-site scripting
29、 ，XSS)漏洞是 Web 应用程序中最常见的漏洞之一。如果您的站点没有预防 XSS 漏洞的固定方法，那么就存在 XSS 漏洞。这个利用 XSS 漏洞的病毒之所以具有重要意义是因为，通常难以看到 XSS 漏洞的威胁，而该病毒则将其发挥得淋漓尽致。这个利用 XSS 漏洞的蠕虫病毒的特别之处在于它能够自我传播。 上的一个用户希望自己能够在网站的友人列表上更“受欢迎”。但是该用户不是通过普通的方法来结交新朋友，而是在自己的个人信息中添加了一些代码，导致其他人在访问他的页面时，会不知不觉地利用 XSS 漏洞将他加为好友。更恶劣的是，它会修改这些人的个人信息，使其他人在访问这些被感染的个人信息时，也会被
30、感染。由于这种呈指数传播的方式，这种病毒才很快就被发现。很难预防站点中的 XSS。因此一定要认真检查您的应用程序是否存在 XSS 漏洞。此外，WebLogic Server 的 encodeXSS()也可以有所帮助。可以试着针对所有牵涉到使用encodeXSS()或其他某个筛选方法的输出找出一种编码模式找出对一种编码模式来说不正确的应用程序往往要比找出 XSS 漏洞要容易的多。更重要的是，不要认为，就因为 XSS漏洞是一个常见问题，所以它危害不大。之所以出现 XSS 漏洞有两个原因。首先，HTML 没有明确区分代码和数据。无法确定指出“这个字符串表示的是数据”。您可以将其放入引号中，但是数据是
31、否包含引号呢？其次，程序在将用户数据发送回浏览器时没有进行有效的转义。这导致包含有（例如说）引号的数据被放入页面中，从而引发了问题。而 AJAX 要提供的好处是，它包含一个专用渠道 XML 链接，其中全是数据而没有代码。这样，就有可能让客户端 AJAX 引擎负责对字符串进行转义、检测不正确的值，等等。说是这么说，直到 AJAX 更为成熟（可能也更为标准化）之前，它只会导致错误的编程和安全漏洞。XSS 漏洞可能造成的后果包括窃取用户会话，窃取敏感信息，重写 Web 页面，重定向用户到钓鱼网站等，尤为严重的是，XSS 漏洞可能使得攻击者能够安装 XSS 代理，从而攻击者能够观察到该网站上所有用户的
32、行为，并能操控用户访问其他的恶意网站。14 / 35对于 XSS 漏洞，我们有两种常见的措施，第一种就是消除漏洞，简而言之就是在输出页面上不提供任何用户的输入信息；另外一种就是想办法来抵御这种漏洞，可以采用对所有用户的输入编码后再输出（可以用 OWASP 的 ESAPI），也可以对所有用户输入进行“白名单”验证，另外，OWASP 还提供了 AntiSamy 对 HTML 页面做优化以消除这个漏洞。防范 XSS 跨站脚本攻击测试篇XSS 也是一种对浏览器的解释器的代码注入攻击，这些攻击能够通过HTML，JavaScript，VBScript ， ActiveX，Flash 等其他客户端语言执行，
33、同时，这些攻击也可能造成用户信息泄露，配置更改，cookie 窃取等造成危害，甚至能够用于对 Web 服务器进行 DOS 攻击。与大部分攻击不同的是，大部分攻击往往只涉及 2 方（攻击者和网站，攻击者和受害者） ，而 XSS 则涉及 3 方，攻击者、客户端、网站， XSS 的目的就是窃取客户端的 cookie 或是其他信息以冒充客户在网站上进行认证，进而在网站上操作任何想进行的操作。下面我们看看到底有哪些类型的 XSS 攻击：Stored XSS（存储式跨站脚本攻击）这是最强大的一种 XSS 攻击，所谓存储跨站攻击是指用户提交给 Web 应用程序的数据首先就被永久的保存在服务器的数据库，文件系
34、统或其他地方，后面且未做任何编码就能显示到 Web 页面，最典型的就是 2005 年在 MySpace 发现的 XSS 漏洞以及利用该漏洞的Samy MySpace Worm。举例，假设我们的网站允许我们给其他用户留言，但事实上我们没有留言而是写入了一段代码：15 / 35那么服务器将会存储这些信息，当用户点击我们伪造的留言时，他的浏览器就会执行我们的脚本。Reflected XSS（反射跨站脚本攻击）这是最常见也是最知名的 XSS 攻击，当 Web 客户端提交数据后，服务器端立刻为这个16 / 35客户生成结果页面，如果结果页面中包含未验证的客户端输入数据，那么就会允许客户端的脚本直接注入到
35、动态页面中。传统的例子是站点搜索引擎，如果我们搜索一个包含特殊HTML 字符的字符串时，通常在返回页面上仍然会有这个字符串来告知我们搜索的是什么，如果这些返回的字符串未被编码，那么，就会存在 XSS 漏洞了。初看上去，由于用户只能在自己的页面上注入代码，所以似乎这个漏洞并不严重，但是，只需一点点社会工程的方法，攻击者就能诱使用户访问一个在结果页面中注入了代码的 URL，这就给了攻击者整个页面的权限。由于这种攻击往往会需要一些社会工程方法，所以研发人员往往不会太过看重，但是我们看如下的例子，在服务器上有如下代码：article.php?title=这就使得浏览器每 3 秒就刷新一次页面，而且是一
36、个死循环的状态，这就形成了 DOS攻击，导致 Web 服务器挂掉。DOM-Based XSS（基于 DOM 的 XSS）这个漏洞往往存在于客户端脚本，如果一个 Javascript 脚本访问需要参数的 URL，且需要将该信息用于写入自己的页面，且信息未被编码，那么就有可能存在这个漏洞。黑盒测试和示例：比较简单的测试是否存在 XSS 漏洞的方法是验证 Web 应用是否会对一个包含了 HTTP响应的简单脚本的访问请求，例如，Sambar 服务器（5.3）包含一个众所周知的 XSS 漏洞，我们向服务器发送如下的请求，从服务器端能够产生一个响应从而在 Web 浏览器中执行http:/server/cg
37、i-bin/testcgi.exe?alert(“Cookie”+document.cookie)这个脚本会在客户浏览器端被执行。我们再举个例子：由于 Javascript 是区分大小写的，有些人会尝试将所有字符转换为大写字符来避免 XSS漏洞，在这时，我们最好还是使用 VBScript，因为它是大小写不区分的：JavaScript.alert(document.cookie);VBScript.alert(DOCUMENT.COOKIE)如果我们已经过滤了” ，那么我们就需要尝试各种编码方法了%3cscript. src=http:/ / 35x3cscript. src=http:/ TO
38、P10 排名第 3 的威胁“遭破坏的认证和会话管理”，简而言之，就是攻击者窃听了我们访问 HTTP 时的用户名和密码，或者是我们的会话，从而得到 sessionID，进而冒充用户进行 Http 访问的过程。由于 HTTP 本身是无状态的，也就是说 HTTP 的每次访问请求都是带有个人凭证的，而 SessionID 就是为了跟踪状态的，而 sessionID 本身是很容易在网络上被监听的到，所以攻击者往往通过监听 sessionID 来达到进一步攻击的目的。这些漏洞往往会存在于 Web 页面的“更改我的密码”、 “记住我的密码”、“忘记密码”、“安全提问”、“注销登录”、“邮件地址”等环节上。那
39、么，一般来说，如何来防范这种漏洞呢？第一， 我们要整体审视我们的架构 认证机制本身必须是简单、集中和标准化的； 使用容器提供给我们的标准 session id； 确保在任何时候用 SSL 来保护我们的密码和 session id第二， 验证认证的实现机制 检查 SSL 的实现方法 验证所有与认证相关的函数 确保“注销登录 ”的动作能够关闭所有的会话 使用 OWASP 的 WebScrab 来测试你的应用如何进行验证测试所谓认证，就是建立确信某物或某人是真实的这么一个过程，authentication 来自于希腊语 ，即真实的，可信的。认证本身依赖于多个认证因子，在计算机安全领域，认证意味着验证
40、通讯发起者的数字身份，常见的认证过程就是用户登录认证，所谓认证测试就是理解系统中的认证机制并找到方法绕过该认证机制。认证测试需要考虑的点有很多，下面我们逐一来进行解释说明 在加密通道上传递密码18 / 35原则上，用户的认证必须通过加密信道进行传输，我们在这里的目的不是要验证诸如HTTPS 是否安全，我们要验证的仅仅是用户的认证信息是否已经被加密了。在用户登录时，最常见的方式是用户输入用户名和密码后，通过 POST 方法传输，一般来说，认证信息或者是通过不安全的 HTTP 传递，或者是通过加密的 HTTPS 传递。我们注意到，甚至有些网站在登录页面显示给我们的是 HTTPS，但事实上却仍然是用
41、 HTTP的，最简单的方法就是用网络监听工具，如 SnifferPro 或 Ethereal 来判断是否是真实加密了。下面，我们用 OWASP 的 WebScrab 截取一些信息来做个例子假设，登录页面要求用户输入用户名和密码，然后有一个“提交”按钮，那么在WebScrab 中我们得到如下的请求数据：POST http:/ HTTP/1.1Host: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404Accept: text/xml,application/xml,applic
42、ation/xhtml+xmlAccept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-aliveReferer: http:/ JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!Content-Type: application/x-www-form-urle
43、ncodedContent-length: 64delegated_service=218 U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/2008040419 / 35Accept: text/xml,application/xml,application/xhtml+xml,text/htmlAccept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-A
44、live: 300Connection: keep-aliveReferer: https:/ language=English;Content-Type: application/x-www-form-urlencodedContent-length: 50Command=Login U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404Accept: text/xml,application/xml,application/xhtml+xml,text/htmlAccept-Language: it-it,it;q=0.8,en-us;q=0.
45、5,en;q=0.3Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-aliveReferer: http:/ SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6FContent-Type: application/x-www-form-urlencodedContent-length: 45User=test U; Windows NT 5.1; it; r
46、v:1.8.1.14) Gecko/20080404Accept: text/xml,application/xml,application/xhtml+xml,text/htmlAccept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-aliveReferer: https:/ Mon, 30 Jun 2008 07:55:11 GMT
47、If-None-Match: “43a01-5b-4868915f“从上面的例子可以看到，用户名和密码都以明文的方式在 URL 里存在，而不像上面的几个例子中都在消息体中，但并不是说攻击者就可以很容易看到这些信息，TLS/SSL 毕竟是安全性很高的协议，整个 HTTP 数据包是加密的，但仍然要注意的是这些用户名和密码在传输过程中会被存储在代理和服务器上，这也就有可能会泄露用户信息。 用户列举测试法这种测试，简而言之是通过与应用的认证机制的交互，尝试能否获得一些正确的用户名，这对后面我们会讲到的暴力破解很有效，确认了正确的用户名就能用暴力破解去尝试密码了。通常，WEB 应用对于用户名正确的输入会有一些信息反馈，例如，如果我们输错了密码，那么有时会反馈告知我们系统存在该用户，或密码错误。所以，作为测试人员，就要尝试不同的请求来判断系统是否会有不同的返回。对于 HTTP 的响应消息测试： 输入正确的用户名和密码期望结果：使用 WebScrab 抓取服务器的返回信息（HTTP 200 Response,消息的长度） 输入正确的用户名 /错误的密码21 / 35期望结果：从浏览器我们往往会得到如下的返回或者是如下返回甚至是如下的返回Login for User foo: invalid password
