Сомнительные данные
В предыдущих главах мы обсудили различные типы пользовательского ввода и причины постоянного недоверия к нему. Теперь рассмотрим варианты, которые можно использовать как план работы с каждым типом ввода.
1. Получаемые из любого источника данные проверяются на соответствие ожиданиям (тип, размер, формат, источник) и «правильность». Под правильностью подразумевается, что данные являются приемлемыми в рамках бизнес-контекста. Только владелец компании и другие заинтересованные стороны могут решать, является ли ввод данных правильным.
A. Проверка выполняется на стороне сервера, а не внутри JavaScript или иным образом на стороне клиента.
B. Если ввод не соответствует установленным требованиям, необходимо отклонить его и выдать сообщение об ошибке, четко объясняющее пользователю, что от него ожидается (а не то, что он сделал неправильно).
Пример: формат номера социального страхования: 999 999 999.
Ввод любых символов, кроме цифр, должен быть отклонен.
Ввод слишком большого количества цифр должен быть отклонен.
Ввод недостаточного количества цифр должен быть отклонен.
Ввод специальных символов должен быть отклонен и зарегистрирован в журнале как потенциальная проблема безопасности.
C. В тех редких случаях, когда необходимо принимать специальные символы, они должны быть экранированы. Следует соблюдать крайнюю осторожность и по возможности использовать функцию в собственной среде программирования или специальный компонент стороннего производителя, например OWASP Java Encoder (github.com/OWASP/owasp-java-encoder). Писать свою функцию экранирования следует только в том случае, если в платформе она недоступна. При этом она должна быть тщательно и внимательно протестирована.
2. Если ввод вызывает какую-либо транзакцию (добавление, удаление, обновление, покупку и т. д.), следует удостовериться в том, что под его прикрытием не проводится CSRF-атака: необходимо проверить, был ли передан соответствующий токен, была ли заполнена капча или была ли произведена повторная аутентификация пользователя другим способом.
СОВЕТ. Межсайтовая подделка запросов (CSRF, от англ. Cross-Site Request Forgery) – атака, направленная на активные сессии пользователей, – подробно описана в главе 5.
3. Если ввод будет выводиться на экран, необходимо выполнять кодирование вывода, что подробно описано в главе 3. По возможности следует убедиться, что применяется соответствующий контекст кодирования вывода.
4. Если ввод будет использоваться для обращения к базе данных, следует использовать параметризованные запросы (которые в MS SQL Server называются хранимыми процедурами). Его ни в коем случае нельзя связывать с другим текстом и отправлять в базу данных как одну команду (иногда называется «встроенным SQL»). Следует поместить входные данные в соответствующие параметры и затем вызвать хранимую процедуру. Такой подход нейтрализует большинство инъекционных атак, связанных с базами данных.
5. Если пользовательский ввод направляет приложение на другой сайт, это называется перенаправлением или переадресацией. Обычно перенаправление или переадресация на непроверенные сайты считается небезопасным действием. При проверке ссылки понадобится список предварительно одобренных ссылок. Маловероятно, что целью приложения является перенаправление пользователей на небезопасные ссылки, и поэтому следует запретить приложению их использовать.
Если впредь вы будете следовать представленной блок-схеме для всех входных данных в ваших приложениях, то устраните очень большой процент потенциальных уязвимостей, включая (но не ограничиваясь) инъекциями, XSS, CSRF, повышением привилегий и многими типами уязвимостей бизнес-логики. На рис. 4.1 показана блок-схема проверки сомнительных данных.
Рис. 4.1. Блок-схема проверки ввода для сомнительных данных
HTTP-глаголы
Протокол HTTP – способ взаимодействия приложений через интернет – имеет несколько методов, которые обычно называют глаголами, поскольку большинство из них являются таковыми с лингвистической точки зрения. Они используются для выполнения действий на веб-сервере от имени приложения. Например, можно удалить что-то с помощью (как нетрудно догадаться) глагола DELETE. Глаголы применяются для общения с веб-приложением, расположенным на веб-сервере. Зачастую большинство разработчиков программного обеспечения, операторы и специалисты DevOps рассматривают только те глаголы, которые они используют, и забывают о неиспользуемых, а потому оставляют все глаголы активными на веб-сервере, независимо от степени их необходимости. Если все глаголы включены, но не применяются, это означает, что они вряд ли были должным образом протестированы и нет гарантий, что они не делают того, чего не должны делать. Иногда злоумышленники используют неправильный глагол, пытаясь получить информацию или выполнить действия (атаки), направленные против приложения или веб-сервера. В идеале любой неиспользуемый HTTP-глагол должен быть отключен или заблокирован на веб-сервере.
Большинство веб-приложений используют только GET, POST, OPTIONS и HEAD, то есть остальные HTTP-глаголы не требуются. Все неиспользуемые HTTP-глаголы должны быть отключены, чтобы уменьшить площадь атаки.
ВНИМАНИЕ. WEBDAV расширяет HTTP для включения еще большего количества методов, поэтому применять его в производстве следует, только если вы уверены в его необходимости и выполняете соответствующие инструкции по укреплению безопасности. По возможности избегайте использования WEBDAV.
Ниже приведен пример отключения этих глаголов на Apache Tomcat Web Server. Обратите внимание, что это всего лишь пример. Внесите в него необходимые изменения, чтобы он правильно сработал в ваших приложениях. (Источник: narayanatututorial.com/tutorial-blog/owasp/disable-dangerous-http-methods-apache-tomcat-server.)
<security-constraint>
<web-resource-collection>
<web-resource-name>All JSP direct access</web-resource-name>
<url-pattern>*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>DEBUG</http-method>
<http-method>HEAD</http-method>
<http-method>CATS</http-method>
<http-method>JEFF</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>MKCOL</http-method>
<http-method>LOCK</http-method>
</web-resource-collection>
<auth-constraint>
<description>
No Access
</description>
</auth-constraint>
</security-constraint>
