《黑客攻防技术宝典：Web实战篇》第二版习题答案-Toy模板网

这篇具有很好参考价值的文章主要介绍了《黑客攻防技术宝典：Web实战篇》第二版习题答案。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

第2章：核心防御机制

1. 为什么说应用程序处理用户访问的机制是所有机制中最薄弱的机制？

典型的应用程序使用三重机制（身份验证、会话管理和访问控制）来处理访问。这些组件之间高度相互依赖，其中任何一个组件存在缺陷都会降低整个访问控制机制的效率。例如，攻击者可以利用身份验证机制中的漏洞以任何用户身份登录，并因此获得未授权访问权限。如果能够预测令牌，攻击者就可以假冒成任何已登录用户并访问他们的数据。如果访问控制不完善，则任何用户都可以直接使用应该受到保护的功能。

2. 会话与会话令牌有何不同？

会话是服务器上保存的一组数据结构，用于追踪用户与应用程序交互的状态。会话令牌是应用程序为会话分配的一个特殊字符串，用户需要在连接提出请求的过程中提交该字符串，以重新确认自己的身份。

3. 为何不可能始终使用基于白名单的方法进行输入确认？

许多时候，应用程序可能会被迫接受与已知为“良性”输入的列表或模式不匹配的待处理数据。例如，许多用户的姓名包含可用在各种攻击中的字符。如果应用程序希望允许用户以真实姓名注册，就需要接受可能的恶意输入，并确保安全处理这些输入。

4.攻击者正在攻击一个执行管理功能的应用程序，并且不具有使用这项功能的任何有效证书。

为何他仍然应当密切关注这项功能呢？
攻击者可以利用任何访问控制核心机制中的缺陷未授权访问管理功能。此外，攻击者以低权限用户身份提交的数据最终将向管理用户显示，因此，攻击者可以提交一些恶意数据，用于在管理用户查看这些数据时攻破他们的会话，从而对管理用户实施攻击。

5. 旨在阻止跨站点脚本攻击的输入确认机制按以下顺序处理一个输入：
(1) 删除任何出现的<script>表达式；

(2) 将输入截短为50个字符；

(3) 删除输入中的引号；

(4) 对输入进行URL解码；

(5) 如果任何输入项被删除，返回步骤(1)。
是否能够避开上述确认机制，让以下数据通过确认？
“><script>alert(“foo”)</script>

是。如果没有第4步，此机制将是可靠的，能够过滤其旨在阻止的特定项目。但是，由于输入在执行过滤步骤后被解码，攻击者只需要对有效载荷中的选定字符进行URL编码，就可以避开这种过滤：
">
如果首先执行第4步，或根本不执行该步骤，攻击者将不可能避开上述过滤。

第3章：Web应用程序技术

1. OPTIONS方法有什么作用？

OPTIONS方法要求服务器报告可用于特定资源的HTTP方法。

2.If-Modified-Since和If-None-Match消息头的作用是什么？它们为何引起攻击者的兴趣？

If-Modified-Since消息头用于指定浏览器最后一次收到被请求的资源的时间。If-None-Match消息头用于指定实体标签，在最后一次收到被请求的资源时，服务器与被请求的资源一起发布该标签。
在上述两种情况下，这些消息头用于支持浏览器中的内容缓存，服务器通过它们指示浏览器使用资源的缓存副本，而非资源的完整内容（如果这样做没有必要）。
在攻击应用程序时，浏览器可能已经缓存了攻击者感兴趣的资源（如JavaScript文件）副本。如果删除这两个消息头，就可以覆写浏览器的缓存信息，确保服务器以攻击者希望查看的新的资源副本做出响应。

3.当服务器设置cookie时，secure标签有什么意义？

secure标签用于向浏览器发出以下指示：只应通过HTTPS连接、绝不能通过未加密的HTTP连接重新提交cookie。

4.常用状态码301与302有什么不同？

301状态码告诉浏览器被请求的资源已永久移动到其他位置。在当前浏览器会话期间，如果浏览器需要访问最初请求的资源，它将使用在301响应中指定的位置。
302状态码告诉浏览器被请求的资源已临时移动到其他位置。下次浏览器需要访问最初请求的资源时，它将从最初请求的位置请求此资源。

5.使用SSL时，浏览器如何与Web代理实现互操作？

浏览器向代理发送一个CONNECT请求，将目标主机名和端口号指定为此请求中的URL。如果代理允许该请求，它将返回一个状态码为200的HTTP响应，使TCP连接保持开放，并在随后作为指定目标的纯TCP级中继。

第4章：解析应用程序

1. 当解析一个应用程序时，会遇到以下URL：

https://wahh-app.com/CookieAuth.dll?GetLogon?curl=Z2Fdefault.aspx
据此可以推论出服务器使用何种技术？该技术的运作方式可能是怎样的？
文件名CookieAuth.dll说明应用程序正使用Microsoft ISA Server。这是登录功能的URL，成功登录后，应用程序将重定向到URL /default.aspx。

2.如果所针对的应用程序是一个Web论坛，并且只发现了一个URL：

http://wahh-app.com/forums/ucp.php?mode=register
如何通过它获得论坛成员列表？
此URL是phpBB Web论坛软件的常用“指纹”。因特网上提供了有关此软件的大量信息，读者可以自己安装该软件以进行体验。可以通过以下URL获取成员列表：
http://wahh-app.com/forums/memberlist.php
通过类似于下面的URL可以获取单个用户的用户资料：
http://wahh-app.com/forums/profile.php?mode=viewprofile&u=2
phpBB软件中包含各种漏洞，因此，读者应确认所使用的版本并研究任何相关问题。

3.当解析一个应用程序时，遇到以下URL：

https://wahh-app.com/public/profile/Address.asp?action=view&location=default
据此推断服务器端应使用何种技术。可能还存在哪些其他内容和功能？
.asp文件扩展名说明应用程序正使用Microsoft的Active Server Pages（ASP）。/public路径说明可能存在其他有用的路径，如/private。action=view参数表明可能存在其他操作，如edit、add或delete。应调查location=default参数的用途，其中可能包含用户名，因此应在应用程序中探查路径遍历漏洞。

4.Web服务器的一个响应包含以下消息头：

Server:Apache-Coyote/1.1
这表示服务器使用何种技术？
如果该消息头是准确的，说明服务器正运行Apache Tomcat。Tomcat是一种Java Servlet容器，因此应用程序可能使用的是Java和JSP技术。

5.假设正在解析两个不同的Web应用程序，在每个应用程序中请求URL /admin.cpf。每个请求返回的响应消息头如下所示。仅由这些消息头能否确定每个应用程序中存在被请求的资源？
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Mon, 20 Jun 2011 14:59:21 GMT
Content-Location: http://wahh-
app.com/includes/error.htm?404;http://wahh-app.com/admin.cpf
Date: Mon, 20 Jun 2011 14:59:21 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 2117

HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: Basic realm=”Wahh Administration Site”
Content-Type: text/html;charset=utf-8
Content-Length: 954
Date: Mon, 20 Jun 2011 15:07:27 GMT
Connection: close

第一个响应使用HTTP状态码200，通常这表示请求已成功提交。但是，Content-Location消息头表示从中获取该响应的位置。这似乎是一个动态生成的错误页面，并且其查询字符串中包含值404，表明响应中包含定制的“文件未发现”消息。
第二个响应使用HTTP状态码401，表明被请求的资源存在，但用户必须提供HTTP验证证书才能访问该资源。
对于以上每一种情况，可以使用相同扩展名（如/iuwehuiwefuwedw.cpf）请求同一目录中的某个确定不存在的项目，并比较相关响应，以证实上述结论。第一个应用程序可能会返回与原始响应极其类似的响应。第二个应用程序可能会返回包含“文件未发现”消息的不同响应。

第5章：避开客户端控件

1.通过客户端传送的数据如何阻止破坏性攻击？

可以使用保存在服务器上的密钥对数据进行加密或散列处理，就像选择性地使用ASP.NET ViewState一样。除非攻击者以某种方式获得密钥，否则他们将无法加密任意数据，或计算出任意数据的有效散列。但是，攻击者仍然能够将一种情形中的数据用于另一种情形——例如，可以用廉价商品的加密价格替代昂贵商品的加密价格。为防止这种攻击，应用程序应在受保护的数据中包含足够的上下文信息，以便于确认所采用的数据源自同一情形——例如，可以将产品代码和价格组合在一个加密对象中。

