У цій статті піде мова про відомих вразливості OAuth. Читачі також дізнаються, як можна реалізувати безпечну і захищену авторизацію в веб-додатку.
OAuth - це надійний протокол, але його ступінь захищеності в значній мірі залежить від обізнаності веб-розробників при реалізації авторизації. Це робить дану тему надзвичайно важливою для фахівців у сфері інформаційної безпеки. Їм необхідно забезпечити високий рівень захисту облікових записів своїх користувачів. Настала пора познайомитися з ефективними практиками, які допоможуть знизити небезпеку поганої реалізації OAuth.
ВступПротокол OAuth 2.0 в даний час широко використовується в різних додатках. За допомогою нього стає доступним зручний призначений для користувача інтерфейс, легша аутентифікація і авторизація в порівнянні з традиційними методами введення імені користувача і пароля. При правильній і продуманої реалізації протокол OAuth буде більш безпечним, ніж традиційна авторизація, оскільки користувачам не потрібно ділитися своїми обліковими даними зі стороннім додатком для отримання доступу до певного ресурсу. Користувачі часто вважають за краще входити в систему за допомогою їх акаунтів Google, Facebook або LinkedIn замість того, щоб створювати новий обліковий запис кожного разу, коли потрібно зареєструватися на якомусь веб-сайті. Таким чином, протокол OAuth значно спрощує наше життя.
В цілому, популярних постачальників послуг OAuth дуже надійні. Вхід в систему за допомогою облікового запису Google або Facebook вселяє користувачам певне почуття безпеки, і це правильно. Протокол ретельно протестований фахівцями. Всі наявні уразливості завжди швидко виправляються командою розробників. Однак, варто зазначити, що відчуття повної безпеки може бути помилковим.
Постачальники послуг OAuth залишили розробникам додатків багато причин похвилюватися про безпеку своїх програм. Насправді, спочатку захищений сервіс OAuth, неправильно реалізований в процесі його установки, може стати легкою мішенню для зловмисників. Подібна недбалість призведе до крадіжки особистих даних користувачів.
Далі слід розглянути найбільш поширені уразливості, що зустрічаються в сторонніх додатках, що реалізують протокол OAuth для авторизації своїх користувачів. Потрібно пам'ятати, що сам протокол безпечний і надійний. Тільки після невірної реалізації він стає вразливим для атак хакерів.
Крадіжка токена OAuth за допомогою заголовка RefererКоли додаток запитує авторизацію від імені користувача у сервера OAuth, людина отримує код, який слід ввести і відправити назад на сервер для його подальшої перевірки. Якщо в процесі роботи користувач буде перенаправлений на іншу сторінку, то код буде видно в заголовку «Referer» HTTP-запиту. Таким чином, код потрапить на зовнішній веб-сайт, що поставить під загрозу зареєстровані на сервері OAuth дані користувачів.
Примітка: заголовок «Referer» - це заголовок HTTP-запиту, він передає хосту URL-адресу, з якого відправляється запит.
Щоб пом'якшити наслідки даної уразливості, розробнику необхідно переконатися, що його веб-додаток не містить будь-яких html-ін'єкцій. Якщо ін'єкції були виявлені, то зловмисник з легкістю може встановити тег зображення на свій веб-сервер і знайти спосіб перенаправити користувача на нього. Таким чином, він отримає можливість вкрасти код з заголовка «Referer» HTTP-запиту.
Крадіжка токена OAuth за допомогою параметра redirect_uriДодаток ініціює процес авторизації, відправляючи запит на сервер OAuth:
https://www.example.com/signin/authorize?[...]&redirect_uri=https://demo.example.com/loginsuccessful
Питати щоразу містить параметр «redirect_uri», який використовується сервером OAuth для відправки токена назад в додаток після того, як користувач дав свою згоду. У разі, якщо значення цього параметра не контролюється або не перевіряється, зловмисник може легко змінити його і перенаправити запит на свій веб-сайт, де він використовує спеціальну програму для обробки токена і отримання доступу до обмеженого ресурсу.
https://www.example.com/signin/authorize?[...]&redirect_uri=https://localhost.evil.com
Іноді подібні URL блокуються. Зловмисник може перенаправити отримані дані на відкритий URL, як цей:
https://www.example.com/oauth20_authorize.srf?[...]&redirect_uri=https://accounts.google.com/BackToAuthSubTarget?next=https://evil.com
Або цей:
https://www.example.com/oauth2/authorize?[...]&redirect_uri=https%3A%2F%2Fapps.facebook.com%2Fattacker%2F
При реалізації OAuth ніколи не можна включати в білий список цілі домени. Слід додавати тільки кілька URL-адрес, щоб «redirect_uri" не перенаправляв запит на Open Redirect.
Підробка міжсайтових запитівПідробка міжсайтового запиту може статися, коли зловмисникові вдасться змусити жертву натиснути на його посилання і, таким чином, згенерувати запит, який він не збирався генерувати. Підробка міжсайтових запитів зазвичай пом'якшується за допомогою токена CSRF, який пов'язаний з сеансом користувача. Він допомагає з додатком перевірити особу людини, що відправив запит. Параметр «state» в протоколі OAuth служить токеном CSRF.
Варто поглянути, як здійснюється CSRF-атака на OAuth і як параметр «state» може бути використаний для пом'якшення наслідків уразливості.
Хакер відкриває веб-додаток і запускає процес авторизації для отримання доступу до постачальника послуг за допомогою OAuth. Додаток запитує у постачальника послуг дозвіл на доступ, який необхідно надати. Хакер буде перенаправлений на веб-сайт постачальника послуг, де зазвичай потрібно ввести своє ім'я користувача та пароль для авторизації доступу. Замість цього хакер ловить і запобігає цей запит і зберігає його URL-адресу. Хакер якимось чином змушує жертву відкрити цей URL. Якщо жертва увійшла в систему постачальника послуг, використовуючи свій аккаунт, то її облікові дані будуть використані для видачі коду авторизації. Код авторизації обмінюється на токен доступу. Тепер обліковий запис хакера в додатку авторизована. Він може отримати доступ і до облікового запису жертви.
Отже, як можна запобігти цю ситуацію за допомогою параметра «state»?
Додаток має створити значення, яке якимось чином засноване на вихідної облікового запису (наприклад, задіяти хеш-ключ сеансу користувача). Не настільки важливо, яке воно, головне, що значення унікально і генерується з використанням приватної інформації про початковий користувача. Воно і присвоюється параметру «state».
Це значення передається постачальнику послуг при перенаправлення. Тепер хакер запрошує жертву відкрити URL-адресу, який він зберіг.
Код авторизації видається і повертається назад клієнту в сеансі разом з параметром «state».
Клієнт генерує значення параметра на основі інформації про сеанс і порівнює його зі значенням «state», яке було відправлено назад із запиту авторизації постачальнику послуг. Це значення не відповідає параметру «state» в запиті, оскільки воно було створене тільки на основі інформації про поточний час. В результаті, отримане значення не береться системою.
Інші уразливості, виявлені при реалізації OAuth, включають в себе можливість виконання XSS (міжсайтового скриптинга) з використанням параметра «redirect_uri», розкриття OAuth Private Key (ключ іноді може бути отриманий при декомпіляції мобільного додатка) і Authorization Code Rule Violation (коли код авторизації може бути використаний більш ніж один раз для видачі декількох токенов доступу). Ці уразливості зустрічаються рідше, ніж описані вище, але це не робить їх менш небезпечними. Розробник повинен знати всі необхідні практики, щоб забезпечити надійну роботу свого веб-додатки.
Автор перекладеної статті: Simon Saliba.
Важливо! Інформація виключно в навчальних цілях. Будь ласка, дотримуйтесь усіх законів і не застосовуйте цю інформацію в незаконних цілях.
Більше цікавого матеріалу на cisoclub.ru. Підписуйтесь на нас: Facebook | VK | Twitter | Instagram | Telegram | дзен | Мессенджер | ICQ New | YouTube | Pulse.