Уплыў SQL Injection
Ін'екцыя SQL (SQLi) дазваляе зламысніку ўмешвацца ў запыты, якія прыкладанне робіць да сваёй базы дадзеных [S1]. Асноўнае ўздзеянне ўключае несанкцыянаваны доступ да канфідэнцыяльных даных, такіх як паролі карыстальнікаў, дадзеныя крэдытных карт і асабістая інфармацыя [S1].
Акрамя крадзяжу даных, зламыснікі часта могуць змяняць або выдаляць запісы базы дадзеных, што прыводзіць да пастаянных змен у паводзінах прыкладанняў або страты даных [S1]. У выпадках высокай сур'ёзнасці, SQLi можа быць узмоцнена, каб скампраметаваць серверную інфраструктуру, уключыць атакі адмовы ў абслугоўванні або забяспечыць пастаянны бэкдор у сістэмы арганізацыі [S1][S2].
Асноўная прычына: небяспечная апрацоўка ўводу
Асноўнай прычынай SQL-ін'екцыі з'яўляецца няправільная нейтралізацыя спецыяльных элементаў, якія выкарыстоўваюцца ў камандзе SQL [S2]. Гэта адбываецца, калі праграма стварае SQL-запыты, аб'ядноўваючы ўваходныя дадзеныя пад знешнім уплывам непасрэдна ў радок запыту [S1][S2].
Паколькі ўвод належным чынам не ізаляваны ад структуры запыту, інтэрпрэтатар базы дадзеных можа выканаць часткі ўводу карыстальніка як код SQL, а не разглядаць яго як літаральныя даныя [S2]. Гэтая ўразлівасць можа выяўляцца ў розных частках запыту, уключаючы аператары SELECT, значэнні INSERT або аператары UPDATE [S1].
Канкрэтныя выпраўленні і змякчэнне наступстваў
Выкарыстоўвайце параметрызаваныя запыты
Найбольш эфектыўным спосабам прадухілення ўкаранення SQL з'яўляецца выкарыстанне параметрізаваных запытаў, таксама вядомых як падрыхтаваныя аператары [S1]. Замест аб'яднання радкоў распрацоўшчыкі павінны выкарыстоўваць структураваныя механізмы, якія забяспечваюць падзел даных і кода [S2].
Прынцып найменшых прывілеяў
Праграмы павінны падключацца да базы дадзеных з самымі нізкімі прывілеямі, неабходнымі для іх задач [S2]. Уліковы запіс вэб-праграмы не павінен мець адміністрацыйных прывілеяў і павінен быць абмежаваны пэўнымі табліцамі або аперацыямі, неабходнымі для яго функцыянавання [S2].
Праверка ўводу і кадзіраванне
Нягледзячы на тое, што праверка ўводу не замяняе параметрызацыю, яна забяспечвае паглыбленую абарону [S2]. Праграмы павінны выкарыстоўваць стратэгію "прыняць-вядома-добра", правяраючы, што ўвод адпавядае чаканым тыпам, даўжыні і фарматам [S2].
Як FixVibe правярае гэта
FixVibe ужо ахоплівае ўкараненне SQL праз закрыты модуль сканера active.sqli. Актыўнае сканаванне запускаецца толькі пасля праверкі права ўласнасці на дамен і атэстацыі. Праверка скануе канчатковыя кропкі GET таго ж паходжання з параметрамі запыту, устанаўлівае базавы адказ, шукае характэрныя для SQL лагічныя анамаліі і паведамляе аб знаходцы толькі пасля пацверджання часу на працягу некалькіх працягласцей затрымкі. Сканаванне сховішча таксама дапамагае выявіць асноўную прычыну раней з дапамогай code.web-app-risk-checklist-backfill, які пазначае неапрацаваныя выклікі SQL, створаныя з дапамогай інтэрпаляцыі шаблонаў.