加密 HTTP Web 开发 Web 开发 IIS 服务器架构师高级 XML .NET 3.5 C# 2.0 C# 3.0 C# 4.0 中级开发 .NET ASP.NET C#

ASP.NET Web 应用程序安全审查：应做与禁做

santosh poojari

4.88/5 (108投票s)

2011年11月29日

CPOL

22分钟阅读

502621

本文旨在帮助您构建和启用健壮的 Web 应用程序，其中涉及系统设计时需要考虑的各种安全方面。

概述
避免点击劫持攻击：使用 X-Frame-Options [Deny]
限制暴露的 HTTP 方法 - UrlScan 工具
禁用目录列表和目录遍历：HTTP 错误 403 vs. 404
加密 web.config 文件中的连接字符串
始终设置自定义错误页面
始终传递安全 cookie
Web 场安全规范
杂项
附录：IIS 6.0 vs. IIS 7.0 中的安全加固
附录：防盗链资源
附录：安全最佳实践
优化响应头
HTTP: Postman Inteceptor 和开发者工具
Cookies，智能且易受攻击的 Cookies
打破它，修复它！
OWASP Top 10 戒律 YYYY
结论
大师：Troy Hunt

1. 概述

本文旨在帮助您构建和启用健壮的 Web 应用程序，其中涉及系统设计时需要考虑的各种安全方面。未考虑安全评估而设计的系统会导致不合规，并可能面临安全威胁。此类系统容易受到有害攻击。以下指南将促进应用程序的加强，减轻潜在攻击的风险，并减少未经授权的活动。本文中描述的问题、场景和解决方案都是以 .NET 为中心的。我试图涵盖大多数导致问题和不合规的最重要的安全审查项。

2. 避免点击劫持攻击：使用 X-Frame-Options [Deny]

简而言之，网站的点击可能会被任何网站使用点击劫持技术劫持。此概念背后的基本思想是利用 HTML 页面中 DIV 和 IFrame 标签的 z-index 属性。我们可以通过在实际网站上方放置一个虚假网站来损害实际网站的交易。这里发生了什么？恶意网站将在其 HTML IFrame 中加载实际网站页面，并将实际网站置于背景中，并将透明度设置为“false”。使用这种机制，虚假网站将复制/模拟真实网站，所有非虚拟按钮都精确地放置在真实网站上方，并帮助在线用户在虚假网站提供的信息下以欺诈动机在实际网站上执行操作。

点击劫持技术

以下是两步实现

将目标网站置于低 z-index 级别，例如 5，并设置 AllowTransparency="false"
将虚假网站置于高 z-index 级别，例如 10

<html>
<body>
<iframe src="http://www.microsoft.com" allowtransparency="false" style="float; position: absolute;
        left: -5px; top: 12px; width: 731px; background: white; height: 259px; z-index: 5;
        margin-top: 0px;" border="0" frameborder="0" scrolling="no"/>
<div style="position:absolute; left:0px; top:0px; width: 250px; height: 200px; background:white; z-index:10">
<h1>Click Jacking</h1>
</div>
</body>
</html>

这个概念非常简单。钓鱼网站将放置在目标网站的正上方，这样在虚假网站上执行的任何操作都将触发实际网站上的事件。这就是这种不正当行为将导致无效交易发生，并且目标网站将容易受到点击劫持。

实时场景

假设有一个电子商务网站，我们可以在线购买书籍。将会有另一个网站具有完全相同的副本，但有一些更改，以激励用户进行交易。一个场景是电子商务网站将有一个带有“购买”标题的按钮，而恶意网站将有一个屏幕，上面有一个被掩盖的非事件按钮“捐赠”，正放置在其上方。用户点击被掩盖的非事件按钮“捐赠”的那一刻，实际上它将触发低 z-index 的“购买”按钮。这就是黑客如何滥用您的网站以达到其目的。

点击劫持网站的解决方案

以下解决方案严格以 .NET 为中心，每种技术都有其解决此问题的方法。X-Frame-Options 是我们可以限制网站被点击劫持滥用的一个领域。

