Проверка содержания веб-страницы на утечку информации

Резюме

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

Для современных веб-приложений использование JavaScript на стороне клиента становится все более популярным. Популярные технологии для фронтенда, такие как ReactJS, AngularJS или Vue, часто используют JavaScript на клиентской стороне. Подобно комментариям и метаданным в HTML-коде, многие разработчики также жестко кодируют конфиденциальную информацию в переменных JavaScript на фронтенде. К такой конфиденциальной информации могут относиться (но не ограничиваются): частные API-ключи (например, неограниченный API-ключ Google Maps), внутренние IP-адреса, чувствительные маршруты (например, маршруты к скрытым страницам администратора или функционалу) или даже учетные данные. Эта конфиденциальная информация может быть утечена из JavaScript-кода на фронтенде. Следует провести проверку, чтобы определить, есть ли какие-либо утечки конфиденциальной информации, которые могут быть использованы злоумышленниками.

Для больших веб-приложений проблемы производительности являются серьезной заботой для разработчиков. Разработчики используют различные методы для оптимизации производительности фронтенда, включая Syntactically Awesome Style Sheets (SASS), Sassy CSS (SCSS), webpack и др. Использование этих технологий иногда делает код фронтенда сложнее для понимания и труднее для отладки, поэтому разработчики часто размещают файлы карт источников для целей отладки. "Файл карты источника" — это специальный файл, который связывает минифицированную/углубленную версию ресурса (CSS или JavaScript) с оригинальной версией. Разработчики все еще спорят о том, следует ли размещать файлы карт источников в производственной среде. Однако несомненно, что файлы карт источников или файлы для отладки, если они размещены в производственной среде, сделают их исходный код более читаемым для человека. Это может упростить злоумышленникам поиск уязвимостей на фронтенде или сбор конфиденциальной информации из него. Следует провести проверку JavaScript-кода, чтобы определить, есть ли какие-либо файлы отладки, открытые с фронтенда. В зависимости от контекста и чувствительности проекта эксперт по безопасности должен решить, должны ли эти файлы существовать в производственной среде или нет.

Цели тестирования

Проверить комментарии и метаданные веб-страницы на наличие утечек информации.
Собрать файлы JavaScript и проверить код JS, чтобы лучше понять приложение и найти утечки информации.
Определить, существуют ли файлы карт источников или другие файлы отладки фронтенда.

Как тестировать

Проверка комментариев и метаданных веб-страницы
HTML-комментарии часто используются разработчиками для включения отладочной информации об приложении. Иногда они забывают удалить комментарии, оставляя их в производственной среде. Тестировщики должны искать HTML-комментарии, которые начинаются с <!--.

Проверьте исходный код HTML на наличие комментариев, содержащих конфиденциальную информацию, которая может помочь злоумышленнику лучше понять приложение. Это может быть SQL-код, имена пользователей и пароли, внутренние IP-адреса или отладочная информация.

<div class="table2">
  <div class="col1">1</div><div class="col2">Mary</div>
  <div class="col1">2</div><div class="col2">Peter</div>
  <div class="col1">3</div><div class="col2">Joe</div>

  <!-- Запрос: SELECT id, name FROM app.users WHERE active='1' -->

</div>

Тестировщик может даже найти что-то вроде этого:

<!-- Используйте пароль администратора БД для тестирования: f@keP@a$$w0rD -->

Проверка информации о версии HTML на предмет действительных номеров версий и URL-адресов DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

strict.dtd — стандартный строгий DTD
loose.dtd — нестрогий DTD
frameset.dtd — DTD для документов с фреймами

Некоторые мета-теги не предоставляют активных векторов атак, а позволяют злоумышленнику профилировать приложение:

<META name="Author" content="Andrew Muller">

Распространенным (но не соответствующим стандартам WCAG) мета-тегом является Refresh.

<META http-equiv="Refresh" content="15;URL=https://www.owasp.org/index.html">

