Главная > Uncategorized > Какая технология разработки веб-приложений самая безопасная?

Какая технология разработки веб-приложений самая безопасная?

Ко мне часто обращаются с вопросом: «какая технология разработки веб-приложений — самая безопасная?» Ответ следует неизменно один — та, для которой Вы найдете разработчиков с головой и прямыми руками. Согласны, что это ответ математика? Абсолютно правильный и абсолютно бесполезный. С другой стороны, каков вопрос, таков и ответ…

Давайте попробуем задаться правильным вопросом: «какая технология (и/или фреймворк) сделает разработку уязвимого приложения максимально затруднительным?» Речь тут, конечно, идет о трудностях привнесения технических уязвимостей, ведь никакой фреймворк не предотвратит внесение уязвимостей бизнес-логики.

Итак, какой же фреймворк будет мешать разработчикам привносить уязвимости? У этого фреймворка должны быть жесткие настройки безопасности по умолчанию, SQL-запросы должны быть реализованы исключительно через prepared statements, возникающие исключения должны ловиться фреймворком и не выдаваться в HTTP-ответ, должна быть встроенная поддержка anti-CSRF и т.д.

Вообще, есть два способа ответить на вопрос про самый «строгий» фреймворк:
1. Провести сравнительный анализ функциональности существующих фреймворков, их возможностей, настроек по умолчанию и т.д. Способ хороший, только он даст исключительно теоретическое представление о «безопасности» фреймворков. Дело в том, что из самого факта наличия в технологии некой функции обеспечения безопасности вовсе не следует, что её будут использовать.
2. Проанализировать статистику уязвимостей веб-приложений и скоррелировать её со статистикой использования фреймворков. Здесь у нас получится более «практическое» представление о том, каким уязвимостям больше подвержен конкретный фреймворк, а каким — меньше. Слабое место этого подхода — то, что мы имеем дело с обнаруженными уязвимостями. А в идеале мы бы хотели знать обо всех уязвимостях веб-приложений. То есть, если один из фреймворков затрудняет обнаружение уязвимостей (например, потому что краулер веб-сканера не справляется с навигацией по веб-приложению из-за AJAX, одноразовых ссылок, форм, CAPTCHей и т.д.), статистика будет заведомо перекошена.

На прошлой неделе компания WhiteHat Security выпустила первую версию отчета, в котором проведен анализ распределения уязвимостей веб-приложений по основным технологиям. Отчет можно скачать отсюда. Очень рекомендую ознакомиться и попробовать проинтерпретировать представленные там числа. Здесь же я приведу диаграмму Top уязвимостей по каждой технологии. Диаграмма взята из того самого отчета.
Распределение уязвимостей по технологиям разработки

Статистика считается следующим образом. Фиксируется класс уязвимостей, например XSS. Фиксируется технология — например, PHP. Вычисляется ΣPj / N, где Pj равно 1, если j-ое веб-приложение на PHP содержит хотя бы одну уязвимость XSS, и 0 в противном случае. N — общее количество веб-приложений на PHP.

В обсуждении с автором статистики, мы пришли к нескольким выводам относительно интерпретации результатов:
1. В качестве исходных предположений при интерпретации полезно выдвигать следующие:

  • Распределение «хороших», «средних» и «плохих» разработчиков — одинаковое для всех технологий. Действительно, трудно предположить, что под PHP программируют исключительно криворукие люди, а под Java — просветленные гуру.
  • Распределение классов уязвимостей в веб-приложении сильно зависит от времени создания данного приложения. Действительно, разработчики не будут реализовывать контр-меры против тех угроз, о которых они не слышали, или которые они не «уважают».
  • Разработчики со временем уходят от «голой» технологии к фреймворкам и CMSкам, которые, в свою очередь, постоянно совершенствуются.

2. В связи с этим, для полного осознания картины в отчете не хватает:

  • Срезов по времени для того, чтобы посмотреть на динамку изменения вероятностей для каждого класса уязвимостей в каждой конкретной технологии.
  • Срезов по CMSкам в технологиях Perl и PHP. Так как фреймворки даже внутри одной технологии очень неоднородные, то судить о защищенности самой технологии без такой информации очень затруднительно.

3. Тем не менее, в отчете ясно видно, что:

  • Для каждого класса уязвимостей есть технологии, которые защищены от него в большей или меньшей степени.
  • Панацеи, silver bullet, конечно, не существует.
  • Фреймворки и технологии с самыми безопасными значениями по умолчанию в заданном классе уязвимостей оказываются в выигрыше по сравнению с теми, которые дают волю вольную разработчикам.

Если у кого-то есть еще идеи по интерпретации этой статистики, мне будет очень интересно их выслушать…

Реклама
  1. Георгий
    18.05.2010 в 23:52

    Лично меня в данной статистике еще удивило отсутствие python, учитывая присутствие perl.

    • 19.05.2010 в 00:33

      Ну они явно сказали в отчете, что для других технологий (Питон, Рубин и т.д.) у них была нерепрезентативная выборка (по их мнению)

  2. 19.12.2010 в 02:56

    Статистика адовая…
    Что по ней можно сказать? Мне кажется, только то, что метод подсчета что-то показал ;)
    Причем это что-то равномерно распределено и не зависит от критерия, который назвали языком программирования…

    Это если отвлечься от всей безопасности и просто посмотреть на цифири.

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

    Как бы там ни было, не ясно главное — что хотели люди показать этой диграммой? Какую цель преследовали? Если просто написать абы что — у них получилось ;)

    По выводам, да простит меня автор:

    >>Для каждого класса уязвимостей есть технологии, которые защищены от него в большей или меньшей степени.

    Видно? А какая погрешность определены величин?

    >>Панацеи, silver bullet, конечно, не существует.

    это аксиома. Ее можно увидеть в любой диаграмме, будь она даже пустая

    >Фреймворки и технологии с самыми безопасными значениями по умолчанию в заданном классе уязвимостей оказываются в выигрыше по сравнению с теми, которые дают волю вольную разработчикам.

    Это видно из диаграммы??? Не понимаю ;(

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: