Разрешено разрешение на ниво обект с примери

В тази публикация ние изследваме и обсъждаме неуспех на разрешено ниво на счупен обект.

Ще започнем, като обясним какво означава оторизация на ниво счупен обект. След това ще преминем през атаката, обяснявайки свързаните рискови фактори.

След това ще разгледаме някои от възможните въздействия на уязвимостта, преди най-накрая да разгледаме общите защити.

Какво е разрешение за ниво на счупен обект

Накратко, този тип атака означава, че упълномощаването, приложено към данните, не се извършва както трябва. Това води до предоставяне на достъп до ресурси и данни, когато не би трябвало да бъде.

В миналото оторизацията на счупено ниво е била известна като Insecure Direct Object Reference (IDOR).

Когато казваме думата обект в Упълномощаването на ниво счупен обект имаме предвид стойност или група от стойности. Обект може да бъде публикация в социалната мрежа, която съдържа автора, съдържанието и датата на публикуване.

Разрешение е всичко, до което е разрешен достъп на потребител. Следователно говорим за потребител, който вече е влязъл в системата.

Когато потребителят направи заявка към API, заявката се използва за достъп до обекти. Това е точката, при която трябва да се вземе решение за разрешение. Потребителят трябва да има достъп само до обекти, до които е получил достъп. Това е упълномощаване, което работи правилно.

Когато оторизацията е нарушена, на потребителите се разрешава достъп до данни и ресурси, които не бива да им се разрешава.

API улеснява различни операции върху обекти. Можем да получаваме, създаваме, актуализираме или дори изтриваме обекти.

Взаимодействието с обект е цялостната точка на API, следователно, ако контролите за упълномощаване около тези обекти са счупени, тогава имаме уязвимост при счупен достъп на ниво обект.

Експлоатация на уязвимост за достъп на ниво счупен обект

Обикновено е лесно да се използва тази уязвимост, след като бъде открита. Всичко, което нападателят трябва да направи, е да смени идентификатор в заявка и те потенциално са получили достъп до обекти, до които не бива да имат право.

Нека го видим в пример.

Тук имаме URL, който се използва за извикване на API:

https://myemail.com/messages/12345

Това API повикване се използва за извличане на лични съобщения на потребител. Използваният ресурс е съобщения .

Съобщението е обектът, към който се позоваваме в Упълномощаването на ниво счупен обект. Предполага се, че личните съобщения могат да бъдат прочетени само от желания получател.

След това имаме идентификатора на съобщението 12345. Това е важна част за нападателя.

Идентификаторът казва на услугата кой запис да се върне. API извлича този запис от хранилище за данни и го връща в отговора.

Сега какво се случва, ако сменим идентификатора от 12345 до 12346? например:

https://myemail.com/messages/12346

Ако съобщението с id 12346 е предназначен за нашия потребител, трябва да можем да го извлечем.

Но ако съобщението принадлежи на друг потребител, API никога не трябва да го връща. Ако все пак успяхме да извлечем съобщението, значи имаме неуспех при разрешаване на обект на счупено ниво.

Друг пример е изпращане на POST заявка за актуализиране на ресурс. Можем да си поиграем с идентификатора в полезния товар на JSON:

{
'userId': '12345678',
'oldPassword': 'My_0ld_Pa$$',
'newPassword': '$uperS3CurE' }

Ако трябва да сложим някакъв потенциал userId в заявката и успяхме да актуализираме данните на друг потребител, тогава имаме огромен проблем.

Техническо въздействие

След като разберем, че уязвимостта съществува, можем да я използваме по всякакъв начин. Както споменахме по-горе, можем да използваме различни HTTP методи за API. Можем да използваме Id за актуализиране или дори изтриване на съобщения!

Какво се случва, ако успяхме да прегледаме всички идентификатори? Може да успеем да изтрием всяко съхранявано съобщение. Това е голямо въздействие.

Обща уязвимост

Това е много често срещана уязвимост. Както бе споменато по-горе, API се използват за достъп до обекти и в повечето случаи използваме идентификатори в заявката за идентифициране на ресурси. Въпросът е дали има въведени проверки за оторизация за този достъп?

Има главно две причини, поради които в крайна сметка имаме уязвимости за разрешено разрешение на ниво обект в кода.

Първият е, че контролът за сигурност просто не е приложен. Кодът не е написан за извършване на проверки за оторизация на заявки.

Втората причина е човешката грешка. Хората правят грешки. Добър пример е в API, който обработва и двете чувствителни към нечувствителни данни. Някои заявки трябва да имат проверки за упълномощаване, а други не. Така че може да е лесно да пропуснете проверка, когато пишете код.

Как да се открие

Автоматизираните инструменти обикновено не биха намерили този тип уязвимост, тъй като обикновено отнема поне малко мозъчна мощ.

За човек е сравнително лесно да открие тази уязвимост. Всичко, което трябва да направим, е да намерим Идентификатора, който се използва за извличане на обекти.

Обърнете внимание, че идентификаторът може да бъде в URL адреса, в тялото на заявката или в заглавката.

Също така трябва да анализираме и интерпретираме отговора, който се връща, за да видим дали има уязвимост или не.

Инструменти

Можем да използваме всеки инструмент, който проверява HTTP заявките и отговорите. Някои от тях са:

• Google Developer Tools
• Супер суит
• Пощальон

Burp Suite може да се използва и за автоматизиране на някои от заявките.

Защита срещу разрешено ниво на счупен обект

Тук имаме две защити.

Първата защита е да се използва непредсказуеми идентификатори като GUID . Когато използваме последователни числа в кода, напр. 12345, това означава, че идентификаторите са много предвидими. Нападателят не се нуждае от много усилия, за да премине през числа, за да намери предмети.

Пример за GUID:

d3b773e6-3b44-4f5f-9813-c39844719fc4

GUID са сложни и много трудни за отгатване и не са последователни.

Следващата защита е всъщност да имаме някакъв код проверете разрешението . Тази проверка често просто не се случва.

Удостоверяването трябва да се извършва всеки път, когато потребителят представи API в рамките на идентификатор, който ще бъде използван. Основният принцип тук е, че никога не бива да се доверяваме на данни, които потребителят дава на API.

Исканият идентификатор трябва да бъде проверен, за да се потвърди, че потребителят е оторизиран за достъп до обекта.

Тези проверки могат да бъдат просто прегледи на кода по време на разработването на софтуер и / или автоматизирани проверки, които проверяват за неуспешни разрешения по време на разработката.

Заключение

Както видяхме, разрешаването на ниво счупен обект е често срещана уязвимост и е лесно да се забележи и атакува. Потенциалните въздействия са огромни.

Истинският източник на тази уязвимост е доверителните данни, които се предават на API от клиента.

Голяма част от защитата е да се уверим, че нямаме доверие на тези данни. Затова трябва да се уверим, че проверките за оторизация са налице.