Відкритий редирект - це уразливість, коли вебзастосунок бере URL призначення з невалідованого вводу користувача - зазвичай з параметра запиту на кшталт ?next= чи ?url= - і переадресовує браузер туди, не перевіривши його. Лінк починається на домені, якому жертва довіряє, тож він проходить огляд, а потім тихо приводить її кудись інде. Виправлення - не перестати робити редиректи. Це перестати дозволяти запиту вирішувати, куди йде редирект.
Ця відмінність важить, бо редиректи всюди, і більшість із них нормальні. Вхід і повернення на потрібну вам сторінку, передача платіжному провайдеру, зворотний виклик OAuth - усе це звичайні редиректи. Вада, каталогізована як CWE-601 і згрупована під broken access control у OWASP Top 10, - це конкретно випадок, коли ціль приходить з контрольованого користувачем вводу і ніщо не валідує її спершу. Зловмисник підставляє свій власний URL, довірений сайт переадресовує на нього, і довіра передається разом з кліком.
Я проводжу свої дні на шляху редиректу, тож у мене є думки на цю тему. Короткі лінки за визначенням є редиректами, що робить питання "чи скорочувач - це просто відкритий редирект?" справедливим - і відповідь, зробленого правильно, - чисте ні. Ми дійдемо до цього нижче. Якщо механіка редиректів для вас нова, типи редиректів - це вступ, а як працюють скорочувачі URL охоплює основи рівня редиректу.
Що таке відкритий редирект насправді#
Зведімо до механізму. Сторінка приймає параметр, що називає, куди йти далі, і використовує його в HTTP-редиректі, не підтвердивши, що він вказує кудись дозволено.
https://trusted.example/login?next=https://evil.example/fake-login
Жертва бачить trusted.example спереду і клікає. Після входу застосунок читає next і видає редирект на evil.example. Браузер підкоряється, бо редирект - це просто заголовок Location і статус 3xx - специфікація HTTP описує цю поведінку відверто, і браузер ніяк не може знати, що ця конкретна ціль ворожа. Користувач, спостерігаючи, як адресний рядок змінюється після того, як він уже довірився лінку, часто не помічає.
OWASP описує основну небезпеку прямолінійно: ім'я сервера в зміненому лінку ідентичне до оригінального сайту, що надає довіри шкідливому редиректу. Уразливість не в тому, що сайт робить редирект. Вона в тому, що сторонній вибрав призначення.
Чому "нешкідливий" редирект - це справжня загроза#
Рефлекс - знизати плечима: ну, він відправляє когось на інший вебсайт, у чому шкода. Шкода - це позичена довіра, і вона масштабується.
Фішинг - це головне застосування. Лінк, який починається з банку, входу в SaaS чи урядового порталу, пропливає повз швидку візуальну перевірку, яку робить більшість людей, і повз дивовижну кількість автоматичних фільтрів, що оглядають лише провідний домен. Жертва прибуває на піксельно точну підробку сторінки входу, яку очікувала, на домені, який виглядав правильно один перехід тому, і набирає свій пароль. Жодного шкідливого ПЗ, жодного екзотичного навантаження - просто редирект і клон.
Стає гірше, коли редиректи стоять поблизу автентифікації. Відкритий редирект у потоці OAuth може витягти код авторизації чи токен на контрольований зловмисником redirect_uri, що ескалює "незначну" ваду до повного захоплення акаунта. Ось чому відкриті редиректи - це основа звітів bug-bounty, а не примітка. Той самий трюк також відмиває репутацію: спамери та оператори шкідливого ПЗ обожнюють відбиватися через довірений домен, бо це проводить їхній справжній лінк повз чорні списки. Ми охоплюємо ширшу категорію в чеклісті безпеки скорочувача URL, а кут довіри з боку відвідувача - в чи безпечні скорочувачі URL.
Як запобігти відкритим редиректам#
Існує ієрархія виправлень, і її вершина - те, що насправді кладе край проблемі. Шпаргалка OWASP їх ранжує, і порядку варто дотримуватися.
- Взагалі не беріть URL із запиту. Хай клієнт надсилає коротке ім'я, ID чи токен, а ви розв'язуєте його до повного призначення на сервері. OWASP називає це найвищим ступенем захисту, бо вхідний запит більше не може назвати довільну ціль. Якщо цей патерн здається знайомим, так і має бути: саме так працює скорочувач URL.
- Список дозволених, а не список заборонених. Коли вам доводиться приймати призначення, перевіряйте його за списком довірених хостів чи суворим regex. Список дозволених провалюється закрито - усе, що не дозволено явно, відхиляється. Список заборонених провалюється відкрито, а зловмисникам платять за те, щоб знаходити записи, які ви забули.
- Розбирайте суворо. Відхиляйте протокол-відносні URL (
//evil.example), нормалізуйте зворотні скісні риски, декодуйте перед валідацією і ставтеся до хоста - а не лише до префікса рядка - як до того, що треба перевірити. Більшість обходів фільтрів живуть у лінивому розборі. - Покажіть проміжну сторінку як підстраховку. Якщо редиректу на зовнішній сайт не уникнути, проводьте його через сторінку, яка називає призначення і просить користувача підтвердити. Це тертя, але воно перетворює тихий редирект на усвідомлений.
Повторювана тема в тому, що безпечні редиректи вирішує сервер, з даних, яким сервер уже довіряє - ніколи з будь-якого рядка, що прибув у запиті.
Якщо ви вбудовуєте редиректи в продукт і радше не володіли б цим режимом збою, платформа для розробників Elido зіставляє коди з призначеннями на сервері за дизайном - почніть з швидкого старту API і ніколи більше не пишіть власноруч параметр ?url=.
Чому короткі лінки - це захист, а не вада#
Ось частина, яка дивує людей. Правильно побудований скорочувач URL - це підручникова реалізація виправлення відкритого редиректу номер один від OWASP.
Коли короткий лінк створюється, його призначення валідується і зберігається на сервері, прив'язане до короткого коду. Коли хтось заходить, рівень редиректу шукає цей код і переадресовує на збережену ціль. Призначення ніколи не приходить із вхідного запиту - відвідувач не може додати ?url= і вигнути лінк кудись інде, бо немає такого параметра, який можна було б вигнути. Це якраз те зіставлення токена-до-URL, яке рекомендує OWASP, що працює в продакшені мільйони разів на день. Архітектурно це живе в нашому рівні edge-редиректу, а бюджет затримки, за який це платить, - тема досягнення p95 під 15 мс для редиректів.
Чесне застереження: скорочувачем усе ще можна зловживати, просто не через відкритий редирект. Якщо платформа дозволяє будь-кому карбувати лінки на будь-що без сканування чи модерації, зловмисники використовуватимуть репутацію її домену, щоб замаскувати свої власні шкідливі призначення - ось чому відповідальні скорочувачі сканують цілі та забезпечують дотримання політик проти зловживань. Це проблема модерації контенту, відмінна від вади валідації вводу, про яку ця стаття, і її варто не плутати. Споріднена практика навмисного приховування призначення розглядається в клоакінг лінків і маскування URL пояснено, а соціально-інженерний родич усього цього - ворожі QR-коди - в чи безпечні QR-коди.
Висновок в один рядок#
Якщо ваш код читає призначення із запиту і робить на нього редирект, у вас є відкритий редирект, який чекає, поки його знайдуть. Натомість зіставляйте ID з серверною ціллю, додавайте до списку дозволених усе, що ви не можете уникнути брати з вводу, і розбирайте так, ніби очікуєте атаки. Редиректи - не ризик. Дозволяти запиту обирати, куди вони йдуть, - ось ризик. Різниця між 301 і 302 у 301 проти 302 редиректів - це примітка поруч із цим одним правилом.
Пов'язане в блозі#
Спробуйте Elido
Вставте URL - отримайте коротке посилання
Без реєстрації. Посилання живе 30 днів. Зареєструйтесь, щоб зберегти назавжди.
Безкоштовно, без реєстрації · 2 на день