API Authentication

1. ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – гр. ВАРНА
Център Магистърско Обучение
Реферат
Безопастност и Защита
Тема: API-автентификация и безопасност и защита на Web
приложения
Изготвил:
Веселин Георгиев Братанов
фак. №: 91296
специалност: „Информатика“
Проверили:
Доц. Д-р Стефан Дражев
Ас. Радка Начева
Съдържание
I. Въведение
II. Увеличаване на сигурността на API
III.Автентикация в системата

2. 1
IV. API Ключове
V. Заключение

3. 2
I. Въведение
Изготвянето на API (Application Programming Interface) към уеб приложения и системи
е широко разпространено и продължава да придобива популярност сред уеб
приложенията, микросървисните архитектури, облачните услуги и всички системи
нуждаещи се от уеб комуникация в интернет.
Фиг. 1 - Какво е API
API е интерфейс, който позволява на нашата система да бъде използвана от други
системи или част от системата да бъде изнесена във външен микро-компонент, който
да комуникира с нея по специално предварително определени правила.
Заплаха за API-тата е непозволения достъп до сървърните ресурси на системата.
Съществуват реални рискове от хакерски атаки, източване на информация и
присвояване на потребителски сесии при неправилно или непълно въведени протоколи
и мерки за сигурност при автентикация.

4. 3
Фиг 2. - Пропуски в сигурността на API
Използването на API има много предимства - улеснява се особено предоставянето на
услуги към външни системи, абстрахират се данните и тяхното представяне, позволява
се създаването на многоезична платформа и други, но то крие и много рискове за
сигурността и интегритета на данните. При изготвянето на API и на автентикация към
него могат да бъдат допуснати много грешки при разработката, за които трябва да сме
наясно за да бъдат предвидени своевременно, а не в процес на работа на интерфейса,
понеже тогава редакцията в характеристиките на API би струвала скъпо.
Стандартизираното изграждане на API е наложително за всяка една система, но това
отваря по-голям потенциал за възможни атаки и пропуски в сигурността. С него се
увеличава предсказуемостта на входа и изхода, което е както плюс, така и минус ако
ресурсите не са правилно защитени.
Сред възможните атаки, с които може да бъде атакуван API са инжектиране на
скриптове в съдържанието на данните, SQL инжекции и всички останали възможни
атаки познати от стандартните уеб-сайтове, за които разработчиците са подготвени в
повечето от случаите.

5. 4
II. Увеличаване на сигурността на API
За справяне с множеството от атаките е наложително да се филтрира щателно
входната и изходна информация. Принципът, познат като FIEO (Filter Input, Escape
Output) са методи за обработката на входната и изходна информация, които намаляват
потенциалните възможности за атака. При спазване на следните правила за
повишаване на сигурността на системата може значително да се намалят възможните
слаби места в сигурността:
- За входните данни е важно те да бъдат типизирани, тоест да не се приемат
данни от тип - различен от дефинирания, колекциите и числовите стойности
трябва да бъдат коректно валидирани, като не е добра практика всички данни да
бъдат обръщани в низове за по-лесна обработка.
- Необходимо е използването на валидация според зададена схема - с правилно
създадена документация към API може да се създаде и автоматична валидация
на данните, типовете и приеманите стойности.
- Трябва правилно да бъдат валидирани всички Header полета при всеки един
request. Това предотвратява използването на услугата от неоторизирани лица и
прави проникването в системата една идея по-трудно.
- Предвиждането на повече функционалности отколкото бизнес логиката и
ситуацията налагат трябва да се избягва за да има системата по-малко точки
подлежащи на евентуален пробив.
- Необходимо е изготвяне на whitelist и blacklist с използвани тагове и видове
входна информация. Като пример могат да се забранят <script>-тагове и други
познати уеб атаки.
- Внимателно трябва да се подходи с извеждането на съобщения за грешка. Както
при стандартните уеб сайтове съобщенията за грешка не трябва да са видими за
потребителя в публична среда. Вместо това се връща стандартизирано
съобщение и по-подробна информация може да се види в системните логове на
сървъра или от съответния административен панел.

6. 5
- Съобщенията за грешка, които са необходими на клиента за работа също трябва
да бъдат възможно най-малко и не трябва да издават информация за
вътрешната структура на данните или начина на работа на системата. Например
съобщението: { “error”: “Please provide an user_credit_cart_number field for the
users table.” } е крайно недопустимо понеже извежда информация за имена на
колоните в таблицата и дори името на самата таблица, които могат да бъдат
използвани за извършване на множество различни атаки започвайки с SQL
инжекциите. Това, че сме предвидили защита от SQL инжекции не означава, че
системата е абсолютно непробиваема и не трябва да избягваме
имплементирането на различните проверки за сигурност колкото и да сме
сигурни във валидацията на данните за конкретния случай. Крайно недопустимо
е извеждането на грешката и системният trace до нея или на заявката към база
от данни, която не се е изпълнила правилно. По този начин можем както да
компрометираме сигурността на системата, така и да изведем лична
информация за потребител или потребители на системата на грешни и/или
неоторизирани лица.
III. Автентикация в системата
Друг основен проблем на API автентикацията е възможността за представяне на
идентичността на потребителя към системата. Стандартните уеб системи работят
главно със сесии и cookie-та, като те могат да бъдат приложени и в съответния
програмен интерфейс. Най-честата реализация на подобна логика е след логин да
бъде върнат определен от сървъра token, който има валидност и е уникален за сесията
на потребителя. Този token на по-късен етап може да бъде изпратен като параметър
към методите, които се нуждаят от автентикация и след проверка за неговата
валидност да се извърши съответната операция. Възможно е този логин да бъде
извършен както с най-често срещаният метод с име/парола така и чрез по-развити
техники като например x.509 сертификати, Multi-Factor автентикация, Kerberos, SAML и
прочие. В стандартите на REST API1 за автентикация е предвидена възможността с
всеки request да се изпращат име и парола на потребителя в head частта на request-a
чрез Auth Basic. Строго препоръчително е това да се извършва през HTTPS протокола
и паролата да бъде предварително хеширана, но въпреки това зад тези техники се
1
RESTful API се наричат уеб API услугите, които спазват архитектурните ограничения на REST API,

