Best option to store hardcoded domain names in web application

Question

I have web application where I refer to file names with domain names. Where can I add these domain names and call them from. When I run tools like fortify to check for security issues and standards it always warns me not to keep hard coded domain names. What would be a best option like where can I store and retrieve these main domain names from web application end(Not db)?

I am using visual studio and working on asp.net core mvc application.

Below is a sample example

<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" />

Other example

<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

When addressing security warnings by tools like Fortify, it's important to understand the reasoning behind the warnings so you can mitigate them correctly.

Hardcoded Domain in HTML warning

Fortify's reasoning for this "Hardcoded Domain in HTML" warning is linking to an external domain will compromise the security of your site because the file you are linking can be changed. The following is from "Fortify Taxonomy: Software Security Errors":

Abstract

Including a script from another domain means that the security of this web page is dependent on the security of the other domain.

Explanation

Including executable content from another web site is a risky proposition. It ties the security of your site to the security of the other site.

Example: Consider the following <script> tag.

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

If this tag appears on a web site other than www.example.com, then the site is dependent upon www.example.com to serve up correct and non-malicious code. If attackers can compromise www.example.com, then they can alter the contents of fancyWidget.js to subvert the security of the site. They could, for example, add code to fancyWidget.js to steal a user's confidential data.

• Ref: https://vulncat.hpefod.com/en/detail?id=desc.content.html.hardcoded_domain

Attack Mitigation

There are two ways to address this:

1. Move all scripts to your own domain. This way you are in control of the content of the scripts. This seems to be Fortify's recommendation.
2. Use the Subresource Integrity property for <script> and <link> tags as described by the Mozilla Foundation (MDN) below. This will also prevent browsers from executing remote scripts that have been modified.

Subresource Integrity (SRI) is a security feature that enables browsers to verify that files they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched file must match.

An example of the SRI integrity attribute is shown below and used by many CDNs.

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

Ideally, Fortify should support SRI as a valid mitigation technique, but if they don't, they will still flag these errors and you would need to manually check and give passes to any such warning that has been mitigated.

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

Best Option

The "Best" option depends on your requirements. Here are some thoughts:

• If you are running a commercial service and need your site to be operational and under your control, serving the files yourself may be the best option since you can control not only the security but also availability. Regarding availability, if you are using a remote site and the remote site becomes unavailable, then your site may no longer work properly. Even if you host the files yourself, you should still use SRI just in case your own files are compromised.
• If you are running a non-commercial or small commercial site, it may be okay to use a CDN with SRI as it would allow you to enforce security while not requiring you to host the files. The downside is that if the changes or disappears, your site may not work.

Answer 2

First, you could host the files on your own server and use relative paths.

If not viable, you will need some system to change the URLs for these dependencies dynamically, you could source them from environment variables, or a config file? The DB is not a bad source for that.

---

If you're going to include files from a CDN you should make use of subresource integrity to ensure the file is not loaded if it has been modified.

I suspect SCA will still flag those being on an external domain though, in which case, you can audit the vulnerabilities if you're not going to change from this approach.

Answer 3

In PHP MVC world, one of the ways to do this is through a library class with all external URI. Much easier to manage since you know where to look for a broken link. Also, it is a good practice to use '//' instead of http:// or 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];
  }
}

And to call it:

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

Answer 4

I usually by default host the files on the server itself and reference it like so:

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

It's very handy for if their site goes down or their SSL certificate becomes invalid. Some sites don't use versioning and having the copy locally on the server avoids newer versions breaking existing code or affecting its appearance. Adding it on the server locally also avoids the external version being replaced by a malicious version.