Как да защитим backend api?

[Александър]

Здравейте. Направих сайт https://anketi.bg/tarsene. За клиент използвам чист react(spa). За сървър имам api, което искам да предпазя.

Може ли да ми дадете идеи как да защита сървъра си, така че да се използва само от клиентската ми част, а не от някой с postman и тн.?
 

[Avatara]

Здравейте,

С удоволствие Бих Ви помогнал но преди това Ви моля да ми отговорите на следния въпрос:

Какъв точно вид API използвате, в смисъл:

• Използвате REST при който ресурсът е компонент от конкретен URL адрес. В този случай  HTTP методите GET, POST, UPDATE и DELETE приложени към един и същ ресурс, изпълняват различни функции, което има специфика, която е добре да се отчита и за която ще поговоря.
• Ползвате SOAP, което е разширение на протокола XML-RPC. Ако си спомняте той първоначално бе предназначен за RPC (Remote Procedure Call), а сега се използва по-често за XML съобщения. Това е ако вашият web ресурс използва някакъв вграден някакъв месенджър или друг тип подобна услуга. Тогава се изисква различен подход за защита. 
• Ползвате RPC, което на практика е най-простият тип API. В този случай заявките Ви се обработват (примерно) по следния начин: 

 

                           POST /api/conversations.archive

                           HOST mysite.com

                          Content-Type: application/x-www-form-urlencoded

                          Упълномощаване: токен OAUTH-TOKEN

                          Канал=C01234

 

Това е нещо различно и тук подхода е друг.

В зависимост от това, което използвате се използва различен подход за защита. Това е въпрос, който касае т.н. "архитектура на решението". Ако изскате да изградите сериозна защита е добре да се обърнете към експерт, защото това е цяла наука. И за да ме разберете правилно ето Ви малко информация, която ако желаете бихме могли да обсъдим.

Според класивикацията на  OWASP (Open Web Application Security Project) най-опасни уязвимости в API са както следва:

• API1:2019 - Липса на контрол върху изполваните обекти (Insecure Direct Object References или Direct Object References). Масово срещан проблем, който има много сериозни последици за експлотационната сигурност. Изисква специфична методика за отстраняване на заплахите.
• API2:2019 - Проблеми с оторизиранията на потребителите (Broken User Authentication). Тук проблемите са неизброими и ще ми отнеме дни да изброя всички възможни, но има много ефективни и доказани решения.
• API3:2019 - Нарушаване на изискванията за конфеденциалност на данните (Excessive Data Exposure). Това е един от най-често срещаните проблеми, който може да доведе до сериозни правни и финансови неприятности. Хубавото е, че тук има действащи стандарти и утвърдени протоколи. 
• API4:2019 - Отсъствие на система за контрол на съблюдаването на наложените ограничения (Lack of Resources & Rate Limiting). Тук опираме до т.н. "системни отчети", "контрол на трафика" не само, които освен от техническа са задължителни и от правна гледна точка.
• API5:2019 - Недостатъци при реализиране на достъп до функционалните нива (Broken Function Level Authorization).  Това изисква сериозен анализ на използваното API и до колко то съответства на действащите стандарти. Също едно от често нарушваните правила за безопасност. 
• API6:2019 - Необезопасена десерилизация (Mass Assignment). Ак не ме разбирате за какво говоря (защото преди време една колежка, работеща в държавна структура в Република Булгария се отнесе изключително несериозно към тази заплаха, пораси липса на ужните компетенции) ще обясня, че десерилизацията е процес на преобразуване на данни, сериализирани в определен формат, обратно в обектите или структурите от данни, които те представляват. Това е една орт най сериозните уязвимости при използване на публично достъпни ресурси (web сайтове, мобилни решения и др.), отстраняването на която изисква сериозни познания не само в сферата на програмирането и СУБД, но и в такива науки като "теория на крайните автомати", "специална теория на информацията" и др..
• API7:2019 - Неправилно конфигуриране на системните насторйки (Security Misconfiguration). Това е проблем, който е обвързан с използваната от вас сървърна ОС (държа обаче да подчертая, че между различните сървърни операционнии системи има много големи различия, а професионалните такива са много скъпи и до сега не съм видял в България някой да използва такава, независимо кой какво твърди) 
• API8:2019 - Инжектиране (Injection). Важно е да знаете, че тук не включвам само и единствено масово разпространениоето SQL инжекции. От години се ползват много по-усъвършенствани средства. Типичен приме за това е т.н. "текстова стеганография", която е масово рещано явление в системите с отворен код. Нямате и най-малка представа какво може да бъде имплементирано в един скрипт и какво може да се случи, когато се активира. Да не споменавам за т.н. "пакетна стеганография".
• API9: 2019 Неправилно управление (Improper Assets Management). Тук опираме до системите за експлотационен контрол и администриране. За да ме разберете, правилно ще кажа само, че в една от най-големите куриерски фирми в БЪлгария не знаеха защо е нужно да имат въведени вътрешни правила за управление на сигурността, кой и как трябва да отговаря, да не говорим за съхранение, отчетност и много други неща. Главната им юристка нямаше и най-малка представа кои данни (при реализиране на пощенски услуги), се считат за "критични" и какви последствия би могло да има неспазването на експлотационните протоколи за сигурност.
• API10 2019 - Недостатъчен контрол върху системните журнали и осъществявания мониторинг (Insufficient Logging & Monitoring). Тази уязвимост има непосредствена връзка с гореизложената. Това, че някъде имате някакъв архив и/или текстови файл в който съхранявате някаква информация е без каквато и да било правна тежест, в случай на форсмажорни обстоятелства.  Тук има набор от процедури в т.ч. сертификационни, които се изпълняват от оторизирани за това органи. Добре е и да се познава местното, регионалното и международното законодателства. Всичко, базирано на използването на internet има трансграничен характер, с всички произтичащи от това последици.

