浏览器：浏览器网络安全整理

, , ,

记一下 csrf 和 xss

同源策略可以隔离各个站点之间的 DOM 交互、页面数据和网络通信，虽然严格的同源策略会带来更多的安全，但是也束缚了 Web。这就需要在安全和自由之间找到一个平衡点，所以我们默认页面中可以引用任意第三方资源，然后又引入 CSP 策略来加以限制；默认 XMLHttpRequest 和 Fetch 不能跨站请求资源，然后又通过 CORS 策略来支持其跨域。

CSP 策略

配置内容安全策略涉及到添加 Content-Security-Policy HTTP 头部到一个页面，并配置相应的值，以控制用户代理（浏览器等）可以为该页面获取哪些资源。比如一个可以上传文件和显示图片页面，应该允许图片来自任何地方，但限制表单的 action 属性只可以赋值为指定的端点。一个经过恰当设计的内容安全策略应该可以有效的保护页面免受跨站脚本攻击。制定策略：

  1. Content-Security-Policy: policy
  2. Content-Security-Policy: default-src ‘self’
  3. Content-Security-Policy: default-src ‘self’ _.trusted.com
  4. Content-Security-Policy: default-src ‘self’; img-src _; media-src media1.com media2.com; script-src userscripts.example.com
  5. Content-Security-Policy: default-src https://onlinebanking.jumbobank.com
  6. Content-Security-Policy: default-src ‘self’ _.mailsite.com; img-src _

跨站脚本攻击（XSS）

XSS 全称是 Cross Site Scripting，为了与“CSS”区分开来，故简称 XSS，翻译过来就是“跨站脚本”。
XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。

  1. 危害：

  • 可以窃取 Cookie 信息。恶意 JavaScript 可以通过“document.cookie”获取 Cookie 信息，然后通过 XMLHttpRequest 或者 Fetch 加上 CORS 功能将数据发送给恶意服务器；恶意服务器拿到用户的 Cookie 信息之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。

  • 可以监听用户行为。 恶意 JavaScript 可以使用“addEventListener”接口来监听键盘事件，比如可以获取用户输入的信用卡等信息，将其发送到恶意服务器。

  • 可以通过修改 DOM 伪造内容

  • 还可以在页面内生成浮窗广告

    。。。

  1. 如何注入
  • 存储型 XSS 攻击、反射型 XSS 攻击和基于 DOM 的 XSS 攻击。

存储型是用户输入的恶意脚本地址被存储到数据库，当哦用户访问页面时，被展示出来，浏览器识别成 script 脚本。这个时候这个脚本就可以读取 cookie 信息，操作 dom 了，监听输入了。

反射型跟存储型的区别在于服务器没有存储反射型 XSS 攻击的恶意脚本。

基于 DOM 的攻击。在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。比如通过网络劫持在页面传输过程中修改 HTML 页面的内容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的等等。

  1. 如何阻止 XSS 攻击
  • 输入来源：服务器对输入脚本进行过滤或转码。如 > 转换成 &gt, 或者直接过滤掉 <script>
  • 充分利用 CSP
    • 限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
    • 禁止向第三方域提交数据，这样用户数据也不会外泄；
    • 禁止执行内联脚本和未授权的脚本；
    • 还提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。
  • 使用 HttpOnly 属性

CSRF 攻击

CSRF 英文全称是 Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求。简单来讲，CSRF 攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。

发起 CSRF 攻击的三个必要条件：

  1. 目标站点一定要有 CSRF 漏洞；
  2. 用户要登录过目标站点，并且在浏览器上保持有该站点的登录状态；
  3. 需要用户打开一个第三方站点，可以是黑客的站点，也可以是一些论坛。

防止：

  1. 利用好 Cookie 的 SameSite 属性
  2. 验证请求的来源站点，HTTP 请求头中的 Referer 和 Origin 属性。Origin 属性只包含了域名信息，并没有包含具体的 URL 路径，这是 Origin 和 Referer 的一个主要区别。
  3. CSRF Token
    • 第一步，在浏览器向服务器发起请求时，服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中。
    • 第二步，在浏览器端如果要发起转账的请求，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到 CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。

CSRF Token 和 JWT 的区别

CSRF Token 是用来防范 CSRF 攻击的。JWT 主要用于用户身份认证（http 无状态，所以这种方式将 session id 加密存储在客户端，而不是存储在后端唯一的 session 服务，因为这样不好做负载均衡）

HTTP 是无状态的,为了能够在 HTTP 协议之上保持住状态,比如用户是否登陆、购物车等等。
这种技术就叫 Session。
Session 的功能是把一个个分离的 HTTP 请求关联起来，只要能实现这个功能，基本上都能叫 Session 的一种实现。

  • 在 Cookie 里放个 JSESSIONID，在服务器中存上状态，用户请求来了，根据 JSESSIONID 去服务器里查状态，这是 Tomcat 的实现方法。
  • 把所有状态都存在 Cookie 里，服务器给个签名防止伪造，每次请求来了，直接从 Cookie 里提取状态，这是 JWT 的实现方法。
  • 在 Cookie 里放个 token，状态不存在中间件里，而是存在 Redis 里，这也是一种 Session 实现方法。

只要 HTTP 还是无状态的，只要保存状态还是刚需，Session 就不会消失，变化的只是它的实现方式。 举个例子，只要人们还要出行，交通工具就不可能消失，只是实现的方法从走路变成了马车，在变成火车、汽车、飞机，未来可能还有火箭啥的。

  • 版权声明： 本博客所有文章除特别声明外，均采用 CC BY 4.0 CN协议 许可协议。转载请注明出处！

Laputa Z

Жизнь, как качели - то вверх, то вниз.