Асноўныя ўразлівасці API OATH
Асноўныя ўразлівасці API OATH: увядзенне
Што тычыцца эксплойтаў, лепш за ўсё пачаць з API. API доступ звычайна складаецца з трох частак. Кліентам токены выдае сервер аўтарызацыі, які працуе разам з API. API атрымлівае токены доступу ад кліента і на іх аснове прымяняе даменныя правілы аўтарызацыі.
Сучасныя праграмы ўразлівыя да розных небяспек. Будзьце ў курсе апошніх эксплойтаў і недахопаў бяспекі; мець тэсты для гэтых уразлівасцяў вельмі важна для забеспячэння бяспекі прыкладання да таго, як адбудзецца атака. Прыкладанні іншых вытворцаў усё часцей спадзяюцца на пратакол OAuth. Дзякуючы гэтай тэхналогіі карыстальнікі атрымаюць лепшы агульны вопыт, а таксама больш хуткі ўваход і аўтарызацыю. Гэта можа быць больш бяспечным, чым звычайная аўтарызацыя, паколькі карыстальнікам не трэба раскрываць свае ўліковыя даныя ў староннім дадатку, каб атрымаць доступ да дадзенага рэсурсу. У той час як сам пратакол бяспечны і бяспечны, спосаб яго рэалізацыі можа пакінуць вас адкрытымі для нападаў.
Пры распрацоўцы і размяшчэнні API гэты артыкул прысвечаны тыповым уразлівасцям OAuth, а таксама розным мерам бяспекі.
Зламаная аўтарызацыя на ўзроўні аб'екта
У выпадку парушэння аўтарызацыі існуе шырокая зона атакі, паколькі API забяспечваюць доступ да аб'ектаў. Паколькі элементы, даступныя праз API, павінны прайсці аўтэнтыфікацыю, гэта неабходна. Рэалізуйце праверкі аўтарызацыі на ўзроўні аб'ектаў з дапамогай шлюза API. Доступ павінен быць дазволены толькі тым, хто мае адпаведныя ўліковыя даныя дазволу.
Парушаная аўтэнтыфікацыя карыстальніка
Несанкцыянаваныя токены - яшчэ адзін часты спосаб для зламыснікаў атрымаць доступ да API. Сістэмы аўтэнтыфікацыі могуць быць узламаныя або ключ API можа быць памылкова адкрыты. Маркеры аўтэнтыфікацыі могуць быць выкарыстоўваецца хакерамі атрымаць доступ. Аўтэнтыфікуйце людзей, толькі калі ім можна давяраць, і выкарыстоўвайце надзейныя паролі. З OAuth вы можаце выйсці за рамкі простых ключоў API і атрымаць доступ да сваіх даных. Вы заўсёды павінны думаць пра тое, як вы будзеце ўваходзіць і выходзіць з месца. Абмежаваныя токены адпраўшчыка OAuth MTLS могуць выкарыстоўвацца ў спалучэнні з узаемным TLS, каб гарантаваць, што кліенты не будуць паводзіць сябе няправільна і не перададуць токены няправільнаму боку падчас доступу да іншых машын.
Прасоўванне API:
Празмернае ўздзеянне дадзеных
Няма абмежаванняў на колькасць канчатковых кропак, якія могуць быць апублікаваныя. У большасці выпадкаў не ўсе функцыі даступныя ўсім карыстальнікам. Адкрываючы больш дадзеных, чым гэта абсалютна неабходна, вы падвяргаеце сябе і іншых небяспецы. Пазбягайце раскрыцця адчувальных інфармацыя пакуль гэта абсалютна неабходна. Распрацоўшчыкі могуць вызначаць, хто да чаго мае доступ, выкарыстоўваючы вобласці дзеянняў і прэтэнзіі OAuth. У прэтэнзіях можа быць указана, да якіх раздзелаў даных мае доступ карыстальнік. Кантроль доступу можна зрабіць больш простым і лёгкім у кіраванні, выкарыстоўваючы стандартную структуру для ўсіх API.
Недахоп рэсурсаў і абмежаванне хуткасці
Чорныя капелюшы часта выкарыстоўваюць напады на адмову ў абслугоўванні (DoS) як метад грубай сілы, каб перагрузіць сервер і, такім чынам, скараціць час яго бесперабойнай працы да нуля. Пры адсутнасці абмежаванняў на рэсурсы, якія можна выклікаць, API уразлівы для знясільваючай атакі. «Выкарыстоўваючы шлюз API або інструмент кіравання, вы можаце ўсталяваць абмежаванні хуткасці для API. Павінны быць уключаны фільтраванне і пагінацыя, а таксама абмежаваныя адказы.
Няправільная канфігурацыя сістэмы бяспекі
Розныя рэкамендацыі па канфігурацыі бяспекі даволі поўныя з-за значнай верагоднасці няправільнай канфігурацыі бяспекі. Шэраг дробязяў можа паставіць пад пагрозу бяспеку вашай платформы. Цалкам магчыма, што чорныя капелюшы са скрытымі мэтамі могуць выявіць канфідэнцыяльную інфармацыю, адпраўленую ў адказ на няправільныя запыты, напрыклад.
Масавае заданне
Тое, што канчатковая кропка не вызначана публічна, не азначае, што распрацоўшчыкі не могуць яе атрымаць. Сакрэтны API можа быць лёгка перахоплены і сканструяваны хакерамі. Зірніце на гэты асноўны прыклад, які выкарыстоўвае адкрыты Bearer Token у «прыватным» API. З іншага боку, публічная дакументацыя можа існаваць для чагосьці, што прызначана выключна для асабістага карыстання. Адкрытая інфармацыя можа выкарыстоўвацца чорнымі капялюшамі не толькі для чытання, але і для маніпулявання характарыстыкамі аб'екта. Лічыце сябе хакерам, шукаючы патэнцыйныя слабыя месцы ў сваёй абароне. Дазволіць толькі тым, хто мае адпаведныя правы, доступ да таго, што было вернута. Каб мінімізаваць уразлівасць, абмяжуйце пакет адказаў API. Рэспандэнты не павінны дадаваць спасылкі, якія не з'яўляюцца абсалютна абавязковымі.
Рэкламны API:
Няправільнае кіраванне актывамі
Акрамя павышэння прадукцыйнасці распрацоўшчыка, бягучыя версіі і дакументацыя важныя для вашай бяспекі. Рыхтуйцеся да ўвядзення новых версій і адмены старых API загадзя. Выкарыстоўвайце больш новыя API замест таго, каб дазваляць старым заставацца ў выкарыстанні. Спецыфікацыя API можа быць выкарыстана ў якасці асноўнай крыніцы праўды для дакументацыі.
Упырск
API-інтэрфейсы ўразлівыя для ін'екцый, але таксама прыкладанні старонніх распрацоўшчыкаў. Шкоднасны код можа быць выкарыстаны для выдалення дадзеных або крадзяжу канфідэнцыяльнай інфармацыі, такой як паролі і нумары крэдытных карт. Самы важны ўрок, які трэба ўзяць з гэтага, - не залежаць ад налад па змаўчанні. Ваша кіраўніцтва або пастаўшчык шлюза павінны быць у стане задаволіць вашыя унікальныя патрэбы прыкладанняў. Паведамленні пра памылкі не павінны ўтрымліваць канфідэнцыяльную інфармацыю. Каб прадухіліць уцечку ідэнтыфікацыйных даных за межы сістэмы, у токенах трэба выкарыстоўваць парныя псеўданімы. Гэта гарантуе, што ні адзін кліент не можа працаваць разам, каб ідэнтыфікаваць карыстальніка.
Недастатковая рэгістрацыя і маніторынг
Калі атака ўсё ж адбываецца, камандам патрабуецца прадуманая стратэгія рэакцыі. Распрацоўшчыкі будуць працягваць выкарыстоўваць уразлівасці, не будучы злоўленымі, калі надзейная сістэма рэгістрацыі і маніторынгу не будзе на месцы, што павялічыць страты і пашкодзіць грамадскаму ўспрыманню кампаніі. Прыміце строгі маніторынг API і стратэгію тэсціравання канчатковай кропкі вытворчасці. Тэстэры белага капелюша, якія на ранніх стадыях выяўляюць уразлівасці, павінны быць узнагароджаны бонусамі. Журнал можа быць палепшаны шляхам уключэння асобы карыстальніка ў транзакцыі API. Пераканайцеся, што ўсе ўзроўні вашай архітэктуры API правяраюцца з дапамогай даных Access Token.
заключэнне
Архітэктары платформаў могуць абсталяваць свае сістэмы так, каб яны былі на крок наперадзе зламыснікаў, прытрымліваючыся ўстаноўленых крытэрыяў уразлівасці. Паколькі API могуць забяспечваць доступ да інфармацыі, якая дазваляе ідэнтыфікаваць асабістую асобу (PII), захаванне бяспекі такіх сэрвісаў мае вырашальнае значэнне як для стабільнасці кампаніі, так і для захавання заканадаўства, напрыклад GDPR. Ніколі не адпраўляйце токены OAuth непасрэдна праз API без выкарыстання шлюза API і падыходу Phantom Token.
Рэкламны API:
