Лучший способ хранения доменных имен с жестким кодом в веб-приложении

Ответ 1

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

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

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

Аннотация

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

объяснение

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

Пример: рассмотрим следующий <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. Используйте свойство целостности подресурса для тегов <script> и <link> как описано в Mozilla Foundation (MDN) ниже. Это также не позволит браузерам выполнять удаленные сценарии, которые были изменены.

Subresource Integrity (SRI) - это функция безопасности, которая позволяет браузерам проверять, что файлы, которые они выбирают (например, из CDN), доставляются без неожиданных манипуляций. Он работает, позволяя вам предоставить криптографический хеш, которому должен соответствовать извлекаемый файл.

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

Ответ 2

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

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

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

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

Ответ 3

В мире 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 становится недействительным. Некоторые сайты не используют управление версиями и локальная копия на сервере исключает новые версии, нарушающие существующий код или влияющие на его внешний вид. Добавление на локальный сервер также позволяет избежать замены внешней версии вредоносной версией.