图解HTTP

HTTP是不保存状态的协议，协议本身不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事物，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。

可是，随着Web的不断发展，因无状态而导致业务处理变得棘手的情况增多了。比如，用户登录到一家购物网站，即使他跳转到该站的其他页面后，也需要保持登录状态。针对这个实例，网站为了能够掌握是谁送出的请求，需要保存用户的状态。

HTTP1.1虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了Cookie技术。有了Cookie再用HTTP协议通信，就可以管理状态了。

在HTTP1.1中，所有的连接默认都是持久连接，但在HTTP1.0内并未标准化。虽然有一部分服务器通过非标准化的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器，客户端也需要支持持久连接。

状态码：

1XX：信息性状态码，表示接收的请求正在处理
2XX：成功状态码，表示请求正常处理完毕。
200：OK
204：No Content
206：Partical Content(指定范围的实体内容)
3XX：重定向状态码，表示需要进行附加操作以完成请求
301：永久性重定向
302：临时性重定向
303：与302有相同的功能，但303状态码明确表示客户端应当采用GET
方法获取资源，这点与302状态码有区别。
304：客户端发送请求，未满足条件的情况下，直接返回304

304状态码的意义:
如果一个网站被搜索引擎抓取的次数以及频率越多那么他是越有利于排名的，但是如果你的网站出现太多的304，那么一定会降低搜索引擎的抓取频率以及次数，从而让自己的网站排名比别人落一步

.
307：和302有相同含义
4XX：客户端错误状态码，表示服务器无法处理请求
400：客户端请求报文中存在语法错误
401：发送请求需要通过HTTP认证，当浏览器初次收到401响应，会弹出认证用的对话窗口
403：客户端请求访问资源，被服务器拒绝了，未获得文件系统的访问权
404：服务器上无法找到请求的资源
5XX：服务器错误状态码，服务器处理请求出错
500：服务器故障
501：服务器暂时超负荷或停机维护

通信数据转发程序：网关、代理、隧道
代理：服务器和客户端中间人的角色。有两种基准分类：1.是否使用缓存 2.是否会修改报文
网关：工作机制和代理相似，网关能使通信线路上的服务器提供非HTTP协议服务。如Web购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动，提高通信的安全性。
隧道：隧道通信线路会使用SSL等加密手段进行通信，目的是确保客户端与服务器进行安全通信。

HTTP首部

HTTP协议的请求和响应报文中必定包含HTTP首部。
HTTP报文：报文首部+空行+报文主体
HTTP请求报文的报文首部：请求行（报文方法+URI+HTTP版本）+HTTP首部字段（请求首部字段+通用首部字段+实体首部字段）+其他
HTTP响应报文的报文首部：状态行（HTTP版本+状态码）+HTTP首部字段（响应首部字段+通用首部字段+实体首部字段）+其他

HTTP使用首部字段（字段名：字段值）是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

HTTP首部字段：通用首部字段、请求首部字段、响应首部字段、实体首部字段

一 通用首部字段:请求报文和响应报文双方都会使用的首部。

1.Cache-Control：缓存工作机制
1.1 public:表明其他用户可以利用缓存
1.2 private：缓存服务器对特定用户提供资源缓存服务，对于其他用户发送过来的请求，代理服务器则不会返回缓存
1.3 no-cache：直接从服务器获取资源，不从缓存服务器中返回资源
1.4 no-store：请求或响应中包含机密信息。因此缓存不能在本地存储请求或响应的任一部分。
1.5 s-maxage：适用于供多位用户使用的公共缓存服务器。对单一用户重复返回响应的服务器来说，该指令无效。
1.6 max-age：代表资源保存为缓存的最长时间
1.7 min-fresh：缓存服务器返回缓存资源的指定时间，超过则不返回
1.8 max-stale：缓存资源过期也照常接收
1.9 only-if-cached：缓存服务器不重新加载响应，也不会再次确认资源有效性。若发生缓存服务器无响应，则返回状态码504 Gateway Timeout
1.10 must-revalidate：代理会向服务器再次验证即将返回的响应缓存目前是否仍然有效。该指令会忽略请求的max-stale指令
1.11 proxy-revalidate：缓存服务器在接收到客户端带有该指令的请求，在返回响应之前，必须再次验证缓存的有效性。
1.12 no-transform：无论请求还是响应中，缓存都不能改变实体主体的媒体类型，以防止缓存或代理压缩图片等操作。