2.应用程序开发者希望阻止攻击者对登录功能发动蛮力攻击。由于攻击者可能以多个用户名为目标，开发者决定将登录尝试失败次数保存在一个加密cookie中，阻止任何失败次数超过5次的请求。有什么办法能够避开这种防御？

这种防御很容易突破。攻击者不需要提交跟踪登录尝试失败次数的cookie。他们可以在浏览器中禁用cookie，或使用自动化脚本不通过相关cookie提交请求。
其他防御措施包括使用CAPTCHA控件暂时阻止攻击者，或在登录失败次数达到五次后阻止源IP地址，但是，这样做可能会对使用代理或NAT防火墙的多个用户造成负面影响。

3.某应用程序包含一个执行严格访问控件的管理页面。该页面上有一个连接到另一台Web服务器的诊断功能链接。只有管理员才能够访问这些功能。不执行另一种验证机制，下列哪一种（如果有）客户端机制可用于为诊断功能提供安全的访问控件？要选择一个解决方案，是否还需要了解其他信息？

(1) 诊断功能能够检查HTTP Referer消息头，证实请求由主管理页面提交。
(2) 诊断功能能够验证收到的cookie，证实其中包含访问主应用程序所需的有效会话令牌。
(3) 主应用程序可在请求的一个隐藏字段中设置一个身份验证令牌。诊断功能能够确认这一点，证实用户在主应用程序中有一个会话。
(1) 攻击者可以将Referer消息头设置为任意值，因此它不是执行任何访问控制检查的安全方法。
(2) 这种方法仅在包含诊断功能的Web服务器为源Web服务器的父域或子域，且对会话cookie进行了相应地审查时有效，否则cookie将不会被提交到诊断服务器。将需要为诊断服务器实施后端机制，以确认随源服务器一起提交的令牌。
(3) 无论诊断服务器的域名是什么，这种方法都有效。只要身份验证令牌不可预测，并且以安全方式传输（请参阅第7章），这种方法就是安全的。此外，还需要实施用于验证令牌的后端机制。

4.如果一个表单字段的属性为disabled=true，那么它就不会和表单的其他内容一起提交。如何才能改变这种情况呢？

有两种基本的方法：
(1) 可以拦截提交表单的请求，并添加被禁用的参数。
(2) 可以拦截包含表单的响应，并删除disabled=true属性。

5. 应用程序可采取什么方法确保客户端执行了输入确认？

应用程序没有办法可以确保客户端执行了输入确认。在客户端上执行的各种操作完全由用户控制。

第六章

1. 在测试一个使用joe和pass证书登录的Web应用程序的过程中，在登录阶段，在拦截代理服务器上看到一个要求访问以下URL的请求：

http://www.wahh-app.com/app?action=login&uname=joe&password=pass

如果不再进行其他探测，可以确定哪3种漏洞？

     (a) 由于证书在该URL的查询字符串中传送，因此，这些证书将面临通过浏览器历史记录、Web服务器和IDS日志或直接在屏幕上显示而遭到未授权泄露的风险。
    (b) 证书通过未加密HTTP连接传送，因而易于被位于网络适当位置的攻击者拦截。
    (c) 密码为一个包含四个小写字母的英文单词。应用程序并未实施任何有效的密码强度规则。

2. 自我注册功能如何会引入用户名枚举漏洞？如何防止这些漏洞？

通常，自我注册功能非常易于受到用户名枚举攻击，因为用户可以选择自己的用户名，并且应用程序不允许用户注册现有用户名。
    应用程序可以通过以下两种方法防止攻击者通过滥用自我注册功能来实施用户名枚举攻击：
    (a) 应用程序可以生成自己的用户名，然后在每名新用户提交了所需的个人信息后向其分配一个无法预测的用户名。
    (b) 可以在自我注册过程的第一个步骤要求用户输入他们的电子邮件地址。然后，应用程序向用户发送一封电子邮件，该邮件包含一个URL，用户可以使用该URL继续注册过程。如果提供的电子邮件已注册，则在电子邮件中向用户通知这一情况。

3. 某登录机制由以下步骤组成：

(a) 应用程序要求用户提交用户名和密码；

(b) 应用程序要求用户提交值得纪念的词中的两个随机选择的字母。

应用程序为何要求用户分两个阶段提供所需的信息？如果不这样做，登录机制将存在什么缺陷？

要求用户提交值得纪念的词中的两个随机选择的字母，而不是整个单词，其原理在于：即使攻击者截获了用户在一次登录过程中提交的所有证书，他仍然无法使用这些证书再次登录，因为这时应用程序会要求用户提交另外两个字母。
如果应用程序在一个步骤中要求用户提交全部所需信息，那么它必须提前选定随机选择的字母，而此时它并不知道正在进行验证的用户的身份。这意味着，即使攻击者只知道值得纪念的词中的两个字母，他仍然可以通过重复加载登录表单，直到应用程序请求那两个单词，从而使用截获的证书登录。
为避免这种缺陷，应用程序必须在用户每次成功登录后选择另外两个单词，并将其存储在用户配置文件中，直到用户再次成功登录。当用户在登录的第一个阶段确认自己的身份后，将从用户配置文件中检索这两个字母，并要求用户提交相同的字母。这样，即使攻击者在一次登录中获取了用户证书，他仍然需要等待非常长的一段时间，直到应用程序再次要求用户提交相同的字母。

4. 一个多阶段登录机制要求用户首先提交用户名，然后在后续阶段中提交其他信息。如果用户提交了任何无效的数据，将立即返回到第一个阶段。这种机制存在什么缺点？如何修复这种漏洞？

尝试猜测有效证书的攻击者可以轻松确定单个数据项是否有效。攻击者可以利用应用程序的这种行为将蛮力攻击问题细分成一系列单独的问题。
要避免这种漏洞，可以要求应用程序即使在攻击者提交了无效数据项后仍继续完成所有登录步骤，并在最后一个步骤完成后返回常规“登录失败”消息，而不论是哪个数据项导致了登录失败。这样做可以显著增加攻击者使用蛮力猜测用户证书时所需提交的请求数。

5. 应用程序在登录功能中整合了反钓鱼机制。在注册过程中，每名用户从应用程序提供的大量图片中选择一幅特殊的图片。登录机制由以下步骤组成：

(1) 用户输入其用户名和出生日期；

(2) 如果这些信息无误，应用程序向用户显示他们选择的图片，如果信息有误，则随机显示一幅图片；

(3) 用户核实应用程序显示的图片，如果图片正确，则输入他们的密码。

反钓鱼机制的作用在于：它向用户确认，他们使用的是真实而非“克隆”的应用程序，因为只有真正的应用程序才能显示正确的图片。

反钓鱼机制给登录功能造成什么漏洞？这种机制是否能够有效阻止钓鱼攻击？

攻击者可以利用反钓鱼机制将用于猜测有效证书的过程划分成两个阶段。攻击者可以通过两次完成步骤（1）来核实特定用户名和出生日期是否有效。如果两次返回了同一幅反钓鱼图片，则说明猜测的证书肯定有效；否则即无效。攻击者可以通过脚本攻击迅速遍历目标用户的所有出生日期，从而猜测出正确的值。

更糟糕的是，这种机制并不能有效阻止钓鱼攻击。克隆Web应用程序将收到用户在步骤（1）中提交的用户名和出生日期，并可以将这些信息直接提交给原始应用程序，以获取在步骤（2）中向用户显示的正确图片。如果告知用户通过该图片来核实应用程序的真实性，则这种机制实际上可能会起到反作用，并可能导致用户登录他们在其他情况下并不会信任的钓鱼网站。

第7章

1. 登录一个应用程序后，服务器建立以下cookie：

Set-cookie: sessid=amltMjM6MTI0MToxMTk0ODcwODYz;

一个小时后，再次登录并得到以下cookie：

Set-cookie: sessid=amltMjM6MTI0MToxMTk0ODc1MTMy;

通过这些cookie，可以得出什么推论？

sessid cookie包含一个Base64编码的字符串。解码收到的两个cookie可得到以下值：
jim23:1241:1194870863

jim23:1241:1194875132

解码后的cookie包含三个以分号分隔的数据项。初看来，这三个值可能包含用户名、数字用户标识和一个不断变化的数值。最后一项包含10个数字，看起来像一个Unix时间值。转换这两个值后得到以下信息：

