web 安全

2020/03/31 功能实现

前端防范安全

随着互联网的发展,各种 Web 应用变得越来越复杂,满足了用户的各种需求的同时,各种网络安全问题也接踵而至。作为前端工程师的我们也逃不开这个问题

XSS

概念:cross-site-script 跨站脚本攻击,是一种注入代码攻击,攻击者在目标网站注入恶意代码,被攻击者登录网站时就会执行这个恶意代码,脚本可以读取本地的 cookie session 等用户敏感信息

分类:存储型(持久性),反射性(非持久性), DOM

  1. 存储型:恶意代码被存入了数据库中,

    解决方案:

    前端不信任用户输入,对于所有用户输入的进行转义/过滤传给服务器 前端不信任服务器的输入,对所有服务器传入的进行转义/过滤之后渲染到页面
    服务器不信任前端的输入,对所有前端传入的进行转义/过滤之后存到服务器

  2. 非持久性/ DOM :恶意代码被直接渲染到了页面,解决方案,对前端的输入进行转义/过滤之后渲染到页面

CSRF

概念:cross-site request forgery 跨站请求伪造,攻击者诱导受害者进入第三方网站,在第三方网站中,攻击者拿到了用户信息,绕过后台的限制,进行发送跨站请求。

解决方案:

  1. 添加验证码(体验不好)

验证码能够防御 CSRF 攻击,但是我们不可能每一次交互都需要验证码,否则用户的体验会非常差,但是我们可以在转账,交易等操作时,增加验证码,确保我们的账户安全。

  1. 判断请求的来源:检测 Referer (并不安全,Referer 可以被更改)

Referer 可以作为一种辅助手段,来判断请求的来源是否是安全的,但是鉴于 Referer 本身是可以被修改的,因为不能仅依赖于 Referer

  1. 使用 Token(主流)

CSRF 攻击之所以能够成功,是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个 CSRF 攻击者无法获取到的 Token。服务器通过校验请求是否携带正确的 Token,来把正常的请求和攻击的请求区分开。跟验证码类似,只是用户无感知。

  • 服务端给用户生成一个 token,加密后传递给用户
  • 用户在提交请求时,需要携带这个 token
  • 服务端验证 token 是否正确
  1. Samesite Cookie 属性

为了从源头上解决这个问题,Google 起草了一份草案来改进 HTTP 协议,为 Set-Cookie 响应头新增 Samesite 属性,它用来标明这个 Cookie 是个“同站 Cookie”,同站 Cookie 只能作为第一方 Cookie,不能作为第三方 CookieSamesite 有两个属性值,分别是 StrictLax

部署简单,并能有效防御 CSRF 攻击,但是存在兼容性问题。

Samesite=Strict

Samesite=Strict 被称为是严格模式,表明这个 Cookie 在任何情况都不可能作为第三方的 Cookie,有能力阻止所有 CSRF 攻击。此时,我们在 B 站点下发起对 A 站点的任何请求,A 站点的 Cookie 都不会包含在 cookie 请求头中。

Samesite=Lax

Samesite=Lax 被称为是宽松模式,与 Strict 相比,放宽了限制,允许发送安全 HTTP 方法带上 Cookie,如 Get / OPTIONSHEAD 请求.

但是不安全 HTTP 方法,如: POST, PUT, DELETE 请求时,不能作为第三方链接的 Cookie 为了更好的防御 CSRF 攻击,我们可以组合使用以上防御手段。


有时候,虽然素未谋面。却已相识很久,很微妙也很知足。在逝去的岁月里,我们在某一刻,共同经历着一样的情愫。

如果喜欢我的话,我们可以互相关注,相互学习的哟!互相鼓励,你的关注是我最大的动力来源

sunseekers

Search

    Table of Contents