web安全

CSP

简介

全称content-security-policy，内容安全策略。

网络是开放的，所以http协议规定，网页可以加载第三方资源，而这也带来了安全问题。黑客可以注入恶意脚本，通过操作DOM获取用户信息，或修改DOM，影响用户体验。

所以，就出现了CSP，通过CSP，设置资源白名单，可以限制第三方资源的加载，由此防范跨站脚本攻击。

另外，CSP可以上报违例报告。

设置方法

1. 服务器返回返回 Content-Security-Policy HTTP头部。

   Content-Security-Policy: policy

2. meta 元素也可以被用来配置该策略。

   <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

设置属性

1. 子属性：

   属性名	说明
   default-src	默认设置，其他资源类型没有设置策略时使用该策略。
   img-src	图片设置
   media-src	媒体设置
   script-src	脚本设置
   object-src	指定特定元素 object embed applet 等元素的策略
   style-src	样式设置
   report-uri	http://reportcollector.example.com/collector.cgi

2. 值

   值	说明
   	域名或IP地址表示的主机名，可以外加协议、端口。可使用’*’
   	协议名: 必须带冒号，不能有单引号
   ‘self’	指向该文件所在的源，即同源
   ‘unsafe-eval’	允许使用eval()来从字符串创建代码
   ‘unsafe-inline’	允许内联样式
   ‘none’	不允许任何内容，即

违例报告

报告为JSON对象，包含

document-uri 发生违规的文档URL。

referrer 违规发生处的文档引用。

blocked-uri 被阻止的资源URI。

violated-directive 违反的策略名称。

original-policy 原始策略。

例子

1. 一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得)，所有脚本必须从特定主机服务器获取可信的代码。

   Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
   
   

2. 一个线上银行网站的管理者想要确保网站的所有内容都要通过SSL方式获取，以避免攻击者窃听用户发出的请求。

   Content-Security-Policy: default-src https://onlinebanking.jumbobank.com
   

3. 一个在线邮箱的管理者想要允许在邮件里包含HTML，同样图片允许从任何地方加载，但不允许JavaScript或者其他潜在的危险内容(从任意位置加载)。

Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *

Cookie

cookie时服务器发送到用户浏览器并保存到本地的小块数据，在下次向同一服务器发起请求时被携带在头上。

创建Cookie

服务器在响应头添加Set-Cookie 选项。

作用域

Cookie应该发送给哪些URL。

Domain

哪些主机可以接收Cookie。默认为orgin ，不包含子域名。若指定Domain，则会包含子域名，所以应该使用指定Domain。

Path

指定了主机下哪些路径可以接收Cookie，以字符%x2F ("/") 作为路径分隔符，子路径也会被匹配。

安全

SameSite

限制跨站发送Cookie。

1. None 第三方发起的请求，都会带上请求地址的Cookie。
2. Strict 严格模式。第三方发起请求，都不会带上请求地址的Cookie。
3. Lax 宽松模式。从第三方站点的连接打开（a标签），和提交方式为Get的表单带Cookie。但是，Post方法，或img iframe 等标签加载的URL，不携带。

HttpOnly

限制document操作Cookie。

通过document.cookie可以获取cookie，但是，如果Set-Cookie设置了HttpOnly属性，那么，该cookie将不会被JavaScript读取或修改。

CORS

全程Cross-origin Resource Sharing，跨域资源共享。

这是为了解决同源策略导致的资源共享问题的策略，该策略能够安全的实现跨域资源共享。

配置

CORS主要在服务器进行配置，服务器通过设置相关响应头来通知浏览器。

响应头	说明
Access-Control-Allow-Origin	允许的源
Access-Control-Allow-Methods	允许的方法
Access-Control-Allow-Headers	允许自定义的请求头
Access-Control-Max-Age	策略有效期
Access-Control-Allow-Credentials	允许请求带认证

简单请求

对于GET 和 POST ，没有自定义头，请求类型为text/plain 的跨域请求。

浏览器会自动添加origin 头部，以便确认服务器是否提供响应。