有三种解决方案可以解决这个问题

解决方案 1

以下代码位于您的 Web 应用程序解决方案的 *Global.asax* 文件中

void Application_BeginRequest(object sender, EventArgs e)
{
  this.Response.Headers["X-FRAME-OPTIONS"] = "DENY";
}

此处需要注意的是。这确实会抛出诸如“错误：此操作需要 IIS 集成管道模式”之类的错误。

解决方案 2：这对于所有身份验证模式都绝对有效

void Application_BeginRequest(object sender, EventArgs e)
{
    HttpContext.Current.Response.AddHeader("x-frame-options", "DENY");
}

解决方案 3：我们可以通过添加自定义 X-Frame-options 直接设置此限制

网站容易受到点击劫持的影响，这可能允许攻击者使用跨站点脚本 (XSS) 诱骗用户点击恶意链接过程，以使用 IIS 发送 X-Frame-Option 头。

打开 IIS（通过运行 *inetmgr* 命令）。
转到网站文件夹，右键单击您的网站，然后转到属性。
转到 HTTP 头选项卡。
转到自定义头部分。
单击添加。
自定义头名称：X-Frame-Options 自定义头值：“DENY”（不带引号）或“SAMEORIGIN”。
如果存在子目录网站，IIS 将要求您将其覆盖到子目录网站。
确定并通过运行 *iisreset* 命令重新启动 IIS。

注意：确保您添加 DENY 或 SAMEORIGIN。每个都有其自己的重要性。如果我们要将其应用于应用程序级别，一个简单的解决方案是在 *Global.asax* 文件中的以下事件下添加以下代码行。

参考文献

3. 限制易受攻击的 HTTP 方法 - UrlScan 工具

可利用的 HTTP 方法已启用。OPTIONS HTTP 方法已启用。OPTIONS 方法可用于应用程序/服务器的足迹/分析。此问题的答案是 UrlScan 工具。

下载 UrlScan 工具

为什么选择 UrlScan？

UrlScan 工具是一种安全工具，用于扫描和限制 IIS 处理的传入 HTTP 请求。通过阻止特定的 HTTP 请求，UrlScan 有助于防止潜在有害的请求被服务器上的 Web 应用程序处理。此工具提供了应用安全规则和策略的选项，这些规则和策略在 HTTP 请求传递到或由 IIS 处理时是必需的。对于初学者来说，第一次理解 URL 扫描概念可能会有点困惑。基本上，此工具提供了一个配置模板，可帮助我们定义自己的规则或使用适用于应用程序和业务需求的现有规则。

优势

它有助于避免运行恶意代码、发送到 IIS 的请求，这些请求可能对整个网站功能构成威胁和危害。

它做什么？

这些规则主要监控并充当检查器，以限制发送到 IIS 的有害传入请求。但要使其工作，我们需要在 IIS 作为托管平台的 Web 服务器中安装 UrlScan。UrlScan 附带默认配置设置。我们可以根据我们的要求修改配置并利用其优势。

定义规则和策略

阻止 SQL 注入的规则
设置 URL 格式的规则
限制头值的长度
限制 URL 的最大长度
限制 URL 中查询字符串的最大长度
限制请求的内容长度
HTTP 方法 – GET POST、HEAD、TRACE

要更深入地了解，请查看：http://learn.iis.net/page.aspx/476/common-urlscan-scenarios/。

我们在哪里配置上述规则集？

所有上述规则都存在于 *UrlScan.ini* 配置中，我们可以根据我们的业务需求或合规性重新配置或添加自定义配置。下面给出了示例配置设置

UrlScan 的替代方案

UrlScan 在 IIS 级别对整个网站应用规则。如果我们要将安全规范应用于特定网站和模块，那么我们必须查看 .NET 中的安全代码访问选项。有三个基本实践可以帮助我们将安全应用于特定文件、目录 (URL) 和文件类型。这些中的每一个都有其自己的规范和要求。

