在Web应用程序中存储硬编码域名的最佳选择

Question

我有web应用程序,我用文件名称引用域名.我在哪里可以添加这些域名并从中调用它们.当我运行像fortify这样的工具来检查安全问题和标准时,它始终警告我不要保留硬编码的域名.什么是最好的选择,比如我在哪里可以从Web应用程序端(非数据库)存储和检索这些主域名？

我正在使用visual studio并致力于asp.net核心mvc应用程序.

以下是一个示例示例

<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css">
<link rel="stylesheet" href="https://kendo.cdn.telerik.com/2018.1.221/styles/kendo.common.min.css" />

其他例子

<environment exclude="Development">
        <link rel="stylesheet" href="https://ajax.aspnetcdn.com/ajax/bootstrap/3.3.7/css/bootstrap.min.css"
              asp-fallback-href="~/lib/bootstrap/dist/css/bootstrap.min.css"
              asp-fallback-test-class="sr-only" asp-fallback-test-property="position" asp-fallback-test-value="absolute" />
        <link rel="stylesheet" href="~/css/site.min.css" asp-append-version="true" />

    </environment>

Answer 1

首先,您可以在自己的服务器上托管文件并使用相对路径.

如果不可行,您需要一些系统来动态更改这些依赖项的URL,您可以从环境变量或配置文件中获取它们吗？DB不是一个糟糕的来源.

如果要包含CDN中的文件,则应使用子资源完整性,以确保在修改文件时不加载该文件.

我怀疑SCA仍会标记那些在外部域上的内容,在这种情况下,如果你不打算改变这种方法,你可以审计漏洞.

Answer 2

使用Fortify等工具解决安全警告时,了解警告背后的原因非常重要,这样才能正确地缓解这些警告.

HTML警告中的硬编码域

Fortify推断这个"HTML中的硬编码域"警告是链接到外部域会损害您网站的安全性,因为您链接的文件可以更改.以下内容来自"Fortify Taxonomy:软件安全错误":

抽象

包含来自其他域的脚本意味着此网页的安全性取决于其他域的安全性.

说明

包括来自其他网站的可执行内容是一个冒险的主张.它将您站点的安全性与其他站点的安全性联系起来.

示例:考虑以下<script>标记.

<script src="http://www.example.com/js/fancyWidget.js"/>

如果此标记出现在除此之外的网站上www.example.com,则该网站依赖于www.example.com提供正确和非恶意代码.如果攻击者可以妥协www.example.com,那么他们可以改变内容fancyWidget.js以破坏网站的安全性.例如,他们可以添加代码fancyWidget.js来窃取用户的机密数据.

• 参考:https://vulncat.hpefod.com/en/detail？ id = desc.content.html.hardcoded_domain

攻击缓解

有两种方法可以解决这个问题:

1. 将所有脚本移动到您自己的域.这样您就可以控制脚本的内容.这似乎是Fortify的推荐.
2. 使用Subresource Integrity属性<script>和<link>标记,如下面的Mozilla Foundation(MDN)所述.这也将阻止浏览器执行已修改的远程脚本.

子资源完整性(SRI)是一种安全功能,使浏览器能够验证他们获取的文件(例如,来自CDN)是否在没有意外操作的情况下传递.它的工作原理是允许您提供所提取文件必须匹配的加密哈希.

SRI integrity属性的示例如下所示,并由许多CDN使用.

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

理想情况下,Fortify应该支持SRI作为有效的缓解技术,但如果他们不这样做,他们仍然会标记这些错误,您需要手动检查并通过任何已经减轻的警告.

• 参考:https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

最佳选择

"最佳"选项取决于您的要求.以下是一些想法:

• 如果您正在运行商业服务并且需要您的站点可操作并且在您的控制之下,那么自己提供文件可能是最佳选择,因为您不仅可以控制安全性,还可以控制可用性.关于可用性,如果您使用的是远程站点且远程站点不可用,则您的站点可能无法正常运行.即使您自己托管文件,仍应使用SRI,以防您自己的文件受到损害.
• 如果您正在运行非商业或小型商业站点,则可以使用带有SRI的CDN,因为它可以在不要求您托管文件的情况下强制执行安全性.