Mon, 12 Nov 2007 12:34:23 UTC

Mon, 12 Nov 2007 13:45:32 UTC

这表示创建会话的时间。
因此，会话令牌似乎由有意义的用户相关数据和一个可预测的数据项构成。理论上，可以实施蛮力攻击来猜测发布给其他应用程序用户的令牌。

2. 某个应用程序使用由6个字符组成的数字字母会话令牌和由5个字符组成的数字字母密码。它们全都由某种无法预测的算法随机生成。其中哪一个最有可能成为蛮力猜测攻击的目标？列出影响你做出决策的各种不同因素。

与由5个字符组成的密码相比，由6个字符组成的会话令牌的可能值要多得多。因此，似乎较短的密码是最有价值的攻击目标。

但是，针对密码的蛮力攻击与针对会话令牌的蛮力攻击之间存在一些重要的差异。在尝试猜测密码时，必须同时提交用户名和密码，因此每个请求最多只能针对一个账户发动攻击，甚至可能无法针对任何账户发动攻击。你可能已经知道一些用户名，或者能够枚举出用户名，或者可能需要同时猜测用户名和密码。登录机制可能包含多个阶段，或者响应速度较慢。登录机制还可能实施了账户锁定机制，这会显著降低你的攻击速度。

另一方面，在尝试猜测会话令牌时，通常可以同时针对多个用户。应用程序中可能有20、2000或0位已登录用户。如果某位用户当前并未登录，则无法以这种方式对其实施攻击。在收到大量无效令牌时，应用程序根本没有办法实施任何类型的“锁定”。正常情况下，令牌猜测攻击的速度非常快，通常，包含无效令牌的请求会立即收到包含错误消息或重定向的响应。

简言之，这个问题并没有确定的答案。哪一个是最有价值的目标，将取决于你的目的和应用程序的其他因素。如果许多用户都已登录并且只需要攻破其中一位用户，则最好是针对会话实施攻击。如果希望攻破某个极少登录的管理账户，则实施密码猜测攻击会更加有效。

3. 登录位于以下URL的一个应用程序后：

https://foo.wahh-app.com/login/home.php

服务器建立以下cookie：

Set-cookie: sessionId=1498172056438227; domain=foo.wahhapp.

com; path=/login; HttpOnly;

然后访问下面的URL。浏览器会将sessionId cookie提交给哪些URL？（选出全部答案。）

(1) https://foo.wahh-app.com/login/myaccount.php

(2) https://bar.wahh-app.com/login

(3) https://staging.foo.wahh-app.com/login/home.php

(4) http://foo.wahh-app.com/login/myaccount.php

(5) http://foo.wahh-app.com/logintest/login.php

(6) https://foo.wahh-app.com/logout

(7) https://wahh-app.com/login/

(8) https://xfoo.wahh-app.com/login/myaccount.php

(1)是。其中的域和路径均与cookie范围相匹配。

(2) 否。其中的域与cookie的域范围不同，也不是它的子域。

(3) 是。其中的域是范围中指定的域的子域，且路径与范围相匹配。

(4) 是。其中的域和路径均与cookie范围相匹配。虽然采用了HTTP协议，但并未指定secure标记，因此仍然会传送该cookie。

(5) 是。其中的域与cookie范围相匹配。由于路径范围在/login后并没有斜线，因此，该范围将不仅包括路径/login/，而且包括任何其他与/login前缀匹配的路径。

(6) 否。其中的路径与cookie范围不匹配。

(7) 否。其中的域是在范围中指定的域的父域。

(8) 否。其中的域与cookie的域范围不同，也不是它的子域。

4. 所针对的应用程序除使用主会话令牌外，还使用每页面令牌。如果收到一个不按顺序发送的每页面令牌，整个会话将被终止。假设发现了某种缺陷，可通过它预测或截获应用程序发布给当前正在访问应用程序的其他用户的令牌，那么是否能够劫持他们的会话？

攻击者仍有可能实施会话劫持攻击。如果攻击者获得了发布给某个用户的令牌，就可以立即使用那些令牌提出请求，并且服务器将接受这些请求。但是，如果该用户随后向应用程序提出另一个请求，其提交的每页面令牌将出现顺序错误，整个会话将被终止。因此，如果用户仍然在与应用程序交互，则实施攻击的可能性会非常低。如果攻击者只希望利用用户的权限执行特定操作，则可以实施一次脚本攻击，在有限的时间间隔内执行所需操作。

5. 登录一个应用程序后，服务器建立以下cookie：

Set-cookie: sess=ab11298f7eg14;

单击“退出”按钮后，应用程序执行以下客户端脚本：

document.cookie=”sess=”;

document.location=”/”;

通过这种行为，可以得出什么结论？

退出功能存在缺陷。

上述脚本将使浏览器中当前保存的会话令牌失效，也就是说，随后的任何请求将不会提交之前的令牌值。然后，该脚本将启动一个指向应用程序起始页面的重定向。任何访问受保护功能的尝试将遭到拒绝，因为相关请求并不属于通过验证的会话的一部分。

但是，客户端应用程序并未将已执行了退出操作这一信息传达给服务器。服务器上的用户会话将仍处于活动状态，如果将之前发布的令牌提交给服务器，服务器将继续接受该令牌。在会话超时或以其他方式被清除之前，这种情况会一直持续。在这段时间内，已通过某种方式截获或猜测出令牌值的攻击者就可以继续使用令牌来劫持用户的会话。

第8章

1. 一个应用程序可能通过使用HTTP Referer消息头实施访问控制，但它的正常行为并没有公开表露这一点。如何检测出这种缺陷？

选择一系列你有权访问的重要应用程序功能。通过提交经过修改的Referer消息头或不带该消息头的请求访问以上每一项功能。如果应用程序拒绝这些请求，则说明它很可能易于受到攻击。然后，尝试通过另一个不具有相关权限的用户提出相同的请求，但每次提交原始的Referer消息头。如果应用程序现在接受这些请求，则说明应用程序肯定易于受到攻击。

2. 登录一个应用程序后，被重定向到以下URL：

https://wahh-app.com/MyAccount.php?uid=1241126841

应用程序似乎向MyAccount.php页面提交一个用户标识符。已知的唯一标识符是自己的标识符。如何测试应用程序是否使用这个参数以不安全的方式实施访问控制？

应测试以下测试（按效率排序）：

(1)使用相同的语法格式将uid值修改为其他值。如果应用程序仍然返回你自己的账户资料，则说明应用程序可能不易于受到攻击。

(2) 如果能够注册或以其他方式访问另一个用户账户，可以使用该账户登录以获得其他用户的uid值。然后使用自己的原始用户权限，并用这个新uid值替代自己的uid值；如果这时应用程序显示有关其他用户的敏感数据，则说明应用程序易于受到攻击。

(3) 使用一段脚本从自己的uid获得数千个值，并确定（如果提交这些值）应用程序是否会返回任何其他用户的资料。
(4) 使用一段脚本请求介于0和9999999999之间的随机uid值（在本示例中），并确定应用程序是否会返回任何其他用户的资料。

3. 因特网上的一个Web应用程序通过检查用户的来源IP地址实施访问控制。为什么这种行为可能存在缺陷？

攻击者可以假冒其他用户的IP地址，虽然实际上要做到这一点可能极其困难。更重要的是，如果因特网上的多个终端用户位于同一Web代理服务器或NAT防火墙之后，则这些用户可能共享同一IP地址。

在这种情况下，要使基于IP的访问控制发挥效率，一种方法是将其作为深层防御措施，以确保尝试访问管理功能的用户位于组织的内部网络中。当然，那些功能还应由强大的身份验证和会话处理机制进行保护。

4. 某应用程序的唯一用途是为公众提供可搜索的信息仓库。该应用程序并未使用任何验证或会话管理机制。该应用程序应执行何种访问控制？

该应用程序并未对访问权限进行任何水平或垂直划分，因此没有必要实施访问控制来区分不同的个体用户。
即使所有用户均属于同一类别，应用程序仍然需要限制用户可以执行的操作。一个强健的解决方案是应用最低权限原则，以确保应用程序体系架构中的所有用户角色具有运行应用程序所需的最小权限。例如，如果用户只需要对数据的读取访问权限，则应用程序应使用一个低权限账户（仅具有对相关表的只读权限）来访问数据库。

5. 在浏览一个应用程序的过程中遇到几个应防止未授权访问的敏感资源，它们的文件扩展名为.xls。这种情况为何应立即引起注意？

