Почему выбор платформы имеет значение в безопасности веб-приложений

Одним из самых старых клише в области безопасности веб-приложений является то, что «не имеет значения, какую среду вы выберете, если знаете, что делаете». По мнению Ферруха Мавитуна (Ferruh Mavituna), директора компании “Netsparker” в индустрии веб-безопасности это понятие полностью неверно! Эта статья объясняет почему.

Хорошие разработчики всегда разрабатывают безопасные приложения.

Кто-то может попытаться написать безопасное веб-приложение, используя только Brainfuck и достаточно времени и усилий. Они могли бы реализовать свою собственную обработку сеансов и попытаться сделать ее максимально безопасной. Но это звучит смешно, правда? Когда мы говорим, что кто-то может реализовать свою собственную защиту CSRF в PHP, это звучит совершенно нормально, потому что это именно то, что все продолжают делать! Однако это все еще крайне неразумно. Точно так же безопасная реализация сеанса должна быть одной из обязанностей структуры. Разработчик не должен реализовывать безопасную реализацию защиты от CSRF.

Безопасность языка, безопасность фреймворка

Здесь нет идеальных рамок! У каждой популярной платформы есть уязвимости, и то же самое верно для всех популярных веб-приложений. Но некоторые приложения имеют лучшую репутацию в области безопасности, чем другие, и то же самое относится и к фреймворкам. Внедрение выражений OGNL в Apache Struts, различные уязвимости низкого уровня в PHP и серьезные недостатки Perl являются хорошими примерами этих уязвимостей.
PHP прекрасно иллюстрирует это. Сам язык имеет очень много уязвимостей, таких как уязвимость Zend_Hash_Del_Key_Or_Index или перечень ошибок в PHP. Даже если разработчик знал, как обходить бесчисленные ловушки PHP, приложение все равно будет уязвимо, если в самом PHP будет уязвимость. Это без упоминания об ужасных проблемах дизайна, таких как жонглирование типов PHP или внедрение объектов PHP.
Если вы установили каталог как защищенный, и если ваша платформа не может защитить вас, потому что злоумышленник использовал другой метод HTTP, то это не ошибка разработчика, а ошибка платформы. Вот почему фреймворки имеют значение, потому что даже если вы создаете самое безопасное приложение, когда ваша фреймворк уязвим, то ваше приложение соответственно также уязвимо.
Задайте себе эти вопросы о вашей структуре:

• Ваш фреймворк правильно обрабатывает символы Юникода?
• На функции неожиданно влияют нулевые байты?
• Выдает ли конфиденциальные данные, когда вы отправляете один специальный символ в куки?

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

Рамочные специфические проблемы

Вы не увидите много RFI (Remote File Inclusion) в приложениях ASP, потому что нет простого способа представить их там.Вы не увидите много проблем с выполнением кода (таких как eval ()) в приложениях ASP.NET, потому что нет простого способа сделать это.Однако в Classical ASP у вас есть эта проблема. В приложениях PHP даже preg_replace мог оценивать код с помощью модификатора / e. И да, эти проблемы проявляются в реальных приложениях, программное обеспечение форума PHPBB было уязвимо для этого недостатка. Как видите, специфические проблемы имеют значение.

Безопасный по умолчанию

Существуют фреймворки, которые подходят к дизайну определенных функций с точки зрения «безопасности по умолчанию». Например, в ASP.NET очень редко можно встретить проблемы с внедрением HTTP-заголовков (CRLF / HTTP Response Splitting). Это потому, что по умолчанию все связанные функции .NET будут отказываться принимать новые строки. Вы действительно должны пойти своим путем как разработчик, чтобы внедрить эту уязвимость. Однако вы будете удивлены, насколько изобретательны некоторые разработчики, когда дело доходит до внедрения уязвимостей. Непреодолимое стремление некоторых разработчиков представить уязвимости, которые ранее считались невозможными, - это то, что даже лучшая структура не может исправить. 
Сами разработчики фреймворков даже склонны к этому явлению. Лучший пример - магические цитаты в PHP. Безумное количество приложений было уязвимо из-за них, поэтому это привело к беспорядку. Этого не должно было быть в первую очередь, поэтому они в конце концов решили отказаться от него.

