当前位置:首页 » 《关注互联网》 » 正文

前端安全和解决方案

13 人参与  2024年12月24日 14:01  分类 : 《关注互联网》  评论

点击全文阅读


提到这个我可能想到的就是不要暴露太多的账号密码信息。一些页面的请求和操作要加上权限。

然后下面就详细的介绍前端可能遇到的安全问题以及解决方法。

首先比较常见的前端的安全性问题就是跨站脚本攻击(XSS)。跨站请求伪造(csrf)

跨站脚本攻击(XSS)

攻击者通过在目标网站上注入恶意脚本,使之在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息如 Cookie、SessionID 等,进而危害数据安全。

比如:客将恶意 JavaScript 脚本长期保存在服务端数据库中,用户一旦访问相关页面数据,恶意脚本就会被执行。常见于搜索、微博、社区贴吧评论等。

2011年新浪微博曾被黑客 XSS 攻击,黑客诱导用户点击一个带有诱惑性的链接,便会自动发送一条带有同样诱惑性链接微博。攻击范围层层扩大,也是一种蠕虫攻击。

XSS攻击主要有两大步骤:

攻击者提交恶意代码浏览器执行恶意代码

解决办法:

在使用 .innerHTML、.outerHTML、document.write() 时要特别小心,不要把不可信的数据作为 HTML 插到页面上,而应尽量使用 .textContent、.setAttribute() 等。

如果用 Vue/React 技术栈,并且不使用 v-html/dangerouslySetInnerHTML 功能,就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。

DOM 中的内联事件监听器,如 location、onclick、onerror、onload、onmouseover 等,<a> 标签的 href 属性,JavaScript 的 eval()、setTimeout()、setInterval() 等,都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API,很容易产生安全隐患,请务必避免。

使用 W3C 提出的 CSP (Content Security Policy,内容安全策略),定义域名白名单

设置 Cookie 的 HttpOnly 属性,禁止JavaScript读取cookie验证码:防止脚本冒充用户提交危险操作。

跨站请求伪造(CSRF)

攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的。

典型的CSRF攻击是这样的:

受害者登录A网站,并且保留了登录凭证(Cookie)
攻击者引诱受害者访问B网站
B网站向A网站发送了一个请求,浏览器请求头中会默认携带 A 网站的 Cookie
A 网站服务器收到请求后,经过验证发现用户是登录了的,所以会处理请求

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

例子2:访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST操作

<form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script> 

攻击一般发起在第三方网站,而不是被攻击的网站。被攻击的网站无法防止攻击发生。攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;而不是直接窃取数据。整个过程攻击者并不能获取到受害者的登录凭证,仅仅是“冒用”。

解决办法:

同源检测:既然CSRF大多来自第三方网站,那么我们就直接禁止第三方域名(或者不受信任的域名)对我们发起请求。 

表单请求携带CSRF Token:在浏览器向服务器发起请求时,服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的随机字符串,然后将该字符串植入到返回的页面中,通常是放到表单的隐藏输入框中,这样能够很好的保护 CSRF Token 不被泄漏;
当浏览器再次发送请求的时候,就需要携带这个 CSRF Token 值一起提交;
服务器验证 CSRF Token 是否一致;从第三方网站发出的请求是无法获取用户页面中的 CSRF Token 值的。

点击劫持(ClickJacking)

点击劫持(Clickjacking)是一种通过视觉欺骗的手段来达到攻击目的手段。往往是攻击者将目标网站通过 iframe 嵌入到自己的网页中,通过 opacity 等手段设置 iframe 为透明的,使得肉眼不可见,这样一来当用户在攻击者的网站中操作的时候,比如点击某个按钮(这个按钮的顶层其实是 iframe),从而实现目标网站被点击劫持。

解决办法:

判断当前网页是否被 iframe 嵌套。如果有嵌套就让他跳转到原本的页面

加代码

if(selft===top){

    var theBody=document.getElementByTagName('body')[0];

     theBody.style.display='block';

}else{

     top.location=self.location;

}

也可以在你的服务器配置中设置X-Frame-Options

CDN劫持

让用户自动转入自己开发的网站。而很多用户却往往无法察觉到自己已经被劫持。其实验证被劫持的方法,就是输入任何网址看看所打开的网页是否和自己输入的网址一致,

解决办法:

使用SRI来解决CDN劫持。SRI 全称 Subresource Integrity - 子资源完整性,是指浏览器通过验证资源的完整性(通常从 CDN 获取)来判断其是否被篡改的安全特性。

通过给 link 标签或者 script 标签增加 integrity 属性即可开启 SRI 功能,比如

<script type="text/javascript" src="//s.url.cn/xxxx/aaa.js" 
    integrity="sha256-xxx sha384-yyy"
    crossorigin="anonymous"></script>
integrity 值分成两个部分,第一部分指定哈希值的生成算法(sha256、sha384 及 sha512),第二部分是经过 base64 编码的实际哈希值,两者之间通过一个短横(-)分割。integrity 值可以包含多个由空格分隔的哈希值,只要文件匹配其中任意一个哈希值,就可以通过校验并加载该资源。开启 SRI 能有效保证页面引用资源的完整性,避免恶意代码执行。
 

SQL注入(更偏向后端处理)

web应用程序对用户输入数据的合法性没有判断或过滤不严,攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句,在管理员不知情的情况下实现非法操作,以此来实现欺骗数据库服务器执行非授权的任意查询,从而进一步得到相应的数据信息。 

 解决办法:

1、分级管理

对用户进行分级管理,严格控制用户的权限,对于普通用户,禁止给予数据库建立、删除、修改等相关权限,只有系统管理员才具有增、删、改、查的权限。

2、参数传值

在书写SQL语言时,禁止将变量直接写入到SQL语句,必须通过设置相应的参数来传递相关的变量。从而抑制SQL注入。数据输入不能直接嵌入到查询语句中。同时要过滤输入的内容,过滤掉不安全的输入数据。或者采用参数传值的方式传递输入变量。这样可以最大程度防范SQL注入攻击。


点击全文阅读


本文链接:http://zhangshiyu.com/post/206162.html

<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1