2.Connection 控制不再转发给代理的首部字段+管理持久连接
HTTP/1.1之前的HTTP版本的默认连接都是非持久连接。为此，如果想在旧版本的HTTP协议想维持持续连接，则需要制定Connection首部字段的值为Keep-Alive。

3.Date 创建HTTP报文的日期和时间

4.Pragma HTTP/1.1之前版本的历史遗留字段，仅作为与HTTP/1.0的向后兼容而定义。全部服务器使用的HTTP协议版本一致是不现实的，发送请求时会含有下面两个字段：
Cache-Control：no-cache
Pragma：no-cache

5.Trailer 应用在HTTP/1.1版本分块传输编码时

6.Transfer-Encoding 规定了传输报文主体时采用的编码方式

7.Update 用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数可以用来指定一个完全不同的通信协议。

8.Via 追踪客户端与服务器之间的请求和响应报文的传输路径。报文经过代理或网关时，会先在首部字段Via中添加该服务器的信息，然后再进行转发。这个做法和traceroute及电子邮件的Received首部的工作机制很类似。

9.Warning 告知用户一些与缓存相关的问题的警告

二 请求首部字段：客户端往服务器发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

1.Accept 通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。
2.Accept-Charset 通知服务器用户代理支持的字符集及字符集的相对优先顺序。
3.Accept-Encoding 告知服务器用户代理支持的内容编码及内容编码的优先级顺序。
4.Accept-Language 告知服务器用户代理能处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级。可一次指定多种自然语言集。
5.Authorization 告知服务器，用户代理的认证信息
6.Expect 告知服务器，期望出现的某种特定行为
7.From 告知服务器使用用户代理的用户的电子邮件地址
8.Host 告知服务器，请求资源所处的互联网主机名和端口号
9.If-Match 当If-Match的字段值跟ETag值匹配一致时，服务器才会接受请求。
10.If-Modified-Since 告知服务器，若在If-Modified-Since日期后，更新过资源，则处理请求，若未更新过，则返回状态码304Not Modified的响应。
11.If-None-Match If-None-Match字段值的实体标记（ETag）值与请求资源的ETag不一致时，它就告知服务器处理该请求。
12.If-Range 告知服务器若指定的If-Range字段值（ETag值或时间）和请求资源的ETag值或时间相一致时，则作为范围请求处理。反之，则返回全体资源。
13.If-Unmodified-Since 告知服务器，若在If-Unmodified-Since字段值后，未更新过资源，则处理请求，若更新过，则返回状态码412 Precondition Failed的响应。
14.Max-Forwards 通过TRACE或OPTIONS方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，会将Max-Forwards的值减1后重新赋值。当服务器接收到Max-Forwards的值为0时，则不再进行转发，而是直接返回响应。
15.Proxy-Authorization 从代理服务器发来的认证质询时，客户端会发送包含首部字段Proxy-Authorization的请求，以告知服务器认证所需要的信息。认证行为发生在客户端和代理之间，客户端和服务器之间的认证，使用首部字段Authorization可起到相同作用。
16.Range 对于只需获取部分资源的范围请求，包含首部字段Range即可告知服务器资源的指定范围。
17.Refer 首部字段Refer会告知服务器请求的原始资源的URI。
18.TE 告知服务器客户端能够处理响应的传输编码方式及相对优先级。它和首部字段Accept-Encoding的功能很相像，但是用于传输编码。
19.User-Agent 将创建请求的浏览器和用户代理名称等信息传达给服务器

三 响应首部字段：响应首部字段是有服务器向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。

1.Accept-Ranges 告知客户端 服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。可处理范围请求时指定为：bytes 反之则指定为：none
2.Age 告知客户端，源服务器在多久前创建了响应。单位：秒
3.ETag 客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的ETag值。
4.Location 可以将响应接收方引导至某个与请求URI位置不同的资源。
5.Proxy-Authenticate 会把由代理服务器所要求的认证信息发送给客户端
6.Retry-After 告知客户端应该在多久之后再次发送请求
7.Sever 告知客户端当前服务器上安装的HTTP服务器应用程序的信息
8.Vary 对缓存进行控制。如：Vary:Accept-Language 则只对持相同自然语言的请求返回缓存
9.WWW-Authenticate 用于HTTP访问认证

四 实体首部字段：实体首部字段是指包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