1. FileAuthorizationModule

这基本上与与 *.aspx* 或 *.asmx* 相关的文件的 ACL 列表有关。如果我们将身份验证依赖于 IIS，那么我们需要 ASP.NET 模拟。这种模拟与 Windows 身份一起工作，并且基于传递给 IIS 的身份令牌。这都是关于模拟的。我目前不会花太多时间解释所有这些。我只是希望读者专注于安全代码访问，并花时间理解其背后的概念和理论。我们通常在 MOSS 和 PPS 安装中遇到安全启用问题，在那里我们需要第一次正确设置环境，然后所有这些都与代码和交付成果一起进行。

ASP.NET 所需 ACL 列表

public sealed class FileAuthorizationModule : IHttpModule

2. UrlAuthorizationModule

通常，我们有三个主要的 URL 授权项目。它需要基于角色的安全模块，我们可以在其中为特定业务需求的用户分配具有角色的域组。谈到动词，这是 HTTP 方法类型，可以是 GET-POST-HEAD-OPTIONS-TRACE-FIND 等等。这就是我们在 UrlScan 工具中看到的。根据我们的服务器环境，我们可以设置此 HTTP 方法类型。例如，我们可以在测试和开发环境中启用 TRACE 和 Options，但在生产环境中我们不希望它们存在，因为它可能会损害性能并泄漏与服务器或现有配置相关的信息。

用户-角色-动词。

用户（*所有已认证用户/? 匿名用户/或已定义的确定性用户）
角色（域/管理员 - 域/业务用户 - 等等）
动词 - HTTP 方法 - GET、POST、HEAD、OPTIONS、FIND、TRACE 等。

<authorization>
  <[allow|deny] users roles verbs />
</authorization>
<authorization>
  <allow verbs="GET" users="*"/>
  <allow verbs="POST" users="xyz"/>
  <deny verbs="POST" users="*"/>
</authorization>

HttpForbiddenHandler：排除不必要的未使用文件扩展名

在面向 Internet 的 Web 服务器上禁用远程处理、批处理文件、可执行文件（*.rem*、*.soap*、*.bat*、*.exe*）。此外，如果我们知道应用程序中未使用给定的一组扩展文件，我们可以将其分配给 HttpForbiddenHandler。参考：在 IIS 中实现 HttpForbiddenHandler，保护 Web 服务器。

<system.web>
    <httpHandlers>
         <add verb="*" path="*.mdb" type="System.Web.HttpForbiddenHandler" />
         <add verb="*" path="*.csv" type="System.Web.HttpForbiddenHandler" />
         <add verb="*" path="*.private" type="System.Web.HttpForbiddenHandler" />
    <add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/>
    <add verb="*" path="*.soap" type="System.Web.HttpForbiddenHandler"/>
    <add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/>
    </httpHandlers>
</system.web>

4. 禁用目录列表和目录遍历：HTTP 错误 403 vs. 404

应用程序已启用目录列表，允许用户查看应用程序的内部视图和所有可用页面。例如，您的网站 NewBee 具有 *Website/Image*、*Website/Script*、*Website/UI* 的目录列表。

通常，用户将通过指向此源网站来浏览应用程序：*https://NewBee.com*。该网站将按预期工作。

场景 1 - 如果您不小心键入 URL 地址 *https://Newbee.com/UI*，它将列出该目录/文件夹下的所有文件。这样做，您的网站容易受到安全威胁。您允许用户猜测目录结构。

场景 2 - 假设目录列表被禁止并且启用了 HTPP 请求错误代码 403，那么用户将收到一条消息，指出目录浏览被禁止。这意味着 *UI* 文件夹目录有效，并且以某种形式存在 *UI* 文件夹。这为黑客提供了一步可访问性选项，以便他了解目录结构和文件位置。

补救措施和变通办法

禁用目录列表 - 检查是否设置了自定义错误 403。
将 Web 服务器配置为在用户尝试执行目录遍历时显示 HTTP 404 错误页面。显示 HTTP 404 错误而不是 HTTP 403 错误，因为恶意用户可以使用 HTTP 403 错误来映射应用程序结构。

