《黑客攻防技术宝典Web实战篇》习题答案Word文件下载.docx
《《黑客攻防技术宝典Web实战篇》习题答案Word文件下载.docx》由会员分享，可在线阅读，更多相关《《黑客攻防技术宝典Web实战篇》习题答案Word文件下载.docx（29页珍藏版）》请在冰豆网上搜索。
许多时候，应用程序可能会被迫接受与已知为“良性”输入的列表或模式不匹配的待处理数据。
例如，许多用户的姓名包含可用在各种攻击中的字符。
如果应用程序希望允许用户以真实姓名注册，就需要接受可能的恶意输入，并确保安全处理这些输入。
4.
攻击者正在攻击一个执行管理功能的应用程序，并且不具有使用这项功能的任何有效证书。
为何他仍然应当密切关注这项功能呢？
攻击者可以利用任何访问控制核心机制中的缺陷未授权访问管理功能。
此外，攻击者以低权限用户身份提交的数据最终将向管理用户显示，因此，攻击者可以提交一些恶意数据，用于在管理用户查看这些数据时攻破他们的会话，从而对管理用户实施攻击。
5.
旨在阻止跨站点脚本攻击的输入确认机制按以下顺序处理一个输入：
（1）
删除任何出现的<
script>
表达式；
（2）
将输入截短为50个字符；
（3）
删除输入中的引号；
（4）
对输入进行URL解码；
（5）
如果任何输入项被删除，返回步骤
（1）。
是否能够避开上述确认机制，让以下数据通过确认？
“>
<
alert（“foo”）<
/script>
是。
如果没有第4步，此机制将是可靠的，能够过滤其旨在阻止的特定项目。
但是，由于输入在执行过滤步骤后被解码，攻击者只需要对有效载荷中的选定字符进行URL编码，就可以避开这种过滤：
"
>
如果首先执行第4步，或根本不执行该步骤，攻击者将不可能避开上述过滤。
第3章：
Web应用程序技术
OPTIONS方法有什么作用？
OPTIONS方法要求服务器报告可用于特定资源的HTTP方法。
If-Modified-Since和If-None-Match消息头的作用是什么？
它们为何引起攻击者的兴趣？
If-Modified-Since消息头用于指定浏览器最后一次收到被请求的资源的时间。
If-None-Match消息头用于指定实体标签，在最后一次收到被请求的资源时，服务器与被请求的资源一起发布该标签。
在上述两种情况下，这些消息头用于支持浏览器中的内容缓存，服务器通过它们指示浏览器使用资源的缓存副本，而非资源的完整内容（如果这样做没有必要）。
在攻击应用程序时，浏览器可能已经缓存了攻击者感兴趣的资源（如JavaScript文件）副本。
如果删除这两个消息头，就可以覆写浏览器的缓存信息，确保服务器以攻击者希望查看的新的资源副本做出响应。
当服务器设置cookie时，secure标签有什么意义？
secure标签用于向浏览器发出以下指示：
只应通过HTTPS连接、绝不能通过未加密的HTTP连接重新提交cookie。
常用状态码301与302有什么不同？
301状态码告诉浏览器被请求的资源已永久移动到其他位置。
在当前浏览器会话期间，如果浏览器需要访问最初请求的资源，它将使用在301响应中指定的位置。
302状态码告诉浏览器被请求的资源已临时移动到其他位置。
下次浏览器需要访问最初请求的资源时，它将从最初请求的位置请求此资源。
使用SSL时，浏览器如何与Web代理实现互操作？
浏览器向代理发送一个CONNECT请求，将目标主机名和端口号指定为此请求中的URL。
如果代理允许该请求，它将返回一个状态码为200的HTTP响应，使TCP连接保持开放，并在随后作为指定目标的纯TCP级中继。
第4章：
解析应用程序
当解析一个应用程序时，会遇到以下URL：
https:
//wahh-
据此可以推论出服务器使用何种技术？
该技术的运作方式可能是怎样的？
文件名CookieAuth.dll说明应用程序正使用MicrosoftISAServer。
这是登录功能的URL，成功登录后，应用程序将重定向到URL/default.aspx。
如果所针对的应用程序是一个Web论坛，并且只发现了一个URL：
http:
如何通过它获得论坛成员列表？
此URL是phpBBWeb论坛软件的常用“指纹”。
因特网上提供了有关此软件的大量信息，读者可以自己安装该软件以进行体验。
可以通过以下URL获取成员列表：
通过类似于下面的URL可以获取单个用户的用户资料：
phpBB软件中包含各种漏洞，因此，读者应确认所使用的版本并研究任何相关问题。
当解析一个应用程序时，遇到以下URL：
据此推断服务器端应使用何种技术。
可能还存在哪些其他内容和功能？
.asp文件扩展名说明应用程序正使用Microsoft的ActiveServerPages（ASP）。
/public路径说明可能存在其他有用的路径，如/private。
action=view参数表明可能存在其他操作，如edit、add或delete。
应调查location=default参数的用途，其中可能包含用户名，因此应在应用程序中探查路径遍历漏洞。
Web服务器的一个响应包含以下消息头：
Server:
Apache-Coyote/1.1
这表示服务器使用何种技术？
如果该消息头是准确的，说明服务器正运行ApacheTomcat。
Tomcat是一种JavaServlet容器，因此应用程序可能使用的是Java和JSP技术。
假设正在解析两个不同的Web应用程序，在每个应用程序中请求URL/admin.cpf。
每个请求返回的响应消息头如下所示。
仅由这些消息头能否确定每个应用程序中存在被请求的资源？
HTTP/1.1200OK
Microsoft-IIS/5.0
Expires:
Mon,20Jun201114:
59:
21GMT
Content-Location:
http:
Date:
Content-Type:
text/html
Accept-Ranges:
bytes
Content-Length:
2117
HTTP/1.1401Unauthorized
Apache-Coyote/1.1
WWW-Authenticate:
Basicrealm=”WahhAdministrationSite”
text/html;
charset=utf-8
954
Mon,20Jun201115:
07:
27GMT
Connection:
close
第一个响应使用HTTP状态码200，通常这表示请求已成功提交。
但是，Content-Location消息头表示从中获取该响应的位置。
这似乎是一个动态生成的错误页面，并且其查询字符串中包含值404，表明响应中包含定制的“文件未发现”消息。
第二个响应使用HTTP状态码401，表明被请求的资源存在，但用户必须提供HTTP验证证书才能访问该资源。
对于以上每一种情况，可以使用相同扩展名（如/iuwehuiwefuwedw.cpf）请求同一目录中的某个确定不存在的项目，并比较相关响应，以证实上述结论。
第一个应用程序可能会返回与原始响应极其类似的响应。
第二个应用程序可能会返回包含“文件未发现”消息的不同响应。
第5章：
避开客户端控件
通过客户端传送的数据如何阻止破坏性攻击？
可以使用保存在服务器上的密钥对数据进行加密或散列处理，就像选择性地使用ASP.NETViewState一样。
除非攻击者以某种方式获得密钥，否则他们将无法加密任意数据，或计算出任意数据的有效散列。
但是，攻击者仍然能够将一种情形中的数据用于另一种情形——例如，可以用廉价商品的加密价格替代昂贵商品的加密价格。
为防止这种攻击，应用程序应在受保护的数据中包含足够的上下文信息，以便于确认所采用的数据源自同一情形——例如，可以将产品代码和价格组合在一个加密对象中。
应用程序开发者希望阻止攻击者对登录功能发动蛮力攻击。
由于攻击者可能以多个用户名为目标，开发者决定将登录尝试失败次数保存在一个加密cookie中，阻止任何失败次数超过5次的请求。
有什么办法能够避开这种防御？
这种防御很容易突破。
攻击者不需要提交跟踪登录尝试失败次数的cookie。
他们可以在浏览器中禁用cookie，或使用自动化脚本不通过相关cookie提交请求。
其他防御措施包括使用CAPTCHA控件暂时阻止攻击者，或在登录失败次数达到五次后阻止源IP地址，但是，这样做可能会对使用代理或NAT防火墙的多个用户造成负面影响。
某应用程序包含一个执行严格访问控件的管理页面。
该页面上有一个连接到另一台Web服务器的诊断功能链接。
只有管理员才能够访问这些功能。
不执行另一种验证机制，下列哪一种（如果有）客户端机制可用于为诊断功能提供安全的访问控件？
要选择一个解决方案，是否还需要了解其他信息？
诊断功能能够检查HTTP
Referer消息头，证实请求由主管理页面提交。
诊断功能能够验证收到的cookie，证实其中包含访问主应用程序所需的有效会话令牌。
主应用程序可在请求的一个隐藏字段中设置一个身份验证令牌。
诊断功能能够确认这一点，证实用户在主应用程序中有一个会话。
攻击者可以将Referer消息头设置为任意值，因此它不是执行任何访问控制检查的安全方法。
这种方法仅在包含诊断功能的Web服务器为源Web服务器的父域或子域，且对会话cookie进行了相应地审查时有效，否则cookie将不会被提交到诊断服务器。
将需要为诊断服务器实施后端机制，以确认随源服务器一起提交的令牌。
无论诊断服务器的域名是什么，这种方法都有效。
只要身份验证令牌不可预测，并且以安全方式传输（请参阅第7章），这种方法就是安全的。
此外，还需要实施用于验证令牌的后端机制。
如果一个表单字段的属性为disabled=true，那么它就不会和表单的其他内容一起提交。
如何才能改变这种情况呢？
有两种基本的方法：
可以拦截提交表单的请求，并添加被禁用的参数。
可以拦截包含表单的响应，并删除disabled=true属性。
应用程序可采取什么方法确保客户端执行了输入确认？
应用程序没有办法可以确保客户端执行了输入确认。
在客户端上执行的各种操作完全由用户控制。
第六章
在测试一个使用joe和pass证书登录的Web应用程序的过程中，在登录阶段，在拦截代理服务器上看到一个要求访问以下URL的请求：
//www.wahh-
如果不再进行其他探测，可以确定哪3种漏洞？
（a）
由于证书在该URL的查询字符串中传送，因此，这些证书将面临通过浏览器历史记录、Web服务器和IDS日志或直接在屏幕上显示而遭到未授权泄露的风险。
（b）
证书通过未加密HTTP连接传送，因而易于被位于网络适当位置的攻击者拦截。
（c）
密码为一个包含四个小写字母的英文单词。
应用程序并未实施任何有效的密码强度规则。
自我注册功能如何会引入用户名枚举漏洞？
如何防止这些漏洞？
通常，自我注册功能非常易于受到用户名枚举攻击，因为用户可以选择自己的用户名，并且应用程序不允许用户注册现有用户名。
应用程序可以通过以下两种方法防止攻击者通过滥用自我注册功能来实施用户名枚举攻击：
应用程序可以生成自己的用户名，然后在每名新用户提交了所需的个人信息后向其分配一个无法预测的用户名。
可以在自我注册过程的第一个步骤要求用户输入他们的电子邮件地址。
然后，应用程序向用户发送一封电子邮件，该邮件包含一个URL，用户可以使用该URL继续注册过程。
如果提供的电子邮件已注册，则在电子邮件中向用户通知这一情况。
某登录机制由以下步骤组成：
应用程序要求用户提交用户名和密码；
应用程序要求用户提交值得纪念的词中的两个随机选择的字母。
应用程序为何要求用户分两个阶段提供所需的信息？
如果不这样做，登录机制将存在什么缺陷？
要求用户提交值得纪念的词中的两个随机选择的字母，而不是整个单词，其原理在于：
即使攻击者截获了用户在一次登录过程中提交的所有证书，他仍然无法使用这些证书再次登录，因为这时应用程序会要求用户提交另外两个字母。
如果应用程序在一个步骤中要求用户提交全部所需信息，那么它必须提前选定随机选择的字母，而此时它并不知道正在进行验证的用户的身份。
这意味着，即使攻击者只知道值得纪念的词中的两个字母，他仍然可以通过重复加载登录表单，直到应用程序请求那两个单词，从而使用截获的证书登录。
为避免这种缺陷，应用程序必须在用户每次成功登录后选择另外两个单词，并将其存储在用户配置文件中，直到用户再次成功登录。
当用户在登录的第一个阶段确认自己的身份后，将从用户配置文件中检索这两个字母，并要求用户提交相同的字母。
这样，即使攻击者在一次登录中获取了用户证书，他仍然需要等待非常长的一段时间，直到应用程序再次要求用户提交相同的字母。
一个多阶段登录机制要求用户首先提交用户名，然后在后续阶段中提交其他信息。
如果用户提交了任何无效的数据，将立即返回到第一个阶段。
这种机制存在什么缺点？
如何修复这种漏洞？
尝试猜测有效证书的攻击者可以轻松确定单个数据项是否有效。
攻击者可以利用应用程序的这种行为将蛮力攻击问题细分成一系列单独的问题。
要避免这种漏洞，可以要求应用程序即使在攻击者提交了无效数据项后仍继续完成所有登录步骤，并在最后一个步骤完成后返回常规“登录失败”消息，而不论是哪个数据项导致了登录失败。
这样做可以显著增加攻击者使用蛮力猜测用户证书时所需提交的请求数。
应用程序在登录功能中整合了反钓鱼机制。
在注册过程中，每名用户从应用程序提供的大量图片中选择一幅特殊的图片。
登录机制由以下步骤组成：
用户输入其用户名和出生日期；
如果这些信息无误，应用程序向用户显示他们选择的图片，如果信息有误，则随机显示一幅图片；
用户核实应用程序显示的图片，如果图片正确，则输入他们的密码。
反钓鱼机制的作用在于：
它向用户确认，他们使用的是真实而非“克隆”的应用程序，因为只有真正的应用程序才能显示正确的图片。
反钓鱼机制给登录功能造成什么漏洞？
这种机制是否能够有效阻止钓鱼攻击？
攻击者可以利用反钓鱼机制将用于猜测有效证书的过程划分成两个阶段。
攻击者可以通过两次完成步骤
（1）来核实特定用户名和出生日期是否有效。
如果两次返回了同一幅反钓鱼图片，则说明猜测的证书肯定有效；
否则即无效。
攻击者可以通过脚本攻击迅速遍历目标用户的所有出生日期，从而猜测出正确的值。
更糟糕的是，这种机制并不能有效阻止钓鱼攻击。
克隆Web应用程序将收到用户在步骤
（1）中提交的用户名和出生日期，并可以将这些信息直接提交给原始应用程序，以获取在步骤
（2）中向用户显示的正确图片。
如果告知用户通过该图片来核实应用程序的真实性，则这种机制实际上可能会起到反作用，并可能导致用户登录他们在其他情况下并不会信任的钓鱼网站。
第7章
登录一个应用程序后，服务器建立以下cookie：
Set-cookie:
sessid=amltMjM6MTI0MToxMTk0ODcwODYz;
一个小时后，再次登录并得到以下cookie：
sessid=amltMjM6MTI0MToxMTk0ODc1MTMy;
通过这些cookie，可以得出什么推论？
sessidcookie包含一个Base64编码的字符串。
解码收到的两个cookie可得到以下值：
jim23:
1241:
1194870863
1194875132
解码后的cookie包含三个以分号分隔的数据项。
初看来，这三个值可能包含用户名、数字用户标识和一个不断变化的数值。
最后一项包含10个数字，看起来像一个Unix时间值。
转换这两个值后得到以下信息：
Mon,12Nov200712:
34:
23UTC
Mon,12Nov200713:
45:
32UTC
这表示创建会话的时间。
因此，会话令牌似乎由有意义的用户相关数据和一个可预测的数据项构成。
理论上，可以实施蛮力攻击来猜测发布给其他应用程序用户的令牌。
某个应用程序使用由6个字符组成的数字字母会话令牌和由5个字符组成的数字字母密码。
它们全都由某种无法预测的算法随机生成。
其中哪一个最有可能成为蛮力猜测攻击的目标？
列出影响你做出决策的各种不同因素。
与由5个字符组成的密码相比，由6个字符组成的会话令牌的可能值要多得多。
因此，似乎较短的密码是最有价值的攻击目标。
但是，针对密码的蛮力攻击与针对会话令牌的蛮力攻击之间存在一些重要的差异。
在尝试猜测密码时，必须同时提交用户名和密码，因此每个请求最多只能针对一个账户发动攻击，甚至可能无法针对任何账户发动攻击。
你可能已经知道一些用户名，或者能够枚举出用户名，或者可能需要同时猜测用户名和密码。
登录机制可能包含多个阶段，或者响应速度较慢。
登录机制还可能实施了账户锁定机制，这会显著降低你的攻击速度。
另一方面，在尝试猜测会话令牌时，通常可以同时针对多个用户。
应用程序中可能有20、2000或0位已登录用户。
如果某位用户当前并未登录，则无法以这种方式对其实施攻击。
在收到大量无效令牌时，应用程序根本没有办法实施任何类型的“锁定”。
正常情况下，令牌猜测攻击的速度非常快，通常，包含无效令牌的请求会立即收到包含错误消息或重定向的响应。
简言之，这个问题并没有确定的答案。
哪一个是最有价值的目标，将取决于你的目的和应用程序的其他因素。
如果许多用户都已登录并且只需要攻破其中一位用户，则最好是针对会话实施攻击。
如果希望攻破某个极少登录的管理账户，则实施密码猜测攻击会更加有效。
登录位于以下URL的一个应用程序后：
//foo.wahh-
服务器建立以下cookie：
sessionId=1498172056438227;
domain=foo.wahhapp.
com;
path=/login;
HttpOnly;
然后访问下面的URL。
浏览器会将sessionId
cookie提交给哪些URL？
（选出全部答案。
）
（2）https:
//bar.wahh-
（3）https:
//staging.foo.wahh-
（4）http:
（5）http:
（6）https:
（7）https:
（8）
//xfoo.wahh-
其中的域和路径均与cookie范围相匹配。
否。
其中的域与cookie的域范围不同，也不是它的子域。
其中的域是范围中指定的域的子域，且路径与范围相匹配。
虽然采用了HTTP协议，但并未指定secure标记，因此仍然会传送该cookie。
其中的域与cookie范围相匹配。
由于路径范围在/login后并没有斜线，因此，该范围将不仅包括路径/login/，而且包括任何其他与/login前缀匹配的路径。
（6）
其中的路径与cookie范围不匹配。
（7）
其中的域是在范围中指定的域的父域。
所针对的应用程序除使用主会话令牌外，还使用每页面令牌。
如果收到一个不按顺序发送的每页面令牌，整个会话将被终止。
假设发现了某种缺陷，可通过它预测或截获应用程序发布给当前正在访问应用程序的其他用户的令牌，那么是否能够劫持他们的会话？
攻击者仍有可能实施会话劫持攻击。
如果攻击者获得了发布给某个用户的令牌，就可以立即使用那些令牌提出请求，并且服务器将接受这些请求。
但是，如果该用户随后向应用程序提出另一个请求，其提交的每页面令牌将出现顺序错误，整个会话将被终止。
因此，如果用户仍然在与应用程序交互，则实施攻击的可能性会非常低。
如果攻击者只希望利用用户的权限执行特定操作，则可以实施一次脚本攻击，在有限的时间间隔内执行所需操作。
sess=ab11298f7eg14;
单击“退出”按钮后，应用程序执行以下客户端脚本：
document.cookie=
升级会员 