前端安全:CSRF、XSS该怎么防御?

这篇具有很好参考价值的文章主要介绍了前端安全:CSRF、XSS该怎么防御?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

近几年随着业务的不断发展,前端随之面临很多安全挑战。我们在日常开发中也需要不断预防和修复安全漏洞。接下来,梳理一些场景的前端安全问题和对应的解决方案。

XSS攻击介绍

XSS是后端的责任,后端应该在用户提交数据的接口对隐私敏感的数据进行转义。

NO,这种说法不对

所有插到页面的数据,都要进行过滤转移,当没有敏感字符的时候,就可以直接插到页面上显示了。

NO,丝毫没有什么作用

XSS攻击是页面被注入了恶意的代码,利用恶意脚本,攻击者可以获取用户的Cookie、SessionID等敏感信息。

XSS注入的方法:

  • 在HTML中内嵌的文本中,恶意内容通过script标签注入
  • 在内联的JS中,拼接的数据突破了原本的限制
  • 在标签属性中,恶意内容包含引导,从而突破属性值的限制
  • 在标签href、src等属性中,包含javascript:可执行代码
  • 在onload、onerror、onclick事件中,注入不受控制的代码
  • 在style属性中,类似background- image: url("javascript:..")代码

如果开发者没有将用户输入的文本进行合适的过滤,直接插入到HTML中,很容易造成注入漏洞。

XSS攻击的分类

存储型XSS

其攻击步骤如下:

  1. 攻击者将恶意代码提交到目标网站的数据库
  2. 用户打开目标网站,服务端将恶意代码取出,拼在HTML中返回给浏览器
  3. 用户浏览器解析执行,混在HTML中的恶意代码也被执行
  4. 恶意代码窃取用户数据,冒充用户,执行攻击者制定的操作

常见场景:论坛发帖、商品评论、私信

反射型XSS

其攻击步骤如下:

  1. 攻击者构造特殊URL,其中包含恶意代码
  2. 用户点击打开该URL,服务端将恶意代码从URL中取出,拼接在HTML中返回给浏览器
  3. 浏览器解析执行,混在HTML中的恶意代码也被执行
  4. 恶意代码窃取用户数据,冒充用户,执行攻击者制定的操作

看到这里,我们发现反射型XSS和存储型XSS的区别在于恶意代码的存储位置不同:

  • 反射性XSS:恶意代码存URL上
  • 存储型XSS:恶意代码存数据库里

所以反射性XSS攻击通常借助URL传递参数,如网站搜索、跳转等。

DOM型XSS

其攻击步骤如下:

  1. 攻击者构造特殊URL,其中包含恶意代码
  2. 用户点击打开带有恶意代码的URL
  3. 用户浏览器解析执行,前端JS取出URL中恶意代码并执行
  4. 恶意代码窃取用户数据,冒充用户,执行攻击者制定的操作

DOM型XSS和前两种的区别在于:取出和执行恶意代码都在浏览器端执行,属于JS自身的安全漏洞,而存储型XSS、反射型XSS都属于服务端的安全漏洞。

XSS攻击的防御

通过前面的介绍可以发现,XSS攻击两大因素:

  1. 攻击者提交恶意代码
  2. 浏览器执行了恶意代码

所以,我们可以在这两个方面进行防御。

我们要考虑是否能够在用户输入的过程中,过滤到恶意代码,然后提交到后端。

这条路是不可行的,一旦攻击者绕过前端过滤,就可以直接构造请求来提交恶意代码了。

如果我们将过滤的时机转移到:在后端写入数据库前,后端进行过过滤,只存储安全的内容,并返回给前端,这样能成功防御XSS吗?

在实际的开发中,我们并不确定内容要输出到哪里,用户输入的内容可能同时提供给前端和客户端,而一旦经过escapeHtml(),客户端显示的内容就会变成乱码。

所以,这样的方式会引入很大的不确定性和乱码问题,我们通常不这么做。

预防存储型和反射型XSS攻击

这两种攻击都发现在服务端取出恶意代码并拼接在HTML中,最终被浏览器执行,常见的预防方式:

  • 改成纯前端渲染,把代码和数据分离开
  • 对HTML做转义(采用适合的转义库)