如何将 HTTP 403 错误配置为 HTTP 404 错误？

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Web; 
 
namespace MyNameSpace 
{ 
    public class NoAccessHandler: IHttpHandler 
    { 
 
        #region IHttpHandler Members

        public bool IsReusable
        {
        get { return true; }
        }

        public void ProcessRequest(HttpContext context)
        {
        context.Response.StatusCode = 404;
        }

        #endregion
        }
        }

<httpHandlers>
      <add verb="*" path="UI/*" validate="false" type="MyNameSpace.NoAccessHandler"/>
</httpHandlers>
<system.webServer>
        <handlers>
      <add name="NoAccess" verb="*" path="UI/*" 
         preCondition="integratedMode" type="MyNameSpace.NoAccessHandler"/>
    </handlers>
</system.webServer>

5. 加密 web.config 文件中的连接字符串

切勿在 *web.config* 文件中保留明文连接字符串。这带来的风险和后果不言而喻。您所需要做的就是按照以下步骤操作，即可完成此操作。

需要遵循的步骤

aspnet_regiis -pef "connectionStrings" path

"path" 是 *web.config* 所在的物理文件夹路径（例如，*aspnet_regiis -pef "connectionStrings" D:\Apps\NewBeeWebsite*）。

aspnet_regiis -pa "NetFrameworkConfigurationKey" "ASPNET"
aspnet_regiis -pa "NetFrameworkConfigurationKey" "NETWORK SERVICE"
aspnet_regiis -pa "NetFrameworkConfigurationKey" "NT AUTHORITY\NETWORK SERVICE"

在“*C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\*”路径下，转到 Visual Studio 命令提示符。
使用 *aspnet_regiis –I* 命令安装 ASP.NET。
使用以下命令加密 *Web.Config* 连接字符串；
您将收到消息“正在加密配置节...成功！”。
运行以下命令
重新启动 IIS。

6. 始终设置自定义错误页面

为什么需要自定义错误消息？在 *web.config* 文件中启用自定义错误页面选项。切勿向最终用户显示源级别的错误消息。这将帮助用户理解代码的语义和流程。对于任何应用程序级别的异常，显示自定义错误页面是一种良好的做法。

<customErrors mode="On" defaultRedirect="ErrorPage.aspx" />

7. 始终传递安全 cookie

安全 cookie 属性阻止 cookie 发送到 HTTP 流量。在所有 cookie 上设置 SECURE 标志：每当服务器设置 cookie 时，请安排它在 cookie 上设置 SECURE 标志。SECURE 标志告诉用户的浏览器仅通过 SSL 安全的 HTTPS 连接发送回此 cookie。浏览器绝不会通过未加密的 HTTP 连接发送安全 cookie。最简单的步骤是在您的网站使用的每个 cookie 上设置此标志。

<httpCookies httpOnlyCookies="true" requireSSL="true" />

8. Web 场安全规范

保护视图状态并保障其完整性

在基于表单的身份验证中，保护视图状态非常重要，尤其是在 Web 场中存在负载均衡模式的 Web 服务器时。在这种情况下，客户端到服务器的请求是未知的，它可能会根据给定的阈值用户负载将请求发送到服务器，并且这是非确定性的。黑客可能会篡改您的视图状态，并且视图状态的完整性会受到损害。为了保护视图状态在从客户端到服务器以及反向传输过程中不被损坏，我们必须应用 <% @ Page enableViewStateMac=true %>。这将为在页面级别生成的视图状态生成机器身份验证代码。这将使页面级别的视图状态保持完整。但我们再次需要在 Web 场环境中加强此安全性。在这里，我们需要维护另一个级别的完整性。

级别 1：页面级别完整性：<% @ Page enableViewStateMac=true %>。
级别 2：如果 Web 服务器处于 Web 场模式，则在所有 Web 服务器上应用通用的加密和解密。

