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

发布时间 2023-10-29 19:32:24作者: Harley-Chang

概述

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

以下是一些站点部署的配置的记录,往往会在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-ControlPragma都是HTTP响应头,用于控制浏览器如何缓存响应内容。

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

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

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

以下是一个示例HTTP响应头,其中包含了Cache-ControlPragma头:


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的各种属性,例如domainpathhttpOnlysecureexpiration等。

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

httpCookies元素的sameSite属性可以设置为NoneLaxStrict。以下是这些选项的含义:

  • None:表示cookie可以在任何站点上发送。这是默认值。
  • Lax:表示cookie只能在同一站点上发送,或者在从站点导航到目标站点的情况下发送。
  • Strict:表示cookie只能在同一站点上发送。
    通常情况下,建议将sameSite属性设置为LaxStrict,以提高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。