Kā hackers pārņem tīmekļa vietnes ar SQL Injection un DDoS

Pat ja jūs esat tikai brīvi sekojuši hakeru grupu Anonymous un LulzSec notikumiem, jūs, iespējams, dzirdējāt par tīmekļa vietnēm un pakalpojumiem, kas tiek uzlauzti, piemēram, draņķīgi Sony hacks. Vai esat kādreiz domājuši, kā viņi to dara?

Ir vairāki rīki un paņēmieni, kurus šīs grupas izmanto, un, kamēr mēs nemēģinām sniegt jums rokasgrāmatu, lai to izdarītu pats, ir lietderīgi saprast, kas notiek. Divi no uzbrukumiem, kurus jūs pastāvīgi dzirdat par lietošanu, ir "(Distributed) Service Denial( DDoS) un" SQL injekcijas "(SQLI).Lūk, kā viņi strādā.

Attēls pēc xkcd

Atteikšanās no pakalpojuma uzbrukuma

Kas tas ir?

A "atteikšanās no pakalpojuma"( dažreiz saukta par "izplatītu pakalpojuma atteikšanu" vai DDoS) uzbrukums notiek tad, kad sistēma, šajā gadījumā tīmekļa serveris, vienlaikus saņem tik daudz pieprasījumu, ka servera resursi ir pārslogoti, sistēma vienkārši bloķēuz augšu un izslēdzas. Veiksmīga DDoS uzbrukuma mērķis un rezultāts ir mērķa servera tīmekļa vietnes, kurās nav likumīgu satiksmes pieprasījumu.

Kā tas darbojas?

DDoS uzbrukuma loģistiku vislabāk var izskaidrot ar piemēru.

Iedomājieties, ka miljons cilvēku( uzbrucēji) saskaras ar mērķi kavēt uzņēmuma X darbību, pazeminot viņu zvanu centru. Uzbrucēji koordinē tā, ka otrdien plkst. 9.00 viņi visi izsauks uzņēmuma X tālruņa numuru. Iespējams, kompānija X tālruņa sistēma nevarēs apstrādāt miljonu zvanu vienlaicīgi, lai uzbrucēji piesaistītu visas ienākošās līnijas. Rezultāts ir tāds, ka likumīgie klientu zvani( t.i., tie, kas nav uzbrucēji) neizdodas, jo tālruņa sistēma ir saistīta ar zvaniem no uzbrucēju puses. Tātad būtībā uzņēmums X potenciāli zaudē uzņēmējdarbību, jo likumīgie pieprasījumi nav spējīgi tikt galā.

DDoS uzbrukums tīmekļa serverim darbojas tieši tādā pašā veidā.Tā kā praktiski nav veids, kā uzzināt, kāda satiksme tiek iegūta no likumīgiem pieprasījumiem vai uzbrucējiem, kamēr tīmekļa serveris apstrādā pieprasījumu, šāda veida uzbrukums parasti ir ļoti efektīvs.

Uzbrukuma izpilde

Tā kā DDoS uzbrukuma "brutālā spēka" raksturs ir tāds, ka tajā pašā laikā ir nepieciešams saskaņot daudz datoru. Pārvēršot mūsu zvanu centra piemēru, tas prasītu, lai visi uzbrucēji abiem zinātu, ka zvana pulksten 9:00 un faktiski zvana tajā brīdī.Kaut arī šis princips, protams, darbosies, ja runa ir par uzbrukumu tīmekļa serverim, tas kļūst ievērojami vieglāk, ja tiek izmantoti zombiju datori, nevis faktiski darbināmie datori.

Kā jūs droši vien zināt, ir vairāki ļaunprātīgas programmatūras un Trojas zirgiem paredzēti varianti, kas vienā reizē jūsu sistēmā paliek neaktīvi un reizēm "tālrunis mājās", lai saņemtu norādījumus. Viens no šiem norādījumiem varētu, piemēram, nosūtīt atkārtotus pieprasījumus uzņēmuma X tīmekļa serverim plkst. 9:00.Tātad, ar vienu attiecīgo vietnes malware atjauninājumu, viens uzbrucējs var tūlīt koordinēt simtiem tūkstošu kompromitēto datoru, lai veiktu masveida DDoS uzbrukumu.

Zombiju datoru izmantošanas skaistums ir ne tikai tā efektivitāte, bet arī tā anonimitāte, jo uzbrucējam nevajadzētu pilnībā izmantot savu datoru, lai veiktu uzbrukumu.

SQL Injection Attack

Kas tas ir?

SQL injekcijas( SQLI) uzbrukums ir ekspluatācija, kas izmanto sliktas tīmekļa izstrādes metodes un parasti kopā ar kļūdainu datu bāzes drošību. Veiksmīga uzbrukuma rezultāts var būt tas, ka noformējat lietotāja kontu līdz pilnīgai attiecīgās datubāzes vai servera kompromitācijai. Atšķirībā no DDoS uzbrukuma SQLI uzbrukums ir pilnīgi un viegli novēršams, ja tīmekļa lietojumprogramma ir pareizi ieprogrammēta.

