Лучший вариант для хранения жестко закодированных доменных имен в веб-приложении - PullRequest
0 голосов
/ 01 июня 2018

У меня есть веб-приложение, в котором я ссылаюсь на имена файлов с именами доменов.Где я могу добавить эти доменные имена и позвонить им.Когда я запускаю такие инструменты, как fortify, для проверки проблем безопасности и стандартов, я всегда предупреждаю меня не хранить жестко закодированные доменные имена.Что было бы лучшим вариантом, например, где я могу хранить и извлекать эти основные доменные имена из конца веб-приложения (не db)?

Я использую 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 голосов
/ 11 июня 2018

Я обычно по умолчанию размещаю файлы на самом сервере и ссылаюсь на него так:

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

Это очень удобно, если сайт отключается или сертификат SSL становится недействительным.Некоторые сайты не используют управление версиями, а наличие копии локально на сервере позволяет избежать появления новых версий, нарушающих существующий код или влияющих на его внешний вид.Локальное добавление его на сервер также позволяет избежать замены внешней версии вредоносной версией.

0 голосов
/ 07 июня 2018

В мире 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');
0 голосов
/ 09 июня 2018

При обработке предупреждений безопасности с помощью таких инструментов, как Fortify, важно понимать причину, стоящую за предупреждениями, чтобы правильно их смягчить.

Жестко закодированный домен в предупреждении HTML

В обосновании этого предупреждения «Жестко закодированный домен в HTML» компания Fortify ссылается на внешний домен, что ставит под угрозу безопасность вашего сайта, поскольку файл, на который вы ссылаетесь, может быть изменен.Следующее из "Укрепление таксономии: ошибки безопасности программного обеспечения":

Аннотация

Включение сценария из другого домена означает, что безопасность этой веб-страницызависит от безопасности другого домена.

Пояснение

Включение исполняемого контента с другого веб-сайта является рискованным предложением.Он связывает безопасность вашего сайта с безопасностью другого сайта.

Пример: рассмотрим следующий тег <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>, как описано в 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 на тот случай, если ваши собственные файлы будут скомпрометированы.
  • Если вы работаете с некоммерческим или небольшим коммерческим сайтом, то, возможно, можно использовать CDN сSRI, поскольку он позволит вам обеспечить безопасность, не требуя размещения файлов.
0 голосов
/ 06 июня 2018

Во-первых, вы можете разместить файлы на своем собственном сервере и использовать относительные пути.

Если это невозможно, вам понадобится система для динамического изменения URL-адресов для этих зависимостей, вы можете получить их из переменных средыили файл конфигурации?База данных не является плохим источником для этого.


Если вы собираетесь включать файлы из CDN, вы должны использовать целостность подресурса , чтобы гарантировать, что файл не загруженесли он был изменен.

Я подозреваю, что SCA по-прежнему будет отмечать тех, кто находится во внешнем домене, но в этом случае вы можете проверить уязвимости, если вы не собираетесь менять этот подход.

...