Ошибки и их регистрация

Все ошибки следует отлавливать и корректно обрабатывать. На экране не должны отображаться трассировки стека или ошибки базы данных. Эти требования необходимы не только для того, чтобы приложение выглядело профессионально, а у пользователей остались приятные впечатления от работы с ним, но и для того, чтобы злоумышленники не получили дополнительную информацию, которой они могли бы воспользоваться для выполнения своих атак. При возникновении ошибок приложение ни в коем случае не должно переходить в неизвестное состояние. Оно должно откатить все выполненные операции и «закрыть» все, что было открыто (то есть выполнить «аварийное завершение работы»). Такие ситуации всегда следует регистрировать, чтобы в случае необходимости специалистам по реагированию на инциденты было с чем работать при расследовании, а аудиторы могли убедиться в корректной работоспособности системы.

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

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

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

События, которые могут вызвать предупреждение о нарушении безопасности, включают в себя переход в неизвестное состояние, отказ в доступе к функции или документу, попытку обхода рабочего процесса, превышение квоты использования (например, людям не свойственно пытаться войти в систему 10 раз за минуту или 100 раз за час), аварийное завершение работы приложения, использование пользователем определенного (большого) объема трафика, оперативной памяти или ресурсов процессора, вызовы заблокированных HTTP-глаголов и т. д. Решение о том, что подходит для вашей организации и вашего приложения, должно быть принято совместно с бизнес-аналитиками и командой безопасности.

СОВЕТ. Дополнительную информацию о возможных оповещениях и регистрировании можно посмотреть на сайте cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html.

Проверка и санитизация вводимых значений

JavaScript является особым типом языка программирования, потому что он работает в браузере, обычно называемом «стороной клиента», поскольку люди (клиенты), использующие веб-приложения, получают к ним доступ с помощью браузера, который находится на их компьютере, а не на серверах. Все остальные языки программирования работают на стороне сервера: на веб-сервере, PaaS («платформе как услуге» от облачного провайдера) или контейнере (подробнее о контейнерах позже).

Когда в веб-приложении используется веб-прокси, то он размещает себя после выполнения JavaScript-приложения, но до того, как запрос будет отправлен по сети на веб-сервер. Тот, кто использует веб-прокси, может легко изменить HTTP-запрос до того, как он покинет компьютер, и таким образом обойти любую проверку ввода или санитизацию, записанную в JavaScript. Из рис. 2.4 становится ясно, почему проверка безопасности или санитизация должны выполняться на стороне сервера: слишком легко обойти защиту безопасности в JavaScript.

Рис. 2.4. Как прокси-сервер перехватывает веб-трафик

Второе, что необходимо обеспечить при формировании проверки, – это «список разрешенного» или «список одобренного» (белый список) вместо «списка блокировки» (черного списка). Злоумышленники и тестировщики на проникновения показали, что они способны регулярно обходить списки блокировки с относительной легкостью, творчески используя незаблокированные опции ввода. Количество различных способов, которыми кто-то может ввести одинарную кавычку (символ, наиболее часто используемый в атаках внедрения SQL-кода) в поле ввода, просто поражает воображение. Вместо того чтобы пытаться блокировать длинный список различных типов атак, можно составить список разрешенных элементов. «Белый список» пишется с помощью регулярных выражений (regex), и все, что им не соответствует, будет запрещено. Например, если вы хотите разрешить ввод только a – z и A – Z для имени пользователя, можно употребить следующее выражение: ^[a-zA-Z]{1,10}$.

ВНИМАНИЕ. Regex иногда становится объектом атак типа «отказ в обслуживании» (DoS), поскольку его выполнение требует больших ресурсов. Поэтому приложение должно предупреждать о многократном вызове данной функции.