《黑客攻防技术宝典：Web实战篇》习题答案(一)

http://blog.sina.com.cn/s/blog_545eb7860101379s.html

译者按：以下为《黑客攻防技术宝典：Web实战篇》一书第二版中的习题答案，特在此推出。如果读者发现任何问题，请与本人联系。英文答案请见：http://mdsec.net/wahh/answers1e.html。

如有转载，请注明出处。谢谢!

 

第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.       应用程序可采取什么方法确保客户端执行了输入确认？
    应用程序没有办法可以确保客户端执行了输入确认。在客户端上执行的各种操作完全由用户控制。

 

第二部分