Izpildot uzbrukumu

Katru reizi, kad piesakāties tīmekļa vietnei un ievadi savu lietotāja vārdu un paroli, lai pārbaudītu savus akreditācijas datus, tīmekļa lietojumprogramma var palaist šādu vaicājumu:

SELECT userID FROM THE Users WHERE UserName = 'myuser' AND Password= 'mypass';

piezīme: SQL vaicājuma virknes vērtībām jābūt ievietotām vienā kotācijās, tāpēc tās parādās ap lietotāja ievadītajām vērtībām.

Tāpēc ievadītā lietotāja vārda( myuser) un paroles( mypass) kombinācijai ir jāatbilst ierakstam Lietotāju tabulā, lai lietotājdēls tiktu atgriezts. Ja nav atbilstības, neviens UserID netiek atgriezts, tāpēc pieteikšanās akreditācijas dati ir nederīgi. Kaut arī konkrēta īstenošana var atšķirties, mehānika ir diezgan standarta.

Tātad, tagad apskatīsim veidnes autentifikācijas vaicājumu, ko mēs varam aizstāt ar vērtībām, kuras lietotājs ievada tīmekļa veidlapā:

SELECT userID FROM THE USERS WHERE UserName = '[user]' AND Password = '[pass]'

No pirmā acu uzmetiena šovar šķist vienkāršs un loģisks solis, lai viegli validētu lietotājus, tomēr, ja šajā veidnē tiek veikta vienkārša lietotāja ievadīto vērtību aizstāšana, tā ir jutīga pret SQLI uzbrukumu.

Piemēram, pieņemsim, ka lietotājvārdu laukā ir ievadīts "myuser'-" un parole tiek ievadīts "nepareizs numurs".Izmantojot vienkāršu aizstāšanu mūsu veidnes vaicājumā, mēs saņemtu šo:

SELECT userID FROM FROM Users WHERE user name = 'myuser' - 'AND Password =' ​​wrongpass '

Šī paziņojuma atslēga ir divu domu( -) iekļaušana.Šis ir sākuma komentāru marķieris SQL paziņojumiem, tādēļ nekas, kas parādās pēc divām domām( ieskaitot), tiks ignorēts. Būtībā minētais vaicājums datubāzē tiek izpildīts kā:

SELECT Lietotāja ID no lietotājiem, ja lietotājsName = 'myuser'

Šajā acīmredzamajā izlaidumā ir paroles pārbaudes trūkums. Iekļaujot divas domuzīmes kā daļu no lietotāja lauka, mēs pilnībā apietam paroles pārbaudes nosacījumus un varējām pieteikties kā "myuser", nezinot attiecīgo paroli.Šis vaicājuma manipulācijas akts, lai radītu neparedzētus rezultātus, ir SQL injekcijas uzbrukums.

Kādu kaitējumu var panākt?

SQL injekcijas uzbrukums ir saistīts ar nolaidīgu un bezatbildīgu lietojumprogrammu kodēšanu, un tas ir pilnīgi novēršams( ko mēs kādreiz apskatīsim), taču iespējamā kaitējuma apjoms ir atkarīgs no datubāzes iestatīšanas. Lai tīmekļa lietojumprogramma sazinātos ar backend datubāzi, lietojumprogrammai ir jānodrošina pieteikšanās datu bāzē( ņemiet vērā, tas atšķiras no lietotāja pieteikšanās pašai vietnei).Atkarībā no tā, kādas atļaujas ir nepieciešamas tīmekļa lietojumprogrammai, attiecīgajā datu bāzes kontā var būt nepieciešama tikai lasīšanas / rakstīšanas atļauja esošajās tabulās, lai piekļūtu pilnīgai datu bāzei. Ja tas vēl nav skaidrs, dažiem piemēriem vajadzētu palīdzēt nodrošināt zināmu skaidrību.

Pamatojoties uz iepriekš minēto piemēru, jūs varat redzēt, ka, ievadot, piemēram, "youruser" - "," admin "-" vai jebkuru citu lietotāja vārdu, mēs varam uzreiz piekļūt vietnei, jo šis lietotājs, nezinot paroli. Kad mēs esam sistēmā, mēs nezinām, ka mēs patiesībā esam šī lietotāja, tāpēc mums ir pilnīga piekļuve attiecīgajam kontam. Datu bāzes atļaujas šim nolūkam nesniegs drošības tīklu, jo parasti vietnei ir jābūt vismaz lasīšanas / rakstīšanas piekļuvei attiecīgajai datubāzei.

Tagad pieņemsim, ka tīmekļa vietne pilnībā kontrolē savu attiecīgo datubāzi, kas dod iespēju dzēst ierakstus, pievienot / noņemt tabulas, pievienot jaunus drošības kontus utt. Ir svarīgi atzīmēt, ka dažām tīmekļa lietojumprogrammām varētu būt nepieciešama šāda veida atļauja.automātiski nav slikti, ka tiek piešķirta pilnīga kontrole.

