首页 > 解决方案 > Checkmarx 报告的 ASP.Net MVC App Stored XSS 漏洞

问题描述

Checkmarx 对代码进行了分析,并报告了以下问题:

** 行的方法Load_Bank从数据库中获取Where元素的数据。然后,该元素的值在没有经过适当过滤或编码的情况下流经代码,并最终Bank_Read在第 * 行的方法中显示给用户SomeController.cs。这可能会启用存储的跨站点脚本攻击。

internal IEnumerable<BankDTO> Load_Bank()
{
    using (var Container = new EBookletEntities())
    {
        var query = from r in Container.Gen_Bank.AsNoTracking()
                    where r.IsDeleted != true
                    select new Gen_BankDTO
                    {
                        Id = r.Id,
                        Name = r.Name
                    };
        return query.ToList<BankDTO>();
    }
}

下面是控制器代码

using (var bll = new BankBLL())
{
    var item = bll.Load_Bank();
    var model = item.Select(r => new BVM()
        {
            Id = r.Id,
            Name = HttpUtility.HtmlEncode(r.Name)
        }).ToList();

    return Json(model.ToDataSourceResult(request), "application/json", System.Text.Encoding.UTF8, JsonRequestBehavior.AllowGet);

}

Checkmarx 来源:

where r.IsDeleted != true 

目的地:

return Json(model.ToDataSourceResult(request), "application/json", System.Text.Encoding.UTF8, JsonRequestBehavior.AllowGet);

我想知道是否真的存在存储型 XSS 问题或 Checkmarx 报告它是错误的?

如何解决 Checkmarx 问题?

标签: c#asp.net-mvcsecurityxsscheckmarx

解决方案


这是不可利用的,因为响应类型是application/json. 即使存在带有脚本标记的有效 xss 攻击,现代浏览器也不会在具有application/json内容类型的响应中执行该攻击。

另外Id我猜是一个数字或 uuid 并且Name是 html 编码的,你可能会争辩说这是为了深度防御,但它实际上只需要为 json 编码,这是固有的。

您可以在 Checkmarx 中将此标记为不可利用。

另请注意,在 GET 请求中返回 json 数组仍然不是一种好的做法,因为一种称为json hijacking的旧攻击。然而,这在现代浏览器中不再可利用,所以我不会说它不再易受攻击,除了在 IE9 中,不幸的是它可能仍在使用中。


推荐阅读