这些文件为Excel电子表格，它们属于静态资源，应用程序无法对其实施任何访问控制（如通过动态脚本）。应用程序可能会通过其他方法（如Web服务器层）来保护这些资源，但通常情况下并非如此。应立即检查是否可以不经验证而访问这些资源。

第9章

1. 如果要通过实施UNION攻击、利用SQL注入漏洞获取数据，但是并不知道最初的查询返回的列数，如何才能查明这个值？

可以通过两个简单的方法确定列数。其一，可以SELECT每个列中的类型中性值NULL，并逐渐递增列数，直到应用程序返回数据，表明指定了正确的列数，例如：
' UNION SELECT NULL--

' UNION SELECT NULL, NULL--

' UNION SELECT NULL, NULL, NULL--

请注意，在Oracle上，需要在上述每种情况的最后一个NULL后添加FROM DUAL。
另外，可以注入ORDER BY子句并递增指定列，直到引发错误，表明请求了无效的列：
' ORDER BY 1--

' ORDER BY 2--

' ORDER BY 3--

2. 已经确定一个字符串参数中的SQL注入漏洞，已经确信数据库为MS-SQL或Oracle，但当前无法获得任何数据或错误消息确定到底是哪个数据库。如何才能查明这一点？

一种确认数据库类型的简单方法，是使用数据库特定的字符串串联语法在所控制的查询中构建某个良性输入。例如，如果原始参数值为London，则可以轮流提交以下数据项：

'||' London

'+'London

如果第一个数据项导致和原始参数值相同的行为，说明数据库可能为Oracle。如果第二个数据项导致和原始参数值相同的行为，说明数据库可能为MS-SQL。

3. 已经在应用程序的许多位置提交了一个单引号，并通过得到的错误消息确定几个潜在的SQL注入漏洞。下列哪一种方法能够以最快的速度确定专门设计的输入是否会对应用程序的处理过程造成影响？

(a) 注册一个新用户

(b) 更新个人资料

(c) 注销服务

虽然看似违背常理，但用户注册功能可能是最安全的。注册功能通常使用INSERT语句，如果修改这些语句，并不会影响到其他记录。用于更新个人资料的功能可能使用条件性UPDATE语句，如果注入' or 1=1--之类的有效载荷，可能会导致数据表中的所有记录遭到修改。同样，注销功能可能使用条件性DELETE语句，如果操作不当，也可能影响到其他用户。

也就是，我们不可能提前确定某个功能会执行哪些语句；在执行测试之前，应向应用程序所有者警告可能导致的风险。

4. 在登录功能中发现了一个SQL注入漏洞，并尝试使用输入' or 1=1--来避开登录，但攻击没有成功，生成的错误消息表明--字符串被应用程序的输入过滤删除。如何解决这个问题？

有一种简单的方法可以达到相同的效果，即使用输入' or 'a'='a，而无需使用注释符号。

5. 已经发现了一个SQL注入漏洞，但由于应用程序允许任何包含空白符的输入，因而无法实施任何有效的攻击。如何解除这种限制？

可以使用SQL注释字符分隔注入的有效载荷中的关键字和其他项目。例如：

'UNIONSELECTusername,passwordFROMusers--

6. 在将其合并到SQL查询之前，应用程序并不配对用户输入中出现的所有单引号。假设已经在一个数字字段中发现了一个SQL注入漏洞，但需要在攻击有效载荷中使用一个字符串值。不使用单引号，如何在查询中插入字符串？

可以使用CHAR命令通过ASCII数字字符代码返回字符串。例如，在Oracle上，字符串FOO可以表示为：

CHAR(70)||CHAR(79)||CHAR(79)

7. 在极少数情况下，应用程序在用户提交的输入中使用参数化查询，以不安全的方式建立动态SQL查询。什么时候会出现这种情况？

在将用户提交的输入置入查询的其他元素（如表和列名称），而非查询参数中时，将会出现这种情况。参数化查询无法使用这些项目的占位符进行预编译，因此需要采用不同的解决方案（可能需要基于严格的输入确认）。

8. 假设已经提升了在应用程序中的权限，现在完全拥有管理员访问权限，这时如果在某个用户管理功能中发现了一个SQL注入漏洞，如何利用这个漏洞进一步扩大攻击范围？

因为已经具有管理员访问权限，因此可以使用应用程序本身检索所需的任何数据，也就是说，不必通过SQL注入攻击来获取应用程序本身的数据。但是，仍然可以利用这种攻击来访问任何与保存在同一数据库中的其他应用程序有关的数据，或者提升自己在数据库或基础操作系统中的权限，或者攻破数据库服务并将攻击范围扩大到更广泛的内部网络。

9. 在攻击一个并未保存任何敏感数据、也未实施任何身份验证或访问控制机制的应用程序的情况下，如何排列下列漏洞的重要性？

(a) SQL注入

(b) XPath注入

(c) OS命令注入

XPath注入仅可用于从目标XML文件中检索数据。因此，如果应用程序不包含任何敏感数据，则这种漏洞并不会导致严重的后果。同样，利用SQL注入漏洞并不能从数据库中提取任何敏感数据。但是，有时可以利用这类攻击提升在数据库中的权限，并以其他方式实施攻击。

在某些情况下，SQL注入漏洞可能是一个更加严重的漏洞。另一方面，OS命令注入则始终是一个高风险的漏洞，因为攻击者可以利用它直接攻破基础服务器，并可将其作为针对内部系统的其他攻击的起点。

10. 假如正在检测一个允许搜索个人资料的应用程序功能，并且怀疑该功能正访问某数据库或Active Directory后端。如何确定到底是哪一种情况？

如果该功能正访问数据库，则提交SQL通配符%作为搜索查询可能会返回大量记录。同样，如果该功能正访问Active Directory，则提交通配符*作为搜索查询可能会返回大量记录。在其他系统中，这两个通配符都不会造成相同的效果。

第10章

1. 某网络设备提供用于执行设备配置的Web界面。为什么这种功能通常易于受到操作系统命令注入攻击？

用于配置网络设备的应用程序通常包含使用正常的Web脚本API无法轻松实现的功能，如用于重新启动设备、循环访问日志文件或重新配置SNMP的功能。通常，使用一行操作系统命令可以轻松执行这些任务。因此，许多时候，应用程序开发者通过将相关用户输入直接合并到shell命令字符串中来实现这些功能。

2. 在测试以下URL时：

http://wahh-app.com/home/statsmgr.aspx?country=US

将country参数的值更改为foo导致了以下错误消息：

Could not open file: D:\app\default\home\logs\foo.log (invalid file).

可以采取哪些步骤对应用程序实施攻击？
应用程序似乎将用户提交的输入合并到用于文件系统操作的文件路径中，并且可以通过提交专门设计的输入来访问服务器上的任意文件。因此，应尝试使用../遍历序列访问不同的目录。由于.log将被附加到输入之后，因此应尝试使用NULL字节终止文件名。请注意，出现在错误消息中的home目录可能与出现在URL中的home目录为同一目录，这为Web根目录中的项目的位置提供了线索。

3. 在对一个在POST请求中以XML格式传送数据的应用程序进行测试时，可以利用哪种漏洞从服务器的文件系统中读取任意文件？要成功实施攻击，必须满足哪些先决条件？

应用程序可能易于受到XML外部实体（XXE）注入。检索任意文件的内容的先决条件如下：

(a) 应用程序使用的XML解释器必须支持外部实体；

(b) 应用程序必须在其响应中回显请求中的XML元素的内容。

4. 向ASP.NET平台上运行的应用程序提出以下请求：

POST /home.aspx?p=urlparam1&p=urlparam2 HTTP/1.1

Host: wahh-app.com

Cookie: p=cookieparam

Content-Type: application/x-www-form-urlencoded

Content-Length: 15

p=bodyparam

应用程序执行以下代码：

String param = Request.Params[“p”];

请问param变量的值是什么？

param变量的值为urlparam1,urlparam2,bodyparam,cookieparam。

5. HPP是HPI的前提，还是HPI是HPP的前提？

严格来说，这两种攻击都不是对方的前提。

虽然HPI攻击通常包含HPP，但这不是必须的。例如，HPI攻击可能会将某个全新的参数注入到后端请求中，以干扰应用程序的处理过程。但这种类型的攻击并不依赖于应用程序在处理多个同名参数时表现的任何特殊行为。

通常，HPP攻击可以不包括HPI，特别是在对用户输入执行多层处理的情况下。例如，一些针对Internet Explorer XSS过滤器的攻击使用HPP技巧，但并不在后端请求中注入任何参数。

6. 某应用程序包含一项功能，该功能向外部域提出请求，并返回这些请求的响应。为防止服务器端重定向攻击检索应用程序自己的Web服务器上的受保护资源，应用程序阻止了以localhost或127.0.0.1为目标的请求。如何突破这种防御，以访问服务器上的资源？

服务器的回环IP地址有许多备选表示形式，可将其用于避开应用程序的过滤。例如：

(a) 127.1

(b) 127.000.0.1

(d) 这些表示形式的二进制或八进制变体，如017700000001

7. 某应用程序使用一项用于用户提交反馈的功能。该功能允许用户提交他们的电子邮件地址、邮件主题及详细的反馈。然后，应用程序以用户提交的主题和反馈为邮件正文，从用户的电子邮件地址向feedback@wahh-app.com发送一封电子邮件。以下哪一种方法能够有效防御邮件注入攻击？

(a) 在邮件服务器上禁用邮件中继。

(b) 使用feedback@wahh-app.com硬编码RCPT TO字段。

针对此应用程序功能的邮件注入攻击不需要邮件服务器支持邮件中继。如果其他邮件标头包含用户可控制的输入，硬编码RCPT TO字段也无法防范邮件注入，因为攻击者可以使用另一个RCPT TO行注入另一个收件人。在这种情况下，最有效的防御是严格确认所有用户提交的输入，以确保其中不包含任何转行符或其他SMTP元字符。

第11章

1. 何为强制浏览？可以通过它确定哪些漏洞？

强制浏览包括避开浏览器导航对应用程序功能访问顺序实施的任何限制。应使用强制浏览测试多阶段过程或其他区域中的错误假设。通常，这些假设会导致可以通过使用强制浏览加以利用的访问控制漏洞。

2. 为防止不同类型的攻击，应用程序对用户输入实施各种全局过滤。为防止SQL注入，它将出现在用户输入中的单引号配对。为防止针对一些本地代码组件的缓冲区溢出攻击，它将超长的数据截短到适当的长度。这些过滤有什么问题？

如果在实施长度限制之前将引号配对，则通过在配对的两个引号之间截短输入，就可以在输入中引入奇数单引号（请参阅第9章了解详情）。

如果在配对之前应用长度限制，仍然可以通过在有效载荷的开头插入大量单引号，使该有效载荷充分放大，并使用位于有效载荷末尾的专门设计的数据来溢出缓冲区，从而达到利用任何缓冲区溢出条件的目的。

3. 可以采取哪些步骤来探查某登录功能中是否存在故障开放条件？（列出想到的各种不同测试。）

应使用所控制帐户的证书，多次重复登录过程，并以特定方式修改请求：

(a) 对于提交的每个参数，尝试提交一个空值，完全省略名称/值对，并使用不同的值多次提交同一数据项。

(b) 如果登录过程包括多个阶段，应尝试以不同的顺序执行这些阶段、完全跳过单个阶段、直接进入任意阶段，以及在不需要参数的阶段提交参数。

4. 某银行应用程序采用一种非常安全可靠的多阶段登录机制。在第一个阶段，用户输入用户名和密码。在第二个阶段，用户输入在物理令牌上显示的一个不断变化的值，并通过隐藏表单字段重新提交前面输入的用户名。

可以立即发现的逻辑缺陷有哪些？

应用程序很可能单独执行这两个检查，根据一个用户名确认密码，根据另一个用户名确认令牌值，然后为其中一个已确认的用户名创建通过验证的会话。

如果拥有自己的物理令牌的应用程序用户没法获得了其他用户的密码，他们就可以作为该用户登录。相反，取决于该机制的运行方式，能够读取其他用户的令牌值的用户或许可以作为该用户登录，而无需了解后者的密码。该解决方案的总体安全状态将因此被明显削弱。

5. 在通过提交专门设计的输入探查一个应用程序中是否存在常见的漏洞时，应用程序频繁返回包含调试信息的详细错误消息。有时，这些消息与其他用户造成的错误有关。发生这种情况后，就无法令其再次发生。这表示应用程序存在什么逻辑缺陷，接下来该如何处理？

这种行为表示错误消息功能不是线程安全的，将返回由任何用户生成的上一个错误的详细信息。应同时使用两个不同的会话进行深入探查，以确认是否确实出现了这种情况。如果确实如此，应使用一段脚本不断触发一条详细的错误消息，并记录其内容中的任何差异，以获取与其他应用程序用户有关的有用信息。

第12章

1. 在应用程序的行为中，有什么“明显特征”可用于确定大多数XSS漏洞？
用户提交的输入在应用程序对该输入的响应中原样返回。

2. 假设在应用程序未通过验证的功能区域发现了一个反射型XSS漏洞。如何利用这个漏洞攻破一个通过验证的应用程序会话？请想出两种不同的方法。

多数情况下，利用未通过验证的功能中的XSS漏洞一样可以针对已通过验证的用户实施有效攻击——这些功能与已通过验证的功能的运行机制相同，可用于在已通过验证的用户会话中执行任意JavaScript脚本。

即使目标用户在攻击过程中并未登录，攻击者仍有可能攻破他们的账户。如果应用程序易于受到会话固定攻击，攻击者可以截获用户的令牌并等待其登录。攻击者可以在登录页面注入代码来截获键击，甚至可以显示一个木马登录表单，将用户的证书发送到其他位置。

3. 假设一个cookie参数未经过任何过滤或净化就被复制到应用程序的响应中。是否可以利用这种行为在返回的页面中注入任意JavaScript？是否可以利用这种行为实施针对其他用户的XSS攻击？
第一个问题的答案是“是”。当然可以利用这种行为通过专门设计的输入注入任意JavaScript。第二个问题的答案是“或许”。以前，有各种方法可以在跨域请求中注入任意HTTP消息头，注入恶意cookie。旧版本的Flash及XMLHttpRequest一直易于受到这类攻击。此外，许多使用cookie的应用程序实际上接受位于其他位置（如查询字符串或消息主体）的同名参数。

4. 假设在仅返回给自己的数据中发现了保存型XSS漏洞。这种行为是否存在安全缺陷？
孤立来说，用户似乎只可以利用这种行为来攻击自身。但是，如果与其他适当的漏洞（如访问控制漏洞或跨站点请求伪造漏洞）相结合，则这种行为可能会造成严重后果，并可能导致攻击者能够在向其他应用程序用户显示的页面中注入保存型JavaScript。

5. 在攻击一个处理文件附件并在浏览器中显示这些内容的Web邮件应用程序时，应立即检查哪种常见的漏洞？
如果应用程序不经任何净化就显示HTML或文本文件，则这些HTML或文本文件中包含的JavaScript将在任何查看该附件的用户的浏览器中执行。此外，如果JPEG文件包含HTML，则某些浏览器会自动将该文件作为HTML处理。在防范邮件附件中的XSS方面，许多Web邮件应用程序并未采取足够的保护措施。

6. 浏览器的同源策略如何给Ajax技术XMLHttpRequest的应用造成影响？

由于XMLHttpRequest可用于从HTTP请求中获取完整的响应，因此，正常情况下，只能利用它向和调用它的域相同的域提出请求。但是，HTML5引入了一个工具，如果所请求的域许可，XMLHttpRequest可利用该工具提出跨域请求并检索响应。

7. 列举3个利用XSS漏洞的可行攻击有效载荷（也就是说，攻击者可以在其他用户的浏览器中执行的恶意操作而不是传送攻击的方法）。

有无数针对XSS漏洞的攻击有效载荷。以下是一些常见的有效载荷：

盗窃会话cookie；

引诱用户操作；

注入木马功能；

盗窃存入缓存的自动完成数据；以及

记录键击。

8. 已知一个反射型XSS漏洞，可以在返回页面的HTML代码的某个位置注入任意数据。插入的数据被截短至50字节，但是我们希望注入一个超长的脚本，并且不想调用外部服务器上的脚本。如何解决长度限制呢？

可以将反射型XSS漏洞“转换成”基于DOM的XSS漏洞。例如，如果易受攻击的参数称为vuln，则可以使用以下URL执行任意长度的脚本：