Към така изброените заплахи лично аз бих добавил и тези свързани с arhitektura, оторизация и OSI, като:

• Необезопасен транспортен слой (Insecure Transport); 
• Необезопасени хранилища за пароли (Password Plaintext Storage);
• Използване (въпреки всички предупреждения от мен и колегите) на компоненти с доказана уязвимост (Using Components with Known Vulnerabilities);
• Междусайтово изпълнение на сценарии - CWE-79 Cross-site Scripting (XSS);
• Междусайтова подмяна на заявките - CWE-352 Cross-Site Request Forgery (CSRF);
• Небезопасни "бисквитки" (за тях съм писал в този форум) и необезопасени локални хранилища за данни - Insecure Cookies and Local Storage;
• Проблеми с хедътите в HTML - Insecure HTTP Headers;
• Неправилно използване на CORS - Improper Cross-Origin Resource Sharing;
• Подмяна на кликове - Clickjacking и пр. и пр.;

Всяка от тези уязвимости изисква набор от специфични решения.

 

Фиг.1. Част от възможните заплахи за API (за REST).

 

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

За да ме разберете разгледайте Фиг.2, на която е изобразен базовията алгоритъм за Token-Based Authentication (доста популярен в банковите среди). 

Token-Based Authentication, използва токен, подписан от сървъра (маркер), който клиентът изпраща на сървъра в HTTP хедъра за оторизация с ключовата дума Bearer или в тялото на заявката. Например:

 

Authorization: Bearer qyJhwGci1234UzI1NiIsImtpZCI6IjI4Y

 

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

Базираното на токен удостоверяване може да се използва като част от протоколите OAuth 2.0 или OpenID Connect или сървърът може да генерира самия токен. Но това е малка част от всички възможни решения и лично аз ссъм го използвал просто като пример.

 

 

Фиг.2. Алгоритм Token-Based Authentication

 

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

И за да бъда правилно разбран, ще спомена, че направената от мен консултация (това, което написах като отговор на зададения от Вас въпрос до тук), струва на европейска компания малко над 84 000 EUR без ДДС (това е с отстъпка, по официална тарифа, по която работим).

Приемете, че това което правя е малък подарък за Вас, защото лично аз (а и колегите ми) считаме че този форум е изключително за професионалисти.

Правя това от уважение и повярвайте опитвам се да Ви помогна в рамките на познанията и възможностите си.

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

 

С уважение

Avatara

Редактирано Май 12, 2023 от Avatara