Відому проблему усувають у специфікаціях OAuth, OpenID; проблеми реалізації
Твердження дослідника про недоліки безпеки в OAuth і OpenID мають серйозні недоліки, згідно з тими, хто знайомий із специфікаціями.
Новини про проблеми з безпекою сильно вдарили в п’ятницю, стверджуючи, що дві специфікації ідентифікації були недосконалими, а інформацію про вхід користувача та інші дані могли вкрасти хакери. Його відразу ж почали порівнювати з Heartbleed з точки зору його здатності похитнути фундамент Інтернету.
Але помилка, яка отримала назву Covert Redirect Vulnerability, схожа на Heartbleed лише тим, що вона була попередньо запакована з вигаданою назвою, веб-сайт і полірований логотип.
Недоліки, «виявлені» Ван Цзіном, аспірантом Наньянського технологічного університету в Сінгапурі, є вже відомими кількостями, і розробники специфікацій уже розробили їх пом’якшення. Проблеми полягають не в OAuth і OpenID, а в реалізаціях веб-сайтів, які дозволяють так зване «відкрите перенаправлення» що дозволяє веб-браузеру надсилати облікові дані назад за URL-адресою, яка не збігається з URL-адресою, яка спочатку запитувала облікові дані.
OAuth, фреймворк, і OpenID, протокол, побудований на цьому фреймворку, є ключовими елементами для безпечного входу в систему та безпечного обміну обліковими даними контролю доступу між доменами Інтернету. Обидва використовуються такими компаніями, як Google, Microsoft і LinkedIn. Facebook використовує OAuth і щось подібне до OpenID.
Цзін, який опублікував відео, які розповідають про експлойт, показує, як реалізацію OAuth Facebook зламано за допомогою відкритого параметр переспрямування, який надсилає маркер доступу користувача на шкідливий сайт замість того, який спочатку запитував облікові дані.
«Відкриті редиректори є головною проблемою, і це фактично розпізнається та пом’якшується в остаточній версії OAuth», – сказав Єва Малер, аналітик Forrester Research, яка використала фреймворк OAuth для розробки протоколу під назвою «Керований користувачем» Доступ. «Майте на увазі, що ніхто не перевіряє відповідність Facebook (або іншого) остаточному OAuth RFC, тому схоже, фактором, що сприяє виникненню проблеми, є відсутність тестування на відповідність і звітності», – сказав він Малер. Вона каже, що необхідно розпочати дискусію щодо відповідності.
Певна робота щодо відповідності виконується тими, хто визнає проблему не в специфікаціях, а в реалізаціях. У березні LinkedIn попросив розробників зареєструвати URL-адреси перенаправлення OAuth 2.0 для своїх програм, щоб вони відповідали специфікації OAuth щодо відкритих перенаправлень. Кінцевий термін був 11 квітня, і ті, хто не встиг, мали повідомлення про помилку у своїх програмах, коли користувачі намагалися ввійти, використовуючи свої облікові дані LinkedIn.
Вказівки щодо використання команди redirect_uri є частиною документа під назвою «Модель загроз OAuth 2.0». та міркування безпеки», який був опублікований у січні 2013 року Internet Engineering Task Сила. ( Стандартизований IETF OAuth 2.0 в жовтні 2012). Торстен Лоддерштедт з Deutsche Telekom, Марк МакГлойн з IBM і Філ Хант з Oracle є авторами документа Threat Model, який містить розділ «Перевірити попередньо зареєстрований redirect_uri».
У розділі зазначено:
Відповідно до основної специфікації, кожен фактичний URI перенаправлення, надісланий із відповідним «client_id» до кінцевої точки авторизації кінцевого користувача, має відповідати зареєстрованому URI перенаправлення. Якщо він не збігається, сервер авторизації повинен припустити, що вхідний запит GET надіслав зловмисник, і відхилити його».
Джон Бредлі, член правління OpenID Foundation, сказав, що Jing проігнорував пом’якшення безпеки в OAuth і OpenID, які запобігають відкритим перенаправленням. (У Бредлі є більш детальний опис Thread Safe блог).
В відео, опубліковане Jing, «він захоплює (на 3:55 у записі) URL-адресу з панелі браузера та вставляє її в текстовий редактор», — сказав Бредлі. «Це вимагає співучасті користувача, щоб викрасти власний маркер доступу».
Розкриття інформації: ми з Джоном Бредлі працюємо на одного роботодавця.