Bezpečnostné chyby - SQL Injection, XSS a CSRF

bezpecnost.jpg Aj keď sa o bez­peč­nosť webo­vých ap­li­ká­cií za­čí­na za­ují­mať čo­raz väč­ší po­čet prog­ra­má­to­rov, zdá sa, ako­by bol opak prav­da. Den­ne pri­bú­da­jú no­vé sprá­vy o ús­peš­ných úto­koch na väč­šie či men­šie server­y, hac­ke­ri na­chá­dza­jú no­vé zra­ni­teľ­nos­ti v kó­de open sour­ce, ako aj pro­prie­tár­ne­ho sof­tvé­ru, kto­rý pou­ží­va po­čet­né množ­stvo webo­vých server­ov.

Dô­vo­dom je naj­mä stá­le sa zvy­šu­jú­ca ro­bus­tnosť a kom­pli­ko­va­nosť ap­li­ká­cií, pri kto­rých je tak­mer ne­mož­né sto­per­cen­tne ošet­riť kaž­dý vstup a ana­ly­zo­vať do­sa­hy prí­pad­ných zmien v kó­de na bez­peč­nosť. Cie­ľom toh­to člán­ku ne­bu­de pod­rob­ne opí­sať zra­ni­teľ­nos­ti a ob­ra­nu pro­ti úto­kom, ale skôr pou­ká­zať na me­nej zná­me spô­so­by zneu­ži­tia tých­to bez­peč­nos­tných di­er.

SQL In­jec­tion
Opis prin­cí­pu:
Pod­sta­tou tej­to zra­ni­teľ­nos­ti je mož­nosť vkla­da­nia kó­du SQL prip­ra­ve­né­ho útoč­ní­kom do webo­vej ap­li­ká­cie, kto­rá ho nás­led­ne poš­le do da­ta­bá­zo­vé­ho server­a, kto­rý kód spus­tí a vy­ko­ná ak­ciu po­ža­do­va­nú útoč­ní­kom.

Mož­nos­ti úto­ku:
Útok DoS na webo­vý server, od­cu­dzenie ob­sa­hu ce­lej da­ta­bá­zy server­a, zma­za­nie či mo­di­fi­ká­cia dát ulo­že­ných v da­ta­bá­ze.
SQL In­jec­tion je dnes jed­noz­nač­ne naj­po­pu­lár­nej­ší útok na webo­vé ap­li­ká­cie. Dô­vo­dom prav­de­po­dob­ne ani tak nie je to, že by bez­peč­nos­tné di­ery ty­pu SQL In­jec­tion bo­li op­ro­ti iným vý­raz­ne po­čet­nej­šie, ale skôr sú ľah­ko od­ha­li­teľ­né a efek­tív­ne sa da­jú zneu­žiť. Na inter­ne­te sú voľ­ne dos­tup­né exploi­ty, kto­ré sú ľah­ko pou­ži­teľ­né a väč­ši­nou sú veľ­ké len nie­koľ­ko de­sia­tok baj­tov. Ak niek­to ob­ja­ví a zve­rej­ní exploit pre ne­ja­ký vý­znam­ný open sour­ce webo­vý sof­tvér, ra­zom sa o chy­be doz­vie nie­koľ­ko ti­síc či de­sia­tok ti­síc po­ten­ciál­nych útoč­ní­kov. A aj na­priek to­mu, že tvor­co­via kó­du za­rea­gu­jú na chy­bu eš­te v da­ný deň, ďal­šie týž­dne či me­sia­ce ad­mi­nis­trá­to­ri na mno­hých server­och ne­mu­sia k ak­tua­li­zo­va­niu ap­li­ká­cie vô­bec pris­tú­piť.