1.Allow 通知客户端能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的HTTP方法时，会以状态码405 Method Not Allowed 作为响应返回。与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回。
2.Content-Encoding 告知客户端 服务器对实体的主体部分选用的内容编码方式
3.Content-Language 告知客户端，实体主体使用的自然语言（指中文或英文等语言）
4.Content-Length 表明了实体主体部分的大小
5.Content-Location 给出报文主体部分相对应的URI。和首部字段Location不同，Content-Location表示的是报文主体返回资源对应的URI。
6.Content-MD5 是一串MD5算法生成的值，其目的在于检查报文主体在传输过程中是否保持完整，以及确认传输到达。
7.Content-Range 针对范围请求，返回响应是使用的首部字段Content-Range，能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位，表示当前发送部分以及整个实体大小。例：Content-Range：bytes 5001-10000/10000
8.Content-Type 说明了实体主体内对象的媒体类型
9.Empires 会将资源失效的日期告知客户端
10.Last-Modified 指资源最终修改的时间

Post请求下的Content-Type类型（编码类型）

1. application/x-www-form-urlencoded
   这应该是最常见的 POST 提交数据的方式了。浏览器的原生
   表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。请求类似于下面这样（无关的请求头在本文中都省略掉了）：

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

首先，Content-Type 被指定为 application/x-www-form-urlencoded；其次，提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。

2. multipart/form-data
   这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让 表单的 enctype 等于 multipart/form-data。
   直接来看一个请求示例：
   form表单：

    Username: 
    Password: 
    File: 
    

Http协议请求：

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
 
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
 
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
 
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个例子稍微复杂点。首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。关于 multipart/form-data 的详细定义，请前往 rfc1867 查看。

这种方式一般用来上传文件，各大服务端语言对它也有着良好的支持。

上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段标准中原生

表单也只支持这两种方式（通过 元素的 enctype 属性指定，默认为 application/x-www-form-urlencoded。其实 enctype 还支持 text/plain，不过用得非常少）。

3. application/json
   application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。

JSON 格式支持比键值对复杂得多的结构化数据，这一点也很有用。记得我几年前做一个项目时，需要提交的数据层次非常深，我就是把数据 JSON 序列化之后来提交的。不过当时我是把 JSON 字符串作为 val，仍然放在键值对里，以 x-www-form-urlencoded 方式提交。

Google 的 AngularJS 中的 Ajax 功能，默认就是提交 JSON 字符串。例如下面这段代码：

var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
    ...
});

最终发送的请求是：

POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
 
{"title":"test","sub":[1,2,3]}

php://input
json_decode

当然 AngularJS 也可以配置为使用 x-www-form-urlencoded 方式提交数据。如有需要，可以参考这篇文章。

4. text/xml
   它是一种使用 HTTP 作为传输协议，XML 作为编码方式的远程调用规范。典型的 XML-RPC 请求是这样的：

POST http://www.example.com HTTP/1.1
Content-Type: text/xml
 


    examples.getStateName
    
        
            41
        
    

XML-RPC 协议简单、功能够用，各种语言的实现都有。它的使用也很广泛，如 WordPress 的 XML-RPC Api，搜索引擎的 ping 服务等等。JavaScript 中，也有现成的库支持以这种方式进行数据交互，能很好的支持已有的 XML-RPC 服务。不过，我个人觉得 XML 结构还是过于臃肿，一般场景用 JSON 会更灵活方便。

相比之下，get方式的数据提交方式（编码方式）只有一种，就是application/x-www-form-urlencoding

确保Web安全的HTTPS

HTTP与HTTPS之间的最重要差别在于会话的连接建立阶段。在TCP连接建立好、HTTP请求发送前，客户端与服务器之间必须建立SSL会话。SSL会话建立包含多个阶段:客户端与服务器协商使用何种密码、交换公钥、验证协商以及验证身份（可选）。当SsL会话建立完毕后，在TCP连接之上传输的所有数据都将是加密的。

HTTPS 的实现原理

SSL 建立连接过程

SSL 建立连接过程.png

SSL建立连接过程.png

1. client 向 server 发送请求 https://baidu.com，然后连接到 server 的 443 端口，发送的信息主要是随机值1和客户端支持的加密算法。
2. server 接收到信息之后给予 client 响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是 client 发送给 server 加密算法的子集。
3. 随即 server 给 client 发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
4. 客户端解析证书，这部分工作是由客户端的 TLS 来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
5. 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
6. 传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
7. 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
8. 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
9. 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。

怎么保证保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

因为客户端 TLS 验证公钥失败，之后的流程就不会执行，中间人获取不到客户端的发出的信息：如下图虚线部分无法执行。

不让请求变成无效的唯一方法就是信任，该信任由网络库放置在接收到的证书之中。证书
只是签名的公钥。因此，如果网络库信任签名者，那它也会信任主机提供的公钥。黑客提
供的假的根证书成为了让所有安全措施崩溃的罪魁祸首。

