解决asp.net mvc发布到iis下安全问题

环境信息

• 服务器：Windwos Server 2016
• 项目框架版本：.NET Framework 4.7.2

1.The web/application server is leaking version information via the “Server” HTTP response

• 以下静态文件请求都携带了服务器信息

• 为什么请求接口没有，那是因为在Global.asax.cs配置了

protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
    var app = sender as HttpApplication;
    if (app == null || app.Context == null)
    {
        return;
    }

    // 移除Header中的Server
    app.Context.Response.Headers.Remove("Server");
}

• 想要解决请求静态文件携带Server信息，可以使用使用 URL Rewrite 模块移除 Server 头，URL Rewrite 模块可以全局处理所有请求（包括静态文件）

1.安装文件下载地址：下载地址

2.配置web.config

<configuration>
  <system.webServer>
    <rewrite>
      <outboundRules>
        <rule name="Remove Server Header">
          <match serverVariable="RESPONSE_Server" pattern=".*" />
          <action type="Rewrite" value="" />
        </rule>
      </outboundRules>
    </rewrite>
  </system.webServer>
</configuration>

3.效果如下：

2.确保您的Web服务器、应用程序服务器、负载均衡器等已配置为强制执行Strict-Transport-Security。

• iis响应头添加如下配置

Strict-Transport-Security：includeSubDomains

• 效果：
  

3.在HTML提交表单中找不到反CSRF令牌。跨站点请求伪造是一种攻击，涉及迫使受害者在不知情或无意的情况下向目标目标发送HTTP请求，以便作为受害者执行操作。根本原因是应用程序功能以可重复的方式使用可预测的URL/表单操作。攻击的本质是CSRF利用了网站对用户的信任。相比之下，跨站脚本（XSS）利用了用户对网站的信任。与XSS一样，CSRF攻击不一定是跨站点的，但也可能是。跨站点请求伪造也称为CSRF、XSRF、一键攻击、会话骑行、混淆代理和海浪。CSRF攻击在许多情况下都是有效的，包括：*受害者在目标站点上有一个活动会话。*受害者在目标站点上通过HTTP身份验证进行身份验证。*受害者与目标站点位于同一本地网络上。CSRF主要用于使用受害者的权限对目标站点执行操作，但最近发现了通过访问响应来披露信息的技术。当目标站点易受XSS攻击时，信息泄露的风险会急剧增加，因为XSS可以用作CSRF的平台，允许攻击在同源策略的范围内进行。

• 创建令牌

public static class CsrfTokenHelper
{
   private const string SecretKey = ""; // 服务器端的密钥  

   public static string CreateCsrfToken(string user)
   {
       string token = $"{user}"; // 将会话ID和用户值组合起来  

       byte[] secretKeyBytes = Encoding.UTF8.GetBytes(SecretKey);
       byte[] tokenBytes = Encoding.UTF8.GetBytes(token);

       using (HMACSHA256 hmac = new HMACSHA256(secretKeyBytes))
       {
           byte[] hashBytes = hmac.ComputeHash(tokenBytes);
           string csrfToken = Convert.ToBase64String(hashBytes);
           return csrfToken;
       }
   }
}

• 前端from请求中携带令牌

<input type="hidden" name="CSRFToken">

• 添加一个验证令牌的过滤器

//解决(CSRF)安全问题,也就是from没有提供票据问题
public class CsrfTokenFilter : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext context)
    {
        // 获取crsf_token
        string xsrf_token_headers = context.HttpContext.Request.Headers["XSRF-TOKEN"] == null ? "" : context.HttpContext.Request.Headers["XSRF-TOKEN"].ToString();
        string xsrf_token_froms = string.Empty;
        // 获取表单数据
        if (context.HttpContext.Request.Form.Count > 0)
        {
            FormCollection formCollection = new FormCollection(context.HttpContext.Request.Form);
            xsrf_token_froms = formCollection["CSRFToken"];
        }

        string newCsrfToken = CsrfTokenHelper.CreateCsrfToken(CurrentUser.UserAccount);
        if (xsrf_token_headers != newCsrfToken || xsrf_token_froms != newCsrfToken)
        {
            // 验证失败，抛出 401 Unauthorized 异常  
            context.Result = RedirectLogin("/Home/Error");
        }
        base.OnActionExecuting(context);
    }
}

• 在接口中使用

[WithoutLocalization]
[CsrfTokenFilter]
public JsonResult xxxxx(FormCollection formCol)
{

}

4.响应包含“仅内容安全策略报告”标头，这可能表示正在进行的实施工作，或在促进预生产到生产过程中的监督等。内容安全策略（CSP）是一个附加的安全层，有助于检测和缓解某些类型的攻击，包括跨站脚本（XSS）和数据注入攻击。这些攻击用于从数据盗窃到网站污损或分发恶意软件。CSP提供了一组标准HTTP标头，允许网站所有者声明允许浏览器在该页面上加载的已批准内容来源–涵盖的类型包括JavaScript、CSS、HTML框架、字体、图像和可嵌入对象

• 这个问题太恶心了,要是写了内联样式、行内样式、引入脚本文件了，配置了之后各种问题，解决文档

https://www.w3.org/TR/CSP/
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

• web.config配置

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <!--解决Header中没有csp-->
      <add name="Content-Security-Policy" value="default-src 'self';
           script-src 'self' 'unsafe-inline' 'unsafe-eval'; 
           font-src 'self' 'unsafe-inline' 'unsafe-eval' data: http://localhost:*;
           img-src 'self' data: blob: http://localhost:*; 
           style-src 'self' 'unsafe-inline';" />
      <!--允许请求的http 动作-->
    </customHeaders>
  </httpProtocol>
</system.webServer>

5.The response does not include either Content-Security-Policy with ‘frame-ancestors’ directive or X-Frame-Options to protect against ‘ClickJacking’ attacks.

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

6.反MIME嗅探标头X-Content-Type-Options未设置为“nosniff”。这允许旧版本的Internet Explorer和Chrome对响应正文执行MIME嗅探，从而可能导致响应正文被解释并显示为声明的内容类型以外的内容类型。当前（2014年初）和旧版本的Firefox将使用声明的内容类型（如果设置了），而不是执行MIME嗅探。

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

7.web/应用程序服务器通过一个或多个“X-Powered-By”HTTP响应标头泄漏信息。访问此类信息可能有助于攻击者识别您的web应用程序所依赖的其他框架/组件，以及这些组件可能存在的漏洞。

• 携带服务器信息截图
  
• 打开iis下的HTTP响应标头，干掉X-Powered-By
  
• 调整后的效果