为 Cookie 服务的首部字段
Cookie 的工作机制是用户识别及状态管理。Web 网站为了管理用户的 状态会通过 Web 浏览器，把一些数据临时写入用户的计算机内。接 着当用户访问该Web网站时，可通过通信方式取回之前发放的 Cookie。 调用 Cookie 时，由于可校验 Cookie 的有效期，以及发送方的域、路径、协议等信息，所以正规发布的 Cookie 内的数据不会因来自其他 Web 站点和攻击者的攻击而泄露。
expires 属性 ： Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。 当省略 expires 属性时，其有效期仅限于维持浏览器会话时间段内。这通常限于浏览器应用程序被关闭之前。 另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可以显式删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对 客户端 Cookie 的实质性删除操作。
path 属性 ： Cookie 的 path 属性可用于限制指定 Cookie 的发送范围的文件目录。 不过另有办法可避开这项限制，看来对其作为安全机制的效果不能抱 有期待。
domain 属性 ： 通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。比 如，当指定 example.com 后，除 example.com 以外，www.example.com 或 www2.example.com 等都可以发送 Cookie。 因此，除了针对具体指定的多个域名发送 Cookie 之 外，不指定 domain 属性显得更安全。
secure 属性 ： Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才 可以发送 Cookie。 当省略 secure 属性时，不论 HTTP 还是 HTTPS，都会对 Cookie 进行 回收。
HttpOnly 属性 ： Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本 无法获得 Cookie。其主要目的为防止跨站脚本攻击（XSS）对 Cookie 的信息窃取。 通过上述设置，通常从 Web 页面内还可以对 Cookie 进行读取操作。 但使用 JavaScript 的 document.cookie 就无法读取附加 HttpOnly 属性后 的 Cookie 的内容了。因此，也就无法在 XSS 中利用 JavaScript 劫持 Cookie 了。 虽然是独立的扩展功能，但 Internet Explorer 6 SP1 以上版本等当下的 主流浏览器都已经支持该扩展了。另外顺带一提，该扩展并非是为了 防止 XSS 而开发的。
Cookie ： 首部字段 Cookie 会告知服务器，当客户端想获得 HTTP 状态管理支 持时，就会在请求中包含从服务器接收到的 Cookie。接收到多个 Cookie 时，同样可以以多个 Cookie 形式发送。
为 Cookie 服务的首部字段
Set-Cookie 字段的属性
确保 Web 安全的HTTPS
在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。
HTTP 的缺点 ：① 通信使用明文（不加密），内容可能会被窃听 ② 不验证通信方的身份，因此有可能遭遇伪装 ③ 无法证明报文的完整性，所以有可能已遭篡改 。
通信使用明文可能会被窃听 ： 由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使 用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文 使用明文（指未经过加密的报文）方式发送。 窃听相同段上的通信并非难事。只需要收集在互联网上流动的数据包（帧）就行了。对于收集来的数据包的解析工作，可交给那 些抓包（Packet Capture）或嗅探器（Sniffer）工具。
加密处理防止被窃听 ： 在目前大家正在研究的如何防止窃听保护信息的几种对策中，最 为普及的就是加密技术。加密的对象可以有这么几个。 ① 通信的加密 ： 一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以 通过和 SSL（安全套接层）或 TLS（安全层传输协议）的组合使用， 加密 HTTP 的通信内容。 用 SSL建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL组合使用的 HTTP 被称为 HTTPS（超文本传输安全协议）或 HTTP over SSL。 ② 内容的加密 ： 还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中 没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP 报文里所含的内容进行加密处理。 在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送请求。 诚然，为了做到有效的内容加密，前提是要求客户端和服务器同 时具备加密和解密机制。主要应用在 Web 服务中。有一点必须 引起注意，由于该方式不同于 SSL或 TLS 将整个通信线路加密 处理，所以内容仍有被篡改的风险。
不验证通信方的身份就可能遭遇伪装 ： HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服 务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真的 返回到实际提出请求的客户端”等类似问题。① 任何人都可发起请求 ： 在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何 人都可以发起请求。另外，服务器只要接收到请求，不管对方是 谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没 有被 Web 服务器设定限制访问的前提下）。 HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会 返回响应，因此不确认通信方，会存在以下各种隐患。 ① 无法确定请求发送至目标的 Web 服务器是否是按真实意 图返回响应的那台服务器。有可能是已伪装的 Web 服务 器。 ② 无法确定响应返回到的客户端是否是按真实意图接收响 应的那个客户端。有可能是已伪装的客户端。 ③ 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通 信的权限。 ④ 无法判定请求是来自何方、出自谁手。 ⑤ 即使是无意义的请求也会照单全收。无法阻止海量请求 下的 DoS 攻击（拒绝服务攻击）。② 查明对手的证书 ： 虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL则可以。 SSL不仅提供加密处理，而且还使用了一种被称为证书的手段， 可用于确定方。 证书由值得信任的第三方机构颁发，用以证明服务器和客户端是 实际存在的。另外，伪造证书从技术角度来说是异常困难的一件 事。所以只要能够确认通信方（服务器或客户端）持有的证书， 即可判断通信方的真实意图。 通过使用证书，以证明通信方就是意料中的服务器。这对使用者 个人来讲，也减少了个人信息泄露的危险性。 另外，客户端持有证书即可完成个人身份的确认，也可用于对 Web 网站的认证环节。
无法证明报文完整性，可能已遭篡改 ： 所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味 着无法判断信息是否准确。 ① 接收到的内容可能有误 ： 由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响 应送出之后直到对方接收之前的这段时间内，即使请求或响应的 内容遭到篡改，也没有办法获悉。 换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请 求 / 响应是前后相同的。 比如，从某个 Web 网站上下载内容，是无法确定客户端下载的 文件和服务器上存放的文件是否前后一致的。文件内容在传输途 中可能已经被篡改为其他的内容。即使内容真的已改变，作为接 收方的客户端也是觉察不到的。 像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻 击称为中间人攻击（Man-in-the-Middle attack，MITM）。 ② 如何防止篡改 ： 虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便 捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法， 以及用来确认文件的数字签名方法。 提供文件下载服务的 Web 网站也会提供相应的以 PGP（Pretty Good Privacy，完美隐私）创建的数字签名及 MD5 算法生成的散 列值。PGP 是用来证明创建文件的数字签名，MD5 是由单向函 数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用 户本人亲自检查验证下载的文件是否就是原来服务器上的文件。 浏览器无法自动帮用户检查。 可惜的是，用这些方法也依然无法百分百保证确认结果正确。因 为 PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。 为了有效防止这些弊端，有必要使用 HTTPS。SSL提供认证和加 密处理及摘要功能。仅靠 HTTP 确保完整性是非常困难的，因此 通过和其他协议组合使用来实现这个目标。下节我们介绍 HTTPS 的相关内容。
互联网上的任何角落都存在通信内容被窃听的风险
与 SSL组合使用的 HTTP 被称为 HTTPS（超文本传输安全协议）或 HTTP over SSL
客户端对 HTTP 报文进行加密处理
查明对手的证书
无法证明报文完整性，可能已遭篡改
中间人攻击
HTTP+ 加密 + 认证 + 完整性保护=HTTPS
HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS： 如果在 HTTP 协议通信过程中使用未经加密的明文，比如在 Web 页 面中输入信用卡号，如果这条通信线路遭到窃听，那么信用卡号就暴 露了。 另外，对于 HTTP 来说，服务器也好，客户端也好，都是没有办法确认通信方的。因为很有可能并不是和原本预想的通信方在实际通信。 并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能 性。 为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证 等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS。
使用 HTTPS 通信
网友评论