2022秋招-前端学习记录9-网络安全类

CSRF、XSS，以及区别

CSRF是什么？

CSRF 全名： 跨站请求伪造。

网站过分信任用户，放任来自所谓通过访问控制机制的代表合法用户的请求执行网站的某个特定功能。

比如一个非常重要的转账网页，需要用户登录才能进行下一步操作。
然而在有CSRF漏洞的网页，黑客可以伪装成这个用户，在用户打开另一个恶意的网站时，利用图片或者虚拟框架嵌入网址 发送黑客所需要的转账请求。
这里，如果web服务器的用户信息验证不够的话，就会造成用户经济损失。

所以如何阻挡CSRF攻击呢？
1、尽量使用post，因为get请求太容易被人利用了。
2、加入验证码，要保证验证码的随机性。
3、验证Referer，Referer会记录操作来源，可以设定Referer里来源的网址如果不是指定来源，均要拒绝。
4、anti CSRF Token，一般是在html的head里加入一个服务端传过来的随机的token，每次请求都是随机的码，比对前端和后端的这个token，一致才给放行，不一致就给拦截。

 
XSS是什么？

XSS全名： 跨站脚本攻击。 一种代码注入
xss原理上利用的是浏览器可以拼接成任意的javascript，然后黑客拼接好javascrip 让浏览器自动地给服务器端发出多个请求（get、post请求）。
用户过分信任网站，放任来自浏览器地址栏代表的 那个所谓的网站代码 在自己本地任意执行。

XSS是一种代码注入，浏览器没有智商，你输入一个<script>标签或者<a>标签只要浏览器访问到了，可以是贴吧留言甚至是url中的构造，浏览器上他无法辨别这是html标签还是单纯的文字语义，他都是当代码进行执行了。自己构造一段浏览器的恶意代码，那就是为所欲为，危害很大！

比如一个博客网站，用户发送博客，如果用户发的是这种：<script> alert(‘试试看能不能执行’) </script>，本来这种不应该执行的，结果网页真的执行并且弹出来了，这样就会造成一次XSS攻击。

那么如何识别这些脚本，将其拦截下来，并且做一些过滤，防止脚本执行呢？
XSS防御手段：
1、对输入的东西，比如用户输入、url参数、post请求、Ajax 进行一个过滤操作；
2、对输出的东西进行编码，把特殊的输出比如 <script> 进行转义 \<script> 后输出；
3、对Cookie设置http-only

CSRF和XSS的区别：
CSRF原理上利用的是网站服务器端所有参数都是可预先构造的原理，然后黑客 拼接好具体请求url ，可以引诱你提交他构造好的请求。网站过分信任用户，放任来自所谓通过访问控制机制的代表合法用户的请求执行网站的某个特定功能。

XSS原理上利用的是浏览器可以拼接成任意的javascript，然后黑客拼接好javascrip 让浏览器自动地给服务器端发出多个请求（get、post请求）。用户过分信任网站，放任来自浏览器地址栏代表的 那个所谓的网站代码 在自己本地任意执行。
XSS是一种代码注入，浏览器没有智商，你输入一个<script>标签<a>标签只要浏览器访问到了，可以是贴吧留言甚至是url中的构造，浏览器上他无法辨别这是html标签还是单纯的文字语义，他都是当代码进行执行了。自己构造一段浏览器的恶意代码，那就是为所欲为，危害很大！

后台开发，一定！不能信任任何的前端输入！ 哈哈哈哈哈哈一定要 做一些过滤和校验

 
 

Cookie、Session，以及区别

参考文章（写的比较全）：https://www.cnblogs.com/pengc/p/8714475.html

cookie是HTML4的本地存储
浏览器的缓存机制 提供了可以将用户数据存储在客户端上的方式，cookie和session都是用来跟踪浏览器用户身份的会话方式。

查看当前网页的cookie：在控制台输入 document.cookie

区别：
1、保存位置：cookie保存在浏览器端，session保存在服务器端

2、使用方式：
（1）cookie机制：
    如果不在浏览器中设置过期时间，cookie被保存在内存中，生命周期随浏览器的关闭而结束，这种cookie简称会话cookie。
    如果在浏览器中设置了cookie的过期时间，cookie被保存在硬盘中，关闭浏览器后，cookie数据仍然存在，直到过期时间结束才消失。
