• Всё равно большинство актуальных задач сводится к проблеме останова МТ или P=NP, расходимся • Тогда зачем? – обсудить актуальные нерешенные практические задачи в вебе • Warning для практиков: используется сочетание “методически решенная задача” • Не будет слайда с Боромиром
разработки – черным ящиком – в исходном коде • Технологии защиты веб-‐приложений от атак на эти недостатки • Out of scope: – технологии поиска или недопущения недостатков внедрения и эксплуатации – технологии защиты от атак на эти недостатки
популярен принцип safe by default – ORM, HTML через объектные модели, защита от CSRF на уровне фреймворка, даже XXE того • Повышается уровень абстракции API – Vaadin и GWT на сервере и Angular.JS на клиенте • Тенденция к исчезновению типичных недостатков в новом коде • Описанные задачи в старом коде научились решать (методически) сравнительно неплохо – Trinity: статические анализаторы, black-‐box сканеры и WAF • Но только не для applica…on specific недостатков
valida…on – в общем случае -‐ некорректное использование API внешних подсистем – порождают класс injec…on-‐атак – injec…on-‐атаки порождают в запросах структурные (синтаксические) аномалии • Applica…on-‐specific -‐ это логика – в общем случае API -‐ собственное; правила использования есть только в голове авторов – порождают класс атак на логику (abuse/misuse/hijacking и т.п.) – в запросах нет структурных аномалий
• Нарушение целостности процесса – процедуры checkout’ов • Некорректное использование криптографических примитивов – купоны и прочие тикеты • Ошибки интеграции aka неверные допущения о границах доверия – интернет-‐магазины, платежные системы, OAuth туда же • Вменяемой типизации и классификации нет
– боль для нестрого типизированных языков – боль связывать представления через хранилища • Получить возможные значения переменных в каждой точке – наследование, интерфейсы, reflec…on
– используемая модель -‐ модель невмешательства имени Деннинг – данные из недоверенного канала попадают в канал с высоким уровнем доверия • Как классифицировать каналы? – по имени вызовов API – по маркерным значениям в множестве возможных значений переменной • Типичные vs applica…on specific – API заранее неизвестно, маркеры тоже непонятно какие
Сrawling классических приложений – разбор HTML, заполнение форм, вызов обработчиков • Сrawling SPA (GWT, Vaadin) – h“p://dashboard.demo.vaadin.com/, Google AdWords – динамический анализ JS и состояния DOM • Проблема – экспоненциальное кол-‐во последовательностей взаимодействия для полного обхода интерфейса
элементов UI и способы их активации? • Обработчики событий могут добавляться/удаляться динамически • Код может генерироваться динамически или приходить с сервера • Обработка событий – делегированная обработка – фазы перехвата и всплытия – возможность остановки распространения
действия в UI -‐ полезные? – как понять, что мы изменили интерфейс и перешли в новое состояние? • Что входит в состояние? – состояние DOM? содержимое localStorage? URI? глобальные переменные? состояние таймеров? • Как сравнивать состояния между собой? • По какой стратегии переходить в новые состояния? – на странице AdWords 132 обработчика, и только 15% из них повторяющиеся • Как возвращаться в предыдущие состояния?
– таймеры – ожидание конца начальной загрузки – асинхронные запросы • Сrawljax работает очень плохо, остальные -‐ еще хуже • Итого, основная проблема: – для полного обхода надо вызывать все возможные комбинации UI-‐элементов на всех страницах • НО: – в любой момент могут появиться новые обработчики (в т.ч. на посещенных страницах) – могут быть удалены еще не посещенные обработчики
– нет API для реализации бизнес-‐логики => нет сигнатур для стат анализатора на основе последовательности вызовов API • Как ловить атаки, не вызывающие структурные аномалии в запросах/ответах? – нет структурных аномалий в запросах => нет сигнатур на основе синтаксиса • Как построить модель анализируемого SPA приложения? – черным ящиком со стороны клиента – на уровне промежуточного фильтра (WAF) – из исходного кода • Актуальные задачи: динамический анализ JS+DOM и майнинг инвариантов поведения из трафика
owaspmoscow
smt7174
_hashimo2
fujiwara3
hiroramos4
abenben
ahus1
pocke
naoto33
.jpg){kind=avatar}
ikuodanaka
kaz29
tomokusaba
mmmatsuda
holman
rmw
garrettdimon
chriscoyier
chrislema
destraynor
tammyeverts
mraible
lemiorhan
malarkey
eileencodes