这个问题的解决方案就是所谓的证书锁定。这种方案的工作原理是，通过只信任一个或几个能够作为应用 根证书的证书，应用创建一个自定义的信任级别。这允许应用仅信任来自白名单的证书， 确保设备上永不安装那些允许网络监视的未知证书。

SSL 建立连接.png

HTTP的缺点：

通信使用明文（不加密），内容可能会被窃听
抓包工具可获取到HTTP响应报文的内容，所以我们需要对通信进行加密。
不验证通信防的身份，因此有可能遭遇伪装
任何人都可以发起请求，所以我们为了确认通信方，就可以使用查明对手证书的方式进行验证。
无法证明报文的完整性，所以有可能已遭篡改
SSL提供认证和加密处理及摘要功能。HTTP直接和TCP通信，当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP。
SSL技术最初是由浏览器开发商网景通信公司率先倡导的，开发过SSL3.0之前的版本。目前主导权已转移到IETF（Internet Engineering Task Force，Internet工程任务组）的手中。IETF以SSL3.0为基准，后又制定了TLS1.0、TLS1.1、TLS1.2。TLS是以SSL为原型开发的协议，有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TLS1.0。
HTTPS在使用SSL时，它的处理速度会变慢。一是因为先与SSL通信，通信量会增加，二是因为，SSL必须进行加密处理，会消耗服务器和客户端的硬件资源。

基于HTTP的功能追加协议
HTTP协议的缺点：
一条连接上只可发送一个请求
请求只能从客户端开始。客户端不可以接收除响应以外的指令。
请求/响应首部未经压缩就发送。首部信息越多延迟越大。
发送冗长的首部。每次相互发送相同的首部造成的浪费较多。
可任意选择数据压缩方式。非强制压缩发送。
追加的协议:
1.Google发布了SPDY协议，在TCP/IP的应用层与运输层之间通过新加会话层的形式运作，通过多路复用流（单个TCP连接可以无限制处理多个HTTP请求）、赋予请求优先级、压缩HTTP首部、推送功能、服务器提示功能，来缩短Web页面的加载时间。
2.Ajax利用JavaScript和DOM的操作，以达到局部Web页面替换加载的异步通信手段。通过JavaScript脚本语言功能就能和服务器进行HTTP通信，借由这种手段，就能从已加载完的Web页面上发起请求，只更新局部页面。
3.Comet将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。因此，服务器端一旦有更新，就可以立即反馈给客户端。这样就会导致一次连接的持续时间变长，会消耗更多资源。
4.WebSocket是建立在HTTP基础上的协议，连接的发起方仍是客户端，一旦建立WebSocket通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文。因为服务器可以直接发送数据，服务器就具备推送功能。和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也相应减少。
5.HTTP Speed + Mobility由微软公司起草，用于改善并提高移动端通信时的通信速度和性能的标准。
6.Network-Friendly HTTP Upgrade主要是在移动端通信时改善HTTP性能的标准

构建Web内容的技术
Web页面几乎全有HTML（超文本标记语言）构建
2014年左右使用的HTML5标准，依然是现在HTML的使用标准
CSS指定如何展现HTML内的各种元素，属于样式表标准之一。
动态HTML技术是客户端通过JavaScript实现对HTML的Web页面的动态改造，利用DOM可指定欲发生动态变化的HTML元素。
服务器返回事先编写好的HTML是属于静态内容
服务器返回由Web服务器上的程序创建的HTML内容，叫动态内容
XML（可扩展标记语言）和HTML都是从标准通用标记语言SGML简化而成。
XML文档中读取数据比HTML简单，而被互联网广泛接受
RSS（简易信息聚合）/ Atom都用到了XML
JSON是一种由JavaScript的对象表示法为基础的轻量级数据标记语
言。

