Применение механизмов пассивной защиты от уязвимостей при разработке интернет ресурсов с использованием современных фреймворков

Аннотация. В статье рассматриваются 5 основных уязвимостей сети, выявленных в рамках проекта Open Web Applicaton Security Project.

Ключевые слова: безопасность, информация, веб-приложения, уязвимости

Введение

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

Распространенная ошибка веб-безопасности # 1: недостатки при внедрении

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

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

Например, в системе с 1000 входами успешной фильтрации 999 из них недостаточно, поскольку это все еще оставляет одно поле, которое может служить лечением Ахилла для разрушения вашей системы. И вы можете подумать, что поместить результат запроса SQL в другой запрос - это хорошая идея, так как база данных является доверенной, но если периметр отсутствует, входные данные поступают косвенно от парней с недоброжелательностью. Это называется SQL-инъекцией второго порядка, если вам это интересно.

Распространенная ошибка веб-безопасности # 2: сломанная аутентификация

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

Возможные ловушки:

1. URL-адрес может содержать идентификатор сеанса и передавать его в заголовке реферера кому-либо еще.
2. Пароли не могут быть зашифрованы ни при хранении, ни при передаче.
3. Идентификаторы сеанса могут быть предсказуемыми, поэтому получение доступа является тривиальным.
4. Фиксация сессии может быть возможной.
5. Перехват сеанса может быть возможен, таймауты не реализованы правильно или используется HTTP (без защиты SSL) и т.д.

Защита. Самый простой способ избежать этой уязвимости веб-безопасности - это использование инфраструктуры. Возможно, вы сможете реализовать это правильно, но первое гораздо проще. Если вы хотите развернуть свой собственный код, будьте предельно параноидальны и узнайте, в чем заключаются подводные камни.

Распространенная ошибка веб-безопасности # 3: межсайтовый скриптинг (XSS)

Это довольно распространенный сбой очистки входных данных (по сути, частный случай распространенной ошибки #1). Злоумышленник предоставляет вашему веб-приложению теги JavaScript на входе. Когда этот ввод возвращается пользователю без санитарии, браузер пользователя выполнит его. Это может быть так же просто, как создать ссылку и убедить пользователя нажать на нее, или это может быть что-то гораздо более зловещее. При загрузке страницы скрипт запускается и, например, может использоваться для отправки ваших куки-файлов злоумышленнику.

Защита. Существует простое решение для веб-безопасности: не возвращайте теги HTML клиенту. Это дает дополнительное преимущество защиты от внедрения HTML, аналогичная атака, при которой злоумышленник вводит простой HTML-контент (например, изображения или громкие невидимые флэш-плееры) - не сильный, но, безусловно, раздражающий («пожалуйста, остановите!»). Обычно обходной путь заключается в простом преобразовании всех сущностей HTML, поэтому <script> возвращается как & lt; script & gt ;. Другой часто используемый метод очистки - использование регулярных выражений для удаления тегов HTML с использованием регулярных выражений на <и>, но это опасно, так как многие браузеры прекрасно интерпретируют сильно нарушенный HTML. Лучше конвертировать всех персонажей в своих сбежавших собратьев.

Распространенная ошибка веб-безопасности # 4: небезопасные прямые ссылки на объекты.

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

Например, в коде имеется модуль download.php, который читает и позволяет пользователю загружать файлы, используя параметр CGI для указания имени файла (например, download.php? File = кое-что.txt). По ошибке или из-за лени разработчик пропустил авторизацию в коде. Теперь злоумышленник может использовать это для загрузки любых системных файлов, к которым у пользователя, работающего с PHP, есть доступ, например, сам код приложения или другие данные, оставленные на сервере, например, резервные копии. Ой-ой.

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

Распространенная ошибка веб-безопасности # 5: отсутствует контроль доступа на уровне функций

Это просто ошибка авторизации, которая означает, что при вызове функции на сервере надлежащая авторизация не была выполнена. Часто разработчики полагаются на тот факт, что серверная часть генерирует пользовательский интерфейс, и считают, что клиент не может получить доступ к функциям, которые не предоставляются сервером. Это не так просто, поскольку злоумышленник всегда может подделать запросы к «скрытой» функциональности и не будет сдерживаться тем фактом, что пользовательский интерфейс не делает эту функцию легко доступной. Представьте, что есть панель / admin, и кнопка присутствует в пользовательском интерфейсе, только если пользователь действительно является администратором. Ничто не мешает злоумышленнику обнаружить эту функцию и использовать ее, если авторизация отсутствует.

Защита. На стороне сервера авторизация всегда должна быть сделана. Да всегда. Никакие исключения или уязвимости не приведут к серьезным проблемам.

Заключение

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