预防DOM型XSS攻击

实际上是网站JS代码本身不够严谨,把不可信数据当作可执行代码。

所以我们在使用.innerHTMLouterHTML时要特别注意,不要把不可信数据作为HTML插入页面。

在vue和react中,也不建议使用v-htmldangerouslySetInnerHTML

检测XSS方法

  1. 使用CSS攻击字符串手动检测XSS漏洞
  2. 使用扫描工具检测(ecsypno)

在github小有个工具库:点击直达

前端安全:CSRF、XSS该怎么防御?
我们将它copy 并拼接在URL参数上,就可以检测了:


jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

虽然很难通过技术手段完全避免 XSS,但我们可以总结以下原则减少漏洞的产生:

  • 利用模板引擎
  • 避免内联事件
  • 避免拼接 HTML
  • 增加攻击难度,降低攻击后果
  • 主动检测和发现

CSRF攻击介绍

CSRF利用受害者的注册凭证,绕过后台验证,冒充用户执行某些操作。

典型的流程:

  1. 受害者登录a.com,并保留了登录cookie
  2. 攻击者诱导用户访问b.com
  3. b.com向a.com发送请求
  4. a.com收到请求后,校验通过,误以为是受害者自己发送的请求
  5. a.con以受害者名义执行某些操作
  6. 攻击完成,受害者浑然不知

常见的CSRF攻击类型

GET

<img src="http://bank.example/withdraw?amount=10000&for=hacker" > 

在受害者访问含有这个img的页面后,浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。

POST

通常CSRF利用一个自动提交的表单,相当于模拟用户完成一次POST操作。

CSRF的特点

  • 攻击一般发起在第三方网站,被攻击的网站无法防止攻击
  • 利用受害者的登录凭证,冒充受害者,而不是直接窃取数据
  • 整个过程不能获取到受害者的登录凭证,仅仅是冒用
  • 通常的方式:图片URL、超链接、CORS、From表单提交

CSRF通常是跨域的,所以我们可以专门制定防御策略,比如:

  • 组织不明外域的访问:同源检测、Samesite Cookie
  • 提交时加上本域才有的信息:CSRF Token、双重Cookie验证

同源检测

在HTTP中每个异步请求都会携带两个Header:Origin Header、Referer Header

服务器可以通过解析这两个Header中的域名,确定请求的来源域

CSRF Token

  1. 将CSRF Token输出到页面
  2. 页面提交的请求中携带这个Token
  3. 服务器验证Tojen是否正确

⚠️注意:Token随机生成,不会被攻击者才到

Samesite Cookie

Set-Cookie响应头新增Samesite属性,它用来标明这个 Cookie是个“同站 Cookie”,同站Cookie只能作为第一方Cookie,不能作为第三方Cookie,Samesite 有两个属性值,分别是 Strict 和 Lax:

  1. Strict:严格模式,任何情况下都不能作为第三方Cookie
  2. Lax:宽松模式,Cookie可作为第三方Cookie

双重Cookie验证

比CSRF Token繁琐一些,而且不能在通用的拦截上统一处理所有的接口:

  1. 在用户访问网站时,向请求的域名注入一个cookie,内容为随机字符串
  2. 前端向后端发起请求时,取出cookie,并添加在URL参数中
  3. 后端接口验证cookie字段与URL参数中字段是否一致

它的好处在于无需使用Session,适用面广。且Token存在客户端,也不会给服务器造成压力。但这样Cookie中增加了额外的字段。如果有其他漏洞(如XSS),攻击者可以注入cookie,防御就会失效。

为了更好的防御CSRF,最佳实践就是结合上述的防御措施的优缺点来综合考虑。文章来源地址https://www.toymoban.com/news/detail-433014.html

