【Web安全篇】Http Protocol && Customer Headers

概述

我们在做网站开发时，为了网站的运行安全，往往会做一些渗透测试，来观察我们部署的系统是否存在安全问题，在做完这个之后，往往会形成一套开发规则，等待系统计划上线时，一定要遵循这个规则。

以下是一些站点部署的配置的记录，往往会在web.config文件中进行配置，这样网站运行时就会遵循这些规则

<httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
        <add name="Cache-Control" value="no-cache"/>
        <add name="Content-Security-Policy" value="#{CONTENT_SECURITY_POLICY}#"/>
        <add name="Pragma" value="no-cache"/>
        <add name="Referrer-Policy" value="Strict-origin-when-cross-origin" />
        <add name="Strict-transport-security" value="max-age=2592000; includeSubDomains;"/>
        <add name="X-Content-Type-Options" value="nosniff"/>
        <add name="X-Frame-Options" value="SAMEORIGIN" />
        <add name="X-XSS-Protection" value="1; mode=block"/>
      </customHeaders>
</httpProtocol>

X-Frame-Options

X-Frame-Options是一个HTTP响应头，用于控制网页是否可以在<frame>、<iframe>或<object>元素中显示。它的作用是防止点击劫持攻击（Clickjacking Attack）。

点击劫持攻击是一种利用透明的或隐藏的iframe来欺骗用户点击一个看似无害的按钮或链接，实际上却触发了恶意操作的攻击方式。通过设置X-Frame-Options头，网站可以告诉浏览器是否允许在<frame>、<iframe>或<object>元素中显示网页内容，从而防止这种攻击。

X-Frame-Options头有三个可选值：

• DENY：表示网页不允许在任何<frame>、<iframe>或<object>元素中显示。
• SAMEORIGIN：表示网页只允许在同源的<frame>、<iframe>或<object>元素中显示。
• ALLOW-FROM uri：表示网页只允许在指定的URI中显示。
  通常情况下，建议使用SAMEORIGIN选项，因为它可以防止网页被嵌入到其他网站中，同时又允许网页在同源的<frame>、<iframe>或<object>元素中显示。

X-Content-Security-Policy

X-Content-Security-Policy是一个旧版的CSP头，现在已经被Content-Security-Policy头所取代。因此现代浏览器已经不再支持X-Content-Security-Policy头

但是，一些旧版的浏览器仍然支持X-Content-Security-Policy头，

包括：

• Internet Explorer 10和11
• 旧版的Safari浏览器（5.1及以下版本）
• 旧版的Firefox浏览器（4.0及以下版本）

X-Content-Type-Options

X-Content-Type-Options是一个HTTP响应头，用于控制浏览器是否应该尝试将响应内容解释为MIME类型。它的作用是防止MIME类型混淆攻击（MIME Sniffing Attack）。

MIME类型混淆攻击是一种利用浏览器的MIME类型解释机制来欺骗用户访问恶意网站的攻击方式。攻击者可以通过发送一个响应，其中包含一个错误的MIME类型，来欺骗浏览器将响应内容解释为攻击者想要的类型。通过设置X-Content-Type-Options头，网站可以告诉浏览器不要尝试解释响应内容的MIME类型，从而防止这种攻击。

X-Content-Type-Options头有一个可选值：

• nosniff：表示浏览器不应该尝试将响应内容解释为MIME类型。
  例如，以下代码片段演示了如何在Web.config文件中配置X-Content-Type-Options头：

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Content-Type-Options" value="nosniff" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

在这个示例中，X-Content-Type-Options头被设置为nosniff，表示浏览器不应该尝试将响应内容解释为MIME类型。

Cache-Control 和Pragma

Cache-Control和Pragma都是HTTP响应头，用于控制浏览器如何缓存响应内容。

Cache-Control头是HTTP/1.1协议中定义的一个标准头，用于指定缓存策略。它可以设置多个指令，例如max-age、no-cache、no-store、public、private等。这些指令可以告诉浏览器如何缓存响应内容，以及哪些内容可以被缓存。例如，max-age指令可以指定响应内容的最大缓存时间，no-cache指令可以告诉浏览器不要缓存响应内容。

Pragma头是HTTP/1.0协议中定义的一个头，用于向后兼容。它可以设置一个指令，例如no-cache。这个指令的作用与Cache-Control头中的no-cache指令相同，都是告诉浏览器不要缓存响应内容。

在现代的Web应用程序中，Cache-Control头已经取代了Pragma头，成为控制缓存的首选方式。因此，建议你在HTTP响应中使用Cache-Control头，而不是Pragma头。

以下是一个示例HTTP响应头，其中包含了Cache-Control和Pragma头：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

在这个示例中，Cache-Control头的值为no-cache, no-store, must-revalidate，表示不缓存响应内容。Pragma头的值为no-cache，也表示不缓存响应内容。Expires头的值为0，表示响应内容已经过期。

Strict-Transport-Security（STS）

要设置Strict-Transport-Security（STS）头，你可以在Web.config文件中的<system.webServer>元素下添加以下代码：

<httpProtocol>
  <customHeaders>
    <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
  </customHeaders>
</httpProtocol>