在 Web 服务器的 *machine.config* 中，我们需要保持 machinekey 一致且相同，以便它具有相同的加密和解密密钥。

<machineKey validationKey="AutoGenerate "
            decryptionKey="AutoGenerate"
            validation="SHA1"/>

会话状态管理

正如我之前提到的关于 Web 场环境，来自同一登录用户的连续/连续请求可能会命中 Web 场中的不同 Web 服务器。在这种情况下，包含用户凭据的会话的完整性可能会丢失，并且跨 Web 服务器的用户会话将无法维护，信息也会丢失。这可能导致每次连续请求的会话无效。唯一的解决方法是将会话存储在 SQL Server 中（进程外状态管理）。

参考：http://msdn.microsoft.com/en-us/library/ff649337.aspx。

9. 其他

应用程序加固 - 一些先决条件和第一级安全基于应用程序加固的硬事实是必须的，并且必须注意

处理 SQL 注入。UrlScan 也帮助防止 SQL 注入。在 SQL 脚本和前端处理 SQL 注入。所需的是确定性客户端验证。尽量使用客户端验证，并且仅在最需要时使用服务器端验证。
始终加密应用程序中的查询字符串。查询字符串会暴露应用程序数据，并帮助用户收集更多信息以攻击网站。
尽量在应用程序中使用较少的隐藏字段。
加密视图状态。参考：http://msdn.microsoft.com/en-us/library/aa479501.aspx。
切勿将高度机密的数据保存在 cookie 中。
重要提示：安装 *SSLSCAN.exe* 以验证弱密码套件，并且其位长不应低于 128 位。例如，首选服务器密码套件 (s) SSLv3 256 位。下载 SSL 扫描实用程序
禁用应用程序跟踪和调试模式 [false]。

10. 附录：IIS 6.0 vs. IIS 7.0 中的安全加固

IIS 6.0 vs. IIS 7.5

上述内容更符合我们现有基础设施设置中的内容，并且大多数生产中的应用程序仍在使用 IIS 6.0 和 Window Server 2003。根据需求和持续迁移，上述安全方面在 IIS7 中得到了很好的处理。为了使本文更有用和更好，我添加了一些关于 IIS7.5 的上下文，其中涉及自 IIS7.0 诞生以来它所经历的根本性变化。

IIS 6.0 架构

IIS 7 内部结构

序号	IIS 6	IIS 7
1	IIS 6.0 - 它有自己的认证和授权机制，ASP.NET 也有自己的认证和授权模式。在认证和授权方面存在隔离。	IIS 7.5 只有认证选项，ASP.NET 只有授权模式启用。IIS 7.5 有两种模式：经典模式（适用于 IIS 6.0）和集成模式，其中认证由 IIS 处理，而授权由 ASP.NET 处理。
2	IIS 6.0 具有匿名访问权限，存在于用户和来宾组 IIS_WPG 中。	IIS 7.5 具有匿名访问权限，分配给新的 Windows 内置用户 IUSR，该用户存在于用户组 – IIS_IUSRS 中。这取代了 IIS 6.0 的 IIS_WPG，改为 IIS_IURS。该组不需要用户 ID/密码。有一个选项可以将应用程序池标识包含为匿名用户。
3	有 Web 服务扩展可启用非静态内容，例如 ASP.NET、WebDAV、服务器端包含等。	此功能直接可用并默认启用。这是 CGI 和 ISAPI.dll 限制的一部分，可以相应地设置。
4	我们可以使用 UrlScan 设置规则来对 URL 请求过滤施加限制。	它具有内置的请求过滤功能。查询字符串标题文件名扩展 HTTP 动词规则 - 例如 SQL 注入 URL
5	支持通配符脚本映射。	支持经典 IIS 6.0 和集成管道模式 IIS7 的通配符映射。只需查找 `<modules runAllManagedModulesForAllRequests="true">` http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx http://haacked.com/archive/2010/12/22/asp-net-mvc-3-extensionless-urls-on-iis-6.aspx http://learn.iis.net/page.aspx/508/wildcard-script-mapping-and-iis-integrated-pipeline/

