Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis...
Методические отличия при анализе кода внутренних и внешних приложений
1. Методические отличия при анализе кода
внутренних и внешних приложений
CISO Forum 2013
Петухов Андрей
Thursday, July 18,
2. • Основополагающий принцип при построении
системы защиты
• Подходы к реализации:
➡ наименьшие привилегии и разграничение доступа
➡ резервирование и архивное копирование
➡ реализация системы мониторинга и реагирования
• Подходы реализуются на различных уровнях ИС
➡ сетевой, системный (узловой), прикладной, физический и т.п.
Принцип ограниченности ущерба
Thursday, July 18,
3. • Для управления угрозами, исходящими от обычных
пользователей отлично годятся все три подхода
• Как насчет пользователей с высоким уровнем
технического допуска?
➡ “How to Grant Administrator Authority without Losing Control over System?” (с)
➡ “How to Grant Developer Authority without Losing Trust into System?” (с)
• Начнем с администраторов; в целом, все известно:
➡ Least privilege & monitoring [& ITSM]
• Продолжим про разработчиков
➡ Secure SDLC способно побороться с преднамеренным и непреднамеренным
внесением недостатков
➡ А если SDLC нет и не предвидится?
“For whom how” (c)
Thursday, July 18,
4. • SDLC нет и не предвидится
➡ дорого и/или долго и/или нецелесообразно
➡ вся основная разработка давно завершилась
➡ почти вся разработка - это расширение существующих функций в уже внедренных
приложениях, добавление новых и исправление ошибок
➡ принимается приложение, разработанное на стороне, при заказе которого не
предъявлялись требования к безопасности
• Как методически решать задачу организации
мониторинга за действиями разработчиков?
• По идее, комплекс мониторинга должен включать:
➡ анализ исходного состояния приложения
➡ фиксирование и анализ изменений
➡ мониторинг взаимодействия пользователей с приложением
➡ протоколирование работы приложения
Проблематика
Thursday, July 18,
5. • Есть приложения, основанные на веб-технологиях,
которые почти не отличаются от открытых в WWW
• Есть и другие,“особенные”:
➡ толстые клиенты вместо веб-интерфейса, возможно свой протокол обмена данными
➡ используются DSL (LotusScript) и прочие нетипичные сейчас языки (Cobol)
➡ могут быть расширениями огромной платформы (1С, SAP, Lotus и т.п.)
• Особенности
➡ высокая критичность
➡ большое количество связей в другими системами
Специфика внутренних приложений
Thursday, July 18,
6. • Высокая критичность => сканирование запрещено
• Много связей с другими системами => развернуть в лаборатории для
динамического анализа нереально
• Что остается из методов?
➡ ручной black-box анализ
➡ статический анализ (ручной или автоматический)
• Толстые клиенты => XSS нерелевантно
• DSL-языки => SQLi и прочие “классические” атаки могут быть
неосуществимы
• Что остается из релевантных недостатков?
➡ application specific недостатки: уязвимости авторизации, уязвимости логики
➡ бекдоры, закладки, логические бомбы
➡ некорректная конфигурация платформы, сервера и приложения
Выводы из свойств
Thursday, July 18,
7. • Доступ к приложению: onsite vsVPN
➡ VPN может быть запрещен политиками; но onsite будет дороже
• Какие уязвимости можно найти
➡ если внутренне приложение - веб-приложение: все типичные уязвимости веб-
приложений, позволяющие проводить Injection-атаки (XSS, SQLi, и т.п.)
➡ если внутреннее приложение “особенное”: некоторые классы уязвимостей
авторизации и логики, уязвимости конфигрурирования
➡ важно: для полноценного black-box анализа потребуется доступ от имени
пользователей различных ролей, в т.ч. привилегированных (!), что не всегда
возможно (см. политики организации)
Ручной black-box анализ
Thursday, July 18,
8. • Доступ к коду: onsite vs передача
➡ передача может быть запрещена политиками; но onsite будет дороже
• Автоматический анализ способен найти только типичные недостатки
(SQLi/XSS и т.п.)
• Для DSL и других нераспространненых языков не всегда найдется
анализатор
• App specific недостатки можно найти с приемлемой полнотой только
вручную
• Для “особенных” приложений самыми актуальными являются
следующие классы недостатков:
➡ уязвимости авторизации
➡ некорректное использование API платформы
➡ контуры для удаленной отладки и мониторинга
Статический анализ
Thursday, July 18,
9. • Внутренние веб-приложения приемлемо анализировать методом черного
ящика на начальном этапе (см. быстро и дешево найти “тупые”
уязвимости)
➡ этот подход не так хорошо работает для “особенных” приложений (DSL/толстые
клиенты)
• Недостатки некоторых классов можно найти только статически и только
вручную
➡ это решит задачу анализа исходного состояния, как построить систему мониторинга
(см. еженедельные обновления в коде)?
• Статический анализ по сигнатурам, написанным в результате ручного
анализа, сможет обеспечить мониторинг изменений в коде
• Offtopic: Injection-атаки во внутренней сети очень шумные => мониторинг!
Выводы
Thursday, July 18,
10. • Контакты
➡ Twitter: @p3tand
➡ Mob: +7 916 360-52-49
➡ Email: petand@seclab.cs.msu.su
➡ Blog: http://andrepetukhov.wordpress.com/
Ответы на вопросы
Thursday, July 18,