Po­mo­cou SQL In­jec­tion nie je prob­lém dos­tať sa k prih­la­so­va­cím me­nám a has­hom he­siel da­ta­bá­zo­vé­ho server­a. A v prí­pa­de, že sa mož­no vzdia­le­ne na­po­jiť na port da­ta­bá­zo­vé­ho server­a, mô­že dôjsť k jed­no­du­ché­mu zís­ka­niu kon­tro­ly nad ce­lým sys­té­mom. No nie všet­ky úto­ky mu­sia sme­ro­vať tak­to. Na webo­vý server mož­no spus­tiť aj útok DoS, kto­rý ús­peš­ne vy­uží­va bez­peč­nos­tnú di­eru SQL In­jec­tion. Pred­pok­la­daj­me, že útoč­ník na webo­vej strán­ke náj­de neo­šet­re­ný vstup do ap­li­ká­cie cez pa­ra­me­ter id_clan­ku, kto­rý sa sta­rá o zob­ra­ze­nie jed­né­ho kon­krét­ne­ho člán­ku na server­i.

URL bu­de vy­ze­rať nap­rík­lad tak­to:

http://www.cie­lo­vy_ser­ver.com/clan­ky.php?id_clan­ku=1 SQL kód v PHP, kto­rý má na sta­ros­ti zob­ra­zo­va­nie člán­kov, bu­de vy­ze­rať tak­to: "SE­LECT * FROM clan­ky WHE­RE id_clan­ku = ".$_GET['id_clan­ku'];

Ak útoč­ník do­pí­še na ko­niec URL OR 1=1, da­ta­bá­zo­vý server bu­de mu­sieť na­čí­ta­vať ove­ľa väč­šie množ­stvo dát, kto­ré bu­de mu­sieť sof­tvér webo­vé­ho server­a od­osie­lať, čím bu­de zá­ro­veň blo­ko­vať pre­no­so­vú lin­ku.

Kom­plet­ná URL ad­re­sa bu­de vy­ze­rať tak­to

http://www.cie­lo­vy_ser­ver.com/clan­ky.php?id_clan­ku=1 OR 1=1 a po­žia­dav­ka SQL tak­to: "SE­LECT * FROM clan­ky WHE­RE id_clan­ku = 1 OR 1=1", čo zna­me­ná, že pod­mien­ka bu­de spl­ne­ná pre všet­ky zá­zna­my v ta­buľ­ke clan­ky.

Ke­by sme pred­pok­la­da­li, že v da­ta­bá­ze je ulo­že­ných nap­rík­lad 200 člán­kov, z kto­rých má kaž­dý veľ­kosť s ob­ráz­ka­mi oko­lo 100 kB, vý­sle­dok sa bu­de rov­nať 20 MB dát. Je­di­nou po­žia­dav­kou cez pro­to­kol HTTP sme tak pri­ká­za­li server­u pre­zrieť ce­lú ta­buľ­ku clan­ky, na­čí­tať jej ce­lý ob­sah a od­os­lať ho klien­to­vi. Útoč­ní­ko­vi tak pos­ta­čí aj nie­koľ­ko má­lo de­sia­tok po­čí­ta­čov, aby za pár se­kúnd za­hl­til server po­žia­dav­ka­mi, kto­ré ne­bu­de stí­hať spra­cú­vať. V prí­pa­de, že by spus­ti­lo ta­ký­to útok na­raz 100 zom­bie po­čí­ta­čov s in­ten­zi­tou 3 po­žia­dav­ky za se­kun­du, vý­sled­ný efekt by sa rov­nal: 3 × 100 × 20 MB = 6000 MB = 6 GB vy­žia­da­ných dát za je­di­nú se­kun­du.

XSS
Opis prin­cí­pu:
Pod­sta­ta úto­ku spo­čí­va v mož­nos­ti vlo­že­nia kó­du skrip­to­va­cie­ho ja­zy­ka (Ja­vaS­cript, VBScript) útoč­ní­kom na webo­vú strán­ku.

Mož­nos­ti úto­ku:
Útok DoS pro­ti náv­štev­ní­kom strán­ky (pres­me­ro­va­nie náv­štev­ní­kov), od­cu­dzenie úč­tov webo­vej ap­li­ká­cie, zme­na ob­sa­hu webo­vej strán­ky, ov­lád­nu­tie po­čí­ta­ča náv­štev­ní­ka strán­ky.

