Главная > Uncategorized > Безопасность — как фактор качества веб-приложений

Безопасность — как фактор качества веб-приложений

Этот пост меня побудило написать недавнее выполнение оценки безопасности одного веб-проекта.
Случилась ситуация ровно, как было описано в примере (см. первое примечание): в исходном коде содержался SELECT, в который попадал параметр из HTTP-запроса без обработки. Однако, в результате анализа окружения, в котором работало веб-приложение, стало ясно, что в исходном коде найдена не уязвимость, а всего лишь недостаток. Тем не менее, я его поместил в итоговый отчет. Реакция разработчиков была, как в шутке :)

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

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

Теперь вернемся к вопросу о недостатке с SELECT’ом из начала поста. Есть насущный вопрос: в каком случае запись о таких недостатках должна включаться в итоговые отчеты?
Очевидно, что при анализе кода с целью проверки его качества — должна. А что насчет мероприятий по оценке безопасности?
По этому поводу есть два мнения. Первое мнение, что если недостаток не является уязвимостью, то его описание и не должно попадать в итоговый отчет. Второе мнение, что такие вещи обязательно должны попадать в итоговые отчеты. Я — горячий сторонник второго мнения, вот мои аргументы:

1. Вспомним, что цель оценки безопасности веб-приложения — определение рисков, связанных с его использованием. Всем известна классификация уязвимостей по этапу их появления в ПО: уязвимости проектирования, уязвимости реализации и уязвимости эксплуатации. Риск, связанный с использованием веб-приложения, может быть следствием любой из уязвимостей. Но что самое интересное (и главное) — это то, что некачественный программный код сейчас может стать причиной появления уязвимостей потом, в один из моментов этапа эксплуатации. Следовательно, некачественный программный код может стать источником рисков.
Примеры нежелательных сценариев:
— Переиспользование некачественного кода. В новом месте недостатки могут стать уже уязвимостями.
— Запуск в другом окружении, с другой конфигурацией. Например, с использованием учетной записи sa (администратор в MSSQL) для подключения к СУБД.
— Продажа или передача исходного кода третьей стороне, которая в результате его анализа увидит его недостатки.

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

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

Кто что думает? Хотел бы выслушать ваши аргументы.

Реклама
  1. 25.05.2010 в 19:48

    «в исходном коде содержался SELECT, в который попадал параметр из HTTP-запроса без обработки. Однако, в результате анализа окружения, в котором работало веб-приложение, стало ясно, что в исходном коде найдена не уязвимость, а всего лишь недостаток. »

    Если рассматривать безопасность конкретного сайта — это потенциальная уязвимость. Потенциал копится ровно до тех пор, пока администратор, или кто-то еще не поменяет то самое «окружение», анализ которого проводился.

    Если рассматривать веб-приложение, то это, безусловно уязвимость. Так как веб-приложение написано для широко спектра «окружений» и в некоторых из них уязвимо.

    В общем, я уже писал о том что требуется различать понятия «безопасность системы управления сайтом» и «безопасность сайта» вот это как раз из той оперы.

    • 25.05.2010 в 20:04

      Ну да, идея поста как раз донести, что наличие некачественного кода (даже без анализа окружения с целью разделения всех находок на недостатки и уязвимости) является потенциальным риском и должно документироваться.
      Хочется особо отметить, что для приведенного примера с SQL аргументов в пользу нашего мнения есть куча. А вот как насчет кода, где возможно разыменование нулевого указателя? Вот там противников нашего мнения уже становится больше :)

  1. No trackbacks yet.

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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