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

时间:2018-05-31 21:01:24

标签: html code-analysis fortify

我有网络应用程序,我在那里引用带域名的文件名。我在哪里可以添加这些域名并从中调用它们。当我运行像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>

4 个答案:

答案 0 :(得分:7)

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

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

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

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

答案 1 :(得分: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. 使用下面的Mozilla Foundation(MDN)所述的<script><link>标记的Subresource Integrity属性。这也将阻止浏览器执行已修改的远程脚本。
  3.   

    子资源完整性(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,因为这样可以强制执行安全性,同时不要求您托管文件。

答案 2 :(得分: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');

答案 3 :(得分:4)

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

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

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