/script.asp?vuln=<script>eval_r(location.hash.substr(1))</script>#alert('long script here ......')

9. 已知在一个必须使用POST方法的请求中存在反射型XSS漏洞。攻击者可以使用哪种传送机制实施攻击？

如果POST方法是必需的，则不能仅仅在应用程序中构建一个专门设计的URL，以便在用户访问该URL时实施攻击。但是，可以创建一个第三方网页，使用POST方法向易受攻击的应用程序提交一个表单和位于隐藏字段中的相关参数。当用户查看该网页时，可以使用JavaScript自动提交上述表单。

第13章

1. 已知一项应用程序功能将一个查询字符串参数的内容插入到某个HTTP重定向的Location消息头中。利用这种行为，攻击者可以实施哪3种不同类型的攻击？

(a) 任何重定向都会增加钓鱼攻击的可信度；

(b) 注入cookie消息头以利用会话固定漏洞；

2. 要针对应用程序的一项敏感功能实施CSRF攻击，必须满足什么前提条件？
攻击者必须能够提前确定提交给该功能的所有相关参数。也就是说，这些参数不得包含任何秘密或无法预测的值，即攻击者不劫持受害者的会话就无法设置的值。

3. 哪3种防御措施可用于防止JSON劫持攻击？

(a) 标准的反CSRF防御，即在针对包含敏感数据的JavaScript对象的请求中包括无法预测的参数；

(b) 在JavaScript响应的开头部分插入无效或存在问题的JavaScript；

4. 对于以下每一种技术，确定该技术请求/crossdomain.xml以正确实施域隔离的任何情形：

(a) Flash

(b) Java

(c) HTML5

(d) Silverlight

(a) 当某个Flash对象尝试提出跨域请求并检索响应时，Flash将请求/crossdomain.xml文件。即使该对象指定了应从中加载跨域策略的其他位置，Flash仍然会请求/crossdomain.xml，以确认主策略是否允许这样做。

(b) Java不会通过请求/crossdomain.xml来检查跨域策略。

(d) 当某个Silverlight对象尝试提出跨域请求并检索响应时，Silverlight将请求/crossdomain.xml文件，前提是Silverlight首先请求的/clientaccesspolicy.xml文件不存在。

5.“我们不会受到单击劫持攻击，因为我们不使用框架。”以上表述是否正确，为什么？

单击劫持攻击是指攻击者的网站创建一个包含易受攻击的网站的框架。它们与目标站点本身是否采用框架无关。

6. 已知某应用程序使用的昵称中存在一个永久性XSS漏洞，此字符串仅在配置它的用户登录应用程序时向该用户显示。请描述用于攻破该应用程序的其他用户的攻击所需执行的步骤。

可以使用以下步骤对这个漏洞加以利用：

(a) 攻击者在应用程序上创建自己的账户，并在自己的昵称中插入一个恶意有效载荷；

(b) 攻击者创建自己的站点，使访问者使用攻击者的证书登录易受攻击的应用程序（通过针对登录功能的CSRF攻击），然后请求包含恶意昵称的页面。

(c) 受害者受到诱惑访问攻击者的网站时，将登录易受攻击的应用程序，攻击者的JavaScript同时执行。该脚本将保存在受害者的浏览器中，并退出应用程序，同时呈现某些诱使受害者使用自己的证书登录的内容。如果受害者受到诱惑，则攻击者的脚本就可以攻破受害者的证书及生成的会话。从受害者的角度看，这种攻击简直“天衣无缝”，自己只是单击了一个链接，然后就看到易受攻击的应用程序本身的登录功能。

7. 如何测试应用程序是否允许使用XMLHttpRequest提出跨域请求？

可以在每个请求中添加以下消息头：

Origin: attacker.com

然后看应用程序的响应中是否包含以下消息头：

Access-Control-Allow-Origin

如果包含，则可以通过此消息头确定应用程序允许与哪些外部域（如果有）进行双向交互。

8. 请描述攻击者可诱使受害者使用任意cookie的3种方法。

(a) 一些应用程序功能接受任意参数名称/值，并在响应中的cookie内设置这些值。

(b) 可以利用任何HTTP消息头注入或XSS漏洞为受影响的域设置任意cookie。

第14章

1. 指出使用自动技巧在应用程序中枚举标识符时用到的3个标识符“触点”。

(a) HTTP状态码

(b) 响应长度

(d) Location消息头的内容

(e) 任何cookie的设置

(f) 出现的任何时间延迟

2. 对于下面的每一类漏洞，指出一个可用于确定该漏洞的模糊测试字符串：

(a) SQL注入

(b) OS命令注入

(d) 脚本文件包含

这个问题没有明确的答案。以下是可用于测试每类漏洞的模糊测试字符串示例，其他许多字符串也同样适用：

(a) '

'; waitfor delay '0:0:30'--

(b) ||ping -i 30 127.0.0.1;x||ping -n 30 127.0.0.1 &

..\..\..\..\..\..\..\..\..\..\boot.ini

(d) http://<yourservername>/

3. 当对一个包含各种不同参数的请求进行模糊测试时，为何要在保持其他参数不变的情况下轮流针对每一个参数进行测试？

在许多情况下，以某种方式修改参数的值会导致错误，使应用程序停止对该请求执行其他处理。因此，应用程序将不会执行各种可能以危险方式处理其他参数的代码路径。

为确保自动模糊测试可以达到令人满意的代码覆盖效果，一种有效的方法是使用一个良性请求作为模板，并轮流修改每个参数，同时使其他参数保留其初始值。然后，可以基于模糊测试的结果及对每个参数作用的理解，继续对多个参数同时执行手动测试。如果时间允许，还可以使用有效载荷的不同排除组合同时修改多个参数，继续执行更加复杂的模糊测试。

4. 假设在一个试图对登录功能实施蛮力攻击以找到其他账户证书的自动攻击中，无论提交的是有效证书还是无效证书，应用程序都返回一个指向相同URL的HTTP重定向。在这种情况下，使用什么方法探查“触点”最为可靠？

通常，除重定向以外，在提交有效证书时，应用程序还会设置一个新cookie，用于分配一个通过验证的会话，当访问重定向时，此会话将显示不同的内容。如果是这种情况，则可以将Set-Cookie消息头作为探查触点的可靠方法。

如果情况并非如此，即在提交有效证书时，应用程序会升级现有会话，则攻击脚本可能需要访问重定向的目标，并检查生成的页面的内容，以确定渗透测试员是否已成功登录。

5. 当使用自动攻击从应用程序中获取数据时，想要的信息常常位于一个静态字符串之后，渗透测试员可以轻易截获这些数据。例如：

<input type=”text” name=”LastName” value=”

但是，在其他情况下事实并非如此，需要的信息之前的数据可能会发生变化。这时该如何设计一个自动攻击来满足需要？

如果幸运的话，或许可以设计一个与所需截获的信息之前的数据或所需数据唯一匹配的正则表达式。否则，可能需要创建一段完全自定义的脚本，以分析每个应用程序响应并确定有用的数据项。

第15章

1. 当探查SQL注入漏洞时，如果请求以下URL：

https://wahh-app.com/list.aspx?artist=foo’+having+1=1--

将收到如下错误消息：

Server: Msg 170, Level 15, State 1, Line 1

Line 1: Incorrect syntax near ‘having1’.

从中可以得出什么结论？应用程序中包含任何可被利用的条件吗？

这说明应用程序将输入直接插入动态构建的查询中。但是，如错误消息中的表达式having1所示，它似乎删除了输入中出现的任何空白符。

当然可以对这种条件加以利用。可以使用SQL注释而不是空白符来分配查询中的语法项。例如：

https://wahh-app.com/list.aspx?artist=foo'having1=1--

这将返回不同的错误消息：

Server: Msg 8118, Level 16, State 1, Line 1

Column 'users.ID' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.

这证实可以对上述条件加以利用，并完成了枚举所执行的查询的结构的第一个步骤。

2. 当对各种参数进行模糊测试时，应用程序返回以下错误消息：

Warning: mysql_connect() [function.mysql-connect]: Access denied for

user ‘premiumdde’@’localhost’ (using password: YES) in

/home/doau/public_html/premiumdde/directory on line 15

Warning: mysql_select_db() [function.mysql-select-db]: Access denied

for user ‘nobody’@’localhost’ (using password: NO) in

/home/doau/public_html/premiumdde/directory on line 16

Warning: mysql_select_db() [function.mysql-select-db]: A link to

