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

问题描述 投票:15回答:4

我有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>
html code-analysis fortify
4个回答
6
投票

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

HTML警告中的硬编码域

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

抽象

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

说明

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

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

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

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

攻击缓解

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

  1. 将所有脚本移动到您自己的域。这样您就可以控制脚本的内容。这似乎是Fortify的推荐。
  2. 使用<script><link>标记的Subresource Integrity属性,如下面的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作为有效的缓解技术,但如果他们不这样做,他们仍然会标记这些错误,您需要手动检查并传递已经减轻的任何此类警告。

最佳选择

“最佳”选项取决于您的要求。以下是一些想法:

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

7
投票

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

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


如果您要包含CDN中的文件,则应使用subresource integrity以确保文件未被加载(如果已修改)。

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


4
投票

在PHP MVC世界中,执行此操作的方法之一是通过具有所有外部URI的库类。因为您知道在哪里寻找断开的链接,所以更容易管理。此外,最好使用'//'而不是http://或https://。

class External_uri
{
  public function __construct()
  {
    parent::__construct();
  }

  public function get_external_uri($name)
  {
    $uri = [
      'bootstrap_css'     => '//ajax.aspnetcdn.com/ajax/bootstrap/3.3.7/css/bootstrap.min.css',
      'font_awesome_css'  => '//stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css',
      'kendo_common_css'  => '//kendo.cdn.telerik.com/2018.1.221/styles/kendo.common.min.css',
    ]

    return $uri[$name];
  }
}

并称之为:

$this->External_uri->get_external_uri('bootstrap_css');

4
投票

我通常默认托管服务器本身的文件,并像这样引用它:

<link rel="stylesheet" href="~/Content/font-awesome/4.7.0/css/font-awesome.min.css">

如果他们的网站出现故障或SSL证书无效,这非常方便。某些站点不使用版本控制,并且在服务器上本地复制可以避免新版本破坏现有代码或影响其外观。在本地服务器上添加它也可以避免外部版本被恶意版本替换。

© www.soinside.com 2019 - 2024. All rights reserved.