262-000177-001 OWASP Топ 10 за безбедност на API
„
Информации за производот
Спецификации
- Име на производ: Водич за развивачи за OWASP Топ 2023 за API за 10 година
Безбедност - Содржина: Лист со безбедносни информации за API, дефиниции и детални информации
водичи за OWASP Топ 2023 за безбедност на API на 10 година
Упатство за употреба на производот
Вовед во безбедноста на API-то
Водичот за програмери дава сеопфатни информации за
Топ 2023 на OWASP за 10 година за безбедност на API, со акцент на заедничката безбедност
ризици при развивање апликации со API-ја.
Лист со упатства за безбедност на API
Листот со измами ги наведува следните категории на безбедност на API
ризици:
- Авторизација на неисправно ниво на објект
- Неисправна автентикација
- Авторизација на ниво на својство на скршен објект
- Неограничена потрошувачка на ресурси
- Овластување на неисправно ниво на функција
- Неограничен пристап до чувствителни деловни текови
- Фалсификување на барање од страна на серверот
- Неправилна безбедносна конфигурација
- Неправилно управување со залихи
- Небезбедна потрошувачка на API-ја
Водич за програмериview
Водичот навлегува во секоја категорија на ризик за безбедноста на API, обезбедувајќи
детални објаснувања и упатства за тоа како да се справите и ублажите
ефикасно ги ублажуваат овие ризици.
Најчесто поставувани прашања (ЧПП)
П: Зошто е важна безбедноста на API-то?
A: Безбедноста на API е клучна бидејќи API-јата често откриваат чувствителни податоци
и логика на апликацијата, што ги прави главни цели за напаѓачите.
Обезбедувањето на API-интерфејси е од суштинско значење за спречување на прекршувања на податоци и
обезбедување на целокупната безбедност на системот.
П: Како можам да имплементирам безбедни API-ја?
A: За да имплементирате безбедни API-ја, следете ги најдобрите практики како што се
соодветна автентикација, механизми за авторизација, валидација на влезни податоци,
енкрипција на чувствителни податоци и редовни безбедносни проценки и
ажурирања.
„`
БЕЛА КНИГА
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
Содржини
Лист за безбедност на API со измами
5
Дефиниции
5
API1:2023–Овластување на неовластено ниво на објект
7
API2:2023–Неуспешна автентикација
8
API3:2023–Овластување на ниво на својство на оштетен објект
9
API4:2023–Неограничена потрошувачка на ресурси
11
API5:2023–Овластување на ниво на неисправна функција
13
API6:2023–Неограничен пристап до чувствителни деловни текови
14
API7:2023–Фалсификување на барања од страна на серверот
16
API8:2023–Погрешна безбедносна конфигурација
18
API9:2023–Несоодветно управување со залихи
19
API10:2023–Небезбедна потрошувачка на API-ја
21
Топ 10 за безбедност на API не е доволен!
23
Заклучок
23
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
2/23
Бидејќи компаниите усвоија cloud-native инфраструктура и методологии во стилот на DevOp, web Интерфејсите за програмирање на апликации, или API-јата, се проширија. Некои од најпопуларните јавни API-ја вклучуваат оние што им овозможуваат на програмерите пристап до Google Search, да собираат податоци од TikTok, да следат возила, да собираат спортски резултати и податоци за преземања на слики од популарни страници.1 Во 2023 година, сообраќајот поврзан со API сочинува 58 проценти од целиот динамичен - дефиниран како сообраќај што не може да се зачува во кешот, во споредба со 54 проценти на крајот од 2021.2 година.XNUMX
API-интерфејсите станаа начин преку кој корпоративните апликации комуницираат и се интегрираат едни со други. Компаниите користат околу две третини од нивните API-интерфејси (64%) за поврзување на своите апликации со партнери, додека околу половина (51%) се пристапни точки до микросервиси. Генерално, повеќе од три четвртини од фирмите користат просечно најмалку 25 API-интерфејси по апликација.3
Усвојувањето на инфраструктура за апликации базирана на API не треба да биде изненадување: Компаниите што прифаќаат API за да привлечат развивачи од трети страни и да создадат екосистеми забележуваат зголемен раст. Овие „инвертирани фирми“ - така наречени затоа што ги превртуваат традиционалните концепти за создавање бариери околу технологиите и овозможуваат отворен пристап до некои можности и податоци - пораснаа за речиси 13 проценти во текот на две години и 39 проценти во текот на 16 години, во споредба со фирмите кои не прифатија API, според труд од 2022 година од истражувачите на Универзитетот Чепмен и Универзитетот Бостон.4
Сепак, со усвојувањето на микросервиси, контејнеризација и API-ја, доаѓаат и различни ризици, како што се небезбедни софтверски компоненти, лоша деловна логика и несоодветна безбедност на податоците. Девет од десет организации (92%) претрпеле барем еден безбедносен инцидент поврзан со небезбедни API-ја.5 Големите компании обично имаат илјадници API-ја, а нападите врз тие системи сочинуваат околу 20 проценти од безбедносните инциденти, додека помалите компании имаат стотици API-ја чија помала површина на напад учествува со пет проценти од безбедносните инциденти.6 Годишните загуби поради прекршувања предизвикани од ранливости на API-јата надминуваат 40 милијарди долари на глобално ниво, според проценка на Марш Мекленан.7
1 Арелано, Кели. Топ 50 најпопуларни API-ја. Блог на RapidAPI. RapidAPI. Web Страница. 16 март 2023 година.
2 Треманте, Мајкл и др. Извештај за безбедноста на апликациите: втор квартал од 2 година. Блог на Cloudflare. Cloudflare. Објава на блогот. 2023 август 21 година.
3 Маркс, Мелинда. Обезбедување на површината за напад на API. Група за стратегија на претпријатија. Спонзорирано од Palo Alto Networks. PDF извештај, стр. 10. 23 мај 2023 година.
4 Бензел, Сет Г., и др. Како API-ата создаваат раст со инвертирање на фирмата. Мрежа за истражување на општествените науки. Истражувачки труд. Ревидирано: 30 декември 2022 година.
5 Обезбедување на површината за напад на API. Enterprise Strategy Group, стр. 14. 6 Лемос, Роберт. Загубите на безбедноста на API се вкупно милијарди, но е комплицирано. Темно читање.
Весник. 30 јуни 2022 година. 7 Марш Мекленан. Квантифицирање на трошоците за несигурност на API. Спонзорирано од Имперва.
PDF извештај. 22 јуни 2022 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
3/23
Листата „Топ 2023“ за безбедност на API за 10 година ги истакнува десетте најчести и најсериозни безбедносни ризици што се создаваат при развивање апликации што изложуваат или користат API-ја.
Проблемот е толку сериозен што Агенцијата за национална безбедност на САД се здружи со Австралискиот центар за сајбер безбедност (ACSC) и Агенцијата за сајбер безбедност и инфраструктура на САД (CISA) за да понуди насоки за безбедносните проблеми на API, особено за најчестите, познати како небезбедни ранливости на директна референца на објекти (IDOR).8
Не е изненадувачки што, наспроти оваа позадина на растечки безбедносни загрижености, Проектот за отворена светска безбедност на апликации (OWASP) објави ажурирање на својата листа „Топ 10“ за безбедност на API. Освежувајќи ја својата прва листа за 2019 година, листата „Топ 2023“ за безбедност на API за 10 година ги истакнува десетте најчести и најсериозни безбедносни ризици создадени при развивање апликации што изложуваат или користат API. Проблеми како што се Неисправна авторизација на ниво на објект, суперсет што вклучува ранливости на IDOR, останува ист од претходната листа. Сепак, новите категории - или реорганизираните категории - сега ги истакнуваат проблемите што биле занемарени во минатото, како што се Фалсификување на барања од страна на серверот (API7:2023) и Неограничен пристап до чувствителни деловни текови (API6:2023).
„По природа, API-јата откриваат логика на апликацијата и чувствителни податоци како што се лични информации (PII) и поради ова, API-јата сè повеќе стануваат цел на напаѓачите“, изјави групата OWASP во своето соопштение.9 „Без безбедни API-ја, брзата иновација би била невозможна“.
8 нови совети за сајбер безбедност предупредуваат за Web Ранливости на апликацијата. Национална безбедносна агенција. Соопштение за медиумите. 27 јули 2023 година.
9 Отворен проект за безбедност на апликации низ целиот свет. Безбедност на OWASP API Топ 10: Напред. OWASP.org. Web Страница. 3 јули 2023 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
4/23
Лист за безбедност на API со измами
OWASP Топ 10 категорија 1. Неисправна авторизација на ниво на објект 2. Неисправна автентикација 3. Неисправна авторизација на ниво на својство на објект 4. Неограничена потрошувачка на ресурси 5. Неисправна авторизација на ниво на функција 6. Неограничен пристап до чувствителни деловни текови 7. Фалсификување на барања од страна на серверот 8. Погрешна конфигурација на безбедноста 9. Неправилно управување со залихи 10. Небезбедна потрошувачка на API-ја
Решение за сајбер безбедност SAST SAST, DAST SAST, DAST SAST, DAST, безбеден менаџер API SAST DAST DAST SAST, DAST Secure API Manager SCA, SAST
Дефиниции
Крајна точка на API – Точката на комуникација помеѓу два система, обично URL на контејнер или сервер што извршува микросервис. Користејќи URL, апликацијата или развивачот можат да побараат информации од серверот или да извршат дејство на API серверот или микросервисот.
Сообраќај поврзан со API – Интернет сообраќај што се состои од HTTP или HTTPS барање и има содржина на одговор од XML или JSON, што укажува дека податоците се пренесуваат до апликација, обично преку SOAP, WSDL, REST API или gRPC (видете подолу).
Динамичко тестирање на безбедноста на апликациите (DAST) – Процес на анализа на апликација или API сервер со користење на интерфејсот, без разлика дали е корисничкиот интерфејс за апликацијата, web преден дел за web апликација, или URLs за API крајни точки. Кај типот на тестирање со црна кутија, овој пристап ја оценува апликацијата од „надвор кон внатре“ со напаѓање на апликацијата на ист начин како напаѓачот, обично без познавање на внатрешните процеси.
Статичко тестирање на безбедноста на апликациите (SAST) – пристап кон безбедноста на апликациите што го скенира изворниот, бинарниот или бајт-кодот за препознаени шеми на грешки или ранливости. Понекогаш се нарекува тестирање на бела кутија, SAST користи пристап „одвнатре кон надвор“ што ги идентификува потенцијалните ранливости и грешки што може, или не, да бидат искористливи од надворешен напаѓач. Лесните статички алатки можат да обезбедат повратни информации во реално време за програмерите во нивното IDE.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
5/23
Авторизацијата на неисправно ниво на објект е широко распространет и лесен за експлоатација проблем во web апликации бидејќи API повиците носат информации за состојбата. Апликациите се ранливи ако му дозволат на корисникот да презема дејства со наведување на идентификатор во API без да провери дали има овластување да ги преземе тие дејства.
SOAP/WSDL – XML-базиран протокол за креирање Web API-ја. SOAP е самиот протокол и WSDL (Web Јазик за дефиниција на услуги) е форматот што се користи за формално опишување на услугите. Поради големите трошоци, овој API стил стана непопуларен за новите случувања.
РЕСТОРАН–А Web API стил кој вклучува размена на пораки директно преку HTTP, користејќи ја семантиката на HTTP URLs и глаголи, без употреба на дополнителен „плик“. Содржината обично е кодирана како JSON, иако во некои случаи е XML.
GraphQL – Јазик за барања дизајниран да се користи во API-ја (со барања и одговори во JSON), заедно со време на извршување на серверската страна за извршување на овие барања. Им овозможува на клиентите да ја дефинираат структурата на податоците што им се потребни, а потоа да ги добијат од серверот во тој формат.
gRPC – API протокол кој е поефикасен од REST. Користи HTTP/2 и напредни перформанси.tagшто нуди преку HTTP/1.1. Форматот на поединечните пораки е обично бинарен и базиран на ProtoBuf, повторно создавајќи предност во перформансите.tages преку REST и SOAP.
Топ 2023 за безбедност на API за 10 година
Аналоген безбедносен запис на API од 2019 година
API1:2023–Овластување на неовластено ниво на објект
API1:2019–Овластување на неовластено ниво на објект
API2:2023–Неуспешна автентикација
API2:2019–Неуспешна автентикација на корисник
API3:2023–Овластување на ниво на својство на оштетен објект
API3:2019–Прекумерна изложеност на податоци, API6:2019–Масовно доделување
API4:2023–Неограничена потрошувачка на ресурси
API4:2019–Недостаток на ресурси и ограничување на стапката
API5:2023–Овластување на ниво на неисправна функција
API5:2019–Овластување на ниво на неисправна функција
API6:2023–Неограничен пристап до чувствителни деловни текови
API7:2023–Фалсификување на барања од страна на серверот
API8:2023–Неправилна конфигурација на безбедноста API7:2019–Неправилна конфигурација на безбедноста
API9:2023–Несоодветно управување со залихи
API9:2019–Несоодветно управување со средства
API10:2023–Небезбедна потрошувачка на API-ја
API8:2019–Вбризгување, API10:2019–Недоволно евидентирање и следење
Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ Source: https://owasp.org/API-Security/editions/2019/en/0x11-t10/
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
6/23
Програмерите и тимовите за безбедност на апликациите исто така мора правилно да имплементираат можности за проверка на идентитетот на корисникот преку автентикација.
API1:2023–Овластување на неовластено ниво на објект
Што е тоа?
API-јата овозможуваат пристап до услуги и податоци користејќи стандардизирани web барања. Компаниите ја изложуваат својата инфраструктура и податоци на небезбеден директен пристап кога тие средства не се добро заштитени или кога контролите за авторизација се слабо имплементирани или отсуствуваат. Неисправната авторизација на ниво на објект - исто така позната како небезбедна директна референца на објект (IDOR) - може да доведе до различни ризици, од откривање на податоци до целосно преземање на сметката.
Што ја прави апликацијата ранлива?
Ова е широко распространет и лесен за експлоатација проблем во web апликации. Апликациите се ранливи ако му дозволуваат на корисникот да презема дејства со наведување на идентификатор во API без да провери дали има овластување да ги преземе тие дејства.
Во ексampДетално опишано од OWASP, платформа за онлајн продавници би можела да овозможи пристап до податоците за продавниците со едноставен повик:
/продавници/{именапродавница}/приходи _ податоци.json
Ова е небезбедно бидејќи секој корисник може да го замени shopName со името на продавницата на друг корисник, добивајќи пристап до податоци што не треба да ги има.
Напад ексampлес
Во 2021 година, истражувач за безбедност откри дека web-апликациските и back-end серверите што им обезбедуваа податоци на велосипедите за вежбање на Peloton имаа неколку API крајни точки што им дозволуваа на неавторизираните корисници пристап до приватни податоци. Во февруари 2021 година, Peloton имплементираше делумно решение за проблемот, ограничувајќи го пристапот до API само на автентицирани корисници, но сепак дозволувајќи им на тие корисници пристап до какви било приватни податоци за други членови. Целосното решение дојде во мај 2021.10 година.XNUMX
Како да го спречам тоа како развивач?
Програмерите спречуваат небезбеден пристап до објекти со спроведување на строги контроли, доделување непредвидливи идентификатори на корисници за да се спречи набројување на сметки и проверка на авторизацијата на ниво на објект за секоја функција што пристапува до извор на податоци. Програмерите треба да ги опфатат таквите проверки, особено ако се засновани на внес од корисникот, за да се отстрани можноста ненамерните грешки да ја поткопаат безбедноста. Професионалците за безбедност на апликациите и операции треба да бараат проверки на авторизацијата за секое барање до податоци од позадината.
Како може OpenText да помогне?
Статичкото тестирање на безбедноста на апликациите на OpenText™ (SAST) и динамичкото тестирање на безбедноста на апликациите на OpenText™ (DAST) можат да детектираат широк спектар на ранливости во категоријата Небезбедна директна референца на објекти (IDOR). IDOR може да вклучува ранливости како што се преминување на директориуми, File Постави, и File Вклучување. Поопшто, IDOR вклучува и класи на ранливости каде што идентификаторите
10 Мастерс, јануари. Тур де Пелотон: Изложени кориснички податоци. Блог на партнери за тестирање на пенкало. Партнери за тестирање на пенкало. Web Страница. 5 мај 2021 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
7/23
Програмерите и тимовите за безбедност на апликациите исто така мора правилно да имплементираат можности за проверка на идентитетот на корисникот преку автентикација.
може да се измени преку URL, Манипулација со тело или заглавие. Системот ќе ги предупреди програмерите за случаи каде што корисникот може директно да го избере примарниот клуч во барањето на API за база на податоци или контејнер за складирање, проблем што често води до оваа класа на ранливости. Системот исто така ќе предупреди кога недостасува очекувана проверка за авторизација.
API2:2023–Неуспешна автентикација
Што е тоа?
Проверките за авторизација го ограничуваат пристапот до податоци врз основа на специфични улоги или корисници, но тие ограничувања не се доволни за заштита на системите, податоците и услугите. Програмерите и тимовите за безбедност на апликациите, исто така, мора правилно да имплементираат можности за проверка на идентитетот на корисникот преку автентикација. И покрај критичната природа на автентикацијата, компонентите често се лошо имплементирани или неправилно користени - основните причини за неисправна автентикација на корисникот. Неисправната автентикација на корисникот им овозможува на напаѓачите можност привремено или трајно да ги претпостават идентитетите на другите корисници со искористување на небезбедни токени за автентикација или компромитирање на недостатоците во имплементацијата.
Што ја прави апликацијата ранлива?
Овој чест и лесен за експлоатација проблем се јавува бидејќи автентикацијата е сложен процес кој може да биде збунувачки и, по дефиниција, е изложен на јавноста. Грешките на програмерите и погрешните конфигурации на апликациите може да резултираат со недостаток на потребни проверки, дозволувајќи им на напаѓачите да избегнат автентикација. Програмерите кои не успеваат да имплементираат автентикација за одредена крајна точка или дозволуваат слаб механизам за автентикација ги изложуваат апликациите на различни напади, како што се полнење на акредитиви, повторување на токени или „шмркање“ на лозинки.
Напад ексampлес
Помеѓу февруари и јуни 2023 година, нападите со преполнување на акредитиви го насочија трговецот на облека „Хот Топик“, кој ги извести своите клиенти дека непознат број сметки се компромитирани. Напаѓачите - користејќи акредитиви собрани од непознати извори - беа во можност да пристапат до чувствителни лични податоци, како што се имињата на клиентите, е-адресите, историјата на нарачки, телефонските броеви и месеците и деновите на раѓање.11
Во февруари 2022 година, погрешно конфигурирана кофа за складирање во облак остави 1 GB чувствителни податоци од услугата за е-маркетинг Beetle Eye без заштита со лозинка или енкрипција. Податоците вклучуваа информации за контакт и информации поврзани со туризмот собрани од разни туристички агенции и американски држави.12 Погрешно конфигурираните механизми за автентикација се сметаат за варијанта на категоријата „Неисправна автентикација на корисник“.
Како да го спречам тоа како развивач?
11 Тулас, Бил. Малопродажниот синџир „Хот Топик“ открива бран напади со полнење на акредитиви. BleepingComputer. Вести. 1 август 2023 година.
12 Наир, Праџит. Податоци на 7 милиони луѓе откриени преку американската маркетинг платформа. Пробив на податоци денес. Мрежа ISMG. 11 февруари 2022 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
8/23
Стандардизацијата е ваш пријател за автентикација. Тимовите на DevSecOps треба да создадат еден – или ограничен број – методи за автентикација за апликациите и да се осигурат дека програмерите унифицирано ги имплементираат механизмите низ сите микросервиси и API-ја.
Стандардизацијата е ваш пријател за автентикација. Тимовите DevSecOps треба да создадат еден – или ограничен број – методи за автентикација за апликациите и да обезбедат дека програмерите унифицирано ги имплементираат механизмите низ сите микросервиси и API-ја. Секоја имплементација на автентикација треба повторно да сеviewед во контекст на OWASP Стандардот за верификација на безбедноста на апликациите (ASVS), моментално на верзија 4,13 за да се обезбеди точноста на имплементацијата и поврзаните безбедносни контроли. Секое отстапување од стандардот - особено секое намерно изложување на неавтентифицирани крајни точки - треба да биде оценето од безбедносниот тим и дозволено само за задоволување на силен деловен услов.
Како може OpenText да помогне?
OAuth и JWT се два од најчестите типови на автентикација што се користат за имплементација на API-ја, а OpenText Dynamic Application Security Testing има проверки за слаби имплементации на двата стандарди во апликациите, како и за погрешни конфигурации и ранливи шеми, како што се CSRF и Session Fixation, кои се појавуваат во прилагодените имплементации за автентикација. Скенирањето на алатката за динамичка безбедност на апликации (DAST) од OpenText е одличен начин за откривање на ранливости при автентикација, особено во API.
Тестирањето за безбедност на апликациите OpenText Static овозможува широк спектар на проверки поврзани со лоша автентикација. Алатката за статичка анализа вклучува откривање на генерички проблеми - како што е истекување на акредитиви - како и проблеми специфични за API-то, како што се барања за недостаток на заштита во JWT токени или барања што се појавуваат во JWT заглавија.
API3:2023–Овластување на ниво на својство на оштетен објект
Што е тоа?
Авторизацијата на ниво на неисправен имот на објект е нова категорија во листата на OWASP за 2023 година што комбинира две категории од претходната листа: Прекумерна изложеност на податоци (API3:2019) и Масовно доделување (API6:2019). Проблемот е предизвикан од недостаток на валидација на овластувањето на корисникот - или неправилно овластување на корисникот - на ниво на имот на објект. Крајните точки на API треба да потврдат дека секој корисник има овластување за секое својство до кое се обидува да пристапи или да го промени. Искористувањето на проблемот може да доведе до изложеност на информации или манипулација со податоци од страна на неовластени страни.
Што ја прави апликацијата ранлива?
Честиот и лесен за користење проблем се јавува кога корисникот може да биде овластен да пристапи до некои својства на одреден објект, како што е резервација на соба во апликација за патување, но не и до други, како што е цената на собата. Кога корисникот пристапува до својствата на објектот преку API, апликацијата треба да провери дали корисникот:
· Треба да може да добие пристап до специфичното својство на објектот
13 Стандард за верификација на безбедноста на апликациите на OWASP. OWASP. Страница на GitHub. Последен пристап: 17 ноември 2023 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
9/23
Авторизацијата на ниво на својство на скршен објект е нова категорија во листата на OWASP за 2023 година што комбинира две категории од претходната листа: Прекумерна изложеност на податоци (API3:2019) и Масовна распределба (API6:2019).
Статичкото тестирање за безбедност на апликации на OpenText™ помага да се спречи и прекумерна изложеност на податоци и масовно доделување преку анализа на протокот на податоци. Системот ќе истакне многу извори на приватни податоци, како што се оние засновани на имиња на променливи или одредени API повици, и ќе идентификува објекти што дозволуваат масовно доделување.
(прекршувањата претходно беа познати како Прекумерно изложување на податоци) и/или
· Дозволено е да се промени специфичното својство на објектот (некои апликации не успеваат да го проверат ова бидејќи користат рамка за автоматско мапирање) web барање параметри до објектни полиња, проблем познат како доделување на маса).
Во OWASP exampНа пример, онлајн видео платформата му овозможува на корисникот да го промени описот на видеото, дури и на блокираното видео, но не треба да му дозволува на корисникот да го менува својството „блокирано“.
PUT /api/video/update _ видео
{
„опис“: „смешно видео за мачки“,
„блокирано“: лажно
}
Напад ексampлес
Во јануари 2022 година, програма за наградување за грешки откри пропуст во Твитер што му дозволуваше на корисникот да достави е-адреса или телефонски број во системот на Твитер, кој потоа ќе го врати името на сметката на која припаѓаат информациите.14 Непознат напаѓач го искористи пропустот за да состави список на милиони кориснички сметки поврзани со телефонски броеви и е-адреси. Со тоа што дозволи на секого да поврзе две својства, Твитер ненамерно дозволи псевдонимните корисници да бидат поконкретно идентификувани.
Како да го спречам тоа како развивач?
Програмерите секогаш треба да имплементираат соодветни контроли врз можноста за пристап или промена на специфични својства на објектот. Наместо да враќаат општа структура на податоци со секое својство - што често се случува со генерички методи, како што се to_json() и to_string() - програмерите треба да бидат многу специфични во тоа кои информации ги враќаат. Како дополнителна мерка за безбедност, апликациите треба да имплементираат валидација на одговор базирана на шема што спроведува безбедносни контроли на сите податоци вратени од API методите. Пристапот треба да ги следи принципите на најмали привилегии, дозволувајќи пристап само доколку е апсолутно неопходно.
Како може OpenText да помогне?
Статичкото тестирање за безбедност на апликации на OpenText™ помага да се спречи и прекумерна изложеност на податоци и масовно доделување преку анализа на протокот на податоци. Системот ќе истакне многу извори на приватни податоци, како што се оние засновани на имиња на променливи или одредени API повици, и ќе идентификува објекти што дозволуваат масовно доделување. Корисниците можат да дефинираат и свои извори, следејќи ги податоците преку програмата и, доколку завршат на несоодветно место, да го известат развивачот или операторот за ризикот.
14 Инцидент што влијае на некои сметки и приватни информации на Твитер. Центар за приватност на Твитер. Твитер. Web Страница. 5 август 2022 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
10/23
Апликациите што не ги ограничуваат ресурсите доделени за задоволување на барањето можат да бидат ранливи, вклучувајќи ги и оние што не успеваат да ја ограничат доделената меморија, бројот на files или процеси до кои е пристапено, или дозволената стапка на барања, меѓу другите атрибути.
Покрај тоа, OpenText SAST има познавање на најважните механизми за серијализација и десеријализација на JSON и XML. Користејќи го ова, алатката може да детектира код кој не ги десеријализира правилно објектите за пренос на домени (DTO), што би можело да дозволи масовно доделување на неговите атрибути. Некои случаи на изложеност на информации и масовно доделување може да се детектираат и со користење на OpenText Dynamic Application Security Testing. Конечно, некои контрамерки може да се имплементираат преку додавање правила во web заштитен ѕид на апликацијата (WAF).
API4:2023–Неограничена потрошувачка на ресурси
Што е тоа?
API-интерфејсите откриваат многу корисни деловни функции. За да го сторат тоа, тие користат компјутерски ресурси како што се сервери за бази на податоци или може да имаат пристап до физичка компонента преку оперативна технологија. Бидејќи системите имаат ограничен сет на ресурси за да одговорат на API повици, напаѓачите можат специјално да изработат барања за да создадат сценарија што резултираат со исцрпување на ресурсите, одбивање на услуга или зголемени деловни трошоци. Во многу случаи, напаѓачите можат да испраќаат API барања што ги заробуваат значителните ресурси, преоптоварувајќи ја машината или ресурсите на пропусниот опсег и резултирајќи со напад со одбивање на услуга. Со испраќање повторени барања од различни IP адреси или облачни инстанци, напаѓачите можат да ги заобиколат одбраните дизајнирани да детектираат сомнителни скокови во употребата.
Што ја прави апликацијата ранлива?
API барањата активираат одговори. Без разлика дали тие одговори вклучуваат пристап до база на податоци, извршување на I/O, извршување пресметки или (сè повеќе) генерирање на излезот од модел на машинско учење, API-јата користат компјутерски, мрежни и мемориски ресурси. Напаѓачот може да испрати API барања до крајна точка како дел од напад со одбивање на услуга (DoS) кој, наместо да го преоптовари пропусниот опсег - целта на волуметрискиот DoS напад - наместо тоа ги исцрпува ресурсите на процесорот, меморијата и облакот. Апликациите што не ги ограничуваат ресурсите доделени за задоволување на барањето можат да бидат ранливи, вклучувајќи ги и оние што не успеваат да ја ограничат доделената меморија, бројот на files или процеси до кои е пристапено, или дозволената стапка на барања, меѓу другите атрибути.
API-јата за обработка на серверот треба да имаат ограничувања за да се спречи прекумерна алокација на меморија и работни оптоварувања, прекумерни барања за операции активирани од API или прекумерни трошоци за услуга од трета страна без ограничувања за трошење.
Чест напад е да се модифицираат аргументите пренесени на крајната точка на API-то, како што е зголемување на големината на одговорот и барање милиони записи во базата на податоци, наместо, да речеме, првите десет:
/api/корисници?страница=1&големина=1000000
Дополнително, ако напаѓачот може да пристапи до backend услуга која наплаќа за користење, нападите со потрошувачка на ресурси можат да се користат за да се наплатат трошоци за сопственикот на апликацијата. Друг OWASP поранешенampОва укажува на функција за ресетирање на лозинката што користи СМС-порака за потврда на идентитетот и која може да се повика илјадници пати за да се зголемат трошоците за жртвата.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
11/23
Филтрирање на работ на мрежата со користење на мрежи за испорака на содржина (CDN) спарени со web Заштитните ѕидови на апликациите (WAF) можат да ги намалат поплавите од сообраќај, а воедно да го минимизираат влијанието врз индивидуалните корисници.
ПОШТА /sms/испрати _ ресетирање _ лозинка _ код
Домаќин: willyo.net {
„телефонски _ број“: „6501113434“ }
Напад ексampлес
Бидејќи нападите со потрошувачка на ресурси често се групираат заедно со проблеми со перформансите и достапноста, целните компании имаат тенденција да ги третираат како дел од трошоците за водење бизнис, наместо како инциденти што треба да се пријават, намалувајќи ја видливоста на заканата. Во 2022 година, нападите со дистрибуирано одбивање на услуга (DDoS) на апликацискиот слој, супермножество напади со потрошувачка на ресурси на API, се намалија како удел во сите напади, но во четвртиот квартал од 4 година сепак беа регистрирани 2022% повеќе напади отколку во истиот квартал претходната година.79
Во еден напад опишан во 2015 година, еден развивач открил дека клиентот на Android постојано контактирал со неговата страница. Web API со случајно генерирани API клучеви, што резултираше со напад со одбивање на услуга. Инвеститорот претпостави дека злонамерна апликација инсталирана на Android уреди се обидува да го погоди 64-битниот API клуч.16
Како да го спречам тоа како развивач?
Со користење на ограничувања на брзината и праг, повеќето напади со потрошувачка на ресурси можат да бидат пригушени, иако легитимниот сообраќај може да биде засегнат и од лошо конструирана одбрана. Треба да се постават специфични ограничувања на:
· Распределба на меморија
· Процеси
· Инстанци во облак
· Поставено file дескриптори и file големина
· Вратени записи
· Број на платени трансакции кон услуги од трети страни
· Сите дојдовни параметри (на пр., должини на низи, должини на низи, итн.)
· Број на API интеракции по клиент во рамките на одреден временски прозорец
Филтрирање на работ на мрежата со користење на мрежи за испорака на содржина (CDN) спарени со web Заштитните ѕидови на апликациите (WAF) можат да ги намалат поплавите од сообраќај, а воедно да го минимизираат влијанието врз индивидуалните корисници. Платформите за испорака на апликации овозможуваат лесно филтрирање, вклучувајќи ограничувања на меморијата, процесорите и процесите.
15 Јоачимик, Омер. Извештај за DDoS закани од Cloudflare за четвртиот квартал од 2022 година. Блог на Cloudflare. Web Страница. 10 јануари 2023 година.
16 Како да се запре хакерски/DOS напад врз web API. StackOverflow. Web Страница. 15 септември 2015 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
12/23
Тестирањето на динамичката безбедност на апликациите OpenText може да ги тестира серверите и API функциите за ранливост на напади со одбивање на услуга без да влијае на услугата. Покрај тоа, самиот чин на извршување на DAST скенирање може да изврши доволно стрес-тестирање на околината за да ги покаже потенцијалните слабости во потрошувачката на ресурси.
Како може OpenText да помогне?
Со OpenText SAST и OpenText Dynamic Application Security Testing, DevSecOps тимовите можат да го тестираат својот код и инфраструктура за отпорност на напади со исцрпување на ресурсите. OpenText SAST може да открие многу области каде што напаѓачот би можел да ја злоупотреби логиката на апликацијата за да создаде екстремна потрошувачка на ресурси.
Безбедноста на ниво на код не е доволна за да се реши овој проблем во апликацијата. Исцрпувањето на ресурсите и ограничувањето на брзината се специфични подсегменти на нападите со одбивање на услуга кои треба да се ублажат за време на извршување. OpenText Dynamic Application Security Testing може да ги тестира серверите и API функциите за ранливост на напади со одбивање на услуга без да влијае на услугата. Покрај тоа, самиот чин на извршување на DAST скенирање може да изврши доволно стрес-тест на околината за да ги покаже потенцијалните слабости во потрошувачката на ресурси.
API5:2023–Овластување на ниво на неисправна функција
Што е тоа?
Модерната апликација има многу различни функции кои пристапуваат, креираат, манипулираат, бришат и управуваат со податоци. Не секој корисник на апликацијата има потреба од пристап до секоја функција или до сите податоци, ниту пак треба да биде дозволен според принципот на најмали привилегии. Секоја крајна точка на API има наменета публика која може да вклучува анонимни, редовни непривилегирани и привилегирани корисници. Административните и управувачките функции треба да бараат привилегирана авторизација, но понекогаш се достапни преку легитимни API повици од неовластен корисник - потеклото на неовластеното ниво на функција. Бидејќи различните хиерархии, групи и улоги создаваат сложеност во контролите за пристап, функциите на апликацијата може да немаат соодветни ограничувања за тоа кој може да ги повика.
Што ја прави апликацијата ранлива?
Апликациите што дозволуваат специфични функции да извршуваат административни задачи не смеат да го ограничат пристапот до тие функции на безбеден начин. API-јата што директно се мапираат на такви функции ќе ги изложат тие слабости на експлоатација. Функциите што не го користат механизмот за автентикација и авторизација на апликацијата треба да се сметаат за потенцијални безбедносни слабости.
Во ексampСпоред OWASP, напаѓачот добива пристап до барањата на API за додавање поканет корисник во нова мобилна апликација, забележувајќи дека поканата содржи информации за улогата на поканетиот корисник. Искористувајќи ја слабоста, напаѓачот испраќа нова покана:
ПОСТАВЕТЕ /api/invites/new
{
„е-пошта“: „attacker@somehost.com“,
„улога“: „администратор“
} Ова им овозможува да добијат администраторски привилегии на системот.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
13/23
Тимовите на DevSecOps треба да дизајнираат стандарден пристап кон авторизација и автентикација што по дифолт спречува пристап до барања, наметнувајќи ја стандардната опција „одбиј ги сите“.
Контролата на апликациите и логичките текови се срцето на секој онлајн бизнис, и како што компаниите префрлаат поголем дел од своите операции во облакот, тие текови можат да бидат изложени и експлоатирани. Овој прекумерен пристап може да му наштети на бизнисот.
Напад ексampлес
Во 2022 година, Министерството за осигурување на Тексас ја извести јавноста дека информациите на речиси два милиони Тексашани биле откриени преку дел од апликацијата за надомест на работниците што ненамерно им овозможило на членовите на јавноста пристап до заштитени податоци.17 Во втор инцидент во 2022 година, австралиската телекомуникациска фирма Optus призна дека личните информации и информациите за сметките на дури 10 милиони Австралијанци биле откриени од API што не барало никаква автентикација или овластување. Додека Optus го нарекол нападот „софистициран“, истражувач за безбедност запознаен со деталите за нападот го опишал како „тривијален“.18
Како да го спречам тоа како развивач?
Тимовите на DevSecOps треба да дизајнираат стандарден пристап кон автентикација и авторизација што по дифолт спречува пристап до барања, наметнувајќи стандардна вредност „одбиј ги сите“. Од оваа стандардна вредност, секогаш применувајте го принципот на најмали привилегии при одредување на пристапот за улоги/групи/корисници. Програмерите треба да обезбедат дека автентикацијата и авторизацијата се воспоставени за сите релевантни HTTP глаголи/методи (на пр., POST, GET, PUT, PATCH, DELETE) поврзани со секоја крајна точка на API. Нерелевантните глаголи треба да бидат оневозможени. Покрај тоа, програмерите треба да имплементираат основна класа за административен пристап и управување, користејќи наследување на класа за да се осигурат дека контролите за авторизација ја проверуваат улогата на корисникот пред да одобрат пристап. Сите критични административни функции треба да го користат механизмот за авторизација за да спречат ескалација на привилегиите.
Како може OpenText да помогне?
Со комбинирање на карактеристиките за статички код и анализа на API на OpenText™ Static Application Security Testing со проверките за време на извршување на пакетот OpenText Dynamic Application Security Testing (DAST), тимовите на DevSecOps можат да ја проценат својата апликација за проблеми со авторизација на неисправни функции и континуирано да го тестираат производствениот код за безбедносни слабости пред да ја распоредат. За да детектира проблеми со авторизација на неисправни функции на објекти, OpenText™ Static Application Security Testing користи правила што специфицираат кога би се очекувала проверка на авторизација во одредени програмски јазици и рамки, а отсуството на таква проверка се пријавува.
API6:2023–Неограничен пристап до чувствителни деловни текови
Што е тоа?
Од sneakerbots до ticket bots, нападите врз залихите на онлајн трговците на мало преку нивните API-ја станаа значаен проблем за сајтовите за е-трговија. Со разбирање на бизнис моделот и логиката на апликацијата, напаѓачот може да креира серија API повици кои автоматски можат да резервираат или купат.
17 Биферман, Џејсон. Личните податоци на 1.8 милиони Тексашани со барања за отштета од Министерството за осигурување биле изложени со години, вели ревизијата. Тексас Трибјун. 17 мај 2022 година.
18 Тејлор, Џош. Нарушување на безбедноста на податоците преку Optus: сè што знаеме досега за тоа што се случило. The Guardian. 28 септември 2022 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
14/23
Спречувањето на неограничен пристап до чувствителни деловни текови е повеќе поврзано со холистички пристап кон безбедноста на апликациите, а помалку со пронаоѓање на специфична технологија.
инвентар, со што се спречуваат други, легитимни потрошувачи да добијат пристап до производите или услугите на бизнисите. Секое API што овозможува пристап до бизнис процес може да го користи напаѓачот за да влијае на бизнисот и спаѓа под дефиницијата за неограничен пристап до чувствителни деловни текови.
Што ја прави апликацијата ранлива?
Контролата на апликациите и логичките текови се срцето на секој онлајн бизнис, и како што компаниите префрлаат поголем дел од своите операции во облакот, тие текови можат да бидат изложени и експлоатирани. Овој прекумерен пристап може да му наштети на бизнисот, кога напаѓачите го автоматизираат купувањето на производи, создаваат ботови за оставање коментари и повторно...views, или автоматизирајте ја резервацијата на стоки или услуги.
Ако апликацијата нуди крајна точка што има пристап до деловниот тек на компанијата без ограничување на пристапот до деловните операции зад крајната точка, тогаш апликацијата ќе биде ранлива. Заштитите вклучуваат ограничување на бројот на обиди за пристап од еден уред преку отпечаток од прст, откривање дали активноста потекнува од човечки актер и откривање дали е вклучена автоматизација.
Напад ексampлес
Кога билетите за Тејлор Свифт беа пуштени во продажба на Ticketmaster во ноември 2022 година, 1.5 милиони клиенти се регистрираа однапред, но повеќе од 14 милиони барања – вклучувајќи три пати повеќе сообраќај од ботови – swampги адресираа линковите за купување и API-јата штом се отвори продажбата на билети. Веб-страницата се сруши, спречувајќи многу клиенти да купуваат билети.19
Нападот од ботови за препродавачи наликуваше на оние што го уништија лансирањето на PlayStation 5 во ноември 2020 година. Проблемите со синџирот на снабдување веќе ја ограничија понудата пред лансирањето на најновата играчка конзола на Sony, но автоматизираните ботови го отежнаа пронаоѓањето на достапни единици и доведоа до астрономски цени за препродажба. Во случајот на една веб-страница за е-трговија, бројот на трансакции „додај во кошничка“ порасна од просек од 15,000 барања на час на повеќе од 27 милиони, користејќи го API-то на продавницата за директно барање производи по SKU број.20
Како да го спречам тоа како развивач?
Програмерите треба да соработуваат и со тимовите за деловно работење и со инженерските тимови за да се справат со проблемите со потенцијален злонамерен пристап до деловните текови. Деловните тимови можат да идентификуваат кои текови се изложени преку API-јата и да спроведат анализи на закани за да утврдат како напаѓачите би можеле да ги злоупотребат тие крајни точки. Во меѓувреме, програмерите треба да соработуваат со инженерските операции како дел од DevOps тимот за да воспостават дополнителни технички одбранбени мерки, како што е користење на отпечатоци од уредот за да се спречи преоптоварување на автоматизираните инстанци на прелистувачот и идентификување на шеми во однесувањето што разликуваат помеѓу човечките и машинските актери.
19 Стил, Били. Ticketmaster знае дека има проблем со бот, но сака Конгресот да го реши. Engadget. Вести. 24 јануари 2023 година.
20 Муванди, Тафара и Ворбуртон, Дејвид. Како ботовите го уништија лансирањето на PlayStation 5 за милиони гејмери. Блог на F5 Labs. F5. Web Страница. 18 март 2023 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
15/23
Најпознатиот бившampеден од нападите на SSRF вклучуваше поранешен Амазонец Web Инженер за услуги (AWS) кој искористил погрешно конфигуриран web заштитен ѕид на апликацијата (WAF) за потоа да користи пропуст на SSRF за да собере податоци од инстанца на сервер што му припаѓа на финансискиот гигант Capital One.
Оперативните тимови исто така треба повторно даview сите API-ја дизајнирани да ги користат други машини, како на пример за случаи на употреба B2B, и да се осигура дека постојат одредени одбрани за да се спречат напаѓачите да ги искористат интеракциите меѓу машините.
Како може OpenText да помогне?
Фаќањето на ранливи и чувствителни деловни текови честопати зависи од спроведување на основите. Компаниите треба да ги документираат и следат сите свои функционални API-ја и да утврдат кои од нив ги изложуваат чувствителните процеси и податоци на потенцијални напаѓачи. Логиката на апликацијата исто така треба да се анализира за логички недостатоци што би можеле да ги искористат напаѓачите.
Генерално, спречувањето на неограничен пристап до чувствителни деловни текови е повеќе поврзано со холистички пристап кон безбедноста на апликациите, а помалку со наоѓање на специфична технологија.
API7:2023–Фалсификување на барања од страна на серверот
Што е тоа?
Бекенд серверите обработуваат барања направени преку крајните точки на API. Фалсификувањето на барања од страна на серверот (SSRF) е ранливост што му овозможува на напаѓачот да натера сервер да испраќа барања во нивно име и со нивото на привилегии на серверот. Честопати нападот го користи серверот за да го премости јазот помеѓу надворешниот напаѓач и внатрешната мрежа. Основните SSRF напади резултираат со одговор вратен на напаѓачот, многу полесно сценарио од нападите на Blind SSRF, каде што не се враќа одговор, оставајќи го напаѓачот без потврда дали нападот бил успешен.
Што ја прави апликацијата ранлива?
Недостатоците на фалсификување барања од страна на серверот (SSRF) во суштина се резултат на недостаток на валидација на внесените податоци од корисникот. Напаѓачите се во можност да креираат барања и да вклучат URI што овозможува пристап до целната апликација.
Современи концепти во развојот на апликации, како што се webКуките и стандардизираните апликациски рамки го прават SSRF почест и поопасен, според OWASP.
Во ексampле цитирано од OWASP, социјална мрежа што им овозможува на корисниците да поставуваат проfile сликите би можеле да бидат ранливи на SSRF, ако серверот не ги потврди аргументите испратени до апликацијата. Наместо URL покажувајќи кон слика, како на пример:
ПОСТ /api/profile/качи _ слика
{
„слика _“ url": "http://example.com/profile _ слика.jpg”
}
Напаѓачот може да испрати URI што може да утврди дали одреден порт е отворен користејќи го следниов API повик:
{ „слика _ url": "локален домаќин: 8080"
}
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
16/23
Неправилната безбедносна конфигурација вклучува поставување апликации со ранливи стандардни конфигурации, дозволување премногу попустлив пристап до чувствителни функции и податоци и јавно откривање информации за апликацијата преку детални пораки за грешки.
Дури и во случај на Blind SSRF, напаѓачот може да утврди дали портата е отворена со мерење на времето потребно за да се добие одговор.
Напад ексampлес
Најпознатиот бившampеден од нападите на SSRF вклучуваше поранешен Амазонец Web Инженер за услуги (AWS) кој искористил погрешно конфигуриран web заштитен ѕид на апликацијата (WAF) за потоа да користи SSRF пропуст за собирање податоци од инстанца на сервер што му припаѓа на финансискиот гигант Capital One. Инцидентот, кој се случи во јули 2019 година, резултираше со кражба на податоци од приближно 100 милиони граѓани на САД и шест милиони канадски граѓани.21 Amazon ја смета погрешната конфигурација за извор на компромитирање, а не пропустот SSRF.22
Во октомври 2022 година, фирма за безбедност во облак го извести Мајкрософт за четири SSRF ранливости во водечката облак платформа Azure на компанијата. Секоја ранливост влијаеше на различна услуга на Azure, вклучувајќи ја услугата за машинско учење Azure и услугата за управување со API на Azure.23
Како да го спречам тоа како развивач?
Програмерите треба да ги енкапсулираат механизмите за преземање ресурси во нивниот код, изолирајќи ја функцијата и поставувајќи слоевити заштити за да ги потврдат сите барања. Бидејќи ваквите функции обично се користат за преземање оддалечени ресурси, а не внатрешни, програмерите треба да ги конфигурираат енкапсулираните функции да користат листа на дозволени оддалечени ресурси и да ги блокираат обидите за пристап до внатрешни ресурси. HTTP пренасочувањето треба да биде оневозможено за функциите за преземање ресурси и сите барања да бидат анализирани за злонамерен код.
Ризикот од слабости на SSRF не може секогаш целосно да се елиминира, па затоа компаниите треба внимателно да го земат предвид ризикот од користење повици до надворешни ресурси.
Како може OpenText да помогне?
Тестирањето за динамичка безбедност на апликациите на OpenText им овозможува на тимовите од DevSecOps редовно да тестираат за фалсификување на барања од страна на серверот. Тестирањето за динамичка безбедност на апликациите на OpenText™ скенира апликациски сервер во конфигурирана средина, така што сите компоненти - апликација, сервер и мрежа - можат да бидат тестирани, давајќи ѝ на платформата за динамичка анализа сеопфатна view за влијанието на барањата од серверот.
OpenText SAST може да открие многу случаи на SSRF преку анализа на загадувања - на пр.ampт.е. ако апликацијата користи невалидиран кориснички внес за да конструира URL тоа потоа ќе биде преземено. Алатката ќе го означи користењето на неограничен внес на корисник.
21 Информации за сајбер инцидентот во „Капитол Уан“. Адвајзор на „Капитол Уан“. Web Страница. Ажурирано на 22 април 2022 година.
22 Нг, Алфред. Амазон им кажува на сенаторите дека не е виновен за прекршувањето на безбедноста на Capital One. CNET News. com. Вести. 21 ноември 2019 година.
23 Шитрит, Лидор Бен. Како Орка пронајде ранливости на фалсификување барања од страна на серверот (SSRF) во четири различни Azure услуги. Блог за безбедност на Орка. Web Страница. 17 јануари 2023 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
17/23
Безбедноста-како-код може да помогне, со тоа што ќе ги направи конфигурациите повторливи и ќе им даде можност на тимовите за безбедност на апликациите да постават стандардни конфигурациски сетови за специфични компоненти на апликацијата.
API8:2023–Погрешна безбедносна конфигурација
Што е тоа?
Програмерите често погрешно ги конфигурираат своите апликации, не успевајќи да ги одвојат развојните од производствените средства, извезувајќи чувствителни податоци. files–таква конфигурација files–до нивните јавни складишта и неможност за промена на стандардните конфигурации. Безбедносната погрешна конфигурација вклучува поставување апликации со ранливи стандардни конфигурации, дозволување премногу попустлив пристап до чувствителни функции и податоци и јавно откривање информации за апликацијата преку детални пораки за грешки.
Што ја прави апликацијата ранлива?
Стандардните конфигурации на апликациите често се премногу попустливи, им недостасува зајакнување на безбедноста и ги оставаат инстанците за складирање во облак отворени за јавноста. Честопати, web Рамките врз кои се базираат апликациите вклучуваат мноштво функции на апликацијата кои не се потребни и чие вклучување ја намалува безбедноста.
Во ексampКако што е детално опишано од OWASP, социјалната мрежа што нуди функција за директно испраќање пораки треба да ја заштити приватноста на корисниците, но нуди API барање за преземање на специфичен разговор користејќи го следниов пример:ampбарањето на API:
ДОБИЈ /dm/user _ updates.json?conversation _ id=1234567&cursor=GRlFp7LCUAAAA
Крајната точка на API не ги ограничува податоците складирани во кешот, што резултира со кеширање на приватни разговори од страна на web прелистувач. Напаѓачите би можеле да ги преземат информациите од прелистувачот, откривајќи ги приватните пораки на жртвата.
Напад ексampлес
Во мај 2021 година, фирма за безбедност во облак го извести Microsoft дека најмалку 47 различни клиенти не успеале да ја променат стандардната конфигурација на нивните инстанци на Microsoft Power Apps. Засегнатите организации вклучуваа компании, како што се American Airlines и Microsoft, и државни влади, како што се оние на Индијана и Мериленд, и изложија 38 милиони записи на потенцијално компромитирање низ порталите на Power Apps.24
Во 2022 година, фирма за управување со ранливости откри дека 12,000 инстанци во облак се хостирани на Amazon. Web Услугите и 10,500 хостирани на Azure продолжија да го изложуваат Telnet, протокол за далечински пристап кој се смета за „несоодветен за каква било употреба базирана на интернет денес“, според извештај од 2022 година.25 Вклучувањето на непотребни и небезбедни функции ја поткопува безбедноста на API-јата и апликациите.
24 Истражување на Upguard. Дизајнирано: Како стандардните дозволи на Microsoft Power Apps открија милиони. Блог за истражување на Upgard. Web Страница. 23 август 2021 година.
25 Бердсли, Тод. Извештај за погрешни конфигурации на облакот од 2022 година. Rapid7. PDF извештај. стр. 12. 20 април 2022 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
18/23
Слепа точка во документацијата е кога деталите за намената, функционирањето и версионирањето на API-то се нејасни поради недостаток на документација што ги детализира овие важни атрибути.
Како да го спречам тоа како развивач?
Тимовите на DevSecOps треба да ги разберат чекорите потребни за креирање безбедни конфигурации за нивните апликации и да користат автоматизиран процес на развој за проверка на конфигурацијата. fileпред распоредување, вклучувајќи редовни тестови на единици и проверки за време на извршување за континуирана проверка на софтверот за грешки во конфигурацијата или безбедносни проблеми. Безбедноста-како-код може да помогне, со тоа што ќе ги направи конфигурациите повторливи и ќе им даде можност на тимовите за безбедност на апликациите да постават стандардни конфигурациски сетови за специфични компоненти на апликацијата.
Како дел од нивниот безбеден развоен циклус, програмерите и оперативните тимови треба:
· Воспоставување процес на стврднување што го поедноставува повторното креирање и одржување на безбедна апликациска средина,
· Повторноview и ажурирајте ги сите конфигурации низ API стекот за доследно да го инкорпорирате новиот стандард, и
· Автоматизирајте ја проценката на ефективноста на конфигурациските поставки во сите средини.
Како може OpenText да помогне?
Статичкото тестирање за безбедност на апликации на OpenText може да ги провери конфигурациите за време на процесот на развој и да открие многу видови слабости. Бидејќи погрешните безбедносни конфигурации се јавуваат и на ниво на апликациски код и на ниво на инфраструктура, различни OpenText производи можат да се користат за откривање на погрешни конфигурации.
Скенирањата за тестирање на безбедноста на статичките апликации на OpenText можат да проверат дали кодот на апликацијата има проблеми со погрешна конфигурација. За време на проверката на статичката анализа, OpenText SAST може да ја процени конфигурацијата. files за безбедносни грешки, вклучувајќи ги и оние за Docker, Kubernetes, Ansible, Amazon Web Шаблони за Services, CloudFormation, Terraform и Azure Resource Manager.
Грешките во конфигурацијата може да се откријат и за време на извршувањето. OpenText Dynamic Application Security Testing им овозможува на тимовите DevSecOps редовно да тестираат за вообичаени безбедносни грешки. Една од најголемите предности на DAST скенирањето е тоа што работи на апликацискиот сервер во конфигурирана средина, што значи дека целата околина - апликацијата, серверот и мрежата - се тестираат одеднаш, давајќи ѝ на платформата за динамичка анализа сеопфатен view на производствената средина е конфигурирана.
API9:2023–Несоодветно управување со залихи
Што е тоа?
Како и повеќето софтверски средства, API-јата имаат животен циклус, при што постарите верзии се заменуваат со побезбедни и поефикасни API-ја или, сè повеќе, користат API поврзани со услуги од трети страни. DevSecOps тимовите кои не ги одржуваат своите API верзии и документација можат да воведат ранливости кога постарите, неисправни API верзии продолжуваат да се користат - слабост позната како несоодветно управување со залихи. Најдобрите практики за управување со залихи бараат следење на
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
19/23
API верзии, редовната проценка и попис на интегрираните услуги и редовното застарување на постарите верзии за да се спречи ширењето на безбедносните ранливости.
Што ја прави апликацијата ранлива?
Софтверските архитектури што зависат од API-јата - особено оние што користат микросервисни архитектури - имаат тенденција да изложуваат повеќе крајни точки отколку традиционалните web апликации. Множеството крајни точки на API, заедно со веројатноста за постоење на повеќе верзии на API во исто време, бара дополнителни ресурси за управување од давателот на API за да се спречи проширување на површината за напад. OWASP идентификува две главни слепи точки што DevSecOps тимовите може да ги имаат во врска со нивната API инфраструктура.
Прво, слепа точка во документацијата е кога деталите за намената, функционирањето и версионирањето на API-то се нејасни поради недостаток на документација што ги детализира овие важни атрибути.
Второ, слепа точка на протокот на податоци се јавува кога API-јата се користат на начини кои немаат јасност, што резултира со можности кои не треба нужно да се дозволат без силна деловна оправданост. Споделувањето чувствителни податоци со трета страна без безбедносни гаранции, недостатокот на видливост на крајниот резултат од протокот на податоци и неуспехот да се мапираат сите текови на податоци во поврзани API-ја се сè слепи точки.
Како ексampНа пример, извештајот на OWASP наведува фиктивна социјална мрежа која овозможува интеграција со независни апликации од трети страни. Иако е потребна согласност од крајниот корисник, социјалната мрежа не одржува доволна видливост во протокот на податоци за да ги спречи страните од понатамошниот тек да пристапат до податоците, како што е следење на активноста не само на корисникот, туку и на неговите пријатели.
Напад ексampлес
Во 2013 и 2014 година, дури 300,000 луѓе учествувале во онлајн психолошки квиз на платформата на Фејсбук. Компанијата зад квизот, Кембриџ Аналитика, не само што собрала информации за тие корисници, туку и за нивните поврзани пријатели - популација која броела дури 87 милиони луѓе, од кои огромното мнозинство не дало дозвола за собирање на нивните информации. Потоа компанијата ги користела информациите за да ги прилагоди рекламите и пораките до тие луѓе во име на своите клиенти, вклучително и испраќање политички реклами во поддршка на Трамп.ampаин на изборите во 2016 година.26 Недостатокот на видливост на Фејсбук за тоа како трети страни ги користеле информациите собрани од неговата платформа е поранешенampле на неправилно управување со залихите.
Како да го спречам тоа како развивач?
Тимовите на DevSecOps треба да ги документираат сите API хостови и да се фокусираат на одржување на видливоста на протокот на податоци помеѓу API-јата и услугите од трети страни. Примарниот начин да се спречи неправилно управување со залихите е деталната документација на критичните аспекти на сите API услуги и хостови, вклучувајќи информации за тоа кои податоци тие ги обработуваат, кој има пристап до хостовите и податоците,
26 Розенберг, Метју и Денс, Габриел. „Вие сте производот“: На мета на Кембриџ Аналитика на Фејсбук. Њујорк Тајмс. Весник. 8 април 2018 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
20/23
Организациите можат да управуваат, следат, обезбедуваат и документираат користењето на нивните API-ја користејќи го OpenText Secure API Manager од OpenText, кој им овозможува на тимовите за безбедност на апликациите да одржуваат ажуриран инвентар на API-средствата.
и специфичните API верзии на секој хост. Техничките детали што треба да се документираат вклучуваат имплементација на автентикација, справување со грешки, одбрани за ограничување на брзината, политика за споделување на ресурси со вкрстено потекло (CORS) и детали за секоја крајна точка.
Значителниот обем на документација е тежок за рачно управување, па затоа се препорачува генерирање документација преку континуиран процес на интеграција и користење на отворени стандарди. Пристапот до документацијата на API треба да биде ограничен и на оние програмери кои се овластени да го користат API-то.
За време на фазите на градење и тестирање на апликации, програмерите треба да избегнуваат користење на податоци за производство при развој или...tagизменети верзии на апликацијата за да се спречи протекување на податоци. Кога ќе се објават нови верзии на API-јата, тимот на DevSecOps треба да направи анализа на ризик за да го одреди најдобриот пристап за надградба на апликациите за да се искористи предноста.tagе на зголемена безбедност.
Како може OpenText да помогне?
Организациите можат да управуваат, следат, обезбедуваат и документираат користење на нивните API-ја користејќи го OpenText™ Secure API Manager, кој им овозможува на тимовите за безбедност на апликациите да одржуваат ажуриран инвентар на API-средства. OpenText Secure API Manager обезбедува авторитативно складиште каде што вашиот DevSecOps тим може да ги складира и управува сите API-ја што ги користи организацијата, овозможувајќи лесен за управување животен циклус од развојот на API-јата до нејзиното повлекување. Софтверот помага да се подобри усогласеноста со прописите и лиценцирањето со тоа што овозможува детална аналитика.
API10:2023–Небезбедна потрошувачка на API-ја
Што е тоа?
Со зголемената употреба на нативна облачна инфраструктура за креирање апликации, API-јата станаа точка на интеграција помеѓу компонентите на апликацијата. Сепак, безбедносната положба на услугите од трети страни до кои се пристапува преку API-јата ретко е јасна, дозволувајќи им на напаѓачите да утврдат на кои услуги се потпира апликацијата и дали некоја од тие услуги има безбедносни слабости. Програмерите имаат тенденција да им веруваат на крајните точки со кои нивната апликација комуницира без да ги проверуваат надворешните или API-јата од трети страни. Ова небезбедно консумирање на API-јата често води до потпирање на апликацијата на услуги кои имаат послаби безбедносни барања или немаат фундаментално зајакнување на безбедноста, како што е валидација на влезот.
Што ја прави апликацијата ранлива?
Програмерите имаат тенденција да им веруваат на податоците добиени од API-јата на трети страни повеќе отколку на внесените податоци од корисниците, иако двата извори се во суштина еквивалентни за мотивиран напаѓач. Поради оваа погрешно поставена доверба, програмерите во суштина завршуваат потпирајќи се на послаби безбедносни стандарди поради недостаток на валидација и дезинфекција на внесените податоци.
Небезбедна потрошувачка на API-јата може да се појави ако апликацијата:
· Користи или троши други API-ја користејќи неенкриптирани комуникации,
· Не успева да ги потврди и дезинфицира податоците од други API-ја или услуги,
· Овозможува пренасочување без никакви безбедносни проверки, или
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
21/23
Доколку развивачот не внесе безбедносни проверки во својата апликација за да потврди какви било податоци вратени од крајната точка на API-то, неговата апликација ќе го следи пренасочувањето и ќе испрати чувствителни медицински информации до напаѓачот.
Топ 10 за безбедност на OWASP API е клучен за cloud-native програмерите кои градат API-ја. Сепак, решавањето на вообичаените ранливости на апликациите како што се SQL инјектирање, изложеност на податоци и погрешна конфигурација на безбедноста треба да има приоритет, бидејќи тие често се експлоатираат од сајбер закани. Топ 10 за безбедност на API е суштински дел од развојот на безбеден софтвер, но треба да биде второстепен во однос на решавањето на општите ранливости на апликациите.
· Не успева да ја ограничи потрошувачката на ресурси користејќи прагови и тајмаути.
Во ексampСпоред извештајот на OWASP, API кое се интегрира со давател на услуги од трета страна за складирање на чувствителни медицински информации на корисниците може да испраќа приватни податоци преку крајна точка на API. Напаѓачите би можеле да го компромитираат домаќинот на API од трета страна за да одговори на идните барања со 308 Трајно пренасочување: HTTP/1.1 308 Трајно пренасочување
Локација: https://attacker.com/
Доколку развивачот не внесе безбедносни проверки во својата апликација за да потврди какви било податоци вратени од крајната точка на API-то, неговата апликација ќе го следи пренасочувањето и ќе испрати чувствителни медицински информации до напаѓачот.
Напад ексampлес
Во декември 2021 година, збир на ранливости во најчесто користената компонента на софтверот со отворен код, Log4J, му дозволија на напаѓачот да обезбеди нечистен влез, како што е кодирана скрипта, и да користи ранливи верзии на Log4J за да ја изврши скриптата на серверот. Проблемот зад ранливоста Log4J потекнува од недостаток на валидација на влезот, поточно од неуспехот да се спроведат безбедносни проверки на десеријализирани податоци доставени од корисникот. Со испраќање серијализиран злонамерен код, напаѓачите би можеле да ја искористат ранливоста и да извршат напад на сервер со ранливоста. Програмерите треба да ги проверат сите влезни податоци обезбедени од API-јата на трети страни и други надворешни извори.27
Како да го спречам тоа како развивач?
Програмерите треба да спроведат длабинска анализа при оценување на давателите на услуги, проценување на нивната безбедносна состојба на API-јата и спроведување на строги безбедносни контроли. Покрај тоа, програмерите треба да потврдат дека сите комуникации до API-јата на трети страни и од трети страни до API-јата на организацијата користат безбеден комуникациски канал за да се спречат напади со шпионирање и повторување.
При примање податоци од надворешни корисници и машини, влезните податоци секогаш треба да се чистат за да се спречи ненамерно извршување на код. Конечно, за cloud услуги интегрирани преку API-ја, треба да се користат листи на дозволи за заклучување на адресата на интегрираното решение, наместо слепо да се дозволува која било IP адреса да го повикува API-то на апликацијата.
Како може OpenText да помогне?
Со комбинирање на функциите за анализа на статичкиот код и API на OpenText Static Application Security Testing со проверките за време на извршување на пакетот OpenText Dynamic Application Security Testing (DAST), тимовите на DevSecOps можат да ја проверат употребата на API-ја од трети страни во нивната апликација и да тестираат вообичаени типови на напади. За да пронајде небезбедни API-ја, OpenText Secure API Manager може да изгради складиште на сите API-ја повикани од системот, како и кои надворешни апликации можат да ги користат API-јата на вашата апликација.
27 Microsoft Threat Intelligence. Упатство за спречување, откривање и барање експлоатација на ранливоста Log4j 2. Microsoft. Web страница. Ажурирано: 10 јануари 2022 година.
Водич за програмери за OWASP Топ 2023 за 10 година за безбедност на API
22/23
Каде да се оди понатаму
Еве ги производите споменати во овој документ: Безбедност на апликации OpenText >
Тестирање на безбедноста на статичната апликација на OpenText >
Тестирање на динамичката безбедност на апликациите на OpenText >
Менаџер на безбеден API на OpenText >
Дополнителни ресурси 10-те најголеми безбедносни ризици на API-то на OWASP – 2023 >
Гартнер Магичен квадрант за тестирање на безбедноста на апликациите >
Безбедност на апликацијата OpenText WebСерија Инар >
Топ 10 за безбедност на API не е доволен!
За cloud-native програмерите кои се специфично фокусирани на креирање API-ја за да понудат услуги на други делови од апликацијата, внатрешни корисници или за глобална потрошувачка, листата OWASP API Security Top 10 е важен документ за читање и разбирање.
Сепак, OWASP API Security Top 10 не е самостоен документ. Програмерите исто така треба да се осигурат дека користат други извори на најдобри практики, како што е OWASP Top 10, кои се релевантни за нивната тековна апликација и архитектура. Честите ранливости на апликациите - SQL инјектирање, изложеност на податоци и погрешна конфигурација на безбедноста - продолжуваат да бидат вообичаени начини на кои групите за сајбер-закани можат да ја компромитираат корпоративната инфраструктура и треба брзо да се санираат. Покрај тоа, некои апликации базирани на API, како што се мобилните апликации, бараат различни чекори за зајакнување на безбедноста на апликациите од самостојниот документ. web-app, и различно од она што може да биде потребно за конективни и IoT уреди. Генерално, листата на API Security Top 10 е важна, но останува само еден аспект од целокупниот животен циклус на развој на безбеден софтвер. Листата и листата на OWASP Top 10 треба да се користат во комбинација со сите други релевантни стандарди и најдобри практики што се потребни за решението што се анализира.
Заклучок
Бидејќи апликациите сè повеќе се потпираат на облачна инфраструктура, web Интерфејсите за апликациски програми (API) станаа основа на Интернетот. Компаниите обично имаат стотици, ако не и илјадници, API крајни точки во нивната околина, драматично зголемувајќи ја површината на напад и изложувајќи ги апликациите на различни слабости.
Објавувањето на листата на OWASP API Security Top 2023 за 10 година е добра почетна точка за компаниите и програмерите да се едуцираат за ризиците од инфраструктурата базирана на API и да ги проценат сопствените апликации. Заедно со попознатата листа на Application Security Top-10, двата рангирања можат да им помогнат на DevSecOps тимовите да развијат холистички пристап кон целокупната безбедност на нивните апликации.
DevSecOps тимовите треба да бидат свесни за безбедносните импликации на API-јата, како да ги намалат ранливостите и безбедносните слабости на имплементацијата и како да го зајакнат својот развоен процес и резултирачкиот API сервер за да им отежнат на напаѓачите да компромитираат апликација преку нејзините API-ја.
Авторски права © 2025 Отворен текст · 04.25 | 262-000177-001
Документи / ресурси
 |
OpenText 262-000177-001 OWASP Топ 10 за безбедност на API [pdf] Упатство за користење 262-000177-001, 262-000177-001 OWASP Топ 10 за безбедност на API, 262-000177-001, OWASP Топ 10 за безбедност на API, За безбедност на API, безбедност на API, безбедност |