这个代码片段将会在HTTP响应头中添加一个Strict-Transport-Security头，告诉浏览器只能通过HTTPS连接访问网站。max-age指令指定了STS头的最大有效时间，单位为秒。在这个示例中，max-age被设置为一年（31536000秒）。includeSubDomains指令指定了子域名也应该强制使用HTTPS连接。preload指令指定了网站应该被添加到浏览器的预加载列表中，以便更快地启用STS。
请注意，一旦STS头被设置，浏览器将会强制使用HTTPS连接访问网站，直到STS头的有效期过期。因此，建议你在测试阶段先将max-age设置为较短的时间，以便在需要时能够更快地撤销STS头。

另外，需要注意的是，STS头只对HTTPS连接有效。如果你的网站没有启用HTTPS连接，那么STS头将不起作用。

Cross-Origin-Opener-Policy（COOP）

Cross-Origin-Opener-Policy（COOP）是一个HTTP响应头，用于控制浏览器如何处理跨域窗口的安全策略。它可以防止一些跨站点攻击，例如跨站点脚本（XSS）攻击和跨站点请求伪造（CSRF）攻击。

COOP头有以下几个可选值：

• same-origin：表示窗口只能在同一站点内打开。
• same-origin-allow-popups：表示窗口只能在同一站点内打开，并且可以在弹出窗口中打开。
• unsafe-none：表示窗口可以在任何站点内打开。
  例如，以下代码片段演示了如何在Web.config文件中配置Cross-Origin-Opener-Policy头：

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Cross-Origin-Opener-Policy" value="same-origin-allow-popups" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

在这个示例中，Cross-Origin-Opener-Policy头被设置为same-origin-allow-popups，表示窗口只能在同一站点内打开，并且可以在弹出窗口中打开。
需要注意的是，COOP头只对支持COOP的浏览器有效。如果浏览器不支持COOP头，那么它将被忽略。此外，COOP头只对跨域窗口有效，对同域窗口没有影响。

Cross-Origin-Embedder-Policy（COEP）

Cross-Origin-Embedder-Policy（COEP）是一个HTTP响应头，用于控制浏览器如何处理跨域嵌入的资源。它可以防止一些跨站点攻击，例如跨站点脚本（XSS）攻击和跨站点请求伪造（CSRF）攻击。

COEP头有以下几个可选值：

• none：表示资源可以在任何站点内嵌入。
• require-corp：表示资源只能在同一站点内嵌入，或者在使用了COOP头的站点内嵌入。
• unsafe-none：表示资源可以在任何站点内嵌入，但是会关闭一些安全特性。
  例如，以下代码片段演示了如何在Web.config文件中配置Cross-Origin-Embedder-Policy头：

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Cross-Origin-Embedder-Policy" value="require-corp" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

在这个示例中，Cross-Origin-Embedder-Policy头被设置为require-corp，表示资源只能在同一站点内嵌入，或者在使用了COOP头的站点内嵌入。
需要注意的是，COEP头只对支持COEP的浏览器有效。如果浏览器不支持COEP头，那么它将被忽略。此外，COEP头只对跨域嵌入的资源有效，对同域嵌入的资源没有影响。

Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy 是一个新的 HTTP 响应头，它允许 Web 开发人员控制网页上的资源如何跨域获取。它被现代浏览器（如 Chrome、Firefox 和 Safari）支持。

要将 Cross-Origin-Resource-Policy 头添加到 Web.config 文件中，你可以在  标签中添加以下代码：

<add name="Cross-Origin-Resource-Policy" value="same-site" />

这将把 Cross-Origin-Resource-Policy 头设置为 same-site，这意味着资源只能从同一站点获取。你也可以根据需要将其设置为 same-origin 或 cross-origin。

PS：WebKit

WebKit是一种开源的浏览器引擎，它被用于许多不同的浏览器中。以下是一些使用WebKit引擎的常见浏览器：

• Safari
• Google Chrome
• Microsoft Edge（旧版）
• Opera
• Vivaldi
• Brave
  这些浏览器都使用WebKit引擎来呈现网页内容，并且都支持CSP头中的X-Webkit-CSP选项。

PS：HttpCookies

httpCookies是Web.config文件中的一个元素，用于配置ASP.NET应用程序中的HTTP cookie。通过httpCookies元素，你可以设置cookie的各种属性，例如domain、path、httpOnly、secure、expiration等。

SameSite属性是一种用于防止跨站点请求伪造（CSRF）攻击的机制。通过设置SameSite属性，可以指定cookie只能在同一站点上发送，从而防止恶意站点利用cookie进行攻击。

httpCookies元素的sameSite属性可以设置为None、Lax或Strict。以下是这些选项的含义：

• None：表示cookie可以在任何站点上发送。这是默认值。
• Lax：表示cookie只能在同一站点上发送，或者在从站点导航到目标站点的情况下发送。
• Strict：表示cookie只能在同一站点上发送。
  通常情况下，建议将sameSite属性设置为Lax或Strict，以提高cookie的安全性。但是，需要注意的是，如果你的应用程序需要在跨站点的情况下发送cookie，那么你应该将sameSite属性设置为None。

以下是一些常用的httpCookies元素属性：

• domain：指定cookie的域名。
• path：指定cookie的路径。
• httpOnly：指定是否只能通过HTTP协议访问cookie。
• secure：指定是否只在HTTPS连接上发送cookie。
• expiration：指定cookie的过期时间。
  例如，以下代码片段演示了如何在Web.config文件中配置httpCookies元素：

<system.web>
  <httpCookies httpOnlyCookies="true" requireSSL="true" />
</system.web>

在这个示例中，httpCookies元素的httpOnlyCookies属性被设置为true，表示只能通过HTTP协议访问cookie。requireSSL属性被设置为true，表示只在HTTPS连接上发送cookie。