IIS 7 应用程序池 - 集成和经典模式与 ASP.NET 框架选项

IIS 7 请求过滤：UrlScan 的替代品

这只是 IIS 的概述，网上还有更多信息可供参考。这将为读者提供一个深入研究 IIS 的方向，以了解如果处理或配置不当可能产生的安全影响。

我们可以过滤对 IIS 的请求并保护对网站资源的恶意调用。

按文件名扩展名过滤
设置规则 - 例如限制跨域调用。
HTTP 动词：允许/拒绝跟踪、获取、发布、放置、选项、查找、跟踪等。
查询字符串：设置查询字符串长度和 URL 中的特殊字符。
头部：设置头部

11. 附录：防盗链资源

有时我们通过 URL 暴露了网站资源，例如图像，这些资源被其他网站直接使用和引用。影响 - 这会增加不相关的流量和版权问题。为了防止这种情况，我们可以使用 URL 重写，我们可以禁止他人使用我们网站源的图像，从而返回一些受限水印以禁止相同的情况。

使用 -URL 重写- 请求过滤限制防盗链图像或资源停止防盗链的解决方法

12. 附录：安全最佳实践

删除不必要的响应头

删除服务器响应头，例如：Server Microsoft-IIS/7.5

public class CustomHeadersModule : IHttpModule
   {
       public void Init(HttpApplication context)
       {
           context.PreSendRequestHeaders += OnPreSendRequestHeaders;
       }
       public void Dispose() { }
       static void OnPreSendRequestHeaders(object sender, EventArgs e)
       {
           // remove the Server Http header
           HttpContext.Current.Response.Headers.Remove("Server");
           //remove the X-AspNetMvc-Version Http header
           HttpContext.Current.Response.Headers.Remove("X-AspNetMvc-Version");
       }
   }

删除响应头：X-Powered-By - 表示该网站由“ASP.NET”提供支持。

<httpProtocol >
<customHeaders >
<remove name="X-Powered-By" />
</customHeaders >
</httpProtocol >

删除响应头：X-AspNet-Version - 指定使用的 ASP.NET 版本。

<system.web>
<httpRuntime enableVersionHeader="false"/>

在 Global.asax.cs 中删除 X-AspNetMvc-Version，添加此行

protected void Application_Start()
{
MvcHandler.DisableMvcResponseHeader = true;
}

MVC 跨站请求伪造-

Html.AntiForgeryToken()
ValidateAntiForgeryToken
Salt base Html.AntiForgeryToken("SaltValue")

XSS 攻击 ASP.NET

HTML 编码 Html.Encode(feedback.Message) AntiXss 库 @Encoder.JavaScriptEncode Javascript 编码辅助类 @Ajax.JavaScriptStringEncode http://weblogs.asp.net/jongalloway//preventing-javascript-encoding-xss-attacks-in-asp-net-mvc

保护控制器

保护控制器和动作

AllowAnonymous
Authorize

13. 优化响应头

HTTP 严格传输安全 (HSTS)

由 OWASP 提供，HTTP X-XSS-Protection 响应头是 Internet Explorer、Chrome 和 Safari 的一项功能，当它们检测到反射式跨站脚本 (XSS) 攻击时，会阻止页面加载。尽管当网站实施强大的内容安全策略 (Content-Security-Policy) 以禁用内联 JavaScript ('unsafe-inline') 时，现代浏览器中这些保护措施大多不必要，但它们仍然可以为尚不支持 CSP 的旧版 Web 浏览器用户提供保护。

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Strict-Transport-Security" value="max-age=31536000"/>
        </customHeaders>
    </httpProtocol>
</system.webServer>

重要警告