Ho­ci v pod­sta­te pri tom­to úto­ku ide naj­mä o vkla­da­nie kó­du skrip­to­va­cie­ho ja­zy­ka, napr. Ja­vaS­cript, ne­žia­du­ce je ta­kis­to vkla­da­nie iných ta­gov, kto­ré mô­žu pod­stat­ne zme­niť vzhľad a ob­sah webo­vej strán­ky a spô­so­biť útok ty­pu od­op­re­nia služ­by – DoS. XSS je eš­te stá­le veľ­mi pod­ce­ňo­va­ná bez­peč­nos­tná di­era. Mož­ná prí­či­na je aj to, že v člán­koch opi­su­jú­cich zá­kla­dy bez­peč­nos­tných di­er XSS sa väč­ši­nou úto­ky de­monštru­jú zob­ra­ze­ním sprá­vy - alert("XSS vul­ne­ra­bi­li­ty!"). Dô­vo­dom ta­kej­to ukáž­ky je však pred­ve­de­nie fun­go­va­nia a jed­no­du­chos­ti úto­ku, ale či­ta­te­lia tak mô­žu na­do­bud­núť do­jem, že ide o to naj­hor­šie, čo sa mô­že pri prí­pad­nom úto­ku od­oh­rať. Opak je však prav­da.

Pros­tred­níc­tvom úto­kov vy­uži­tím chýb XSS sa mož­no jed­no­du­cho dos­tať do úč­tu ad­mi­nis­trá­to­ra webo­vej ap­li­ká­cie ale­bo ho­cik­to­ré­ho iné­ho pou­ží­va­te­ľa. Bez prob­lé­mov sa dá me­niť vzhľad a ob­sah webo­vej strán­ky, umies­tniť na server fa­loš­né for­mu­lá­re atď. Pri pok­ro­či­lej­ších úto­koch sa do­kon­ca kom­bi­nu­jú tech­ni­ky XSS so SQL In­jec­tion, CSRF a iný­mi.

CSRF
Opis prin­cí­pu:
Prin­cíp úto­ku spo­čí­va v mož­nos­ti zneu­ži­tia cu­dzej iden­ti­ty útoč­ní­kom, kto­rý po­mo­cou podvr­hnu­té­ho od­ka­zu HTML vy­ko­ná ne­ja­kú ak­ciu pod úč­tom/iden­ti­tou obe­te, čas­to s cie­ľom od­cu­dziť kon­to webo­vej ap­li­ká­cie. Úto­ky CSRF a XSS útoč­ní­ci spo­lu kom­bi­nu­jú.

Mož­nos­ti úto­ku:
Útok DoS pro­ti náv­štev­ní­kom strán­ky (pres­me­ro­va­nie náv­štev­ní­kov), od­cu­dzenie úč­tov webo­vej ap­li­ká­cie, zme­na ob­sa­hu webo­vej strán­ky, ov­lád­nu­tie po­čí­ta­ča náv­štev­ní­ka strán­ky, ma­ni­pu­lá­cia an­kiet.

CSRF je po­mer­ne má­lo dis­ku­to­va­ná zra­ni­teľ­nosť, kto­rá sa vy­sky­tu­je v úpl­nej väč­ši­ne webo­vých server­ov. Niek­to­rí exper­ti po­va­žu­jú CSRF skôr za vlas­tnosť tech­no­ló­gií ako za chy­bu, keď­že prob­lém by sa z kom­plexné­ho hľa­dis­ka dal ako-tak vy­rie­šiť im­ple­men­tá­ciou no­vých pr­vkov a zmien už v pro­to­ko­le HTTP. Ide to­tiž o vlas­tnos­ti (ale­bo pod­ľa nie­ko­ho ne­dos­tat­ky) pro­to­ko­lu HTTP, ja­zy­ka HTML, klient­skych skrip­to­va­cích ja­zy­kov a, sa­moz­rej­me, aj prog­ra­má­tor­ských ná­vy­kov. Vý­znam­ne by moh­lo po­môcť nap­rík­lad pou­ží­va­nie pro­to­ko­lu, kto­rý by si pa­mä­tal stav spo­je­nia. HTTP je to­tiž bez­sta­vo­vý pro­to­kol, čím pre­sú­va ce­lú zod­po­ved­nosť za ove­re­nie iden­ti­ty, pô­vo­du a auto­ri­zo­va­nia po­žia­dav­ky HTTP na prog­ra­má­to­rov webo­vých ap­li­ká­cií.

