Checkmarx对代码进行了分析,并报告了以下问题:
第**行的方法Load_Bank从数据库中获取Where
元素的数据。然后,该元素的值在未经正确过滤或编码的情况下流经代码,并最终在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问题?
这是不可利用的,因为响应类型是应用程序/json
。即使存在带有脚本标记的有效 xss 攻击,也没有现代浏览器会在具有应用程序/json
内容类型的响应中执行该攻击。
另外,Id
我猜是一个数字或uuid,Name
是html编码的,你可以说这是为了深度防御,但它实际上只需要编码为json,这是固有的。
您可以在检查中的标记将其标记为不可利用。
还要注意,在GET请求中返回json数组仍然不被认为是好的做法,因为有一种叫做json劫持的老攻击。然而,这在现代浏览器中已经不能被利用了,所以我不会说它容易受到攻击,除了在IE9中,不幸的是IE9可能仍然在使用。