Cookie是服务器发给客户端的特殊信息，cookie是以文本的方式保存在客户端，每次请求时都带上它。
（2）session机制：
     当服务器收到请求需要创建session对象时，首先会检查客户端请求中是否包含sessionid：
     通常使用cookie方式存储sessionid到客户端，在交互中浏览器按照规则将sessionid发送给服务器。
     如果cookie里面有sessionid，服务器将根据该id返回对应session对象。
     如果客户端请求中cookie里没有sessionid，服务器会创建新的session对象，并把sessionid在本次响应中返回给客户端。
但是如果用户禁用cookie，则要使用URL重写，可以通过response.encodeURL(url) 进行实现；API对encodeURL的解释为：当浏览器支持Cookie时，url不做任何处理；当浏览器不支持Cookie的时候，将会重写URL将SessionID拼接到访问地址之后，这样没有cookie也可以传SessionID了。

3、存储内容：
cookie只能保存字符串类型文本形式数据；
session通过类似与Hashtable的数据结构来保存，能支持任何类型的对象(session中可含有多个对象)

4、存储的大小：单个cookie保存的数据不能超过4kb；session大小没有限制。

5、安全性：cookie： 针对cookie所存在的攻击：Cookie欺骗，Cookie截获；session的安全性大于cookie。

6、应用场景：
cookie：（1）判断用户是否登陆过网站，以便下次登录时能够实现自动登录（或者记住密码）。若删除cookie，则必须重新登录。（2）保存上次登录的时间等信息。（3）保存上次查看的页面
session： Session用于保存每个用户的专用信息，变量的值保存在服务器端，通过SessionID来区分不同的客户。（1）网上商城中的购物车（2）保存用户登录信息（3）将某些数据放入session中，供同一用户的不同页面使用（4）防止用户非法登录

7、缺点：
cookie：（1）4kb限制（2）用户可禁用cookie（3）安全性低（4） 有些状态不可能保存在 客户端。（5）每次访问都要传送cookie给服务器。
session：（1）Session里东西越多，就越占用服务器内存。2）依赖于cookie（sessionID保存在cookie），如果禁用cookie，则要使用URL重写，不安全。

 
 

Web Storage与Cookie

参考文章（写的比较全）：https://www.cnblogs.com/pengc/p/8714475.html

Web Storage与Cookie的区别
Cookie是HTML4的本地存储，到2014年10月28日，HTML5发布，带来了Web Storage。
由于cookie存储机制有很多缺点，HTML5不再使用Cookie，转而使用改良后的Web Storage存储机制。
WebStorage的主要目的是克服由cookie所带来的一些限制，当数据需要被严格控制在客户端时，不需要持续的将数据发回服务器。

WebStorage的优点：
（1）存储空间更大：cookie为4KB，而WebStorage是5MB；
（2）节省网络流量：cookie每次请求都会传送到服务器；而WebStorage不会传送到服务器，存储在本地的数据可以直接获取，所以减少了客户端和服务器端的交互，节省了网络流量；
（3）对于那种只需要在用户浏览一组页面期间保存而关闭浏览器后就可以丢弃的数据；使用sessionStorage就很方便；
（4）快速显示：有的数据存储在WebStorage上，再加上浏览器本身的缓存。获取数据时可以从本地获取会比从服务器端获取快得多，所以速度更快；
（5）安全性：WebStorage不会随着HTTP header发送到服务器端，所以安全性相对于cookie来说比较高一些，不会担心截获，但是仍然存在伪造问题；
（6）WebStorage提供了一些方法，数据操作比cookie方便

 
 

Web Storage下细分的sessionStorage、localStorage

Web Storage下细分的sessionStorage、localStorage区别与联系

HTML5的WebStorage提供了两种API：localStorage（本地存储）和sessionStorage（会话存储）。

1、生命周期：
localStorage的生命周期是永久的，存在本地的，关闭页面或浏览器之后localStorage中的数据也不会消失。localStorage 除非主动删除数据 ，否则数据永远不会消失。
sessionStorage的生命周期是在仅在当前会话下有效。sessionStorage引入了一个“浏览器窗口”的概念，sessionStorage是在同源的窗口中始终存在的数据。只要这个浏览器窗口没有关闭，即使刷新页面或者进入同源另一个页面，数据依然存在。
但是sessionStorage在关闭了浏览器窗口后就会被销毁。

2、存储大小：一般都是5MB

3、存储位置：localStorage和sessionStorage都保存在客户端 ，不与服务器进行交互通信。

4、存储内容的类型：都只能存储字符串类型，对于复杂的对象可以使用ECMAScript提供的JSON对象的stringify和parse来处理

5、应用场景：localStoragese：常用于长期登录（+判断用户是否已登录），适合长期保存在本地的数据。sessionStorage：敏感账号一次性登录；

cookie 、sessionStorage与localStorage的区别：

 
 

