Най-добри практики за изграждане на сигурни API

от Ракеш Таланки и Видеер Гадикота

Дизайнерите и разработчиците на API (приложен програмен интерфейс) обикновено разбират важността на спазването на принципите на проектиране, докато прилагат интерфейс. Никой не иска да проектира или внедри лош API!

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

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

Идентифициране и решаване на API уязвимости

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

Инжекциите

API-ите са шлюзовете за предприятията да се свързват цифрово със света. За съжаление има злонамерени потребители, които се стремят да получат достъп до задните системи на предприятията чрез инжектиране на непредвидени команди или изрази, които да изпускат, изтриват, актуализират и дори създават произволни данни, достъпни за API.

През октомври 2014 г. например Drupal обяви уязвимост за инжектиране на SQL, която предостави на нападателите достъп до бази данни, код и файлови директории. Атаката беше толкова тежка, че нападателите може да са копирали всички данни от сайтовете на клиентите. Има много видове заплахи за инжектиране, но най-често срещаните са SQL Injection, RegEx Injection и XML Injection. Неведнъж видяхме, че API-ите излизат на живо без защита от заплаха - не е рядкост.

API без удостоверяване

API, създаден без защита от злонамерени заплахи чрез удостоверяване, представлява грешка в дизайна на API, която може да застраши базите данни на организацията. Пренебрегването на правилното удостоверяване - дори ако се използва криптиране на транспортен слой (TLS) - може да причини проблеми. Например с валиден мобилен номер в заявка за API, всеки човек може да получи лични имейл адреси и данни за идентификация на устройството. Затова стандартните за индустрията силни механизми за автентификация и упълномощаване като OAuth / OpenID Connect във връзка с TLS са от решаващо значение.

Чувствителни данни на открито

Обикновено оперативните екипи и други вътрешни екипи имат достъп до инструменти за проследяване за отстраняване на грешки, които могат да осигурят ясен изглед на информацията за полезния товар на API. В идеалния случай данните за притежателите на PCI карти (CHD) и личните данни за здравето (PHI) са кодирани от мястото, където данните се улавят до мястото, където се използват данни, въпреки че това не винаги е така.

С нарастващите опасения относно сигурността на API, криптирането на чувствителни и поверителни данни трябва да бъде основен приоритет. Например, през юни 2016 г. беше разкрита уязвимост на HTTP прокси, която предоставя множество начини на атакуващите да проксират изходящата заявка на избран сървър, да улавят чувствителна информация от заявката и да получат интелигентност относно вътрешните данни. Освен използването на TLS, важно е трафикът на API да бъде защитен чрез криптиране на чувствителни данни, прилагане на маскиране на данни за проследяване / регистриране и използване на токенизация за информация на картата.

Възпроизвеждане на атаки

Основен потенциален проблем за архитектите на предприятията е така нареченото „презаписване на транзакции“. API-тата, които са отворени за обществеността, са изправени пред предизвикателството да разберат дали да се доверят на входящите заявки. В много случаи, дори ако е отправена и отказана ненадеждна заявка, API може учтиво да позволи на - потенциално злонамерен - потребител да опита и опита отново.

Нападателите използват това погрешно доверие, като се опитват да възпроизведат или преиграят законна заявка на потребителя (в някои случаи, използвайки техники за груба сила), докато успеят. През 2016 г. хакерите попаднаха в акаунти на Github чрез атака при възпроизвеждане, като използваха отново имейл адреси и пароли от други онлайн услуги, които бяха компрометирани и ги пробваха в акаунти на Github.

Контрамерките включват политики за ограничаване на скоростта за заглушаване на заявките, използване на сложни инструменти като Apigee Sense за анализ на трафика на заявки от API и идентифициране на модели, които представляват нежелани заявки за бот. Допълнителните мерки за сигурност за стимийни повторни атаки включват:

  • HMAC, който включва времеви марки, за да ограничи валидността на транзакцията до определен период от време
  • двуфакторна автентификация
  • активиране на краткотраен маркер за достъп чрез използване на OAuth

Неочаквани скокове в използването на API

Винаги е сложно да прецените използването на API. Добър пример е приложението, което за кратко свали API на National Weather Service. Този конкретен API нямаше никакъв механизъм за предотвратяване или пренапрежение на трафика, така че неочакваното увеличаване на трафика директно се удари в задния план.

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

Ключове в URI

За някои случаи на използване, прилагането на API ключове за удостоверяване и оторизация е достатъчно добро. Изпращането на ключа като част от Унифицирания идентификатор на ресурс (URI) обаче може да доведе до компрометиране на ключа. Както е обяснено в IETF RFC 6819, тъй като подробностите за URI могат да се появяват в браузъра или системните регистрационни файлове, друг потребител може да бъде в състояние да прегледа URI-ите от историята на браузъра, което прави API ключовете, паролите и чувствителната дата в API URI лесно достъпни.

По-безопасно е да се изпращат API ключове в заглавката за упълномощаване на съобщението, която не се регистрира от мрежови елементи. Като правило, се препоръчва използването на HTTP POST метод с полезен товар, носещ чувствителна информация.

Стак Trace

Много разработчици на API стават удобни, като използват 200 за всички заявки за успех, 404 за всички грешки, 500 за някои вътрешни грешки в сървъра и, в някои крайни случаи, 200 със съобщение за грешка в тялото, отгоре на подробна следа в стека. Проследяване на стека потенциално може да се превърне в изтичане на информация за злонамерен потребител, когато разкрие основните реализации на дизайн или архитектура под формата на имена на пакети, имена на класове, имена на рамки, версии, имена на сървъри и SQL заявки.

Нападателите могат да използват тази информация, като изпращат изработени заявки за URL адреси, както е обяснено в този пример на Cisco. Добра практика е да върнете „балансиран“ обект за грешка, с правилния код на HTTP статус, с минимално изискано съобщение (и) за грешка и „без следа в стека“ по време на грешки. Това ще подобри обработката на грешки и ще защити детайлите за внедряване на API от атакуващ. API шлюзът може да се използва за преобразуване на съобщения за грешки в резервни копия в стандартизирани съобщения, така че всички съобщения за грешки да изглеждат подобни; това също елиминира излагането на структурата на задния код.

Пазете API-тата в безопасност

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

[Търсите да научите повече за сигурността на API? Вземете вашето копие от скорошната ни електронна книга, вътре в продуктовия модул на API: Създаване и управление на сигурни API.]