您必须确保此标头必须与重定向规则或任何与此设置冲突的特定域 URL（使用 http）一起进行评估。感谢 Scott Hanselman 请参考此解释。 我的旧（继承）网站发生了什么？嗯，多年前有人想确保网站上的特定端点/页面通过 HTTPS 提供，所以他们编写了一些代码来做到这一点。没问题，对吧？事实证明，他们还添加了一个 else，有效地强制所有人使用 HTTP，而不是仅仅使用当前/继承的协议。当在整个域的根级别打开 Strict-Transport-Security 时，这是一个问题。现在人们会出现在网站上并得到这种交互：• GET http://foo/web • 301 到 http://foo/web/（规范结尾斜杠）• 307 到 https://foo/web/（带方法的重定向，换句话说，内部重定向到安全并继续使用相同的动词（GET 或 POST））• 301 到 http://foo/web（内部 else，愚蠢且遗留）• 清洗，重复。教训是什么？在域级别打开此功能的配置更改当然影响了所有子目录和应用程序，包括我们的遗留应用程序。我们的遗留应用程序还没有准备好。请务必在所有网站上实施 HTTP Strict Transport Security (HSTS)，但请务必测试并了解您的重定向。

OWASP HTTP 严格传输安全 (HSTS)

X-Content-Type-Options

X-Content-Type-Options 响应 HTTP 标头是服务器用于指示 Content-Type 标头中声明的 MIME 类型不应更改并应遵循的标记。这允许选择退出 MIME 类型嗅探，或者换句话说，这是表示网站管理员知道他们在做什么的方式。<add name="x-content-type-options"> 来自 <https: developer.mozilla.org="" docs="" en-us="" headers="" http="" web="" x-content-type-options="">

X-XSS-Protection: 1; mode=block

HTTP X-XSS-Protection 响应标头是 Internet Explorer、Chrome 和 Safari 的一项功能，当它们检测到反射型跨站脚本 (XSS) 攻击时，会阻止页面加载。尽管当网站实施强大的内容安全策略 (Content-Security-Policy) 以禁用内联 JavaScript ('unsafe-inline') 时，现代浏览器中这些保护措施大多不必要，但它们仍然可以为尚不支持 CSP 的旧版 Web 浏览器用户提供保护。来自 <https: developer.mozilla.org="" docs="" en-us="" headers="" http="" web="" x-xss-protection=""><add name="x-content-type-options">

 <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
        <remove name="X-Content-Type-Options" />
        <add name="X-Content-Type-Options" value="nosniff" />
        <add name="X-XSS-Protection" value="1; mode=block" /> 
      </customHeaders>
    </httpProtocol>

14. HTTP:Postman Inteceptor 和开发者工具

我主要使用 Postman Interceptor 和开发者工具进行网站安全评估。与 Fiddler 不同，这是一个非常方便的工具。相信我，Postman Interceptor 易于使用。以下是启用拦截器的步骤。在 Chrome 中安装 Postman 应用程序和 Postman Interceptor 插件。一个是应用程序，另一个是浏览器拦截器，用于捕获任何网站的请求和响应。它拦截所有传入和传出的调用。您甚至可以过滤 XHR 或主机级别的路由以捕获特定调用。在 Chrome 中安装应用程序和拦截器。请参考截图。启用浏览器拦截器，然后打开 Postman。在 Postman 中，也有一个旋钮可以捕获 Chrome 浏览器请求和响应。应用程序拦截 Chrome 浏览器 URL 并捕获历史记录中的 HTTP 流量。您可以打开其中一个历史记录，并可以修改 GET/POST 等请求正文或请求头。您可以调整头中的数据以及请求 URL 或正文来操作请求。这将帮助您在功能级别分析和设计安全评估测试用例。此外，您可以根据您的个性化设置将此历史记录保存在云中。现在，开发者工具 F12，捕获截图，查看应用程序部分中的 cookie。切换到离线模式，检查网站行为等等。我鼓励开发者更多地使用这些开发者工具功能。在网络选项卡下选择 XHR 以捕获 AJAX 或 Angular 调用以及更多内容。所有这些都是为了让我们的生活更轻松。

了解 Postman Interceptor