关于跨域

我们知道，使用 XMLHTTPRequest 对象发送HTTP请求时，会遇到 同源策略 问题，域不同请求会被浏览器拦截

这里主要介绍三种：①CORS 跨域资源共享；②JSONP；③vue框架的跨域

CORS 跨域资源共享

CORS是一个W3C标准，可以说CORS是W3C给出来的一种跨域方案，所以不用纠结为啥这么写，问就是 规定的。

实现CORS通信的关键是服务器。 只要服务器实现了CORS接口，就可以实现跨源通信。

这种方案无需客户端做出任何变化 (客户端不用改代码)，只是在服务端需要添加一个响应头Access-Control-Allow-Origin，表示这个资源是否允许指定域请求。

服务端会在HTTP请求头中增加一系列HTTP请求参数(例如Access-Control-Allow-Origin等)，来限制哪些域的请求和哪些请求类型可以接受，而客户端在发起请求时必须声明自己的源(Orgin)，否则服务器将不予处理；如果客户端不作声明，请求甚至会被浏览器直接拦截都到不了服务端。

和JSONP不一样，CORS支持所有类型的HTTP请求，get、post、head等等。

使用CORS实现跨域请求的示例
客户端需要声明请求源：

function getHello() {
    var xhr = new XMLHttpRequest();
    xhr.open("post", "http://b.example.com/Test.ashx", true);
    xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");　　　
    // 声明请求源
    xhr.setRequestHeader("Origin", "http://a.example.com");
    xhr.send();
    xhr.onreadystatechange = function () {
        if (xhr.readyState == 4 && xhr.status == 200) {
            var responseText = xhr.responseText;
            console.info(responseText);
        }
    }
}

服务端：（这里是用node.js作服务器。具体代码可参考Code_Job/12_Ajax/7_跨域 这个文件夹的内容）

// 这里是用node.js作服务器。具体代码可参考 Code_Job/12_Ajax/7_跨域 这个文件夹的内容。
// 2-POST.html  app.all 的 all 是可以接收任意类型的请求
app.all('/serverTeriri', (request, response)=>{
    // /serverTeriri 是路径
    // 设置响应头 设置允许跨域，星号*代表允许任何网站跨域请求数据。
    response.setHeader('Access-Control-Allow-Origin','*')
    // 设置特殊的响应头，*表示所有类型的头信息都可以接受
    response.setHeader('Access-Control-Allow-Headers','*')
    // 设置响应体
    response.send('hello teririServer_POST!!~~~');
});

在前后端分离项目开发的时候，要从前端跨域拿到java后端服务器的数据的话，是需要在java这边设置CORS的：

CORS设置前端跨域请求携带Cookie

客户端这一方：把xhr的withCredentials 属性 设置为true
// 当发送跨域请求时，携带cookie信息
xhr.withCredentials = true
服务器这一方：

app.get('/serverTeriri', (req, res)=>{
	// 如果跨域请求中涉及到cookie信息传递, Origin这里不能设置*
	//（即不能设置所有客户端均能访问）
	res.header('Access-Control-Allow-Origin','http://192.168.1.3:8013');
	// 允许客户端发送跨域请求时携带cookie信息
    res.header('Access-Control-Allow-Credentials',true);
    res.send('hello teririServer_POST!!~~~');
})

JSONP

不使用 XMLHTTPRequest 对象是否可以发送跨域HTTP请求呢？
细心的你可能会发现，像诸如：
<script type=“text/javascript” src=“http://www.a.com/scripts/1.js”>
<img src=“http://www.b.com/images/1.jpg” />
<link rel=“stylesheet” href=“http://www.c.com/assets/css/1.css” />

这种标签是不会遇到"跨域"问题的，严格意义上讲，这不是跨域，跨域是指在脚本代码中向非同源域发送HTTP请求。这只是跨站资源请求

jsonp跨域的原理上 是利用src，img，link等标签，进行一个跨站式的请求数据，绕过了W3C标准下的xmlhttprequest。

JSONP包含两部分：回调函数和数据。
回调函数：当响应到来时要放在当前页面被调用的函数。
数据：就是传入回调函数中的json数据，也就是回调函数的参数了。

jsonp的缺点：只能支持get这一种请求。（CORS支持所有类型的HTTP请求）
JSONP的优势在于支持旧版本的浏览器。

 

Vue框架的跨域

这是之前用vue-cli2.x做项目的时候用的一个跨域配置，直接修改config中的index.js文件中的数据；
原理：大致与nginx代理跨域相同，都是通过启一个代理服务器，实现数据的转发