XSS和CSRF

XSS

Cross Site Script，跨站脚本攻击，是指攻击者在网站上注入恶意客户端代码，通过恶意脚本对客户端网页进行篡改，从而在用户浏览网页时，对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式

反射型：把用户输入的数据反射给浏览器，该攻击方式通常诱使用户点击一个恶意链接或者提交一个表单，在用户点击链接或提交表单的同时向用户访问的网站注入脚本

存储型：恶意脚本被保存到了服务器端，并且可以被普通用户完整获取并执行。常见的是攻击者在论坛上写下包含恶意攻击脚本的文章或者评论，如<div><script>alert("XSS攻击")</script> </div>，所有访问该文章或评论的用户，都会执行这段恶意脚本

基于DOM：通过恶意脚本修改页面的DOM结构，是纯粹发生在客户端的攻击，也属于反射型的一种

防范方法：

1.现代主流浏览器内置CSP

内容安全策略(CSP)用于检测和减轻用于Web站点的特定类型的攻击，例如XSS和数据注入等。本质是建立白名单，规定了浏览器只能执行特定来源的代码

通过Content-Security-PolicyHttp头来开启CSP：

    • 只允许加载本站资源Content-Security-Policy: default-src 'self'
    • 只允许加载HTTPS协议图片
      Content-Security-Policy: img-src https://*
    • 允许加载任何来源框架 Content-Security-Policy: child-src 'none'

2.HttpOnly阻止Cookie劫持攻击

为避免跨域脚本 (XSS) 攻击，通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie，它们只应该发送给服务端。如果 Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。

如上所述，发起XSS的攻击者既然可以通过注入恶意脚本获取用户的 Cookie 信息。所以，严格来说，HttpOnly 并非阻止 XSS 攻击，而是能阻止 XSS 攻击后的 Cookie 劫持攻击。

将重要的cookie标记为httponly，这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，但是在js脚本中却不能访问这个cookie，这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie。

3.输入检查/XSS Filter

对于用户的任何输入要进行检查、过滤和转义。一般是检查用户输入的数据中是否包含 <，>,script 等特殊字符，如果存在，则对特殊字符进行过滤或编码。

对于显示富文本来说，不能用上述方法转义所有字符，因为这样会把需要的格式也去掉。例如会把< h1>标题 < /h1>也转义掉。这种方法通常采用白名单过滤的办法，把需要的标签(如< h1>)保留。

CSRF

Cross Site Request Forgery，跨站请求伪造。是劫持受信任用户向服务器发送非预期请求的攻击方式。例如，这些非预期请求可能在url后加入一些恶意的参数。从而达到攻击者的目的

通常情况下，CSRF攻击是攻击者借助受害者的Cookie骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。

简单来说，CSRF就是利用用户的登录态发起恶意请求。

假设有一个 bbs 站点：http://www.c.com，当登录后的用户发起如下 GET 请求时，会删除 ID 指定的帖子：

http://www.c.com:8002/content/delete/:id

如发起 http://www.c.com:8002/content/delete/87343 请求时，会删除 id 为 87343 的帖子。当用户登录之后，服务器会设置如下 cookie并发送到浏览器:

  res.setHeader('Set-Cookie', ['user=22333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);

然后CSRF 攻击者准备了一个页面http://www.a.com：

<p>CSRF 攻击者准备的网站：</p>

<img src="http://www.c.com:8002/content/delete/87343">

该页面使用了一个 img 标签，其地址指向了删除用户帖子的链接：http://www.c.com:8002/content/delete/87343

可以看到，当登录用户访问攻击者的网站时，会向 www.c.com 发起一个删除用户帖子的请求。由于用户已经登录，则www.c.com下已经存在了该user=22333的cookie，那么删除请求就会顺利进行。此时若用户在切换到 www.c.com 的帖子页面刷新，会发现ID 为 87343 的帖子已经被删除。

这个攻击过程中，攻击者借助受害者的 Cookie 骗取服务器的信任，但并不能拿到 Cookie，也看不到 Cookie 的内容。而对于服务器返回的结果，由于浏览器同源策略的限制，攻击者也无法进行解析。因此，攻击者无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。

若 CSRF 攻击的目标并不需要使用 Cookie，则也不必顾虑浏览器的 Cookie 策略了。

CSRF的防范：

可遵循以下几种规则：

  • Get 请求不对数据进行修改
  • 不让第三方网站访问到用户Cookie
  • 阻止第三方网站请求接口
  • 请求时附带验证信息，如验证码或Token

1.验证码：CSRF攻击往往是在用户不知情的情况下发起了网络请求，而验证码会保证用户必须与应用进行交互，才能完成请求

2.Referer Check：在HTTP头中有一个字段叫做Referer,它记录了该HTTP请求的来源地址。通过Referer Check,可以检查是否来自合法的"源".

3.请求地址添加token验证：可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。CSRF 攻击之所以能够成功，是因为攻击者可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 Cookie 中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的 Cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入攻击者所不能伪造的信息，并且该信息不存在于 Cookie 之中。为请求添加token验证可以很好地做到这一点。

4.SameSite Cookie：给Cookie设置SameSite属性。这样服务器可以要求某个cookie在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（CSRF）。但目前SameSite Cookie还处于实验阶段，并不是所有浏览器都支持。

三、XSS与CSRF的对比总结

  • XSS是利用用户对指定网站的信任
  • CSRF是利用网站对用户的信任

 

posted @ 2020-04-02 16:56  ajjoker  阅读(191)  评论(0)    收藏  举报