Встроенные функции безопасности

Предполагается, что каждый достойный разработчик знает, что развертывание вашей собственной криптографии - это глупо, но как-то нормально, что разработчики могут использовать собственную защиту CSRF, фильтр SQL-инъекций, библиотеку защиты XSS, например. Давайте разберемся с этим.
Вот вопросы, которые вы должны задать своей структуре:

• Поддерживает ли она параметризованные запросы SQL (подготовленные операторы)?
• Предоставляет ли она способ разделения данных и HTML и выполнения требуемой кодировки на основе местоположения вывода, чтобы предотвратить уязвимости межсайтового скриптинга?
• Обеспечивает ли это безопасную реализацию сеанса?
• Обеспечивает ли это безопасный механизм аутентификации?
• Обеспечивает ли это безопасный способ выполнения команд ОС? (разделяя параметры и исполняемый файл, чтобы избежать внедрения, как параметризованные SQL-запросы)
• Обеспечивает ли это безопасные варианты хранения? А функции нормализации пути?
• Это обеспечивает способ избежать инъекций заголовка письма?
• Есть ли какая-либо функция, которая может защищать от новых инъекций строки для записи безопасных журналов?
• Есть ли встроенная функция, которая будет применять белый список на входах?

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

Документация, культура и образец кода

Документация и культура вокруг фреймворка также очень важны. Взгляните на некоторые старые примеры Tomcat JSP и IIS 6 ASP. Невероятно, но все они имеют несколько серьезных уязвимостей. Очевидно, недостаточно писать уязвимые примеры приложений, их даже нужно автоматически развертывать во время установки, чтобы ваша среда могла быть уязвимой по умолчанию.
Например, во многих примерах в документации .NET используются параметризованные запросы SQL, что звучит замечательно, но в документации .NET содержится достаточно много других недостатков и ужасных фрагментов кода.
Многие поставщики имеют ужасную документацию и не предоставляют безопасные фрагменты кода.
Наконец, когда дело доходит до культуры, необходимо учитывать и другие факторы. Давайте возьмем Perl в качестве примера. Вы можете увидеть больше командных инъекций OS в приложениях Perl, чем, возможно, в любой другой среде - потому что так работают большинство Perl. Передайте его команде ОС, проанализируйте вывод и распечатайте его на экране. Это довольно редкая практика во многих других средах, но сообщество Perl, похоже, принимает это.

Требуемое время, усилия и знания для безопасного приложения

Все эти факторы влияют на время, усилия и знания в области безопасности, необходимые для разработки безопасного веб-приложения. Если инфраструктура обеспечивает встроенную безопасность для CSRF с одной строкой кода, это немедленно уменьшает сложность приложения и необходимое время для разработки и тестирования. Кроме того, разработчики не должны быть экспертами по безопасности для реализации такой проверки, которая облегчает начинающим писать безопасные приложения.
Или вы действительно думаете, что младший разработчик будет знать, что можно проводить атаки подделки межсайтовых запросов против веб-службы? Поверьте, они этого не делают! Им также не хватает знаний об истории безопасности приложений, таких как возможность выполнения кода JavaScript из CSS, что сделало бы их более осторожными, когда пользовательский ввод используется в таблицах стилей. Они не знают, что им нужно пометить куки как безопасные. Они не знают, что вы можете обойти многие хитрые средства защиты XSS с помощью свободно доступных инструментов, таких как BeEF. Они часто ничего не знают о безопасности, особенно когда дело касается крайних случаев. Многие разработчики могут никогда не знать и не понимать все эти проблемы. Вот почему выбранные фреймворки должны заботиться об этом материале.

Фреймворки имеют значение в безопасности веб-приложений

Будем честны. Там нет идеальной структуры и не будет в ближайшее время. Прямо сейчас, лучшее решение состоит в том, чтобы выбрать лучшую доступную структуру.

Фреймворки, с которыми я больше всего знаком, - это PHP, ASP и ASP.NET, откуда взяты мои примеры. Существует много других фреймворков, таких как Ruby on Rails или Struts, из которых вы можете наблюдать аналогичные преимущества или специфические для фреймворка проблемы