将Web安全问题按照发生的区域来分类,发生在浏览器、Web页面中的安全问题就是前端安全问题。
同源策略
同源:URL由协议、域名、端口和路径组成,如果两个URL的协议、域名和端口相同,则表示他们同源。
URL | 是否同源 | 原因 |
---|---|---|
http://test.test.com/dir2/other.HTML | 是 | |
http://test.test.com/dir/test.HTML | 是 | |
https://test.test.com/test.HTML | 否 | 协议不同 |
http://test.test.com:8080/test.HTML | 否 | 端口不同 |
http://test123.test.com/test.HTML | 否 | 域名不同 |
浏览器的同源策略,限制了来自不同源的document或脚本,对当前document读取或设置某些属性。从一个域上加载的脚本不允许访问另外一个域的文档属性。
如果没有同源限制存在,浏览器中的cookie等其他数据可以任意读取,不同域下DOM可以任意 *** 作,AJAX可以任意请求。如果浏览了恶意网站那么就会泄漏这些隐私数据
在浏览器中,<script>、<img>、<iframe>、<link>等标签都可以加载跨域资源,而不受同源限制。
这些带src属性的标签每次加载时,实际上是由浏览器发起了一次GET请求。不同于XMLhttpRequest的是,通过src属性加载的资源,浏览器限制了JavaScript的权限,使其不能读、写返回的内容。
跨站脚本攻击(XSS)
XSS,即Cross Site Script(跨站脚本攻击);为了和层叠样式表(Cascading Style Sheet)做出区分,在安全领域叫做 XSS。
XSS 攻击是指攻击者在网站上注入恶意的客户端代码,利用恶意脚本对客户端网页进行篡改,从而在用户浏览网页时,对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。有很多种方式进行 XSS 攻击,但它们的共同点为:将一些隐私数据像cookie、session发送给攻击者,将受害者重定向到一个由攻击者控制的网站,在受害者的机器上进行一些恶意 *** 作。
攻击方式反射型XSS恶意代码并没有保存在目标网站,通过引诱用户点击一个链接到目标网站的恶意链接来实施攻击。
攻击流程:
A给B发送一个恶意构造的URLB点击URL后跳转到具有漏洞的HTML页面HTML页面在B浏览器中执行JavaScript,可以执行B所具有权限下的命令存储型XSS恶意代码被保存到目标网站的服务器中,这种攻击具有较强的稳定性和持久性,比较常见场景是在博客,论坛、OA、CRM等社交网站上。
攻击流程:
攻击者提交一条包含XSS代码的留言或其他数据到数据库当目标用户查询时,XSS的内容会从服务器解析之后加载出来浏览器将恶意代码当作正常脚本解析执行,可以执行浏览器所具有权限下的命令DOM Based XSS基于DOM的XSS攻击是指通过恶意脚本修改页面的DOM结构,是纯粹发生在客户端的攻击。DOM型XSS攻击中,取出和执行恶意代码由浏览器端完成,属于前端JavaScript自身的安全漏洞。
攻击流程:
A给B发送一个恶意构造的URLB点击URL后HTML页面获取攻击性的代码,如通过location.hash获取的参数等攻击性代码当作HTML代码写入页面HTML页面在B浏览器中执行JavaScript,可以执行B所具有权限下的命令防范手段输入检查在源头控制,把用户输入的一些不合法的东西都过滤或者编码掉,从而保证安全性。如移除用户提交的的DOM属性如onerror,移除用户上传的节点,<iframe>,<script>,<a>节点等。
一般业务中是对客户端和服务端中同时进行输入检查。
输出检查利用转义库对 HTML 模板各处节点进行充分的转义。
使用httpOnly
通过设置httpOnly,浏览器可以禁止页面的JavaScript访问带有httpOnly属性的cookie。它的目的并非是为了对抗XSS,而是对抗XSS之后的cookie劫持攻击。
cookie的使用过程:浏览器向服务器发起请求,此时没有cookie服务器返回Set-cookie头,向浏览器写入cookie在cookie到期之前,浏览器访问该域下的所有页面,都将发送该cookie
httpOnly是在Set-cookie的时候进行标记的
Set-cookie: <name>=<value>[; <Max-Age>=<age>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; httpOnly]
对输入的内容限定合理长度,可以增加XSS攻击的难度
避免拼接HTML或者使用内联事件前端使用拼接HTML或者内联事件的情况比较危险,建议替换为createElement、setAttribute及addEventListener的实现方法,或者采用成熟的框架进行渲染,如vue/react等
开启CSP网页安全政策(Content Security Policy)
一种由开发者定义的安全性政策申明,通过CSP所约束的责任指定可信的内容来源,(内容可以是指脚本、图片、style 等远程资源)。
CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。
开启方式:
通过http头信息的Content-Security-Policy字段在网页中设置<Meta>标签<Meta http-equiv\="Content-Security-Policy" content\="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:"\>
跨站点请求伪造(CSRF)
跨站请求伪造攻击,原理就是攻击者构造出一个后端请求地址,诱导用户点击或者通过某些途径自动发起请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,冒充用户执行某些 *** 作。
攻击流程被攻击者登录A站点,并保留了登陆凭证攻击者诱使被攻击者访问B站点B站点向A站点发起请求,浏览器会默认携带A站点的cookieA站点接收请求后会对其进行验证,而且会误认为是被攻击者发起的请求,同时以被攻击者的身份执行相应的 *** 作攻击方式GET类型一般是利用<img>标签等发起
<img src="http://test.com/test?test=test">
在被攻击者访问页面时,浏览器会自动向src指向的地址发出请求
POST类型通常是构造一个自动提交的表单在页面上,模拟用户完成了一次POST *** 作
链接类型通常是需要诱骗用户点击才会触发
攻击特点攻击一般发生在第三方站点,被攻击站点无法防止攻击发生攻击手段为冒充受害者提交 *** 作,而非直接窃取数据攻击过程中攻击者并不能获取到用户的登陆凭证,而只是冒充防范手段验证码通过增加网站A的验证手段,例如增加图形验证码或短信验证码等等,只有通过验证的请求才算合法。但是这种方案拥有两个局限性,一个是增加开发成本,另外一个是降低用户体验。
验证Referer根据 http 协议,在 http 头中有一个字段叫Referer,它记录了该 http 请求的来源地址。通过验证Referer,可以检查请求是否来自合法的"源"。
验证Token服务端随机生成token,保存在服务端session中,同时保存到客户端中,客户端发送请求时,把token带到http请求头或参数中,服务端接收到请求,验证请求中的token与session中的是否一致。如果请求中没有 token 或者 token 内容不正确,则认为可能是 CSRF 攻击而拒绝该请求。
广州包装设计公司http://www.maiqicn.com 电脑刺绣绣花厂 ttp://www.szhdn.com
点击劫持在一个Web页面下隐藏了一个透明的iframe(opacity:0),用外层假页面诱导用户点击,实际上是在隐藏的frame上触发了点击事件进行一些用户不知情的 *** 作。
攻击流程攻击者构造一个诱导用户点击的内容,将页面放入到<iframe>利用z-index和opacity将<iframe>叠加到实际页面上方并透明化受害者访问到欺骗页面后,实际看到的是诱使点击的内容,点击之后则是有害页面攻击方式盗取用户资金获得用户敏感信息与XSS或者CSRF相配合,诱骗用户点击恶意链接防范手段设置x-frame-options服务器端可设置http头x-frame-options:DENY来让浏览器主动禁止<iframe>内嵌,但是这种方式需要结合httpS来实现,因为http不可靠,容易被窃听篡改内容
总结以上是内存溢出为你收集整理的浅谈前端安全全部内容,希望文章能够帮你解决浅谈前端安全所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)