服务器如果没有配置Access-Control-Allow-Origin，或源不匹配会返回403和Access-Control-Allow-Origin。

如果匹配则会处理该请求。

可以读取响应的状态和状态信息，但是，也有限制。

限制：

1. 无法发送和接收cookie。
2. 无法设置请求头。
3. 获取请求头信息会得到空。

复杂请求

需要自定义头部，或者使用GET POST 之外的请求，或者请求其他内容类型。浏览器会进行预检请求。

请求方式为OPTIONS。包含头部：

1. Origin
2. Access-Control-Request-Method
3. Access-Control-Request-Headers

服务器返回对应的：

1. Access-Control-Allow-Orgin
2. Access-Control-Allow-Methods
3. Access-Control-Allow-Headers
4. Access-Control-Max-Age

默认请求下，跨域请求不提供凭据，可以通过设置请求头 withCredentials 为 true 表明请求希望发送凭据。服务器如果返回Access-Control-Allow-Credentials 为 true ，则允许发送凭据请求。如果没有这个头部，那么该响应会进入onerror()，status为0。

HTTPS

解决HTTP明文传输带来的安全问题。

安全握手

1. 浏览器发送支持的 对称和非对称加密套件 + client_random
2. 服务器返回选择的 对称和非对称加密 套件 + service_random + 非对称加密公钥
3. 浏览器生成 随机数 pre_mater，使用 非对称加密公钥加密 pre_mater，并发送给服务器
4. 服务器 使用 非对称加密私钥解压获得 pre_mater。
5. 浏览器和服务器使用 pre_master client_random service_random 使用相同对称加密算法生成 master。
6. 使用 master 进行数据传输。

CA认证

1. CA：CA拿到网站提供的明文信息和公钥，使用明文信息生成hash，使用CA的私钥加密hash，即为证书的签名。
2. 服务器返回的不再是非对称加密公钥，而是CA证书。
3. 浏览器拿到CA证书A，使用明文信息生成hash1，使用CA的公钥解密签名得到hash2，如果两个hash一样，那么证明服务器通过了该CA的验证。
4. 如果无法确认CA是权威机构，那么访问CA，拿到该CA的CA证书，一直到确认上层CA是权威的。
5. 根证书使用的CA证书是自己发给自己的，称为自签名。

如果使用盗版的操作系统，或者安装证书。

那么HTTPS可能会被劫持，从而不安全，为此，火狐或谷歌浏览器为此提供了自主的根证书存储，而不是使用系统的根证书。

攻击方式

xss

注入恶意脚本。分为存储型、反射型、Dom型。

影响：

1. 获取用户cookie storage里的信息。
2. 修改dom

解决方法：

1. 设置 重要 cookie 为 httponly，阻止JavaScript获取。
2. 设置CSP指定白名单，阻止非法的内联的脚本、样式执行。
3. 服务器开启关键字过滤，阻止恶意脚本传输。

csrf

跨站伪造请求。用户在目标站点登录，黑客诱导用户从第三方站点发起目标站点的请求。

影响：

1. 目标站点的登录状态可能被利用。

解决方法：

1. 设置 cookie 的 samesite 属性为 lax 或 strict ，阻止从第三方发起的请求携带cookie。
2. 服务器检查关键请求的 Referer，origin 属性，确认请求的来源站点。
3. 在请求里校验 token，需要token验证通过才响应。

中间人攻击

黑客截获HTTP，进行修改。

解决方法：HTTP是明文传输，使用HTTPS。

DDOS

三次握手时，服务器接收到 syn 为1 的请求，便会为连接分配资源。

黑客不断发送 大量 syn 请求，但是不返回确认信息，从而占用服务器资源。

解决方法：

1. 降低SYN超时时间，快速释放无效请求。
2. 如果攻击来自重复 ip，使用防火墙拦截该 ip。
3. 扩容，增大 最大半连接数。
4. SYN cookies 技术：服务器接受到同步请求时，不分配资源，返回的 syn 序号为请求的 hash 值。接到确认报文时，检查 ip 的哈希 是否为 ack - 1。