【web-攻击用户】（9.3.2）诱使用户执行操作--请求伪造——UI伪装

目录

请求伪造——UI伪装

1.1、简介：

1.2、破坏框架防御

1.3、防止UI伪装

---

请求伪造——UI伪装

1.1、简介：

1、一般与页面中的令牌有关的反CSRF防御旨在确保请求是由应用程序中的用户操作本身提出的，而不是由某个第三方域诱发的。即使采用了反CSRF令牌，第三方站点仍然可以通过UI伪装攻击诱使其他域中的用户执行操作。在某种程度上，这类攻击能够成功，是因为生成的请求实际上来自攻击者针对的应用程序。UI伪装技巧通常也称为"点击劫持"、"键击劫持"等其他信见说法。

---

2、一般在UI伪装攻击中，攻击者的网页会将目标应用程序加载到其页面上的iframe中，实际上，攻击者会用其他界面覆盖目标应用程序的界面，攻击者的界面中包含吸引用户并诱使其执行各种操作（如单击）的内容。用户执行这些操作时， 虽然看起来其单击的是攻击者的界面中显示的按钮和其他UI元素，但实际上是在不知情的情况下与攻击者所针对的应用程序进行交互。

---

3、如一个分两步进行转账的银行功能，在第一步中，用户提交转账信息，对此请求的响应将显示这些信息，以及一个用于确认该操作并进行转账的按钮，为防止CSRF攻击， 响应中的表单还包含一个隐藏字段，其中提供了一个无法预测的令牌。此令牌在用户单击“确认” 时提交，应用程序将在转账之前验证它的值。

---

4、在UI伪装攻击中， 攻击者的页面在此过程中使用传统的CSRF提交第一个请求。提交过程在攻击者页面内的iframe中完成。和正常情况下一样，应用程序会作出响应，返回要添加的用户的详细信息，以及一个用于确认该操作的按钮，此响应将在攻击者的iframe中“显示＂，该iframe已由攻击者的界面覆盖，该界面旨在诱使受害用户单击包含“确认” 按钮的区域。如果用户在此区域单击， 他将在不知情的情况下单击目标应用程序中的"确认"按钮，从而创建新用户

---

5、这种攻击之所以能够在纯粹的CSRF攻击无法奏效的情况下取得成功，是因为应用程序使用的反CSRF令牌以正常方式得到处理。虽然由于同源策略的原因，攻击者的页面无法读取该令牌的值， 但攻击者的iframe中的表单包含了由应用程序生成的令牌，在受害用户不知情的情况下单击“确认” 按钮时，这个令牌被返交给应用程序。在目标应用程序看来，一切都很正常

---

6、要实施欺骗，即让受害用户虽然看到一个界面，但实际上却与另一个界面交互，攻击者可以采用各种CSS技术，加载目标应用程序的iframe可以为任意大小，位于攻击者页面中的任何位置，并显示目标页面的任意位置，使用适当的样式属性，可以令该iframe变得完全透明，从而使其对用户不可见

---

7、如果进一步扩展上述基本攻击，攻击者可以在其界面中使用复杂的脚本代码，以诱使受害用户执行更加复杂的操作，而不仅仅是单击按钮，如要实施攻击，需要诱使用户在输入字段（如转账页面的“金额” 字段）中输入一些文本，攻击者可以在其用户界面中包含一些诱使用户输入文本的内容，如用于输入电话号码以赢得奖励的表单，然后攻击者的页面中的脚本可以对进行键击选择性处理，在用户输入相关字符时，将键击操作有效传递到目标界面，从而填写所需的输入字段，如果用户输入攻击者不希望在目标界面中输入的字符， 该键击将不会传递给目标界面，攻击者的脚本将等待下一次键击。

---

8、另外，攻击者的页面中可以包含诱使用户执行拖动鼠标操作的内容，在攻击者的页面中运行的脚本将选择性地处理生成的操作，使用户在不知情的情况下选择目标应用程序界面中的文本，并将其拖动到攻击者的界面中的输入字段中（或相反）。如在针对Web邮件应用程序实施攻击时，攻击者可以诱使用户将电子邮件中的文本拖动到其能够读取的输入字段中。或攻击者可以诱使用户建立某种规则，向*转发所有电子邮件，并将所需电子邮件地址从攻击者的界面拖动到定义该规则的表单的相关输入字段中。由于链接和图像均可以作为URL进行拖动，攻击者甚至可以通过诱发拖动操作从目标应用程序的界面中拦截敏感URL，包括反CSRF令牌

1.2、破坏框架防御

1、在Ul伪装攻击最初受到广泛关注时，许多知名的Web应用程序寻求采用一种称为破坏框架的技术来防范这类攻击。在某些情况下，这种技术已用于防范其他基于框架的攻击。

---

2、破坏框架可以表现为各种形式，但基本上，它是指每个相关的应用程序页面都会运行一段脚本来检测自己是否被加载到iframe中，如果是，应用程序会尝试"破坏" 该iframe，或执行其他防御性操作，如重定向到错误页面或拒绝显示应用程序自己的界面

---

3、如检查页面本身的URL与浏览器窗口中的顶部框架的URL是否匹配，如果不匹配，则说明页面已加载到子框架内，在这种情况下， 脚本会尝试将页面重新加载到窗口内的顶层框架中，从而"逃离"该框架

---

4、实施UI伪装攻击的攻击者可以通过各种方式避开这种防御，将目标页面成功嵌如框架

A、由于攻击者的页面控制着顶层框架，因而可以重新定义top.location的含义， 在子框架
尝试引用它时导致异常

B、顶层框架可能会钩住window.onbeforeunload事件，从而在“破坏框架” 代码尝试设置顶层框架的位置时运行攻击者的事件处理程序，攻击者的代码可以对返回HTTP 204（无内容）响应的URL执行进一步的重定向，这会导致浏览器取消重定向调用链，使顶层框架的URL保持不变

C、预层框架可以在将目标应用程序加载到子框架中时定义sandbox属性，这会在子框架中禁用脚本，同时将其cookie保持为启用状态

D、顶层框架可以利用XSS过滤器在子框架中选择性的禁用“破坏框架”脚本。当攻击者的页面指定iframe目标的URL时，可以创建一个新参数，在参数值中包含一段适当的"破坏框架"脚本，XSS过滤器将标识该参数值及目标应用程序返回的响应中的脚本代码，并禁用响应中的脚本，设法为用户提供保护

1.3、防止UI伪装

1、虽然一些类型的“破坏框架” 代码可以在一定程度上阻止UI伪装攻击，但绝不能将这种技术作为防范UI伪装攻击的万全之策。

---

2、要防止攻击者将应用程序页面嵌入框架，一种更加可靠的方法是使用X-Frame-Options响应消息头。该消息头由IE8引入，随后许多其他流行的浏览器也开始采用这种方法。X-Frarne-Options消息头可以接受两个值：值deny指示浏览器防止页面被嵌人框架， 值sameorigin指示浏览器防止第三方被执行"嵌入框架"操作

---

3、在分析应用程序采用的任何反嵌入框架防御时，应始终检查适用于移动设备的界面的任何相关版本。如虽然xxx.com/chat/能够可靠地防范嵌入框架攻击，但xxx.com/mobile/chat/可能并不提供此类防御，在设计反嵌入框架防御时，应用程序开发者通常会忽略用户界面的移动版本，这可能是因为他们认为UI伪装攻击无法在移动设各上实施。但许多情况下，在使用标准（非移动）浏览器访问时，移动版本的应用程序仍然能够正常运行，并且用户会话可以在移动和非移动版本的应用程序之间共享