Trust Boundaries Identification на прикладі Architects.in.ua

Architects.in.ua дуже простий сайт, виявилось що розробниками написано лише 316 рядків коду. У той самий час сайт має достатньо коду щоб показати деякі проблеми з безпекою. Сьогодні не буде дірок які можна використовувати прямо не виходячи із браузера, сьогодні я хочу розповісти про вельми теоретичне - Trust Boundaries Identification (Кордони Довіри), і як за допомогою цих кордонів зробити додаток більш безпечним.

Це дуже вільна версія, в порівнянні з процесом, який пропонує Microsoft, будьте ласкаві, вважайте її як адаптовану для нашого приклада.

Декомпозиція

З точки зору моделювання небезпек(Threat Modeling), одна за перших активностей це віртуальна декомпозиція додатку на субсистеми.

В прикладі з Architects.in.ua, це може виглядати так. Користувач - це браузер користувача, середній чотирикутник - сам сайт, і декілька джерел даних у вигляді RSS Feedів.

Кордон Довіри (Trust Boundaries)

Така декомпозиція дозволяє вже на діаграмі бачити відносини між субситемами, і що найбільш важливе вже зараз розуміти які субсистеми можуть довіряти, а які ні. Наприклад в більшості випадків Користувач не довіряє сайтам (наприклад ActiveX недозволено). У той самий час більшість додатків довіряють своїм даним. На це є причини, наприклад дуже часто ці додатки спілкуються лише з базою даних, до якої дуже складно дістатися ззовні.

Поточна реалізація Architects.in.ua будує Кордон Довіри  так що сайт повністю довіряє фідам.

Наслідки

Проблема може виникнути якщо хоча б одне джерело даних буде скомпрометовано. В прикладі з Architects.in.ua це достатньо легко уявити, адже джерелом даних для них являється Live Spaces.

Далі припустимо що одне з джерел таки cкомпроментовано. Що це означає для нас? Тут вже залежить від того як джерело використовується. В Architects.in.ua  є декілька шляхів як цим скористатися.

По-перше, так само як і з попередніми уразливостями, це може використовуватись для DoS атак, дефейсу тощо. Але це не цікаво.

Набагато цікавіше те що інформація з джерела після невеличкого очищення (sanitation) просто передається на бік користувача! Тобто скомпрометувавши джерело, атакуючий за допомогою Architects.in.ua компрометує користувача!

Приклад коду який опікується очисткою інформації та опис як його обійти можна знайти в попередньому огляді (Шукати по RemoveTags).

Як протистояти

Що ж робити? По-перше виправити Кордон Довіри. Сайт повинен довіряти тільки собі. Це нам допоможе зробити переоцінку довіри до джерел.

Далі вже по ситуації, наприклад, в нашому випадку є два шляхи. Обидва прості. Перший це встановити рейтинг небезпеці, тут він буде достатньо невеликий, адже скомпрометувати Live Spaces достатньо складно, отже і довіра до джерела даних велика, а згодом на небезпеку з малим рейтингом можна і наплювати...

Схоже саме цей шлях і обрали розробники:

>> Про XSS не согласен, т.к. источники полностью контролируются, а значит не писать любителей подсунуть скрипт.

Другий шлях дещо складніший... все ж таки не довіряти інформації з джерела, і просто пропустити результати через щось на кшталт HttpUtility.HtmlEncode (або ще краще через Anti-Cross Site Scripting Library). Дуже складно?

Висновок

Я тут багато написав, і може скластися уява достатньо робити енкодінг результатів(Encode Output)…  Це не так, головне це реально бачити такі проблеми. Випадок з атакою за допомогою XPath дуже вдалий приклад коли всі знають про SQL Injection, а ось про XPath Injection..

Декілька посилань

Провідник від Microsoft - Threat Modeling Web Applications – відносно стисло і зрозуміло викладено процес;

Частина книги - Chapter 3 – Threat Modeling – детально викладено весь процес, без залежностей від вебу.

Пісемістична заміна для HttpUtility.HtmlEncode - Anti-Cross Site Scripting Library;

Якщо тема моделювання небезпек та Security Development Lifecycle взагалі для вас цікава, вітаю до коментарів, інакше я нічого писати не буду, бо ця тема мені здається досить нудною для викладання в блозі.