Тази статия ще се занимава с известните уязвимости на OAUTH. Читателите също ще научат как да приложат безопасно и сигурно разрешение в уеб приложението.
OAUTH е надежден протокол, но степента на сигурност до голяма степен зависи от информираността на уеб разработчиците при прилагането на разрешението. Това прави тази тема изключително важна за специалистите по сигурността на информацията. Те трябва да осигурят високо ниво на защита на сметките на техните потребители. Време е да се запознаем с ефективни практикуващи, които ще помогнат за намаляване на опасността от лоша продажба на OAUTH.
ВъведениеOAUTH 2.0 Протоколът в момента се използва широко в различни приложения. Използването му, удобен потребителски интерфейс става наличен, по-лесно удостоверяване и разрешение в сравнение с традиционните методи за въвеждане на потребителското име и паролата. С правилното и внимателно прилагане, протоколът OAUTH ще бъде по-безопасен от традиционното разрешение, тъй като потребителите не трябва да споделят своите счетоводни данни с заявление на трета страна за достъп до конкретен ресурс. Потребителите често предпочитат да влизат в профила си в Google, Facebook или LinkedIn, вместо да създават нов акаунт всеки път, когато трябва да се регистрирате на някой уеб сайт. Така протоколът OAUTH значително опростява живота ни.
Като цяло, популярните доставчици на OAUTH услуги са много надеждни. Влезте с Google или Facebook акаунт вдъхновяват известно чувство за сигурност и е правилно. Протоколът е внимателно тестван от експерти. Всички налични уязвимости винаги се коригират бързо от екипа на разработчика. Въпреки това си струва да се отбележи, че усещането за пълна безопасност може да бъде невярно.
Доставчиците на услуги на OAUTH оставиха разработчиците на приложения много причини да твърдят безопасността на техните програми. Всъщност първоначално защитената OAUTH услуга, неправилно внедрена в процеса на инсталацията, може да се превърне в лесна цел за натрапници. Такава загриженост ще доведе до кражба на лични данни на потребителите.
След това трябва да разгледате най-често срещаните уязвимости, срещани в приложения на трети страни, които прилагат OAUTH протокол за разрешаване на техните потребители. Трябва да се помни, че самият протокол е безопасен и надежден. Само след неправилно изпълнение става уязвимо за хакерски атаки.
OAUTH TOCKEY кражба с помощта на заглавието на референтКогато приложението поиска разрешение от името на потребителя на OAUTH сървъра, човек получава кода за влизане и изпращане на сървъра за последващата си проверка. Ако по време на работата потребителят ще бъде пренасочен към друга страница, кодът ще се види в заглавката "Referer" на HTTP заявката. По този начин кодът ще падне на външния уебсайт, който ще застраши потребителските данни, регистрирани на OAUTH сървъра.
Забележка: Референтният заглавие е HTTP заглавие на Query, той предава URL хост, от който се изпраща искането.
За да омекотите последиците от тази уязвимост, разработчикът трябва да се увери, че нейното уеб приложение не съдържа никакви HTML инжекции. Ако инжекциите са били открити, нападателят може лесно да настрои етикета на изображението на своя уеб сървър и да намери начин да пренасочите потребителя върху него. Така той ще получи възможност да открадне кода от заглавката "Referer" на HTTP заявката.
OAUTH TOCKEY THEFT, използвайки параметъра Redirect_uriПриложението инициира процеса на оторизация чрез изпращане на заявка до OAUTH сървъра:
https://www.example.com/signin/Authorize?[...]&redirect_uri=httpps://demo.example.com/loginsucfessful.
Заявката винаги съдържа параметъра "Redirect_uri", използван от сървъра на OAUTH, за да изпращате символи обратно към приложението, след като потребителят даде съгласието си. Ако стойността на този параметър не се контролира или не е проверена, нападателят може лесно да го промени и пренасочи искането до своя уебсайт, където използва специална програма за обработка на токена и да получи достъп до ограничен ресурс.
https://www.example.com/signin/Authorize?[...]&redirect_uri=httpps://localhost.evil.com.
Понякога подобни URL адреси са блокирани. Нападателят може да пренасочи получените данни на отворения URL адрес, подобно на това:
https://www.example.com/oauth20_Authorize.srf ?[&redirect_uri=httpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com.
Или това:
https://www.example.com/oauth2/Authorize? [...]% Ireect_uri = https% 3a% 2F% 2fapps.facebook.com% 2fattacker% 2F.
Когато изпълнявате OAUTH, никога не можете да включвате цели домейни в белия списък. Само няколко URL адреса трябва да бъдат добавени към "пренасочване_URI", които не са пренасочени към искане за откриване на пренасочване.
Подправяне на кръстосани исканияПодправянето на последващо искане може да възникне, когато нападателят успее да накара жертвата да кликне върху връзката си и по този начин да генерира искане, че няма да генерира. Подправете за кръстосани заявки обикновено се смекчава с токена CSRF, който е свързан с потребителската сесия. Тя помага на приложението да провери лицето на човек, който е изпратил искането. Параметърът "State" в протокола OAUTH служи като токен на CSRF.
Струва си да се види как се извършва атаката на CSRF на OAUTH и като "държавен" параметър може да се използва за смекчаване на ефектите на уязвимостта.
Хакерът отваря уеб приложение и стартира процеса на оторизация за достъп до доставчика на услуги, използвайки OAUTH. Приложението изисква доставчик на услуги за достъп, който трябва да бъде предоставен. Хакер ще бъде пренасочен към уебсайта на доставчика на услуги, където обикновено трябва да въведете потребителското си име и парола, за да разрешите достъп. Вместо това хакерът улавя и предотвратява това искане и спестява своя URL адрес. Хакер по някакъв начин кара жертвата да отвори този URL адрес. Ако жертвата влезе в системата на доставчика на услуги, използвайки своята сметка, тогава нейните пълномощия ще бъдат използвани за издаване на код за оторизация. Кодексът за оторизация обменя достъп до токена за достъп. Сега хакерската сметка в заявлението е разрешена. Той може да получи достъп до сметката на жертвата.
И така, как мога да предотвратя тази ситуация, използвайки параметъра "State"?
Приложението трябва да създаде стойност, която е по някакъв начин въз основа на изходния акаунт (например, използвайте ключа на Hash на потребителя). Не е толкова важно какво е, най-важното е, че стойността е уникална и генерирана чрез лична информация за оригиналния потребител. Той се присвоява на параметъра "State".
Тази стойност се предава на доставчика на услуги при пренасочване. Сега хакерът приканва жертвата да отвори URL адреса, който той запази.
Кодът за оторизация се издава и изпраща обратно на клиента на сесията заедно с параметъра "State".
Клиентът генерира стойност на параметрите въз основа на информация за сесията и го сравнява с "държавната" стойност, която е изпратена от искането за разрешение до доставчика на услуги. Тази стойност не съответства на параметъра "State" в заявката, тъй като той е генериран само въз основа на информация за текущата сесия. В резултат на това получената стойност не се приема от системата.
Други уязвимости, открити при прилагането на OAUTH, включват възможността за извършване на XSS (кръстосано място), като се използва параметърът "Redirect_uri", настройката на OAUTH листния ключ (ключът понякога може да бъде получен при декомпилиране на мобилно приложение) и нарушение на кода на разрешението (кога Кодът за оторизация може да се използва повече от веднъж, за да издаде множество символи за достъп). Тези уязвимости са по-малко общи от описаните по-горе, но това не ги прави по-малко опасни. Разработчикът трябва да знае всички необходими практики, за да осигури надеждна работа на своето уеб приложение.
Авторът на преведената статия: Саймън Салиба.
Важно! Информация единствено за академични цели. Моля, спазвайте законодателството и не прилагайте тази информация за незаконни цели.
По-интересен материал на cisoclub.ru. Абонирайте се за нас: Facebook | VK | Twitter | Instagram | Телеграма | Zen | Messenger | ICQ нов |. \ T YouTube | Импулс.