Lai ilustrētu bojājumus, ko var paveikt šajā situācijā, mēs izmantosim piemēru, kas sniegts iepriekš minētajā komiksā, ievadot šādu lietotāja vārdu laukā: "Robert"; DROP TABLE Users - ".Pēc vienkāršas aizstāšanas autentifikācijas vaicājums kļūst:

IZVĒLIETIES lietotāja ID no lietotājiem, ja lietotājvārds = 'Roberts';DROP TABLE Lietotāji; - 'AND Password =' ​​nepareizā puse '

Piezīme: semikols ir SQL vaicājumā tiek izmantots, lai norādītu konkrētā paziņojuma beigas un jaunā paziņojuma sākumu.

Kas izpaužas kā datubāzē:

SELECT Lietotāja ID no lietotājiem, kur UserName = 'Roberts'

DROP TABLE Lietotāji

Tātad, tāpat kā mēs esam izmantojuši SQLI uzbrukumu, lai izdzēstu visu lietotāju tabulu.

Protams, daudz sliktāk var izdarīt, jo, atkarībā no atļautajām SQL atļaujām, uzbrucējs var mainīt vērtības, izlikt tabulas( vai visu datubāzi) teksta failā, izveidot jaunus pieteikšanās kontus vai pat nolaupīt visu datu bāzes instalāciju.

SQL injekcijas uzbrukuma novēršana

Kā mēs vairākkārt iepriekš minējām, SQL injekcijas uzbrukums ir viegli novēršams. Viens no galvenajiem tīmekļa izstrādes noteikumiem ir tāds, ka jūs nekad akli neuzticaties lietotāja ievadam, kā mēs to izdarījām, veicot vienkāršu aizstāšanu mūsu veidnes vaicājumā iepriekš.

SQLI uzbrukumu var viegli novērst tas, ko sauc par sanitizing( vai izvairīties) no jūsu resursiem. Sanitizēšanas process patiesībā ir diezgan nenozīmīgs, jo tas, ko tas būtībā dara, ir apstrādāt jebkuras inline single quote( ') rakstzīmes, kas ir piemērotas tādai, ka tās nevar izmantot, lai priekšlaicīgi izbeigtu virkni SQL iekšienē.

Piemēram, ja jūs vēlaties veikt meklēšanu "O'neil" datubāzē, jūs nevarat izmantot vienkāršu aizstāšanu, jo pēc O viena cipareita rezultātā priekšmets beigsies. Tā vietā jūs sanitize to, izmantojot attiecīgās datubāzes escape raksturs. Pieņemsim, ka izņēmuma raksturs iekšējai vienotajai citatnei ir katra citāta priekšmets ar \ simbolu. Tātad "O'neal" tiks izārstēts kā "O \ 'neil".

Šis vienkāršais sanitārijas akts diezgan daudz novērš SQLI uzbrukumu. Lai ilustrētu, atkārtoti aplūkosim savus iepriekšējos piemērus un redzēsim iegūtos vaicājumus, kad lietotājs ievadīs sanitāri.

myuser "- / nepareizais pults :

IZVĒLIETIES lietotāja ID no lietotājiem, ja lietotājvārds = 'myuser' '-' AND Password = 'wrongpass'

Tā kā viens cipars pēc myuser ir aizvests( tas nozīmē, ka tas tiek uzskatīts par mērķa daļuvērtība), datubāze tiešām meklēs "myuser" - "Lietotāja vārdu".Turklāt, tā kā svītras ir iekļautas virknes vērtībā, nevis pats SQL, tie tiks uzskatīti par mērķa vērtības daļu, nevis tos, ko interpretē kā SQL komentāru.

Robert ';DROP TABULA Lietotāji - / nepareizais pults :

IZVĒLIETIES lietotāja ID no lietotājiem, ja lietotājvārds = 'Robert';DROP TABLE Lietotāji; - 'AND Password =' ​​nepareizā puse '

Vienkārši izvairoties no vienotās cenas pēc Roberta, abas semikols un domuzīmes ir ietvertas UserName meklēšanas virknē, tāpēc datubāze meklē burtu "Roberts"; DROP TABLE Users;- "nevis izpildīt tabulu dzēst.

Kopsavilkumā

Kamēr tīmekļa uzbrukumi attīstās un kļūst sarežģītāki vai koncentrējas uz citu ieejas punktu, ir svarīgi atcerēties, ka jāaizsargā pret pārbaudītiem un patiesiem uzbrukumiem, kas ir iedvesmojuši vairākus brīvi pieejamus "hakeru rīkus", kas paredzēti to izmantošanai.

Dažus uzbrukumu veidus, piemēram, DDoS, nevar viegli izvairīties, bet citi, piemēram, SQLI, var. Tomēr kaitējums, ko var izraisīt šāda veida uzbrukumi, var atšķirties no neērtībām līdz katastrofālai atkarībā no piesardzības pasākumiem.