Web的攻击技术
1.因为HTTP不具备必要的安全功能，攻击者就可以在客户端和服务器发起攻击。在客户端篡改请求、以服务器端为目标的主动攻击：SQL注入攻击 和 OS命令注入攻击、以服务器端为目标的被动攻击：利用设置好的陷阱劫持用户所持的Cookie等个人信息。
2.因输出值转义不完全引发的安全漏洞。
1）跨站脚本攻击，就是弹出一些窗口来获取用户的Cookie等个人信息
2）SQL注入攻击，就是通过修改SQL语句，导致用户浏览的数据遭到非法浏览及篡改。
3）OS命令注入攻击，通过Web应用，执行非法的操作系统命令达到攻击的目的。只要在能调用Shell函数的地方就有存在被攻击的风险。OS命令注入攻击可以向Shell发送命令，执行OS上安装的各种程序。
4）HTTP首部注入攻击，是指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。就是让服务器跳转到指定页面的一种攻击手段。
5）邮件注入攻击，是指Web应用中的邮件发送功能，攻击者通过向邮件首部To或Subject内任意添加非法内容发起的攻击。利用存在安全漏洞的Web网站，可对任意邮件地址发送广告邮件或病毒邮件。
6）目录遍历攻击，是指对本无意公开的文件目录，通过非法截断其目录路径后，达到访问目的的一种攻击。这种攻击有时也称为路径遍历攻击。
7）远程文件包含漏洞，是指当部分脚本内容需要从其他文件读入时，攻击者利用指定外部服务器的URL充当依赖文件，让脚本读取之后，就可运行任意脚本的一种攻击。这主要是PHP存在的安全漏洞，对PHP的include或require来说，通过设定，指定外部服务器URL作为文件名的功能。由于太危险，PHP5.2.0之后默认设定此功能无效。
8）远程文件包含漏洞，是指当部分脚本内容需要从其他文件读入时，攻击者利用指定外部服务器的URL充当依赖文件，让脚本读取之后，就可运行任意脚本的一种攻击。
3.因设置或设计上的缺陷引发的安全漏洞。
1）强制浏览，从安置在Web服务器的公开目录下的文件中，浏览哪些原本非自愿公开的文件。
2）不正确的错误消息处理。系统抛出的错误信息是对开发者有用的信息，对于用户来说是没必要展示的，但对攻击者来说，详细的错误信息可能会给他们下一次攻击以提示。
3）开放重定向，是一种对指定的任意URL作重定向跳转的功能。可信度高的Web网站，如果开放重定向功能，则很有可能被攻击者选中并用来作为钓鱼攻击的跳板。
4.因会话管理疏忽引发的安全漏洞。
1）会话劫持，是指被攻击者拿到了用户的会话ID，并非法使用此会话ID伪装成用户，达到攻击的目的。
2）会话固定攻击，会强制用户使用攻击者指定的会话ID。
3）跨站点请求伪造，是指攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息设定或设定信息等某些状态更新。
5.其他安全漏洞。
1）密码破解，穷举法、字典攻击
2）点击劫持，是指利用透明的按钮或链接做成陷阱，覆盖在Web页面之上。用户在不知情的情况下，点击链接的一种攻击手段，又称为界面伪装。
3）DoS攻击，拒绝服务攻击，有以下两种DoS攻击方式
·集中利用访问请求造成资源过载，资源用尽的同时，实际上服务也就呈停止状态。
·通过攻击安全漏洞使服务停止。
4）后门程序，是指开发设置的隐藏入口，可使用受限功能。分为下面3种类型：
·开发阶段作为Debug调用的后门程序
·开发者为了自身利益植入的后门程序
·攻击者通过某种方法设置的后门程序

RESTful API接口规范

GET：获取资源

• 安全且幂等
• 读取服务器内容时使用
• 变更时获取表示（缓存）
• 没有请求体

POST：创建或更新资源

• 不安全且不幂等
• 使用服务端管理的（自动产生）的实例号创建资源
• 创建子资源
• 部分更新资源
• 如果没有被修改，则不更新资源（乐观锁）
• 有请求体

PUT：创建或更新资源

• 不安全但幂等
• 用客户端管理的实例号创建一个资源
• 通过替换的方式更新资源
• 如果未被修改，则更新资源（乐观锁）

DELETE：删除资源

• 不安全但幂等
• 删除资源

HEAD：获取资源的元数据

• 安全且幂等
• 递交获取资源的元数据

OPTIONS：获取信息

• 安全且幂等
• 获取信息，关于资源的哪些属性是客户端可以改变的。

PATCH：局部更新资源

• 不安全，可以是不幂等的
• 局部更新资源
• 与PUT区别：只更新少部分内容；可能根据原数据进行变化（比如基本工资加200元），这时就不幂等了。

POST和PUT的区别

• 在更新资源的操作上，POST 和 PUT 基本相同。

• 在创建资源时，PUT可以指定资源路径，POST无法指定资源路径。

  因而，PUT是幂等的操作，即重复操作不会产生变化，10次PUT 的创建请求与1次PUT 的创建请求相同，只会创建一个资源，其实后面9次的请求只是对已创建资源的更新，且更新内容与原内容相同，所以不会产生变化。

  POST 的重复操作截然不同，10次POST请求将会创建10个资源。