步骤1：安装这些 Chrome 插件和应用程序

步骤2：打开拦截器按钮

步骤3：查看历史记录并进行操作

了解开发者工具 F12

读取 Ajax XHR 请求

限流-离线！保留日志！禁用缓存

有时您想清除缓存并重新加载请求。简单的方法是查看截图。如果您想模拟 3G、4G 速度甚至离线模式，您可以在 Chrome 中完成。非常有趣的是 XHR 请求，可以在跨页面请求中保留。

15. Cookies，智能且易受攻击的 Cookies

如果您有带表单登录的事务性网站，那么 ASP.NET 中的表单 cookie 肯定会显示为 .ASPAuth，会话 cookie 会是 .Asp.Net_SessionId。处理它们时您必须小心。您必须了解会话超时和表单身份验证超时的重要性。只需拦截这两个 cookie 的详细信息，您就可以操纵网站的核心功能。如果您使用非 HTTP cookie，任何第三方工具都可以通过 document.cookie 轻松拦截您的 cookie。如果您使用 .Net Identity 身份验证，您可能会看到不同的 cookie 变量。在处理会话超时时，必须非常注意服务器会话处理和通过 AJAX 调用提供服务时的会话超时。请注意，这是两种不同的场景。一种是纯粹的服务器端处理，其中会话超时，另一种是通过提交按钮进行 AJAX 调用，您调用服务器 API 返回响应。在这两种场景中，会话过期和处理都必须小心。可能存在您必须平衡这些会话与表单超时的情况。例如购物车，其中会话已创建，然后通过表单或其他方法进行身份验证。

     public void OnAuthorization(AuthorizationContext filterContext)
        {
            var isAuthenticated = filterContext.HttpContext.User.Identity.IsAuthenticated;
            if (!isAuthenticated)
                RedirectToAccessDeniedPage(filterContext);

            var userContext = Some Session;
            if (userContext == null)
            {
                

                if (filterContext.HttpContext.Request.IsAjaxRequest())
                {
                   
                    filterContext.HttpContext.Response.StatusCode = 440;
                }
                else
                {
                    if (!HttpContext.Current.Response.IsRequestBeingRedirected)
                    {
                       //either redirect to login or logout
                        WebUtil.Redirect(returnUrl);
                    }
                }
                return;
            }
        }

Cookies 毕竟是 cookies，必须小心处理，尤其是在使用输出缓存时，当使用基于会话的方法时，请确保您有用户特定的变量来在页面级别缓存输出。

16. 打破它，修复它！

在 50% 的情况下，当 URL 查询字符串长度超出预定义长度时，系统会因 500 错误而失败。系统不可用或 YSOD。很好地处理这种情况。用这个测试您的网站的负面情况。

225 个字符路径（正常）https://com.com/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

226 个字符路径（错误）：https://abc.com/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

17. OWASP Top 10 戒律 YYYY

OWASP Top 10 2017 OWASP TOP 10 2017
OWASP Top 10 2013 OWASP TOP 10 2013

仔细思考测试用例测试用例

18. 结论

在设计阶段纳入必要的关键安全最佳实践是很好的，从而确保系统没有风险，同时具有抵抗黑客攻击的能力。本文中给出的参考文献信息量很大，我强烈建议读者花一些时间阅读它们。我希望我满足了读者的期望，这一定对他们有所帮助。

19. 大师：Troy Hunt

C 代表 cookie，H 代表黑客——理解 HTTP-only 和安全 cookie

参考文献

文档版本

**添加了视图状态加密的参考，日期：2011 年 11 月 30 日。
**添加了 SQL 注入的参考，日期：2011 年 12 月 1 日。
**添加了 Web 场安全注意事项的参考，日期：2011 年 12 月 5 日。
**添加了最佳实践/防盗链的参考，日期：2014 年 8 月 6 日。
**添加了服务器详细信息响应头的自定义代码，2016 年 8 月 9 日。
**添加了 OWASP Top 10、工具和负面测试用例。