owaspbwa筆記
2.1.1 HTTP 基础知识（Http Basics） .............................................9
HTTP 是如何工作的呢？所有的 HTTP 传输都要遵循同样的通用格式（需要使用 IEWatch
或 WebScarab 类插件协助进行学习）。每个客户端的请求和服务端的响应都有三个部分：请
求或响应行、一个报头部分和实体部分。客户端以如下方式启动一个交互：
客户端连接服务器并发送一个文件请求。
GET /index.html?param=value HTTP/1.0
接下来，客户端发送可选头信息，告知接收服务器其配置和文件格式。
User-Agent: Mozilla/4.06 Accept: image/gif, image/jpeg, */*
发送请求和报头之后，客户端可以发送更多的数据。该数据主要用于使用 POST 方法的CGI 程序。
2.1.2 HTTP 拆分（HTTP Splitting）..........................................11
攻击者在向 Web 服务器正常输入的请求中加入恶意代码，受到攻击的应用不会检查 CR
（回车，也可表示为%0d 或\r）和 LF（换行，也可表示为%0a 或\n）。这些字符不仅使攻击
者控制应用程序打算发送的响应头和响应体，而且还使他们能够完全在其控制下创造更多的
答复。
HTTP 拆分攻击配合缓存污染一起使用，能使效果达到最大化。缓存污染攻击的目标是
使缓存污染，欺骗缓存，使其相信使用 HTTP 拆分劫持的页面是一个很正常的页面，是一个
服务器的副本。攻击发生时，使用 HTTP 拆分攻击，加上最后修改添加的部分：请求头，并
设置它为将来的日期。这将迫使浏览器发送 If ‐ Modified‐ Since 请求头，这使攻击者有机会
拦截服务器的答复，并代之以一个“304 不修改”答复。以下是一个简单的 304 响应：
HTTP/1.1 304 Not Modified
Date: Fri, 30 Dec 2005 17:32:47 GMT
2.2 访问控制缺陷（Access Control Flaws） ...............................................................19
2.2.1 使用访问控制模型（Using an Access Control Matrix）...................................19
在一个基于角色的访问控制方案中，角色代表了一组访问权限和特权。一个用户可以被
分配一个或多个角色。一个基于角色的访问控制方案通常有两个部分组成：角色权限管理和
角色分配。一个被破坏的基于角色的访问控制方案可能允许用户执行不允许他/她的被分配
的角色，或以某种方式允许特权升级到未经授权的角色的访问。
2.2.2 绕过基于路径的访问控制方案（Bypass a Path Based Access Control Scheme）.......................22
在一个基于路径的访问控制方案中，攻击者可以通过提供相对路径信息遍历路径。因此，
攻击者可以使用相对路径访问那些通常任何人都不能直接访问或直接请求就会被拒绝的文
件。
2.2.3 基于角色的访问控制（LAB: Role Based Access Control）...............................25
在一个基于角色访问控制的方案中，角色代表一组访问权限和特权。一个用户可以被分
配一个或多个角色，一个基于角色的访问控制通常包括两个部分：角色权限管理和角色分配。
一个被破坏的基于角色的访问控制方案，可能允许用户以没有分配他/她的角色或以某种方
式获得的未经授权的角色进行访问。
2.2.4 远程管理访问（Remote Admin Access）.........................................................36
应用程序通常会有一个管理界面，这个界面一般用户无法访问到，只有具有特权的用户
才能访问。
2.3 Ajax 安全（Ajax Security）....................................................................................38
AJAX 技术的一项关键元素是 XMLHttpRequest（XHR），该技术允许客户端向服务端发起
异步调用。然而，作为一项安全措施，这些请求最好只能从客户端原始页面向服务端发起访
问。
2.3.1 同源策略保护（Same Origin Policy Protection）.............................................38
同源策略是客户端脚本（尤其是 Javascript）的重要的安全度量标准。它最早出自于
Netscape Navigator2.0，其目的是防止某个文档或脚本从多个不同源装载。
当脚本被浏览器半信半疑运行在沙箱时，它们应该只被允许访问来自同一站点的资源，
而不是那些来自其它站点可能怀有恶意的资源。
2.3.2 基于 DOM 的跨站点访问（LAB: DOM‐Based cross‐site scripting）................39
文档对象模型（DOM）从安全的角度展现了一个有趣的问题。它允许动态修改网页内
容，但是这可以被攻击者用来进行恶意代码注入攻击。XSS，一种恶意代码注入，一般会发
生在未经验证的用户的输入直接修改了在客户端的页面内容的情况下。
2.3.3 小实验：客户端过滤（LAB: Client Side Filtering）..........................................43
服务端只向客户端发送其只能访问到的数据。在本课程中，服务端向客户端发送了过多
的数据，由此产生了一个严重的访问控制问题。
2.3.4 DOM 注入（DOM Injection）............................................................................46
一些应用程序专门使用 AJAX 操控和更新在 DOM 中能够直接使用的 JavaScript、DHTML
和 eval()方法。攻击者可能会利用这一点，通过拦截答复，注入一些 JavaScript 命令，实施攻
击。
2.3.5 XML 注入（XML Injection） ..............................................................................49
AJAX 应用程序使用 XML 与服务端进行信息交互。但该 XML 内容能够被非法用户轻易拦
截并篡改。
2.3.6 JSON 注入（JSON Injection）............................................................................52
javaScript Object Notation (JSON)是一种简单的轻量级的数据交换格式，JSON 可以
以很多形式应用，如：数组，列表，哈希表和其他数据结构。JSON 广泛应用于 AJAX 和
web2.0 应用。相比 XML，JSON 得到程序员的更多的青睐，因为它使用更简单，速度更快。
但是与 XML 一样容易受到注入攻击，恶意攻击者可以通过在请求响应中注入任意值。
2.3.7 静默交易攻击（Silent Transactions Attacks）..................................................54
对客户端来说，任何一个静默交易攻击，使用单一提交的系统都是有危险的。举例来说，
如果一个正常的 web 应用允许一个简单的 URL 提交，一个预设会话攻击将允许攻击者在没
有用户授权的情况下完成交易。在 Ajax 里情况会变得更糟糕：交易是不知不觉的，不会在
页面上给用户反馈，所以注入的攻击脚本可以在用户未授权的情况下从客户端把钱偷走。
2.3.8 危险指令使用（Dangerous Use of Eval）.........................................................57
在服务端验证所有用户输入的信息，这是一个不错的做法。如果未验证的用户输入直接
通过 HTTP 响应返回给客户端的话，往往会触发 XSS 攻击。
在这一课中，未验证的用户提供的数据结合了 JavaScript 的 eval()调用一起使用。在反射
型 XSS 攻击中，攻击者可以构造带有攻击脚本的 URL，将其存储于其他站点，通过电子邮件，
或者其他方式诱骗用户点击，达到 XSS 的目的。
2.3.9 不安全的客户端存储（Insecure Client Storage）............................................59 *********************
在服务端验证所有的用户输入信息总是不错的做法。客户端进行的任何验证信息都存在
被逆向分析的脆弱性。记住，客户端的任何数据都不能被视为机密！
客户端 HTML 和 JavaScrip 语句可以对网页内容、形式做修改，如隐藏、控制读写、限
制长度等。同样，通过修改网页代码也能解除此类限制。
2.4 认证缺陷（Authentication Flaws）.......................................................................62
2.4.1 密码强度（Password Strength）.......................................................................62
密码是账户安全的保障。多数用户都在各个网站上使用同样的弱密码。如果您想您的应
用程序不被攻击者暴力破解，应该设置一个较好的密码。好的密码应包含小写字母、大写字
母和数字。密码越长，效果越好。
2.4.2 忘记密码（Forgot Password）..........................................................................64
Web 应用程序经常为用户提供密码找回功能。但不幸的是，很多 Web 应用程序的实施
机制并不正确。验证用户身份所需要的信息往往过于简单。
2.4.3 基本认证（Basic Authentication）....................................................................66
基本身份验证通常用来保护服务端的资源。Web 服务器将发送 401 认证请求与所请求
的资源响应。客户端浏览器会提示用户在浏览器提供的对话框中输入用户名和密码。浏览器
将用户名和密码使用 Base64 编码方式进行编码，并将这些凭据发送给 Web 服务器。Web
服务器会验证这些凭据，如果所提供的凭据正确，则返回所请求的资源。这些凭据会自动重
置每一个使用这一机制的被保护的页面，而不需要用户再次输入这些凭据。
基本认证使用 cookie 传递认证信息，可以使用代理工具拦截请求并查看 cookie。
2.4.4 多级登录 1（Multi Level Login 1） ...................................................................71
多级登录提供了一个健壮的验证。这是加入第二层的存档。在通过您的用户名密码登录
后，您可以请求一个“交易认证号（TAN）”。这经常用于网上银行。您得到一个银行提
供的由很多交易认证号生成唯一的列表，每个交易认证号只能使用一次。另一种方法是用短
信提供一个交易认证号，这样做的好处是攻击者无法获得用户的交易认证号。 很多用过的验证码往往能够被再次使用。
2.4.5 多级登录 2（Multi Level Login 2） ...................................................................73
參考上節:
在这一课中，您将要尝试破坏这种认证，通过其他账号进行登录。您需要做的是通过其
他账号登录，在只知道目标用户名的情况下，以该用户名身份登录系统。
2.5 缓冲区溢出（Buffer Overflows）..........................................................................74
缓冲区溢出是指当计算机向缓冲区内填充数据位数时超过了缓冲区本身的容量，溢出的
数据覆盖在合法数据上。理想的情况是程序检查数据长度并不允许输入超过缓冲区长度的字
符，但是绝大多数程序都会假设数据长度总是与所分配的储存空间相匹配，这就为缓冲区溢
出埋下隐患。
2.5.1 Off‐by‐One 缓冲区溢出（Off‐by‐One Overflows） .........................................74
通过向程序的缓冲区写入超出其长度的内容，导致缓冲区的溢出，从而破坏程序的堆栈，
造成程序崩溃或使程序转而执行其它指令，以达到攻击的目的。造成缓冲区溢出的原因是程
序中没有仔细检查用户输入的参数。
缓冲区溢出是一种非常普遍、非常危险的漏洞，在各种操作系统、应用软件中广泛存在。
利用缓冲区溢出攻击，可以导致程序运行失败、系统宕机、重新启动等后果。更为严重的是，
可以利用它执行非授权指令，甚至可以取得系统特权，进而进行各种非法操作。
2.6 代码质量（Code Quality）....................................................................................78
2.6.1 在 HTML 中找线索（Discover Clues in the HTML） .........................................78
众所周知，很多开发者喜欢在源代码中保存 FIXME's、Code Broken、Hack 等语句。通
过审查源代码中的相关注释往往能找到密码、后门及一些潜在的问题。
2.7 并发（Concurrency） ...........................................................................79
2.7.1 线程安全问题（Thread Safety Problems）.......................................................79
Web 应用程序可以同时处理很多 HTTP 请求。开发人员经常使用的变量不是线程安全
的。线程安全是指一个对象或类的领域在多线程同时使用的时候总是保持有效的状态。它往
往可以利用并发错误，精确地在同一时间同一个页面加载另一个用户。
因为所有的线程共享同一个方法区，而所有的类变量存储在方法区，多个线程试图同时
使用相同的类变量。
用户利用 Web 应用程序中的并发错误，查看同一时间另一个用户试图登录同一个功能
的信息。
2.7.2 购物车并发缺陷（Shopping Cart Concurrency Flaw） ....................................80
Web 应用程序可以同时处理很多 HTTP 请求。开发人员经常使用的变量不是线程安全
的。线程安全是指一个对象或类的领域在多线程同时使用的时候总是保持有效的状态。它往
往可以利用并发错误，精确地在同一时间同一个页面加载另一个用户。
因为所有的线程共享同一个的方法区，所有的类变量存储在方法区，多个线程试图同时
使用相同的类变量。
2.8 跨站脚本攻击（Cross‐Site Scripting (XSS)）.........................................................82
2.8.1 使用 XSS 钓鱼（Phishing with XSS）.................................................................82
在服务端对所有输入进行验证总是不错的做法。当用户输入非法 HTTP 响应时容易造成
XSS。在 XSS 的帮助下，您可以实现钓鱼工具或向某些官方页面中增加内容。对于受害者
来说很难发现该内容是否存在威胁。
2.8.2 小实验：跨站脚本攻击（LAB: Cross Site Scripting） ......................................84
输入验证是一个很好的方法，尤其是验证那些以后将用做参数的操作系统命令、脚本和
数据库查询的输入。尤为重要的是，这些内容将会永久的存放在那里。应当禁止用户创建消
息内容。用户的信息被检索时，可能导致其他用户加载一个不良的网页或不良的内容。当一
个未经验证的用户的输入作为一个 HTTP 响应时，XSS 攻击也可能会发生。在一个反射式
XSS 攻击中，攻击者会利用攻击脚本精心制作一个 URL 并通过将其发送到其他网站、电子
邮件、或其他方式骗取受害者点击它。
2.8.3 存储型 XSS 攻击（Stored XSS Attacks） ...........................................................90
过滤所有用户输入是一个不错的做法，特别是那些后期会被用作 OS、脚本或数据库查
询参数的输入。尤其是那些将要长期存储的内容。用户不能创建非法的消息内容，例如：可
以导致其他用户访问时载入非预期的页面或内容。
2.8.4 跨站请求伪造（Cross Site Request Forgery (CSRF)）.......................................91
跨站请求伪造是一种让受害者加载一个包含网页的图片的一种攻击手段。如下代码所示：
<img src="http://www.mybank.com/sendFunds.do?acctId=123456"/>
当受害者的浏览器试图打开这个页面时，它会使用指定的参数向 www.mybank.com 的
transferFunds.do 页面发送请求。浏览器认为将会得到一个图片，但实际上是一种资金转移
功能。该请求将包括与网站相关的任何 cookies。因此，如果用户已经通过网站的身份验证，
并有一个永久的 cookie，甚至是当前会话的 cookie，网站将没有办法区分这是否是一个从合
法用户发出的请求。通过这种方法，攻击者可以让受害者执行一些他们本来没打算执行的操
作，如注销、采购项目或者这个脆弱的网站提供的任何其他功能
2.8.5 绕过 CSRF 确认（ CSRF Prompt By‐Pass）.......................................................93 **********
网页中所有手动发起的请求操作，其实质是通过 HTML+JavaScript 向服务器发起请求。
类似于 CSRF 课程，您的目标是给新闻组发送一封带有多个威胁请求的 Email。第一个请
求用户资金转账，第二个用于自动处理第一个请求所触发的确认。URL 必须使用以下两个外
部参数“transferFunds=4000”和“transferFunds=CONFIRM”。可以通过在左侧链接中右键鼠
标，复制快捷方式完成 URL 获取。任何收到该邮件的人若正好已经通过认证，则当其访问
该页面时将自动完成资金转账。
2.8.6 绕过 CSRF Token（CSRF Token By‐Pass）..........................................................98
本节课程将指导您如何在启用 CSRF Token 防护的网站上发起跨站请求伪造攻击
（CSRF）。
跨站请求伪造攻击（CSRF/XSRF）欺骗用户（那些已经获取了系统的信任）点击带有
伪造请求的页面从而执行相关命令。
基于 Token 的请求认证用于阻止此类攻击者。该技术在请求发起页面插入 Token。Token
用于完成请求和并验证该操作不是通过脚本执行的。OWASP 提供的 CSRFGuard 使用该技
术以阻止 CSRF 攻击。尽管如此，但如果该站点存在 XSS 攻击漏洞，则该技术可被绕过。由于浏览器同源策
略，相同域名下的页面能够读取其它页面的内容。
2.8.7 HTTPOnly 测试（HTTPOnly Test）...................................................................102
为了降低跨站脚本攻击的威胁，微软引入了新的 cookie 属性字段：“HTTPOnly”。一
旦该字段被标记，浏览器将禁止客户端脚本访问 Cookie。由于该属性相对较新，有些浏览
器还无法正确处理这个属性
2.8.8 跨站跟踪攻击（Cross Site Tracing (XST) Attacks）.........................................103
过滤所有用户输入是一个不错的做法，特别是那些后期会被用作 OS、脚本或数据库查
询参数的输入。尤其是那些将要长期存储的内容。用户不能创建非法的消息内容，例如：可
以导致其他用户访问时载入非预期的页面或内容。
2.9 不当的错误处理（Improper Error Handling） ...................................................105
2.9.1 打开认证失败方案（Fail Open Authentication Scheme）.............................105
本节课程介绍了关于认证“无法打开”的基本知识。用安全术语来讲，“fail open”描
述了一个验证机制的行为。这是一个验证方法的验证结果为“true”时发生的错误（意外的
异常）。在登录过程中，这是特别危险的。
Java 代码中异常处理部分为成功认证行为进行异常捕获。该异常产生是因为密码字段使
用了空指针。.
2.10 注入缺陷（Injection Flaws）...............................................................................107
2.10.1 命令注入（Command Injection）...................................................................107
命令注入攻击对任何一个以参数驱动的站点来说都是一个严重威胁。这种攻击技术背后
的技术方法，简单易学，能造成大范围的损害，危及系统安全。尽管这类风险数目令人难以
置信，互联网中的系统很容易受到这种形式的攻击。
这种攻击容易扩散，造成更坏的影响。但是对于这类威胁，一点常识和预先预防几乎可
以完全阻止。这节课将为学员展示几个参数注入的例子。
“清洗”所有输入数据总是不错的做法，尤其是那些将被用于操作系统命令、脚本和数
据库查询语句的数据。在正常的参数提交过程中，添加恶意的代码，往往能够得到以外的收获。
2.10.2 数字型 SQL 注入（Numeric SQL Injection）...................................................109
SQL 注入攻击对任何一个以数据库作为驱动的站点来说都是一个严重威胁。这种攻击
技术背后的技术方法，简单易学，能造成大范围的损害，危及系统安全。尽管这些风险数目
令人难以置信，互联网中的系统很容易受到这种形式的攻击。
这种攻击容易扩散，造成更坏的影响，但是对于这类威胁，一点常识和预先预防几乎可
以完全阻止。这节课将为学员展示几个参数注入的例子。
尽管 SQL 注入威胁可能已经通过其它方式被拦截，但“清洗”所有输入数据总是不错
的做法，尤其是那些将被用于操作系统命令、脚本和数据库查询语句的数据。
2.10.3 日志欺骗（Log Spoofing）..............................................................................110
这种攻击是在日志文件中愚弄人的眼睛，攻击者可以利用这种方式清除他们在日志中的
痕迹。
2.10.4 XPATH 型注入（XPATH Injection） ..................................................................112
与 SQL 注入类似，XPATH 注入发生在当网站使用用户提供的信息查询 XML 数据时。
通过向网站故意发送异常信息，攻击者可以发现 XML 数据的结构或访问那些本来无法访问
到的数据。如果该 XML 是一个用户认证文件（例如一个基于 XML 的用户文件），攻击者
还能借此提升自己在网站中的特权。使用 XPATH 查询 XML，通过一个简单的描述性语句
类型，允许 XML 查询，找到一条信息。像 SQL 一样，您可以指定找到的某些属性与模式
匹配。
当一个网站中使用 XML，它是普遍接受某种形式的输入，查询字符串，找到并将标识
的内容显示在页面上。此类输入必须进行清洗，以验证它不会影响 XPATH 的查询，并返回
错误数据。
2.10.5 字符串型注入（String SQL Injection） ...........................................................113
2.10.6 小实验：SQL 注入（LAB: SQL Injection） ......................................................115
2.10.7 通过 SQL 注入修改数据（Modify Data with SQL Injection）.........................119
someuserid'; UPDATE salaries SET salary=999999 WHERE userid='jsmith
2.10.8 通过 SQL 注入添加数据（Add Data with SQL Injection）..............................120
whatever'; INSERT INTO salaries VALUES ('rlupin',140000);--
2.10.9 数据库后门（Database Backdoors） ..............................................................121
数据库通常作为一个 Web 应用程序的后端来使用。此外，它也用来作为存储的媒介。
它也可以被用来作为存储恶意活动的地方，如触发器。触发器是在数据库管理系统上调用另
一个数据库操作，如 insert, select, update or delete。举个例子：攻击者可以创建一个触发器，
该触发器在创建新用户时，将每个新用户的 Email 地址设置为攻击者的地址。
101;CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN
UPDATE employee SET email='john@hackme.com' WHERE userid = NEW.userid
2.10.10 数字型盲注入（Blind Numeric SQL Injection）..................................123
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') = 2364 );
2.10.11 字符串型盲注入（Blind String SQL Injection） ..................................124
101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), 1, 1) <'H' );
2.11 拒绝服务（Denial of Service）............................................................................126
2.11.1 多个登录引起的拒绝服务（Denial of Service from Multiple Logins）..........126
拒绝服务攻击是 Web 应用程序中的主要问题。 如果最终用户不能开展业务或执行由
Web 应用程序所提供的服务，则是浪费时间和金钱。数据库连接总是要占用移动资源的；过度使用会影响系统性能。
2.12 不安全的通信（Insecure Communication）.......................................................127
敏感数据不能用明文发送，通常在验证后要切换到安全连接。攻击者可通过嗅探获得的
登录信息和收集到的其他信息入侵账户。一个好的 Web 应用程序总是使用加密方式发送敏
感数据。
2.12.1 不安全的登录（Insecure Login）....................................................................127
2.13 不安全的配置（Insecure Configuration）..........................................................130
2.13.1 强制浏览（How to Exploit Forced Browsing）................................................130
强制浏览是黑客用来访问获取那些没有被引用，但仍然允许被访问的资源的技术。一种
方法是操纵浏览器中的 URL，删除结尾部分，直到找到一个不受保护的目录。
2.14 不安全的存储（Insecure Storage）....................................................................131
2.14.1 强制浏览（How to Exploit Forced Browsing）................................................131
2.15 恶意执行（Malicious Execution）.......................................................................132
2.15.1 恶意文件执行（Malicious File Execution）....................................................132
很多网站允许用户上传文件，例如：图片或是视频。 如果确实有效的安全措施，包含
恶意指令的文件会被上传到服务器并执行。
2.16 参数篡改（Parameter Tampering）....................................................................134
2.16.1 绕过 HTML 字段限制（Bypass HTML Field Restrictions） .............................134
客户端验证不应该被认为是一种安全的参数验证方法。这种验证方式只能帮那些不知道
所需输入的用户缩短服务器处理时间。攻击者可以用各种方法轻易的绕过这种机制。任何客
户端验证都应该复制到服务器端。这将大大减少不安全的参数在应用程序中使用的可能性。
在这个练习中，每个输入框中有不同的输入要求，您要做的就是绕过客户端验证机制破坏这
些规则，输入不允许输入的字符。
2.16.2 利用隐藏字段（Exploit Hidden Fields）.........................................................136
开发人员在加载信息的页面上使用隐藏字段来跟踪、登录、定价等。虽然这是一种方便
且易于开发的机制，他们往往不验证从隐藏字段收到的信息。本课程中，我们将了解如何找
到和修改隐藏字段以便宜的价格购买产品.
2.16.3 利用未检查的 E‐mail（Exploit Unchecked Email） ........................................138
验证所有的输入信息总是不错的做法。多数网站都允许一个非验证的用户给“朋友”发
送 e-mail。对垃圾邮件发送者来说，这是一个绝佳的机制，可以利用公司的邮件服务器来发
送电子邮件。
2.16.4 绕过客户端 JavaScript 校验（Bypass Client Side JavaScript Validation）......142
客户端验证不应该被认为是一种安全的方法验证参数。这种验证方式只能帮那些不知道
所需输入的用户缩短服务器处理时间。攻击者可以用各种方法轻易的绕过这种机制。任何客
户端验证都应该复制到服务器端。这将大大减少不安全的参数在应用程序中使用的可能性。
在这个练习中，每个输入框中有不同的输入要求，您要做的就是绕过客户端验证机制破坏这
些规则，输入不允许输入的字符。
2.17 会话管理缺陷（Session Management Flaws） ..................................................148
2.17.1 会话劫持（Hijack a Session） .........................................................................148
开发人员在开发他们的自有会话 ID 时经常忘记整合的复杂性和随机性，这些因素对安
全来说是必须的。如果用户的特定的会话 ID 不具备复杂和随机性，那么应用程序很容易受
到基于会话的暴力攻击的威胁.会话 ID 一般由 Session 生成，存储在客户端 Cookie 的某个字段中。
2.17.2 认证 Cookie 欺骗（Spoof an Authentication Cookie）...................................154
如果验证 cookie 正确，一些应用程序会允许一个用户自动登录到他们的网站。如果能
够获得生成 cookie 的算法，有时 cookie 的值是可以猜到的。有时候 cookie 可能是通过跨站
攻击截获的。在这一课中，我们的目的是了解身份验证 cookie 的方式，并指导您学习突破
这种身份验证 cookie 的方法
2.17.3 会话固定（Session Fixation）.........................................................................158
服务器通过每个用户的唯一的 Session ID 来确认其合法性。如果用户已登录，并且授权
他不必重新验证授权时，当他重新登录应用系统时，他的 Session ID 依然是被认为合法的。
在一些程序中，可能会在 GET-REQUEST 请求中传递 Session ID。这就是攻击的起点。
一个攻击者可以用一个选定的 Session ID 给受害人发送一个超链接。例如，这里有一个
准备好的邮件，它看起来像是一个从应用程序管理员发来的官方邮件。如果受害者点击了这
个链接，并且该受害者以攻击者指定的 ID 登录了系统；那么攻击者可以不经授权直接使用
与受害者相同的 ID 访问该页
2.18 Web 服务（Web Services）.................................................................................162
2.18.1 创建 SOAP 请求（Create a SOAP Request）...................................................162
Web Services 通过使用 SOAP 请求进行通信。这个请求提交到一个尝试执行一个 Web 服
务描述语言（WSDL）定义的函数的 Web 服务。让我们一起来学习一些关于 WSDL 的文件。
查看一下 WebGoat 的 WSDL 文件。
2.18.2 WSDL 扫描（WSDL Scanning） .......................................................................168
Web Services 通过使用 SOAP 请求进行通信。这个请求提交到一个尝试执行一个 Web 服
务描述语言（WSDL）定义的函数的 Web 服务。让我们一起来学习一些关于 WSDL 的文件。
查看一下 WebGoat 的 WSDL 文件。
2.18.3 Web Service SAX 注入（Web Service SAX Injection）.....................................170
Web Services 通过使用 SOAP 请求进行通信。这个请求提交到一个尝试执行一个 Web 服
务描述语言（WSDL）定义的函数的 Web 服务。让我们一起来学习一些关于 WSDL 的文件。
查看一下 WebGoat 的 WSDL 文件
2.18.4 Web Service SQL 注入（Web Service SQL Injection）.....................................172
2.19 管理功能（Admin Functions）............................................................................175
2.19.1 报告卡（Report Card） ...................................................................................175
2.20 挑战（Challenge）...............................................................................................176
2.20.1 挑战（The CHALLENGE!） ...............................................................................176