7. 6
крият и множество заплахи. Най-явният проблем тук е, че паролата трябва да бъде
кеширана при клиента за да се изпраща със всеки един request, което е риск за
съхраняваните данни в клиентското приложение и подлежи на CSRF2 атаки.
IV. API Ключове
API ключовете са предварително генерирани уникални кодове, които идентифицират
отделният потребител в системата. Позволяват следенето на трафика за отделни
потребители, лимитиране на функционалности и предоставяне на услуги, но са също
така и доста уязвими откъм атаки. Самият ключ е публично достъпен в клиентските
приложения които се изпълняват при потребителя, което само по себе си е риск за
сигурността на данните. Когато API ключа се използва единствено в сървърната част
на системата той може да бъде съхранен и невидим за външни лица до определена
степен. Всеки от гореспоменатите методи за атака на API може да бъде приложен и на
сървърната част използваща въпросното API за да бъде извлечен ключа. Много
програмисти добре подсигуряват сигурността на сървъра, защитават системата от
всевъзможни атаки и след това качват проекта в source control система с всички
налични файлове от проекта. При споделянето на проекта с трети лица, услуги
разпространяващи отворен софтуер и дори такива претендиращи, че каченият проект
ще бъде видим само от вас и упълномощените лица е крайно грешно да се качват и
API ключовете, които проекта използва заедно със самия проект. Както паролите за
достъп до база данни и друга поверителна информация тези полета трябва да бъдат
изнесени в конфигурационни файлове, да бъдат зареждани и попълвани ръчно при
настройка на проекта и никога да не биват качвани в облачни услуги или Git системи.
След направена проверка за API ключ на популярна система за извличане на данни за
летателни полети: flightaware3 в свободно качени проекти в GitHub използващи
FlightAware API бяха намерени поне 5 проекта и голям брой ключове за услугата
свързани към платени акаунти и банкови сметки. Само в един от намерените проекти
използващи тази услуга API ключът беше заменен с <insert_api_key_here>. Подобно
публично публикуване на ключовете може да доведе до лесно източване на банковата
ви сметка, превишаване на лимити за използване или неоторизиран достъп до
2
Cross-Site Request Forgery - вид атака при която зловреден код променя действията на браузъра за
извърши неправомерно действие от страна на потребителя
3
FlightAware е услуга, предоставяща информация в реално време за самолетни полети, билети и други -
flightaware.com

8. 7
поверителна информация. Трябва да се има и предвид, че веднъж качен ключът в
Git/SVN система там се пази история, където той ще бъде наличен дори и да го
изтрием на по-късен етап. При компрометиране на API ключа е добре той да бъде
генериран отново и новият ключ да бъде използван в клиентската част. API ключовете
имат главната цел да следят трафика и спазването на правила от потребителите и не е
редно да бъдат използвани като метод за автентикация - за всички дейности, с които
достъпваме поверителна информация, променяме значима информация или които ни
таксуват при използване трябва да се използва коректна имплементация на логин,
потребителски защитени token-и или някой от другите споменати методи.
V. Заключение
Важна стъпка при защитата на API е да се използва HTTPS връзка абсолютно
навсякъде. Това помага за елиминиране на man-in-the-middle атаките и увеличава
шансовете за по-непробиваема система. В момента цените за използване на HTTPS
връзка значително намаляват и услугата е широко достъпна дори за обикновените
потребители. Правилното имплементиране на PKI и различни методи за аутентикация
може да е трудоемко, но ще повиши сигурността на генерираните потребителски сесии
и ще намали възможността за изтичане на информация от системата. При вход за
потребители е добра идея да се използва OAuth като добре разработена система за
автентикация. В общия случай е по-добре да използваме вече работещи решения,
фреймуърци и среди, отколкото да измислим ново такова поради рискове от допускане
на грешки и по-лесна поддръжка. В крайна сметка поддържане на високо ниво на
сигурност е трудно, но не е невъзможно. За защита на функционалностите и личните
данни могат да бъдат предвидени много различни техники, а със следването на REST
стандартите и насоките може да се създаде един професионален и защитен API.

9. 8
Източници:
1. Best Practices You Must Apply to Secure Your APIs - Scott Morrison, SVP &
Distinguished Engineer, CA Technologies, Cloud Identity Summit
2. Protecting Your APIs Against Attack & Hijack - Scott Morrison, SVP & Distinguished
Engineer, CA Technologies, Cloud Identity Summit