浏览器复习-安全
同源策略、CSP、CORS
同源的定义: 如果两个 URL 的 protocol、port (如果有指定的话)和 host 都相同的话,则这两个 URL 是同源
同源策略:控制不同的源之间如何交互资源
CSP: 内容安全策略(Content-Security-Policy)用于检测和减轻用于 Web 站点的特定类型的攻击,例如 XSS和数据注入等。核心思想是让服务器决定浏览器能够加载哪些资源,让服务器决定浏览器是否能够执行内联 JavaScript 代码
CORS: 跨域资源共享(Cross-Origin Resource Sharing)是一种机制,它由一系列HTTP头部组成,这些头部决定浏览器是否阻止前端 JavaScript 代码获取跨域请求的响应。同源安全策略 默认阻止“跨域”获取资源。但是 CORS 给了web服务器这样的权限,即服务器可以选择,允许跨域请求访问到它们的资源。
跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求,该机制通过浏览器发起一个到服务器托管的跨源资源的"预检"请求。在预检中,浏览器发送的头中标示有HTTP方法和真实请求中会用到的头
对于一些简单请求,并不会发送OPTION预检请求
- 使用GET/POST/HEAD方法
- Context-type为'test/plain'或'multipart/form-data'或'application/x-www-form-urlencoded'
JSONP: 借助一些标签(比如 script
)没有跨域的限制,将标签的 src
属性设置为接口地址,以此来实现发送请求的目的。
XSS
跨站脚本攻击(Cross-site scripting,XSS)是一种安全漏洞,攻击者可以利用这种漏洞在网站上注入恶意的客户端代码。当被攻击者登陆网站时就会自动运行这些恶意代码,从而,攻击者可以突破网站的访问权限,冒充受害者。
如果 Web 应用程序没有部署足够的安全验证,那么,这些攻击很容易成功。浏览器无法探测到这些恶意脚本是不可信的,所以,这些脚本可以任意读取 cookie,session tokens,或者其它敏感的网站信息,或者让恶意脚本重写HTML内容。
XSS攻击的分类
存储型
注入型脚本永久存储在目标服务器上。当浏览器请求数据时,脚本从服务器上传回并执行。
反射型
用户将含有恶意代码的请求提交给 Web 服务器,Web 服务器接收到请求时,又将恶意代码反射给了浏览器端,这就是反射型 XSS 攻击
XSS攻击的危害
- 利用虚假表单骗取用户个人信息
- 利用脚本窃取用户的cookie值,被害者在不知情的情况下帮助攻击者发送恶意请求
预防XSS攻击
过滤用户输入
function filter (str) {
return str
.replace(/&/g, '&')
.replace(/ /g, ' ')
.replace(/</g, '<')
.replace(/>/g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''')
.replace(/\r{0,}\n/g, '<br/>')
}
CSP
cookie设置HttpOnly
CSRF
跨站请求伪造(CSRF,Cross-site request forgery)是一种冒充受信任用户,向服务器发送非预期请求的攻击方式
攻击流程
- 受害者登录http://a.com,并保留了登录凭证(Cookie)
- 攻击者引诱受害者访问http://b.com
- http://b.com 发送了一个请求: http://a.com?act=xxx 。浏览器会默认携带http://a.com的cookie
- http://a.com 接收到请求后,对请求进行验证,确认是受害者,误以为是受害者自己发送的请求
- http://a.com 以受害者的名义执行了act=xxx
- 攻击完成,受害者在不知情的情况下冒充受害者,让http://a.com 执行了攻击者自定义的操作
如何防御
防范CSFR攻击可以遵循以下几种规则:
- 不让第三方网站访问到用户cookie
- 阻止第三方网站请求接口
- 敏感接口请求时附带验证信息,比如token或验证码
具体防范方法:
samesite
可以对cookie设置samesite属性。
samesite选项有
strict
Lax
None
三个值。strict
:浏览器完全禁止第三方拿到cookie;Lax
:相对宽松一点,在跨站点的情况下,从第三方站点点的链接打开或Get
方式的表单提交这两种方式都会携带Cookie
referer
referer
是header的一部分,当浏览器向web服务器发送请求时,一般会带上referer信息告诉服务器是从哪个页面来的,服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。anti CSRF token
目前比较完善的方案是加入anti-csrf token。即发送请求时在http请求中以参数的形式加入一个随机产生的token,并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值,会进行校验该请求当中的token和cookie当中的token值是否都存在且相等,才认为这是合法的请求。否则认为这次请求是违法的,拒绝该次服务。
这种方法相比Referer检查要安全很多,token可以在用户登陆后产生并放于session或cookie中,然后在每次请求时服务器把token从session或cookie中拿出,与本次请求中的token 进行比对。由于token的存在,攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时,当某个页面消耗掉token后,其他页面的表单保存的还是被消耗掉的那个token,其他页面的表单提交时会出现token错误。