web 前端安全

参考:

MDN:https://developer.mozilla.org/zh-CN/docs/Web/Security

CORS:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS

博客: https://blog.csdn.net/ppxin/article/details/94717173

XMLHttpRequest:

文章目录

web 前端安全

三, 常见攻击类型

XMLHttpRequest（XHR）对象用于与服务器交互。通过 XMLHttpRequest 可以在不刷新页面的情况下请求特定 URL，获取数据。这允许网页在不影响用户操作的情况下，更新页面的局部内容。XMLHttpRequest 在 AJAX 编程中被大量使用。

1.CSRF跨站请求伪造(Cross-site Request Forgery)

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。

要完成一次csrf攻击，被攻击者需要完成两个操作：

登录收信任网站A，并在本地生成cookie
在与A的会话结束前，访问危险网站B（危险网站B甚至可能是一个存在漏洞的受人信任的网站）

防御方法：

在客户端表单增加伪随机数（但不能防止对方再利用xss攻击手段获得你的cookie）

在每次做类似提交表单的操作时都通过验证码进行验证

为每个表单设置不同的伪随机数（但会有并行会话兼容问题）

阮一峰: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)

2.XSS攻击(Cross Site Scripting)跨站脚本攻击

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。

具体类型和阻止方法: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)

要坚持一个原则：永远不要相信用户的输入，对每一条输入都进行验证

可以用正则表达式验证输入内容的合法性

3. 点击劫持(click jacking)

在我们浏览网页时经常会出现一些令人讨厌的信息，比如一些中奖通知或者色情信息，但在网页中散布这些内容却是不法分子用来诱惑被攻击者点击的常用手段，

点击劫持就是利用透明的iframe或者被覆盖的iframe，把iframe嵌套进别的网页, 通过诱骗用户在该网页上点击某些按钮，触发iframe页面上的点击操作

阻止方法:

参考http://www.ruanyifeng.com/blog/2008/10/anti-frameset_javascript_codes.html

禁止iframe嵌套即可:

一, 会话跟踪

会话：用户打开浏览器，访问Web服务器上多个资源，然后关闭浏览器，整个过程称之为一次会话。

Http协议是无状态的，因此我们需要使用会话跟踪技术来维护状态。每次用户向服务器请求时，服务器都会将该请求视为新请求。因此，我们需要维护用户的状态以识别特定用户。

1. 会话跟踪中的session和cookie

为了确定会话中的身份，就可以通过创建 session 或 cookie 进行标识。

cookie: 初次发起http请求后,服务器回复http请求时把set-cookie放在http的响应头部, 之后cookie就存在浏览器,即客户端, 每次发起请求都会携带这个cookie, 服务器根据cookie确认此用户身份. 设置HttpOnly属性决定客户端是否可写,增加安全性

session: 初次访问时服务器存储访问状态, 机存在服务器端. session生成时会有唯一标识sessionid, 在请求中可申请sessionid.

两者区别：

session 是在服务器端记录信息；cookie 是在浏览器端记录信息
session 保存的数据大小取决于服务器的程序设计，理论值可以做到不限；单个 cookie 保存的数据大小不超过4Kb，大多数浏览器限制一个站点最多20个cookie
session 可以被服务器的程序处理为 key - value 类型的任何对象；cookie 则是存在浏览器里的一段文本
session 由于存在服务器端，安全性高；浏览器的 cookie 可能被其他程序分析获取，所以安全性较低
大量用户会话服务器端保存大量 session 对服务器资源消耗较大；信息保存在 cookie 中缓解了服务器存储用信息的压力

二, 同源策略

同源策略(Same origin policy)是一种约定, 它是浏览器最核心也最基本的安全功能. 浏览器采用同源策略,禁止页面加载或执行与自身来源不同的域的任何脚本. 出于安全考虑，浏览器限制从JS脚本发起的跨源HTTP请求。例如，XMLHttpRequest和Fetch API都遵循同源策略。

什么叫同源:

如果两个 URL 的 protocol、port (如果有指定的话)和 host 都相同的话，则这两个 URL 是同源。这个方案也被称为“协议/主机/端口元组”，或者直接是 “元组”。（“元组” 是指一组项目构成的整体，双重/三重/四重/五重/等的通用形式）。

下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:

URL 结果原因

http://store.company.com/dir2/other.html 同源只有路径不同

http://store.company.com/dir/inner/another.html 同源只有路径不同

https://store.company.com/secure.html 失败协议不同

http://store.company.com:81/dir/etc.html 失败端口不同 ( http:// 默认端口是80)

http://news.company.com/dir/other.html 失败主机不同

URL	结果	原因
`http://store.company.com/dir2/other.html`	同源	只有路径不同
`http://store.company.com/dir/inner/another.html`	同源	只有路径不同
`https://store.company.com/secure.html`	失败	协议不同
`http://store.company.com:81/dir/etc.html`	失败	端口不同 ( `http://` 默认端口是80)
`http://news.company.com/dir/other.html`	失败	主机不同

什么是跨域请求:

只要协议、域名、端口有任何一个不同，都被当作是不同的域，之间的请求就是跨域操作。

DOM 层面的同源策略：限制了来自不同源的”Document”对象或 JS 脚本，对当前“document”对象的读取或设置某些属性
Cookie和XMLHttprequest层面的同源策略：禁止 Ajax 直接发起跨域HTTP请求（其实可以发送请求，结果被浏览器拦截，不展示），同时 Ajax 请求不能携带与本网站不同源的 Cookie。
同源策略的非绝对性：

跨域*写操作（Cross-origin writes）一般是被允许的。*例如链接（links），重定向以及表单提交。特定少数的HTTP请求需要添加 preflight。

跨域*资源嵌入（Cross-origin embedding）*一般是被允许（后面会举例说明）。

跨域*读操作（Cross-origin reads）一般是不被允许的，*但常可以通过内嵌资源来巧妙的进行读取访问。例如，你可以读取嵌入图片的高度和宽度，调用内嵌脚本的方法，或availability of an embedded resource.

跨域请求的解决方案

JSONP缺点: JSONP只支持GET请求, CORS支持所有类型HTTP请求

JSONP优点:支持老式浏览器,以及可以向不支持CORS的网站请求数据。

1. JSONP

JSON:超轻量级的数据交换格式

JSONP(JSON with Padding)是JSON的一种“使用模式”，可用于解决主流浏览器的跨域数据访问的问题。jsonp的核心原理就是目标页面回调本地页面的方法,并带入参数.

举个例子, 已知script标签可以跨域请求, 现在通过script标记发起跨域请求如下:
在这里插入图片描述

向不同源的该地址请求资源并传参callback=jsoncall参数值, 服务器接收该参数后,会调用相应的方法如下:

在这里插入图片描述

因为是通过script标记请求的,所以会将该结果当作js文件传回客户端

此时在客户端定义一个跟参数值(jsoncall)同名的函数, 调用此方法, 即可完成跨域请求:
在这里插入图片描述

2. CORS(Cross-origin resource sharing)跨域资源共享

跨源资源共享 (CORS) （或通俗地译为跨域资源共享）是一种基于HTTP 头的机制，该机制通过允许服务器标示除了它自己以外的其它origin(域，协议和端口)—许可白名单, 允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

CORS需要浏览器和服务器都支持才能使用

两种请求:

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

3. 服务器代理

nginx代理或者node的中间件实现代理

浏览器有跨域限制，但是服务器不存在跨域问题，所以可以由服务器请求所要域的资源再返回给客户端。

服务器代理是万能的。