Распространенное использование мета-тега — указание ключевых слов, которые поисковая система может использовать для улучшения качества результатов поиска.

<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">

Хотя большинство веб-серверов управляют индексацией поисковых систем через файл robots.txt, это также можно управлять с помощью мета-тегов. Тег ниже будет советовать роботам не индексировать и не следовать ссылкам на HTML-странице, содержащей тег.

<META name="robots" content="none">

Платформа для выбора контента в Интернете (PICS) и Протокол ресурсов описания веба (POWDER) предоставляют инфраструктуру для ассоциации метаданных с интернет-контентом.

Идентификация JavaScript-кода и сбор файлов JavaScript

Разработчики часто жестко кодируют конфиденциальную информацию с помощью переменных JavaScript на фронтенде. Тестировщики должны проверять исходный код HTML и искать JavaScript-код между тегами <script> и </script>. Тестировщики также должны идентифицировать внешние файлы JavaScript, чтобы проверить код (файлы JavaScript имеют расширение .js, и имя файла JavaScript обычно указано в атрибуте src тега <script>).

Проверьте JavaScript-код на наличие утечек конфиденциальной информации, которые могут быть использованы злоумышленниками для дальнейших злоупотреблений или манипуляций с системой. Ищите значения, такие как: API-ключи, внутренние IP-адреса, чувствительные маршруты или учетные данные. Например:

const myS3Credentials = {
  accessKeyId: config('AWSS3AccessKeyID'),
  secretAccessKey: config('AWSS3SecretAccessKey'),
};

Тестировщик может даже найти что-то вроде этого:

var conString = "tcp://postgres:1234@localhost/postgres";

Когда обнаруживается API-ключ, тестировщики могут проверить, настроены ли ограничения API-ключа для каждой службы или по IP, HTTP-рефереру, приложению, SDK и т. д.

Например, если тестировщики обнаружили API-ключ Google Maps, они могут проверить, ограничен ли этот API-ключ по IP или только по API Google Maps. Если API-ключ Google ограничен только по API Google Maps, злоумышленники все равно могут использовать этот API-ключ для запросов к неограниченным API Google Maps, и владельцу приложения придется за это платить.

<script type="application/json">
...
{"GOOGLE_MAP_API_KEY":"AIzaSyDUEBnKgwiqMNpDplT6ozE4Z0XxuAbqDi4", "RECAPTCHA_KEY":"6LcPscEUiAAAAHOwwM3fGvIx9rsPYUq62uRhGjJ0"}
...
</script>

В некоторых случаях тестировщики могут обнаружить чувствительные маршруты в JavaScript-коде, такие как ссылки на внутренние или скрытые страницы администратора.

<script type="application/json">
...
"runtimeConfig":{"BASE_URL_VOUCHER_API":"https://staging-voucher.victim.net/api", "BASE_BACKOFFICE_API":"https://10.10.10.2/api", "ADMIN_PAGE":"/hidden_administrator"}
...
</script>

Идентификация файлов карт источников

Файлы карт источников обычно загружаются при открытии DevTools. Тестировщики также могут найти файлы карт источников, добавляя расширение ".map" после расширения каждого внешнего файла JavaScript. Например, если тестировщик видит файл /static/js/main.chunk.js, он может проверить его файл карты источника, посетив /static/js/main.chunk.js.map.

Тестирование без черного ящика
Проверьте файлы карт источников на наличие конфиденциальной информации, которая может помочь злоумышленнику получить больше информации об приложении. Например:

{
  "version": 3,
  "file": "static/js/main.chunk.js",
  "sources": [
    "static/js/Component.js"
  ],
  "names": [
    "render",
    "login",
    "view",
    "signOut"
  ],
  "mappings": "AAAA;EAEa,CAAC,GAAX,CAAC;AAWZ"
}

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

Пример и результат

После тестирования приложения http://localhost:3000 тестировщик нашел конфиденциальную информацию, включая:

HTML-комментарии
JavaScript-код с API-ключами и внутренними адресами
Открытые файлы карт источников