Ani to však ne­za­ru­ču­je sto­per­cen­tné vy­rie­še­nie tých­to bez­peč­nos­tných prob­lé­mov. Hac­ke­ri by to­tiž prav­de­po­dob­ne naš­li ďal­šie spô­so­by zneu­ži­tia bez­peč­nos­tných sla­bín ta­kej­to inter­ne­to­vej/webo­vej ko­mu­ni­ká­cie. Nie ná­ho­dou sa útok CSRF na­zý­va aj one-click at­tack, už z toh­to náz­vu vy­plý­va jed­no­du­chosť je­ho vy­ko­na­nia.

Lo­gic­ké chy­by
Ako sa čas­to pri­po­mí­na, bez­peč­nosť by ma­la byť sú­čas­ťou vý­vo­ja kó­du, a nie len akým­si do­da­toč­ným oba­lom, kto­rý má za úlo­hu ochrá­niť ako-tak za­bez­pe­če­ný kód. Tvor­co­via kó­du by ma­li s bez­peč­nos­tný­mi exper­tmi ak­tív­ne spo­lup­ra­co­vať už pri návr­hu webo­vých ap­li­ká­cií, keď eš­te nie je na­pí­sa­ný ani ria­dok kó­du. Tí im bez prob­lé­mov po­ra­dia, na čo si dať po­zor a aký bez­peč­nost­ný mo­del pri da­nom ty­pe ap­li­ká­cie je vhod­né pou­žiť. Hľa­dať to­tiž chy­by v kó­de, až keď je úpl­ne ho­to­vý a ob­sa­hu­je aj nie­koľ­ko de­sia­tok ti­síc riad­kov, je ove­ľa zlo­ži­tej­šie. A naj­mä vte­dy, keď pôj­de o tzv. lo­gic­ké chy­by, kam mô­že­me za­ra­diť nas­le­du­jú­ci prík­lad:

// ak je pou­ží­va­teľ ús­peš­ne prih­lá­se­ný, spus­ti nas­le­du­jú­ci kód "SE­LECT * FROM emai­ly WHE­RE id_pou­zi­va­te­la ='".$_GET['id_pou­zi­va­te­la']."' OR­DER BY da­tum DESC";

Ke­by da­ná ap­li­ká­cia pra­co­va­la tak­to, za nor­mál­nych okol­nos­tí by bo­lo všet­ko správ­ne a v po­riad­ku a bež­ní pou­ží­va­te­lia by si nič nev­šim­li. Prob­lém by však nas­tal, ke­by sa útoč­ník roz­ho­dol zme­niť hod­no­tu pre­men­nej id_pou­zi­va­te­la. Ak tú­to pre­men­nú zme­ní na ne­ja­ké plat­né id_pou­zi­va­te­la, kto­ré sa na­chá­dza v da­ta­bá­ze, zob­ra­zia sa mu e-mai­ly nie­ko­ho iné­ho. V prí­pa­de, že sa id_pou­zi­va­te­la pri re­gis­trá­cii ge­ne­ru­je jed­no­du­cho in­kre­men­to­va­ním (li­neár­ne), útoč­ník ne­bu­de mať žiad­ny prob­lém extra­ho­vať tak­to všet­ky e-mai­ly z da­ta­bá­zy.

Po­dob­né lo­gic­ké chy­by ob­sa­hu­je veľ­ké množ­stvo ap­li­ká­cií, aj keď, sa­moz­rej­me, nej­de vždy prá­ve o ta­ké­to tri­viál­ne. Auto­ma­ti­zo­va­né nás­tro­je hľa­da­jú tie­to zra­ni­teľ­nos­ti len ťaž­ko a pri zbež­nom pre­ze­ra­ní kó­du si prog­ra­má­to­ri ne­mu­sia nič všim­núť. Správ­ne by te­da kód mal vy­ze­rať ob­dob­ne:

// ak je pou­ží­va­teľ ús­peš­ne prih­lá­se­ný, spus­ti nas­le­du­jú­ci kód "SE­LECT * FROM emai­ly WHE­RE id_pou­zi­va­te­la ='".$_GET['id_pou­zi­va­te­la']."' AND hes­lo_pou­zi­va­te­la ='".$hes­lo_pou­zi­va­te­la."' OR­DER BY da­tum DESC";

