Kā hakeri pārņem tīmekļa vietnes ar SQL injekciju un DDoS
Pat ja jūs esat tikai brīvi sekojuši Hackers grupas Anonīma un LulzSec notikumiem, jūs, iespējams, esat dzirdējuši par tīmekļa vietnēm un pakalpojumiem, kas ir hacked, piemēram, draņķīgi Sony hacks. Vai esat kādreiz domājuši, kā viņi to dara?
Pastāv vairāki rīki un paņēmieni, ko šīs grupas izmanto, un, kamēr mēs nemēģinām sniegt jums rokasgrāmatu, lai to izdarītu, ir lietderīgi saprast, kas notiek. Divi no uzbrukumiem, ko jūs pastāvīgi dzirdat par tiem, ir “Pakalpojuma atteikums” (DDoS) un “SQL injekcijas” (SQLI). Lūk, kā viņi strādā.
Attēls pēc xkcd
Pakalpojuma uzbrukuma atteikums
Kas tas ir?
“Pakalpojuma atteikums” (dažreiz to sauc par „izplatītu atteikumu sniegt pakalpojumu” vai „DDoS”) uzbrukums notiek tad, kad sistēma, šajā gadījumā tīmekļa serveris, saņem tik daudz pieprasījumu vienā reizē, ka servera resursi ir pārslogoti, sistēma vienkārši bloķējas un izslēdzas. Veiksmīga DDoS uzbrukuma mērķis un rezultāts ir mērķa servera tīmekļa vietnes, kas nav pieejamas likumīgiem satiksmes pieprasījumiem.
Kā tas darbojas?
DDoS uzbrukuma loģistiku vislabāk var izskaidrot ar piemēru.
Iedomājieties, ka miljons cilvēku (uzbrucēji) sanāk kopā ar mērķi kavēt uzņēmuma X biznesu, samazinot zvanu centru. Uzbrucēji koordinē, lai otrdien, plkst. 9.00, visi zvanīs uz uzņēmuma X tālruņa numuru. Visticamāk, uzņēmuma X tālruņa sistēma nespēs vienlaicīgi apstrādāt miljonu zvanus, lai visas ienākošās līnijas piesaistītu uzbrucēji. Rezultāts ir tāds, ka likumīgie klientu zvani (t.i., tie, kas nav uzbrucēji) neiziet cauri, jo tālruņa sistēma ir saistīta ar uzbrucēju zvanu apstrādi. Tātad būtībā uzņēmums X potenciāli zaudē uzņēmējdarbību, jo likumīgie pieprasījumi nespēj nokļūt.
DDoS uzbrukums tīmekļa serverim darbojas tieši tāpat. Tā kā praktiski nav iespējams uzzināt, kāda satiksme tiek iegūta no likumīgiem pieprasījumiem pret uzbrucējiem, kamēr tīmekļa serveris apstrādā pieprasījumu, šāda veida uzbrukums parasti ir ļoti efektīvs.
Uzbrukuma izpilde
Sakarā ar DDoS uzbrukuma „brutālo spēku”, jums ir nepieciešams daudz datoru, kas ir saskaņoti, lai vienlaicīgi uzbruktu. Pārskatot mūsu zvanu centra piemēru, tas prasītu, lai visi uzbrucēji zinātu, ka viņiem jāzvana pie plkst. Kaut arī šis princips noteikti darbosies, kad runa ir par tīmekļa servera uzbrukumu, tas kļūst ievērojami vieglāk, ja tiek izmantoti zombiju datori, nevis faktiskie datori..
Kā jūs droši vien zināt, ir daudz ļaunprātīgas programmatūras un Trojas zirgu variantu, kas vienreiz jūsu sistēmā atrodas mierīgā stāvoklī un dažkārt „mājās mājās”. Viens no šiem norādījumiem varētu būt, piemēram, nosūtīt atkārtotus pieprasījumus uzņēmuma X tīmekļa serverim plkst. Līdz ar to, veicot vienotu atjauninājumu uz attiecīgās ļaunprātīgās programmatūras vietējo atrašanās vietu, viens uzbrucējs var uzreiz koordinēt simtiem tūkstošu kompromitētu datoru, lai veiktu masveida DDoS uzbrukumu.
Zombiju datoru izmantošanas skaistums ir ne tikai tās efektivitāte, bet arī anonimitāte, jo uzbrucējam nav faktiski jāizmanto viņu dators, lai veiktu uzbrukumu..
SQL iesmidzināšanas uzbrukums
Kas tas ir?
„SQL injekcijas” (SQLI) uzbrukums ir izmantojums, kas izmanto sliktas tīmekļa izstrādes metodes un parasti apvieno ar kļūdainu datu bāzes drošību. Veiksmīga uzbrukuma rezultāts var būt, sākot no lietotāja konta piesaistīšanas līdz pilnīgai attiecīgā datubāzes vai servera kompromisam. Atšķirībā no DDoS uzbrukuma SQLI uzbrukums ir pilnīgi un viegli novēršams, ja tīmekļa lietojumprogramma ir atbilstoši ieprogrammēta.
Uzbrukuma izpilde
Ikreiz, kad piesakāties tīmekļa vietnē un ievadāt savu lietotājvārdu un paroli, lai pārbaudītu jūsu akreditācijas datus, tīmekļa lietojumprogramma var palaist vaicājumu, piemēram:
SELECT UserID no lietotājiem WHERE UserName = "Myuser" UN Parole = "mypass";
Piezīme. SQL vaicājumā iekļautās virknes vērtības jāiekļauj atsevišķās citātēs, tāpēc tās parādās ap lietotāja ievadītajām vērtībām.
Tātad ievadītā lietotāja vārda (Myuser) un paroles (mypass) kombinācijai ir jāatbilst ierakstam Lietotāju tabulā, lai varētu atdot Lietotāja ID. Ja nav atbilstības, lietotāja ID netiek atgriezts, lai pieteikšanās akreditācijas dati būtu nederīgi. Lai gan konkrēta īstenošana var atšķirties, mehānika ir diezgan standarta.
Tāpēc aplūkosim šablona autentifikācijas vaicājumu, kuru mēs varam aizstāt ar vērtībām, ko lietotājs ievada tīmekļa veidlapā:
SELECT lietotāju ID no lietotājiem WHERE UserName = "[user]" un Password = "[pass]"
No pirmā acu uzmetiena tas var šķist vienkāršs un loģisks solis, lai viegli apstiprinātu lietotājus, tomēr, ja šajā veidnē tiek veikta vienkārša lietotāja ievadīto vērtību aizstāšana, tas ir jutīgs pret SQLI uzbrukumu.
Piemēram, pieņemsim, ka lietotāja vārdu laukā tiek ievadīts “myuser” - un parole tiek ievadīts “nepareizais ceļš”. Izmantojot veidlapu vaicājumā vienkāršu aizstāšanu, mēs to iegūtu:
SELECT lietotāju ID no lietotājiem WHERE UserName = "myuser" - 'UN Password = "nepareiza rīcība"
Šī paziņojuma atslēga ir divu domuzīmju iekļaušana (-). Tas ir SQL komentāru sākšanas komentārs, tāpēc viss, kas parādās pēc abām svītrām (ieskaitot), tiks ignorēts. Būtībā iepriekš minētais vaicājums datubāzē tiek izpildīts kā:
SELECT UserID no lietotājiem WHERE UserName = "myuser"
Nenovērojamā bezdarbība šeit ir paroles pārbaudes trūkums. Iekļaujot abas svītras kā daļu no lietotāja lauka, mēs pilnīgi apejām ar paroli pārbaudīto nosacījumu un varējām pieteikties kā “myuser”, nezinot attiecīgo paroli. Šis manipulācijas ar vaicājumu, lai radītu neparedzētus rezultātus, ir SQL injekcijas uzbrukums.
Kādu kaitējumu var izdarīt?
SQL injekcijas uzbrukumu izraisa nolaidīga un bezatbildīga lietojumprogrammu kodēšana, un tas ir pilnīgi novēršams (ko mēs aptversim brīdi), tomēr kaitējuma apjoms, ko var izdarīt, ir atkarīgs no datu bāzes iestatīšanas. Lai tīmekļa lietojumprogramma varētu sazināties ar backend datubāzi, lietojumprogrammai ir jāievada pieteikšanās datu bāzē (ņemiet vērā, ka tas atšķiras no lietotāja pieteikšanās uz vietni). Atkarībā no tā, kādas atļaujas pieprasa tīmekļa lietojumprogramma, šai attiecīgajai datu bāzu kontam var būt nepieciešams kaut kas no lasīšanas / rakstīšanas atļaujas esošajās tabulās tikai līdz pilnīgai datu bāzes piekļuvei. Ja tas tagad nav skaidrs, daži piemēri palīdzēs nodrošināt skaidrību.
Pamatojoties uz iepriekš minēto piemēru, jūs varat redzēt, piemēram, ievadot, "jūsu lietotājs" - "," admin "-" vai jebkuru citu lietotājvārdu, mēs varam uzreiz pieteikties vietnē kā šis lietotājs, nezinot paroli. Kad mēs esam sistēmā, nezinām, ka mēs neesam faktiski tādi lietotāji, tāpēc mums ir pilnīga piekļuve attiecīgajam kontam. Datu bāzes atļaujas šim nolūkam nenodrošinās drošības tīklu, jo parasti tīmekļa vietnei jābūt vismaz lasīšanas / rakstīšanas piekļuvei attiecīgajai datu bāzei..
Tagad pieņemsim, ka tīmekļa vietne pilnībā kontrolē savu datu bā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 būt nepieciešams šāda veida atļauja automātiski nav slikta lieta, ka tiek piešķirta pilnīga kontrole.
Tātad, lai ilustrētu kaitējumu, ko var izdarīt šajā situācijā, mēs izmantosim iepriekš minētajā komiksa piemēru, ievadot šādu vārdu lietotāja nosaukuma laukā: "Robert"; DROP TABLE Lietotāji; - ". Pēc vienkāršas aizvietošanas autentifikācijas vaicājums kļūst:
SELECT lietotāja ID no lietotājiem WHERE UserName = "Robert"; DROP TABLE Lietotāji; - 'UN Password = "nepareiza rīcība"
Piezīme: semikols ir SQL vaicājumā, lai norādītu konkrēta paziņojuma beigas un jauna paziņojuma sākumu.
Kas datubāzē tiek izpildīts kā:
SELECT lietotāju ID no lietotājiem WHERE UserName = "Robert"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, izgāzt tabulas (vai visu datubāzi) uz teksta failu, 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 pieminējām, SQL injekcijas uzbrukums ir viegli novēršams. Viens no galvenajiem web izstrādes noteikumiem ir tas, ka jūs nekad neredzat uzticību lietotāju ievadam, kā mēs to darījām, kad mēs veicām vienkāršu aizstāšanu mūsu veidnes vaicājumā.
SQLI uzbrukumu viegli kavē tas, ko sauc par dezinfekciju (vai izbēgšanu) no jūsu ieejām. Sanitize process faktiski ir diezgan triviāls, jo tas viss būtībā ir jebkuras inline viena citāta () rakstzīmju pareiza apstrāde, lai tās nevarētu izmantot, lai priekšlaicīgi pārtrauktu virkni SQL paziņojuma iekšpusē.
Piemēram, ja vēlaties datubāzē meklēt "O'neil", jūs nevarēja izmantot vienkāršu aizstāšanu, jo vienreizējais piedāvājums pēc O radītu virknes priekšlaicīgu beigšanos. Tā vietā jūs to sanitizējat, izmantojot atbilstošo datubāzes glābšanas rakstzīmi. Pieņemsim, ka izejas raksturs, kas paredzēts vienai citai citai citai, ir priekšraksts katram citātam ar simbolu. Tātad „O'neal” būtu sanitizēts kā “O” neil.
Šī vienkāršā sanitārā darbība diezgan daudz novērš SQLI uzbrukumu. Lai to ilustrētu, pārskatīsim iepriekšējos piemērus un aplūkosim radušos vaicājumus, kad lietotāja ievads ir dezinficēts.
myuser '-- / negadījums:
SELECT lietotāju ID no lietotājiem WHERE UserName = "myuser" - 'UN Password = "nepareiza lietošana"
Tā kā vienreizējais piedāvājums pēc tam, kad manis lietotājs ir aizbēgis (tas nozīmē, ka tiek uzskatīts par daļu no mērķa vērtības), datubāze burtiski meklēs lietotāja vārdu "Myuser" - ". Turklāt, tā kā domuzīmes ir iekļautas virknes vērtībā, nevis pašas SQL, tās tiks uzskatītas par mērķa vērtības daļu, nevis tiek interpretētas kā SQL komentārs.
Roberts; DROP TABLE Lietotāji;-- / negadījums:
SELECT UserID no lietotājiem WHERE UserName = "Robert"; DROP TABLE Lietotāji; - 'UN Password = "nepareiza rīcība"
Vienkārši izvairoties no viena citāta pēc Roberta, gan semikols, gan domuzīmes atrodas lietotāja nosaukuma meklēšanas virknē, lai datubāze burtiski meklētu "Robert"; DROP TABLE Lietotāji; - " nevis izpildīt tabulu.
Kopsavilkumā
Lai gan interneta uzbrukumi attīstās un kļūst sarežģītāki vai koncentrējas uz citu piekļuves punktu, ir svarīgi atcerēties, lai aizsargātu pret mēģinātiem un patiesiem uzbrukumiem, kas ir iedvesmojuši vairākus brīvi pieejamus „hacker 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 izdarīt ar šāda veida uzbrukumiem, var būt no neērtībām līdz katastrofālām, atkarībā no piesardzības pasākumiem, kas veikti.
