Итак, позволю себе потихоньку
начатьАвтор: kochetkov.vladimir
Дата: 08.01.10
со введения (ибо без него — никак)
Мне нравится этот девиз, именно поэтому он заменил собой уже примелькавшееся слово "дисклеймер", а также потому, что он будет являться редлайном всего, что планируется здесь опубликовать. Хочу подчеркнуть, что цель данных публикаций — научить разработчиков защищаться, а не нападать. Поэтому, не будьте злыми, используйте полученные знания только в рамках принадлежащих вам проектов и систем, либо в которых вы принимаете непосредственное участие, с согласия их владельцев.
Для начала, предлагаю расставить точки над i относительно того, ЧТО здесь будет публиковаться, КАК, ЗАЧЕМ и КОГДА:
1. Что?
Постепенное раскрытие информации о мерах, предпринимаемых командой RSDN для усиления безопасности как данного ресурса, так и его пользователей (в рамках их сессий на данном ресурсе, разумеется).
2. Как?
Серией постов в этом топике, в формате, весьма близком к т.н. tutorials. Объясню, почему не статьи: к статьям предъявляются гораздно более жесткие требования по части оформления и содержания, а следовательно, на их подготовку уйдет больше времени и усилий, а следовательно, меньше времени и усилий получится потратить на, собственно, процесс. Т.к. процесс важнее, то предпочтительнее, на мой вгзляд, публикация постов в режиме online и живой диалог с их читателями, с возможной публикацией в будущем серии статей, основанных на этой теме с учетом высказанных тут пожеланий и заданных вопросов.
Кроме того, у меня пока еще нет опыта в подготовки настоящих, серьезных статей, и хочется сначала сделать дело, а уже потом пытаться завернуть это в красивую упаковку
3. Зачем
Целей две:
1. Сведение к минимуму рисков реализации информационных угроз как в отношении инфраструктуры ресурса, так и в отношении его пользователей.
2. Повышение осведомленности местного сообщества в вопросах обеспечения информационной безопасности на различных стадиях разработки, внедрения и эксплуатации информационных систем, через наглядные и живые примеры реализации тех или иных подходов и методик.
4. Когда?
Дабы не достичь эффекта, обратного озвученной в предыдущем пункте цели №1, информация будет публиковаться по мере того, как будут полностью устраняться выявленные угрозы. Этим, в частности, будут обусловлены значительные перерывы между публикациями, просьба отнестись к этому с пониманием. Со своей стороны, постараюсь выкладывать новые материалы не реже раза в неделю, но это не всегда будет зависеть только от меня.
Планируемая продолжительность первой итерации этого процесса колеблется в пределах 2-3 месяцев, что при традиционном умножении на e и pi дает нам сроки приблизительно в 6-9 месяцев соответственно. От них и будем отталкиваться
и еще одно:
5. Где?
Здесь, а не в "Веб-программировании" или "Обсуждении сайта", потому что речь пойдет не только о веб-приложениях (и не только о .NET-приложениях — см. ниже), а большинство подходов, методик, инструментов, уязвимостей и т.п. вполне применимы не только к вебу и rsdn.ru, но и к любому другому проекту, следовательно — это ontopic для ФП.
Забегая вперед (т.к. не проведя предварительный анализ исследуемого ресурса, мы не можем строить какие-либо планы по конкретным действиям с нашей стороны), озвучу
приблизительный roadmap первой итерации:
#1. Собственно, проведем анализ инфраструктуры этого ресурса, чтобы аргументированно построить данный roadmap Узнаем как планировать меры по насаждению ИБ в проектах и какие подходы и методики мы можем при этом использовать.
#2. Проведем blackbox-тестирование библиотеки Rsdn.Framework.Formatting, в ходе которого построим и успешно испытаем свой собственный XSS-фаззер. Затем перейдем к проведению ревью безопасности кода этой библиотеки, после чего, самостоятельно закроем все найденные в ней уязвимости и выработаем рекомендации по дальнейшей безопасной разработке этого проекта. Кроме того, оставим после себя тяжелое наследие в виде unit-тестов, как-никак, но обеспечивающих снижение в будущем вероятности появления в библиотеке XSS-уязвимостей.
#3. Проделаем то же самое для библиотеки BLToolkit. Поскольку, если ничего не поменялось с лета прошлого года (я уже занимался тестированием BLT в рамках внедрения системы, ее использовавшей), серьезных уязвимостей мы там не обнаружим, то у нас будет уникальная возможность на живом примере понять: "а что же теперь делать с ней дальше? можно ли считать ее безопасной? ('конечно же нельзя' — прим. автора)"
#4. Проделаем то же самое для оффлайн-клиента RSDN@Home aka Janus + научимся строить полноценные модели угроз, адекватно оценивать риски информационной безопасности в проектах с нетривиальной архитектурой и вырабатывать/внедрять контрмеры по их снижению.
#5. Проведем несколько, различных с т.з. зрения используемых подходов, тестов на проникновение (пентестов) в веб-приложения rsdn.ru
#6. Проведем пентесты в окружение rsdn.ru (веб-сервер, сервер БД, ОС сервера, сетевая инфраструктура)
#7(бонусный). Опыт, полученный при исследовании Janus'а перенесем на другой оффлайн-клиент: RSDN@Linux aka Avalon. Наглядно увидим, чем отличается тестирование безопасности нативного приложения, от практически аналогичного ему .NET-приложения
Описания всех уязвимостей, используемого инструментария и т.п. будут приводиться по мере необходимости там, где они будут упомянуты или непосредствено перед этим. В конце каждого поста будет указываться реальный текущий статус этого процесса.
Дополнения и пожелания приветствуются.
Текущий статус:
#1 — завершен, публикация оформляется.
#2 — тестирование и ревью завершены, идет устранение обнаруженных уязвимостей.
#остальные — еще не были начаты.