the server could not be established in

/home/doau/public_html/premiumdde/directory on line 16

Warning: mysql_query() [function.mysql-query]: Access denied for

user ‘nobody’@’localhost’ (using password: NO) in

/home/doau/public_html/premiumdde/directory on line 448

从中可以获得哪些有用的信息？

该错误消息提供了应用程序用于访问数据库的用户名、连接模式、应用程序Web内容的绝对文件路径，以及生成错误的脚本的行号。孤立来看，上述每一项信息似乎都无关紧要。但是，如果结合其他漏洞，渗透测试员就可以利用这些信息设计出针对应用程序的可怕攻击。

3. 在解析应用程序的过程中，在服务器上发现了一个激活了目录列表的隐藏目录，其中似乎保存着大量以前用过的脚本。请求其中一个脚本返回以下错误消息：

CGIWrap Error: Execution of this script not permitted

Execution of (contact.pl) is not permitted for the following reason:

Script is not executable. Issue ‘chmod 755 filename’

Local Information and Documentation:

CGIWrap Docs: http://wahh-app.com/cgiwrap-docs/

Contact EMail: helpdesk@wahh-app.com

Server Data:

Server Administrator/Contact: helpdesk@wahh-app.com

Server Name: wahh-app.com

Server Port: 80

Server Protocol: HTTP/1.1

Request Data:

User Agent/Browser: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT

5.1; .NET CLR 2.0.50727; FDM; InfoPath.1; .NET CLR 1.1.4322)

Request Method: GET

Remote Address: 192.168.201.19

Remote Port: 57961

Referring Page: http://wahh-app.com/cgi-bin/cgiwrap/fodd

是什么原因造成了这个错误？可以立即发现哪些常见的Web应用程序漏洞？

这是由cgiwrap创建的系统生成的错误消息。它表示因为没有适当的文件权限，所请求的脚本无法在服务器上执行。因此，这个脚本可能没有多少用处。

错误消息中包含了一些可能有用的信息，包括一个电子邮件地址。但是，更重要的是，其中包含了从客户端请求中复制的各种详细信息。因此，应探查服务器如何处理相关请求消息头中的专门设计的输入，以了解错误消息是否易于受到XSS攻击。请注意，用户可能会受到诱惑，从而通过Flash对象提出包含任意请求消息头的请求。

4. 在探查一个请求参数的功能并试图确定它在应用程序中的作用时，如果请求以下URL：

https://wahh-app.com/agents/checkcfg.php?name=admin&id=13&log=1

应用程序将返回以下错误消息：

Warning: mysql_connect() [function.mysql-connect]: Can’t connect to

MySQL server on ‘admin’ (10013) in

/var/local/www/include/dbconfig.php on line 23

这条错误消息是由什么原因造成的？为此应探查什么漏洞？

造成错误消息的原因是因为在name参数中提交了admin值。错误消息指出应用程序尝试（并且无法）连接到名为admin的主机上的数据库。似乎应用程序允许渗透测试员控制将用于执行请求的数据库。

应尝试提交所控制的服务器的IP地址或主机名，看应用程序是否会连接到服务器。还应尝试猜测内部网络中的一系列IP地址，看是否可以查找到可以从应用程序服务器访问的其他数据库。

鉴于所提供的主机名已被复制到错误消息中，因此还应调查应用程序是否易于受到XSS攻击。与应用程序中的主要功能相比，应用程序通常并不对错误消息等次要内容实施严格的输入确认和访问控制。

5. 当对一个请求进行模糊测试，以探查各种漏洞时，测试员轮流在每个请求参数中提交了一个单引号。其中一个请求的响应包含了HTTP 500状态码，表示应用程序可能存在SQL注入漏洞。消息的全部内容如下：

Microsoft VBScript runtime error ‘800a000d’

Type mismatch: ‘ [string: “’”]’

/scripts/confirmOrder.asp, line 715

该应用程序是否易于受到攻击？

这条错误消息由一个脚本生成，该脚本正尝试将基于字符串的输入分配给一个数字参数。似乎只要在此参数中提交的数据并非数值，就会触发这个错误。没有任何迹象表明输入导致了数据库错误，或者由数据库处理。几乎可以肯定此参数不易于受到SQL注入攻击。

第16章

1. 如果不采用特殊的防御措施，为什么栈缓冲区溢出比堆溢出更容易被攻击者利用？

利用基于栈的溢出，通常可以立即控制栈上的已保存返回地址，并因此控制当前功能返回的指令指针。可以将指令指针指向包含shellcode的任意地址（通常位于触发溢出的同一缓冲区内）。

利用基于堆的溢出，通常可以将内存中的任意指针设置为任意值。正常情况下，利用这种修改来控制执行流还需要采取其他步骤。此外，使堆缓冲区溢出后，渗透测试员可能无法立即实施攻击，而要依赖于影响堆内存分配的意外事件。

2. 在C与C++语言中，字符串的长度如何决定？

标准C/C++字符串的长度并没有具体的限制。这类字符串在遇到第一个空字节时结束。

3. 与在因特网上运行的所有权Web应用程序中存在的溢出漏洞相比，非定制网络设备中存在的缓冲区溢出漏洞为什么更可能被攻击者所利用？

虽然探查和检测远程Web应用程序中存在的缓冲区溢出漏洞相对较为容易，但要设计出针对这类漏洞的有效攻击往往极为困难（尽管并非完全不可能）。

另一方面，通过在本地访问易受攻击的网络设备，就可以附加调试设备并全面调查漏洞的本质，从而设计出经过优化的攻击，对漏洞加以有效利用。

4. 下面的模糊漏洞字符串为什么无法确定许多格式化字符串漏洞？

%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n...

默认情况下，最新的printf系列函数禁用了格式说明符%n。因此，应始终提交大量%n说明符，如果应用程序以危险的方式处理输入，这些说明符将受到支持，并很可能会触发异常。

此外，仅仅使用printf系列说明符无法检测对其他格式化函数（如FormatMessage）的危险调用。

5. 假设在一个大量使用本地代码组件的Web应用程序中探查缓冲区溢出漏洞，发现了某个请求的一个参数可能存在漏洞，然而无法让监控到的反常行为再次发生。有时，提交一个长度较长的值会立即造成系统崩溃，有时则需要重复提交几次才能导致崩溃。另外，如果提交大量“良性”请求也会引起系统崩溃。

什么原因最有可能导致应用程序出现这种行为？

这可能说明应用程序中存在堆溢出漏洞。提交的每一个超长请求都可能破坏堆控制结构。但是，通常情况下，只有在执行相关堆操作时，堆受到的破坏才会引发异常，而堆操作的时间可能取决于与所提交的请求无关的其他事件。

请注意，在极少数情况下，其他操作也会导致上述行为——例如，由于负载平衡或对输入的延期处理。

第17章

1. 假设受攻击的应用程序使用两台不同的服务器：一台应用程序服务器和一台数据库服务器。已经发现一个漏洞，可以在应用程序服务器上执行任意操作系统命令。是否可以利用这个漏洞获取保存在数据库中的敏感应用程序数据？

几乎可以肯定能够利用该漏洞获取保存在数据库中的应用程序数据。应用程序本身必须拥有访问自己的数据所需的证书和权限。可以检查服务器端应用程序的脚本和配置文件，以了解它如何访问应用程序。要对所发现的漏洞加以利用，一个明显的方法是在Web根目录中创建一些新脚本，以执行任意查询并使用浏览器检索查询结果。

2. 在另外一种情形中发现了一个SQL注入漏洞，可以利用它在数据库服务器上执行任意操作系统命令。是否可以利用这个漏洞攻破应用程序服务器？例如，是否可以修改保存在应用程序服务器中的应用程序脚本以及向用户返回的内容？

即使完全攻破了整个数据库服务器，也不一定有办法攻破应用程序服务器。通常，应用程序服务器将数据库服务器作为数据库客户端访问，应用程序服务器并不以任何其他方式信任数据库服务器。

但是，渗透测试员或许可以修改向用户返回的内容，因为其中一些内容将使用数据库中包含的数据生成。例如，即使应用程序中不包含可以在它自身中触发的保存型XSS漏洞，仍然可以通过直接修改数据库中的数据，将任意脚本注入应用程序的响应中。如果可以通过这种方法攻击管理用户，就可以迅速攻破整个应用程序。

3. 在攻击共享环境中的一个Web应用程序时，与ISP签订合约后，在所针对的同一台服务器上获得了一些Web空间，允许向其中上传PHP脚本。

是否可以利用这种情况攻破目标应用程序？

PHP语言包含许多强大的函数，可用于执行操作系统命令和访问文件系统。如果能够修改由其他应用程序使用的文件，就可能攻破该应用程序。但是，攻击成功的几率在很大程度上取决于PHP环境的配置，以及应用程序是否对在技术堆栈以下执行的操作实施了任何控制。

4. Linux、Apache、MySQL与PHP等架构组件常安装在同一台物理服务器上。为何这样做会削弱应用程序架构的安全状况？

通常，如果将所有应用程序组件安装在同一台服务器上，将无法对这些组件进行有效隔离。也就是说，如果攻击者攻破应用程序架构的其中一个组件，就能够迅速攻破其他组件。例如，可以利用Web应用程序中的文件泄露漏洞从数据库中检索包含敏感数据的文件。同样，可以利用SQL注入漏洞、使用数据库函数在服务器文件系统上写入任意文件，在Web根目录中创建可以从浏览器访问的脚本，并因此直接攻破应用程序层。

5. 如何找到证据来证明所攻击的应用程序由某个应用程序服务提供商托管？

可以对关键URL和参数名执行因特网搜索，以确定采用同名数据项的其他应用程序。如果这些应用程序似乎包含大量相互重叠的共享功能，就可以调查它们的托管位置，以获取其他证据。

第18章

1. 在什么情况下Web服务器会显示目录列表？
如果请求某目录的URL且满足以下条件，Web服务器将显示目录列表：

(a) Web服务器找不到默认文档（如index.html）；

(b) 目录列表已启用；

2. WebDAV方法有什么作用？为什么说它们会造成危险？

使用WebDAV方法可以基于Web创作Web内容。

如果未对这些方法实施严格的访问控制，则这些方法可能会造成危险。此外，由于涉及复杂的功能，以前它们一直是Web服务器中漏洞的源头——例如，是通过IIS服务器利用操作系统漏洞的攻击向量。

3. 如何利用一个配置成Web代理服务器的Web服务器？

如果可以通过代理服务器反向连接到因特网，就可以利用它攻击因特网上的第三方Web应用程序，这时提出的请求似乎是来自配置不当的Web服务器。

即使向因特网提出的请求被阻止，仍然可以利用代理服务器访问组织内部无法直接访问的Web服务器，或访问服务器本身上的其他基于Web的服务。

4. 何为Oracle PL/SQL排除列表？如何避开这个列表？

PL/SQL排除列表是一个模式匹配黑名单，旨在防止将PL/SQL网关用于访问某些强大的数据库包。

有各种方法可以避开PL/SQL排除列表过滤器。这主要是因为该过滤器采用非常简单的表达式，而后端数据库却遵循更加复杂的规则来说明输入的重要性。人们已经找到大量方法，可用于设计与黑名单模式不匹配、但能够成功执行数据库中的强大包的输入。

5. 如果一个Web服务器允许通过HTTP与HTTPS访问它的功能，当查询漏洞时，使用其中一个协议与使用另一个协议相比有哪些优点？

使用HTTPS进行通信也许能够避开某些网络层入侵检测系统。但是，通常情况下，如果使用HTTP，自动化攻击的执行速度会更快。应用程序可能包含不同的功能，或者在通过不同协议访问时会表现出不同的行为，因此，一般来说，应准备使用这两种协议进行测试。

第19章

1. 列出3种可在源代码中找到明确签名的常见漏洞。

(a) 跨站点脚本

(b) SQL注入

(d) 任意重定向

(e) 操作系统命令注入

(f) 后门密码

(g) 某些本地代码漏洞

2. 当审查PHP应用程序时，为什么有时很难确定用户输入的所有来源？

PHP使用一系列内置数组来存在用户提交的数据。如果启用了register_globals，则PHP会为每个请求参数创建一个全局变量，并且应用程序会通过引用一个同名变量来访问参数——没有任何语法现象表明此变量表示用户输入，而不是在其他位置定义的任何其他变量。

3. 以下两个执行SQL查询的方法都使用了用户提交的输入：

// method 1

String artist = request.getParameter(“artist”).replaceAll(“’”, “’’”);

String genre = request.getParameter(“genre”).replaceAll(“’”, “’’”);

String album = request.getParameter(“album”).replaceAll(“’”, “’’”);

Statement s = connection.createStatement();

s.executeQuery(“SELECT * FROM music WHERE artist = ‘” + artist +

‘” AND genre = ‘” + genre + ‘” AND album = ‘” + album + “’”);

// method 2

String artist = request.getParameter(“artist”);

String genre = request.getParameter(“genre”);

String album = request.getParameter(“album”);

Statement s = connection.prepareStatement(

“SELECT * FROM music WHERE artist = ‘” + artist +

“’ AND genre = ? AND album = ?”);

s.setString(1, genre);

s.setString(2, album);

s.executeQuery();

哪一个方法更加安全，为什么？

方法1更加安全。

虽然方法1从用户输入动态构建SQL查询，但它将输入中出现的所有单引号全部配对，并将所有用户提交的参数视为字符串数据。虽然这并非安全处理SQL查询的最佳方法，但目前似乎并没有任何SQL注入风险。

方法2使用一个参数化查询，这是在SQL语句中安全合并用户提交的输入的首选方法。但是，在三个用户输入中，只有两个输入被正确参数化。其中一个输入被错误地直接放置到指定查询结构的字符串中，因此应用程序肯定易于受到SQL注入攻击。

4. 在审查一个Java应用程序代码时，首先要检查HttpServletRequest.getParameter API的所有用法。下列代码引起了你的注意：

private void setWelcomeMessage(HttpServletRequest request) throws

ServletException

{

String name = request.getParameter(“name”);

if (name == null)

name = “”;

m_welcomeMessage = “Welcome “ + name +”!”;

}

这段代码表示应用程序中可能存在什么漏洞？还需要进行哪些代码分析才能确定应用程序是否确实易于受到攻击？

该应用程序可能易于受到反射型XSS攻击，因为它似乎正从请求参数直接构建在屏幕上显示的欢迎消息。

仅仅从这个代码片段无法最终确认应用程序是否易于受到攻击。为此，还需要进行以下调查：

(a) 是否对其他位置的name参数执行了任何输入确认；以及

(b) 在将m_welcomeMessage复制到应用程序的响应中之前，是否对它执行了任何输出确认。

5. 假设渗透测试员正在审查一个应用程序用于生成会话令牌的机制。相关代码如下：

public class TokenGenerator

{

private java.util.Random r = new java.util.Random();

public synchronized long nextToken()

{

long l = r.nextInt();

long m = r.nextInt();

return l + (m << 32);

}

应用程序生成的会话令牌是否可以预测？请解释理由。

是。了解所使用的令牌创建算法后，就可以基于一个令牌示例进行前后推断，从而确定应用程序创建的所有令牌。

Java API java.util.Random实施一个线性同余发生器，可根据一个完全可预测的算法生成伪随机数字。如果知道该发生器在任何迭代时的状态，就可以推断出它接下来将生成的数字序列，以及它之前生成的序列（利用一点数论知识）。

但是，java.util.Random发生器维持48位的状态，而nextInt方法仅返回32位的状态。因此，获取nextInt方法的一次输出并不足以确定该发生器的状态，或者预测它的输出序列。

当前，我们可以轻松解决这个难题，因为应用程序使用的算法会连续两次调用nextInt。创建的每个会话令牌均包含发生器的一次迭代的32位状态，以及下一次迭代的32位状态。基于这些信息，就可以直接实施本地蛮力攻击，以查明第一次迭代所缺少的16位状态（通过尝试缺少的16个位的每个可能的排列组合，并测试发生器是否会输出从第二次迭代中获取的32个位）。确认缺少的16个位后，就知道了发生器的完整状态，从而能够以标准的方法推断随后及以前的输出。

讽刺的是，开发者做出的两次调用nextInt并组合相关结果的决定却使令牌创建算法比在其他情况下更易于受到攻击。

有关这类攻击的详情，请参阅以下由Chris Anley撰写的论文：

http://www.ngssoftware.com/research/papers/Randomness.pdf文章来源地址https://www.toymoban.com/news/detail-404732.html

到了这里，关于《黑客攻防技术宝典：Web实战篇》第二版习题答案的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！