1.https 原理(加密 证书)
- 客户端使用https的url访问web服务器,要求与服务器建立ssl连接
- web服务器收到客户端请求后,会将 站的证书(包含公钥)传送一份给客户端
- 客户端收到 站证书后会检查证书的颁发机构以及过期时间,如果没有问题就随机产生一个秘钥
- 客户端利用公钥将会话秘钥加密,并传送给服务端,服务端利用自己的私钥解密出会话秘钥
- 之后服务器与客户端使用秘钥加密传输
2. 络安全相关 (XSS攻击和CSRF攻击原理及防御措施;token认证;cookie和session)
XSS
-
XSS: Cross Site Scripting攻击,全称跨站脚本攻击.
XSS指恶意攻击者利用 站没有对用户提交数据进行转义处理或者过滤不足的缺点,进而添加一些 代码,嵌入到web页面中去。使别的用户访问都会执行相应的嵌入代码。 从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
-
XSS攻击的危害包括:
1、盗取各类用户帐 ,如机器登录帐 、用户 银帐 、各类管理员帐
2、控制企业数据,包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、 站挂马
7、控制受害者机器向其它 站发起攻击
-
原因解析
主要原因:过于信任客户端提交的数据!
解决办法: 不信任客户端提交的数据,只要是客户端提交的数据就应该先进行相应的过滤处理后方可进行下一步的操作.
进一步分析: 客户端提交的数据本身就是应用所需的,但是恶心攻击者利用 站对客户端提提交数据的信任,在数据中插入一些符 以及JavaScript代码,那么这些数据就会成为应用代码中给的一部分了,那么攻击者就可以肆无忌惮的展开攻击
因此我们绝对不可信任任何客户端提交的数据
-
类型
持久性(存储型)和非持久性(反射型)
持久型: 持久型也就是攻击的代码被写入数据库中,这个攻击危害性很大,如果 站访问量很大 的话,就会导致大量正常访问的页面,就会导致大量正常访问页面的用户都受到攻击。最典型的 就是留言板的XSS攻击
非持久型: 非持久型XSS是指发送请求时,XSS代码出现在请求的URL中,作为参数提交到服务 器,服务器解析并响应。响应结果中包含XSS代码,最后浏览器解析并执行,从概念上可以看出, 反射型XSS代码首先是出现在URL中,然后需要服务端解析,最后需要浏览器之后XSS代码才能攻 击
-
防御方法
两种方式用来防御
1. 转义字符
- 首先,对于用户的输入应该是永远不信任的,最普遍的做法就是转义输入输出的内容,对于括 ,尖括 ,斜杠进行转义
2. CSP
-
内容安全策略 (CSP) 是一个额外的安全层,用于检测并削弱某些特定类型的攻击,包括跨站脚本 (XSS) 和数据注入攻击等。无论是数据盗取、 站内容污染还是散发恶意软件,这些攻击都是主要的手段
作为一种终极防护形式,始终不允许执行脚本的站点可以选择全面禁止脚本执行
CSP本质上就是建立白名单,开发者明确告诉浏览器哪些外部资源可以进行加载和执行,我们只需要配置规则,如何拦截是由浏览器自己实现的,我们可以通过这种方式来尽量减少XSS攻击
开启CSP的方式(如果使用CSP)
-
- 你可以使用 Content-Security-Policy HTTP头部 来指定你的策略,像这样:
-
- 设置meta标签的方式
常见用例(设置HTTP Header来举例)
- 一个 站管理者想要所有内容均来自站点的同一个源 (不包括其子域名) 只允许加载本站资源
- 一个 站管理者允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)
- 一个 站管理者允许 页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得),所有脚本必须从特定主机服务器获取可信的代码.
- 只允许加载HTTPS协议图片
对于这种方式来说,这要开发者配置了正确的规则,那么即使 站存在漏洞,攻击者也不能执行它的攻击代码,而且CSP的兼容性不错.
CSRF
1 基本概念
CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对 站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装成受信任用户的请求来利用受信任的 站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。
2 原理
原理就是攻击者构造出一个后端请求地址,诱导用户点击或者通过某些途径自动发起请求。如果用户是在登录状态下的话,后端就以为是用户在操作,从而进行相应的逻辑
也就是完成一次CSRF攻击,受害者必须依次完成两个步骤: 1 登录受信任的 站,并在本地生成Cookie 2 在不登出信任 站的情况下,访问危险 站
你也许有疑问:如果我不满足以上两个条件中的一个,我就不会收到CSRF攻击。 的确如此,但是你不能保证以下情况的发生: 1 你不能保证你登录了一个 站后,不再打开一个tab页面并访问其他页面 2 你不能保证你关闭浏览器后,你的本地Cookie立刻过期,你的上次会话已经结束.(事实上,关闭浏览器不能结束一个会话,)
3 危害(CSRF可以做什么)
攻击者盗用了你身份,以你的名义发送恶意请求,CSRF能够做的事情:以你的名义发送邮件,盗取你的账 甚至是购买商品,虚拟货币的转账,个人隐私泄露和财产安全
CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的!
4 如何防御
防范CSRF攻击可以遵循以下几种规则:
- GET请求不对数据进行修改
- 不让第三方 站访问到Cookie
- 阻止第三方 站请求接口
- 请求时附带验证信息,比如验证码或者Token
SameSite
- 可以对Cookie设置SameSite属性,该属性表示Cookie不随着跨域请求发送,可以很大程度上减少CSRF的攻击,但是该属性目前并不是所有浏览器都兼容
验证 Referer HTTP头部
- 对于需要防范CSRF的请求,我们可以通过验证Referer来判断请求是否为第三方 站发起的.
Token服务端核对令牌
- 服务器下发一个服务端核对令牌随机Token,每次发送请求时将Token携带上,服务器验证Token是否有效
验证码
- 这个方案的思路是:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,厄…这个方案可以完全解决CSRF,但个人觉得在易用性方面似乎不是太好,还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug,可能在某些版本的微软IE中受影响。
3.缓存方式
这个其实就是强缓存和协商缓存的问题,强缓存会直接去取缓存的文件,而协商缓存会去像服务器发送一次确认文档是否有效的请求。
详细: mp.weixin.qq.com/s/G5FIrWOts…
一般js、css等静态资源 走强缓存, html走协商缓存(没有hash)
4.跨域方式(proxy代理、CORS策略、jsonp脚本跨域、websoket…)
- 具体实现
- 分别在什么场景下使用
1. JSONP跨域
jsonp的原理就是利用<script>标签没有跨域限制,通过<script>标签src属性,发送带有callback参数的GET请求,服务端将接口返回数据拼凑到callback函数中,返回给浏览器,浏览器解析执行,从而前端拿到callback函数返回的数据。
jsonp的缺点:只能发送get一种请求。
2、跨域资源共享(CORS)
CORS是一个W3C标准,全称是”跨域资源共享”(Cross-origin resource sharing)。 它允许浏览器向跨源服务器,发出XMLHttpRequest请求,从而克服了AJAX只能同源使用的限制。 CORS需要浏览器和服务器同时支持。目前,所有浏览器都支持该功能,IE浏览器不能低于IE10。
浏览器将CORS跨域请求分为简单请求和非简单请求。
只要同时满足一下两个条件,就属于简单请求
(1)使用下列方法之一:
- head
- get
- post
(2)请求的Heder是
- Accept
- Accept-Language
- Content-Language
- Content-Type: 只限于三个值:application/x-www-form-urlencoded、multipart/form-data、text/plain
不同时满足上面的两个条件,就属于非简单请求。浏览器对这两种的处理,是不一样的。
简单请求
对于简单请求,浏览器直接发出CORS请求。具体来说,就是在头信息之中,增加一个Origin字段。
上面的头信息中,Origin字段用来说明,本次请求来自哪个源(协议 + 域名 + 端口)。服务器根据这个值,决定是否同意这次请求。
CORS请求设置的响应头字段,都以 Access-Control-开头:
1)Access-Control-Allow-Origin:必选
它的值要么是请求时Origin字段的值,要么是一个*,表示接受任意域名的请求。
2)Access-Control-Allow-Credentials:可选
它的值是一个布尔值,表示是否允许发送Cookie。默认情况下,Cookie不包括在CORS请求之中。设为true,即表示服务器明确许可,Cookie可以包含在请求中,一起发给服务器。这个值也只能设为true,如果服务器不要浏览器发送Cookie,删除该字段即可。
3)Access-Control-Expose-Headers:可选
CORS请求时,XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段,就必须在Access-Control-Expose-Headers里面指定。上面的例子指定,getResponseHeader(‘FooBar’)可以返回FooBar字段的值。
非简单请求
非简单请求是那种对服务器有特殊要求的请求,比如请求方法是PUT或DELETE,或者Content-Type字段的类型是application/json。非简单请求的CORS请求,会在正式通信之前,增加一次HTTP查询请求,称为”预检”请求(preflight)。
预检请求
预检”请求用的请求方法是OPTIONS,表示这个请求是用来询问的。请求头信息里面,关键字段是Origin,表示请求来自哪个源。除了Origin字段,”预检”请求的头信息包括两个特殊字段。
1)Access-Control-Request-Method:必选
用来列出浏览器的CORS请求会用到哪些HTTP方法,上例是PUT。
2)Access-Control-Request-Headers:可选
该字段是一个逗 分隔的字符串,指定浏览器CORS请求会额外发送的头信息字段,上例是X-Custom-Header。
预检请求的回应 服务器收到”预检”请求以后,检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后,确认允许跨源请求,就可以做出回应。
HTTP回应中,除了关键的是Access-Control-Allow-Origin字段,其他CORS相关字段如下:
1)Access-Control-Allow-Methods:必选
它的值是逗 分隔的一个字符串,表明服务器支持的所有跨域请求的方法。注意,返回的是所有支持的方法,而不单是浏览器请求的那个方法。这是为了避免多次”预检”请求。
2)Access-Control-Allow-Headers
如果浏览器请求包括Access-Control-Request-Headers字段,则Access-Control-Allow-Headers字段是必需的。它也是一个逗 分隔的字符串,表明服务器支持的所有头信息字段,不限于浏览器在”预检”中请求的字段。
3)Access-Control-Allow-Credentials:可选
该字段与简单请求时的含义相同。
4)Access-Control-Max-Age:可选
用来指定本次预检请求的有效期,单位为秒。
3、nginx代理跨域
ginx代理跨域,实质和CORS跨域原理一样,通过配置文件设置请求响应头Access-Control-Allow-Origin…等字段。
1)nginx配置解决iconfont跨域
浏览器跨域访问js、css、img等常规静态资源被同源策略许可,但iconfont字体文件(eot|otf|ttf|woff|svg)例外,此时可在nginx的静态资源服务器中加入以下配置。
2)nginx反向代理接口跨域
跨域问题:同源策略仅是针对浏览器的安全策略。服务器端调用HTTP接口只是使用HTTP协议,不需要同源策略,也就不存在跨域问题。
实现思路:通过Nginx配置一个代理服务器域名与domain1相同,端口不同)做跳板机,反向代理访问domain2接口,并且可以顺便修改cookie中domain信息,方便当前域cookie写入,实现跨域访问。
nginx具体配置:
4、nodejs中间件代理跨域
node中间件实现跨域代理,原理大致与nginx相同,都是通过启一个代理服务器,实现数据的转发,也可以通过设置cookieDomainRewrite参数修改响应头中cookie中域名,实现当前域的cookie写入,方便接口登录认证。
1)非vue框架的跨域
使用node + express + http-proxy-middleware搭建一个proxy服务器。
- 前端代码:
- 中间件服务器代码:
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!