Zá­ver
Jed­not­li­vé ty­py bez­peč­nos­tných di­er útoč­ní­ci v mno­hých prí­pa­doch kom­bi­nu­jú, aby im za­ru­či­li čo naj­jed­no­duch­šie do­siah­nu­tie cie­ľa. Po­rov­na­ním mož­nos­tí úto­kov pri jed­not­li­vých ty­poch bez­peč­nos­tných chýb prí­de­me na to, že útoč­ní­ko­vi sa po­da­rí do­siah­nuť rov­na­ké cie­le (napr. zís­kať dá­ta z da­ta­bá­zy) aj po­mo­cou XSS, aj vy­uži­tím CSRF a, sa­moz­rej­me, aj zneu­ži­tím zra­ni­teľ­nos­ti SQL In­jec­tion. Lí­ši sa len spô­sob úto­ku, ale v ko­neč­nom dôs­led­ku všet­ky vy­ús­tia do rov­na­ké­ho vý­sled­ku.



Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

EÚ schvá­li­la sys­tém Pri­va­cy Shield na ochra­nu európ­skych dát na ame­ric­kých server­och
Európska únia ukončila rokovania s americkou stranou týkajúce sa odovzdávania osobných údajov spoločnostiam sídliacim v USA. čítať »
 
Hac­ke­ri ov­lád­li dro­ny NA­SA a plá­no­va­li ha­vá­riu Glo­bal Hawk
Hackerskej skupine vystupujúcej pod názvom AnonSec sa podarilo nabúrať do špeciálneho programu na ovplyvňovanie počasia, nad ktorým má v súčasnosti kontrolu americká NASA. čítať »
 
Alian­cii Fair-play a plat­for­me Slo­ven­sko.Di­gi­tal sa ne­poz­dá­va­jú šty­ri IT pro­jek­ty mi­nis­terstiev
Neziskové občianske združenie Aliancia Fair-play (AFP) a Platforma Slovensko.Digital žiadajú ministerstvá vnútra, dopravy a školstva, aby zastavili a prehodnotili obstarávania štyroch veľkých IT projektov, ktoré v rezortoch momentálne prebiehajú. čítať »
 
Mô­že sa zo zmu­to­va­nej zi­ky stať glo­bál­na hroz­ba?
Vírus zika sa začal rýchlo šíriť po celom svete. V teplých oblastiach oboch amerických kontinentov, kam sa dostal začiatkom minulého roka, už možno hovoriť o pandémii. čítať »
 
Jad­ro­vé zbra­ne ma­jú ochrá­niť Zem pred prí­pad­ným ar­ma­ge­do­nom
Aj keď sa o jadrových zbraniach hovorí zväčša v negatívom svetle, vedci v nich paradoxne vidia efektívny spôsob na záchranu Zeme pred prípadnou hrozbou. čítať »
 
Di­gi­tál­na bez­peč­nosť v ro­ku 2016: Inter­net ve­cí, mo­bil­né za­ria­de­nia a ochra­na de­tí
ESET každý rok pripravuje svoj prehľad bezpečnostných tém, ktoré budú v najbližších mesiacoch trápiť bežných používateľov alebo firmy a organizácie. čítať »
 
Len 17-roč­ný mla­dík vy­na­šiel ven­ti­lá­to­ro­vý sys­tém brá­nia­ci ší­re­niu mik­ró­bov v lie­tad­le
Chytiť nejakú chorobu na palube lietadla nie je nič príjemné. Pritom mnohé vírusy nebezpečných chorôb, ako je napr. SARS či vtáčia chrípka, sa v nedávnej minulosti šírili po svete práve prostredníctvom lietadiel. čítať »
 
ESET pri­dá­va do kon­zo­ly vzdia­le­nej sprá­vy ma­na­žo­va­nie iP­ho­nov a iPa­dov
ESET vydáva ESET Virtualization Security. Toto nové riešenie pre VMware vShield nevyžadujúce nasadenie agenta kombinuje využitie ESET Virtualization Security s konzolou vzdialenej správy ESET Remote Administrator tak, aby poskytovalo ochranu oceňovaného skenovacieho jadra spolu s osvedčenou vzdialenou správou. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter