作为一个前端工作者，熟悉 HTTP 协议是十分重要的，之前有阅读 HTTP 详解一书，后面会系统总结，这里先了解一下 HTTP 的常见问题和 HTTPS 的基本原理
HTTP 安全传输密码
不用 HTTPS，我们如何传输密码等敏感信息呢？我们只需要使用非对称加密即可。
将公钥以Javascript变量的形式暴露给浏览器。然后用公钥对用户的密码加密后，再将密码密文、用户名和公钥一起发送给服务器。服务器会提前存储公钥和私钥的映射信息，通过客户端发过来的公钥就可以查出对应的私钥，然后对密码密文进行解密就可以还原出密码的明文。
为了加强公钥私钥的安全性，服务器应该动态生成公钥私钥对，并且使用后立即销毁。但是动态生成又是非常耗费计算资源的，所以一般服务器会选择Pool方法提供有限数量的公钥私钥对池，然后每隔一段时间刷新一次Pool。
状态码与数据提交
特殊状态嘛
- 413 Request Entity Too Large：客户端上传图片太大超过服务器限制时，服务器返回413错误。
- 414 Request-URI Too Long：客户端访问的URI太长，超出了服务器允许限制，服务器返回414错误。
- 202 Accepted：常用于异步请求。客户端发送请求到服务器，服务器立即返回一个202 Accepted表示已经成功接收到客户端的请求。但还没处理完毕
提交方式
- application/x-www-form-urlencoded
- 提交数据表单时经常使用，Body内部存放的是转码后的键值对
- GET 也可以，直接拼接在URL后
- application/json：提交结构化表单时使用，Body内部存放的是JSON字符串。
- multipart/form-data：上传文件时经常使用。这种格式比较复杂，它是为了支持多文件上传混合表单数据而设计的一种特殊的格式。
Cookie
浏览器请求的Cookie中往往会携带敏感信息。服务器一般会将当前用户的会话ID存在cookie里，会话的具体内容存在服务器端，会话的内容很敏感。
浏览器请求时会携带Cookie信息，服务器根据Cookie信息中的会话ID找到对应的会话内容。会话内容里可能存储了用户的权限信息，拿到这部分权限信息后就可能随意控制修改用户的数据。
因为HTTP协议的不安全性，请求数据包很容易被窃听，Cookie中的会话信息很容易被盗。解决方案之一就是在会话中记录用户的终端信息和IP地址信息，如果这些信息突然发生改变，需要强制用户重新认证。
不过高级的黑客是可以伪造出和用户真实请求一模一样的数据包的。最彻底的解决方案还是采用HTTPS协议。
普通的Cookie信息可以通过Javascript脚本获取到。如果黑客通过某种方式在网页中植入不安全的脚本，将用户的Cookie拿到然后发送到远程的第三方服务器中，那么Cookie中的信息就被泄露了。
Cookie的两个重要属性
- 被标记为Secure的Cookie信息在HTTP请求中不会被传送，它只会在HTTPS请求中传送，避免数据被泄露。
- 被标记为HttpOnly的Cookie信息是无法通过Javascript API获取到的，它只会在请求中传送。
不安全的WEB
文件路径攻击：使用路径.访问到系统层文件
DNS欺骗
- HTTP协议严重依赖于DNS域名解析。任意一个域名类网址的访问都需要经过域名解析的过程得到目标服务的IP地址才能成功继续下去。
- 掌管DNS服务的运营商作恶
危险HTTP 代理
- HTTP代理作为客户端到服务器之间的中间路由节点，它起到传话人和翻译官的角色。
- 如果这个翻译官不靠谱的话，客户端是会拿到错误的返回数据的。它同DNS欺骗一样，是可以对客户端进行钓鱼攻击的。
- 如果这个翻译官口风不严的话，它可能会将它听到的敏感信息泄露给别人
CSRF(Cross-Site Request Forgery)
- 重点在请求
- 跨站请求伪造，有很多别名，比如One-Click Attack(一键攻击)，比如Session Riding(搭便车攻击)
- 诱惑你去点击不安全链接，如果在某网站已经正常登录，此时你的回话信息很可能被利用，因此修改性的操作务必不得使用简单的GET请求进行处理。
- 即使这种情况下你改成了POST请求，黑客依然有办法伪造请求，那就是通过iframe。黑客在别的什么网站上伪造了一个POST表单，诱惑你去submit。如果只是普通的内嵌进HTML网页的表单，用户提交时会出现跨域问题。因为当前网站的域名和表单提交的目标域名不一致。但是如果通过iframe来内嵌表单，则可以绕过跨域的问题，而用户却完全没有任何觉察。
- 为了防范CSRF攻击，聪明的网站的POST表单里都会带上CSRF_TOKEN这个隐藏字段。CSRF_TOKEN是根据用户的会话信息生成的。当表单提交时，会将token和用户的会话信息做比对。如果匹配就是有效的提交请求。黑客必须拿到CSRF_TOKEN才可以借用用户的会话信息实施CSRF攻击，但是CSRF_TOKEN又必须由用户的会话信息才可以生成。黑客没有用户的会话信息，从而无法实施CSRF攻击。
XSS(Cross Site Scripting)
- 重点在脚本
- 如果黑客可以在你的网页中植入任意Javascript脚本，那他就可以随意鱼肉你的账户。通过Javascript可以获取Cookie的信息，可以借用你的会话去调用一些隐秘的API
- 防范XSS一般是通过对输出的内容进行内容替换做到的。在HTML页面中不同的位置会有不同的内容替换规则。比较常见的是使用HTML entity编码将HTML标签之间的内容中的一些特殊的字符进行转码。还有些UGC内容在HTML标签的属性中、Javascript的变量中、URL、css代码中，他们转码的规则并不一样。
跨域
- 不知道你有没有想过浏览器为什么设置这个恼人的限制呢？其实还是为了安全，比如上面的CSRF攻击
- 希望共享数据给不同的站点，该怎么办呢？
- JSONP：JSONP的不足在于它只能发送GET请求，并且不能携带cookie。
- CORS
- 通过Ajax发送的跨域请求技术。CORS的请求分为两种，一种是简单请求，一种是复杂请求。
- 浏览器发现Ajax的请求是跨域的，就会在请求头添加一个Origin参数，指明当前请求的发起站点来源。服务器根据Origin参数来决定是否授权。
- 如果是简单请求，Ajax直接请求服务器。服务器会当成普通的请求直接返回内容，不同的是还会在响应头部添加几个重要的头部，其中最重要的头部是Access-Control-Allow-Origin:
http://example.com。浏览器如果在响应中没有读到这个头部，就会通知Ajax请求失败。虽然服务器返回了数据，浏览器也不让脚本读到数据，这就保证了跨域的安全。服务器就是通过请求的Origin参数来决定要不要响应Access-Control-Allow-Origin头部来决定是否允许指定网站的跨域请求。 - 如果是复杂请求，要走一个预检的流程。预检就是浏览器先向服务器发送一个Method为Options的请求，如果服务器允许跨域请求，浏览器再发起这个Ajax请求。所以CORS的复杂请求会比简单请求额外耗费一个TTL的时间。
- Nginx代理
HTTPS 原理
主要涉及到非对称加密和对称加密的混合方式，至于为什么要混合？因为对称加密的速度是非对称加密速度的100倍左右。
CA(Certificate Authority)。一些可信的CA的证书都预先存在我们的电脑里了，证书包括CA的信息和CA的公钥和数字签名。数字签名用来验证未篡改。
charles等抓包工具能够抓取https的包，那这是什么原理？此类工具在抓HTTPS的包的时候，需要在你手机或电脑上安装并信任charles证书。
这样是否说明：HTTPS协议也不安全呢？那我只能说你主动泄密，怪谁咯
裸协议
又称相对协议，加载资源的时候使用如下链接，可以随着你的站点的http协议自动选择是 https 还是 http。
//domain.com/path/to/script.js
//domain.com/path/to/style.css