到了这里,关于前端安全:CSRF、XSS该怎么防御?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 常见的前端安全CSRF/XSS以及常规安全策略

    1、CSRF:跨站请求伪造(Cross-site request forgery); 原理: (1)用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A; (2)在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A; (3)用户未退出

    2024年02月04日
    浏览(42)
  • 前端面试:【XSS、CSRF、CSP】Web安全的三大挑战

    嗨,亲爱的Web开发者!在构建现代Web应用时,确保应用的安全性至关重要。本文将深入探讨三个常见的Web安全威胁:XSS(跨站脚本攻击)、CSRF(跨站请求伪造攻击)和CSP(内容安全策略),以帮助你了解并应对这些威胁。 1. XSS(跨站脚本攻击): XSS是一种攻击方式,攻击者

    2024年02月11日
    浏览(42)
  • 郑州轻工业大学近几年数据结构试卷

    近几年数据结构试卷: 链接:https://pan.baidu.com/s/1_ns6dbps8i6UyLN5RNJJiw?pwd=g3z2  提取码:g3z2 2019-2020(2)数据结构期末考试试卷    一、 简答题(共10题,100分)  1、已知某二叉树的先序序列和中序序列分别为ABDGEHCFI和DGBHEACIF,请画出这棵二叉树,并画出二叉树对应的森林。  

    2024年01月25日
    浏览(51)
  • 常见web安全漏洞-暴力破解,xss,SQL注入,csrf

    1,暴力破解 原理:         使用大量的认证信息在认证接口进行登录认证,知道正确为止。为提高效率一般使用带有字典的工具自动化操作         基于表单的暴力破解 --- 若用户没有安全认证,直接进行抓包破解。 验证码绕过                           on s

    2023年04月12日
    浏览(52)
  • 安全测试之xss漏洞的检测与防御

    整理了一些软件测试方面的资料、面试资料(接口自动化、web自动化、app自动化、性能安全、测试开发等),有需要的小伙伴可以文末加入我的学习交流qun,无套路自行领取~  最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是

    2024年02月11日
    浏览(50)
  • 万字讲解9种Web应用攻击与防护安全。XSS、CSRF、SQL注入等是如何实现的

    OWASP(开放Web软体安全项目- Open Web Application Security Project) 是一个开源的、非盈利的全球性安全组织,致力于应用软件的安全研究。使命 是使应用软件更加安全,使企业和组织能够对应用安全风险做出更清晰的决策。 http://www.owasp.org.cn/ OWASP在业界影响力: OWASP被视为web应用

    2023年04月15日
    浏览(50)
  • 近几年计算机毕设之论文参考文献(Java参考文献、MySQL参考文献、jsp参考文献、Python参考文献、微信小程序参考文献、外文参考文献)(10个一组)

    目录   1、Java参考文献 2、JavaWeb参考文献 3、MySQL参考文献 4、Python参考文献 5、微信小程序参考文献 6、Jsp参考文献 7、SpringBoot参考文献 8、vue参考文献 9.ASP.NET参考文献 10、外文参考文献        

    2024年02月20日
    浏览(73)
  • Web前端安全学习-CSRF

    今天下午上了一堂前端安全的课,挺有意思,记录下来。在上课之前,我对安全的概念是: 用户输入是不可信的,所有用户的输入都必须转义之后才入库。 然后,上面这个这种方式,仅仅是防止SQL注入攻击,避免业务数据库被渗入。 在数据库有了一层安全保护之后,攻击者

    2024年02月02日
    浏览(45)
  • 【 安全】什么是CSRF攻击?如何避免?开发的时候怎么预防?

    CSRF定义: 跨站请求伪造(英语:Cross-site request forgery)是一种对网站的恶意利用,也被称为 one-click attack 或者 session riding,通常缩写为 CSRF 或者 XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。 CSRF跨站点请求伪造(Cross—Site Request Forgery) 跟

    2024年03月14日
    浏览(85)
  • xss csrf 攻击

    介绍 xss csrf 攻击 XSS: XSS 是指跨站脚本攻击。攻击者利用站点的漏洞,在表单提交时,在表单内容中加入一些恶意脚本,当其他正常用户浏览页面,而页面中刚好出现攻击者的恶意脚本时,脚本被执行,从而使得页面遭到破坏,或者用户信息被窃取。 要防范 XSS 攻击,需要在

    2024年02月14日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包