Ir vairāki rīki un metodes, ko šī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 ar xkcd
Atteikšanās no pakalpojuma uzbrukuma
Kas tas ir?
Pakalpojuma "atteikums" (dažreiz saukts par "izplatītu pakalpojuma atteikumu" vai DDoS) tiek uzbrukts, kad sistēma, šajā gadījumā tīmekļa serveris, vienlaicīgi saņem tik daudz pieprasījumu, ka servera resursi ir pārslogoti, sistēma vienkārši aizvērs 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, paņemot 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.
Izpildot uzbrukumu
Sakarā ar DDoS uzbrukuma "brutālu spēku" raksturu, vienlaikus ir nepieciešams saskaņot daudz datoru, lai uzbruktu. 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, kuri vienā reizē jūsu sistēmā nonāk neaktīvā stāvoklī 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.
Izmantojot zombiju datorus, 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 injekcijas uzbrukums
Kas tas ir?
"SQL injekcijas" (SQLI) uzbrukums ir ekspluatācija, kas izmanto sliktas tīmekļa izstrādes metodes un parasti to apvieno 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 atbilstoši ieprogrammēta.
Izpildot uzbrukumu
Ikreiz, kad piesakāties tīmekļa vietnei un ievadāt savu lietotāja vārdu un paroli, lai pārbaudītu jūsu akreditācijas datus, tīmekļa lietojumprogramma var izpildīt šādu vaicājumu:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Piezīme: virknes vērtībām SQL vaicājumā jābūt iekļautiem vienotajos citatos, tāpēc tie parādās ap lietotāja ievadītajām vērtībām.
Tāpēc, lai ievadītais lietotājvārds (myuser) un parole (mypass) tiktu savienots ar ierakstu 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 ieraksta tīmekļa veidlapā:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
No pirmā acu uzmetiena tas var šķ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 vārds "myuser" ir ievadīts lietotājvārda laukā un parole tiek ievadīts "nepareizs". Izmantojot vienkāršu aizstāšanu mūsu veidnes vaicājumā, mēs to saņemtu:
SELECT UserID FROM Users WHERE UserName='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ā iepriekš minēto vaicājumu datubāze izpilda kā:
SELECT UserID FROM Users WHERE UserName='myuser'
Šeit lielais trūkums 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 zaudē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), tomēr iespējamā bojājuma apmērs 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 to redzēt, ievadot, piemēram,
'youruser'--', 'admin'--'
vai jebkuru citu lietotāja vārdu, mēs varam uzreiz pieteikties uz vietni kā š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, tādēļ automātiski nav slikta lieta, ka tiek piešķirta pilnīga kontrole.
Tātad, lai ilustrētu zaudējumus, kas var tikt izdarīti šajā situācijā, mēs izmantosim piemēru, kas sniegts iepriekš minētajā komiksā, ievadot šādu lietotāja vārdu lauku:
'Robert'; DROP TABLE Users;--'.
Pēc vienkāršas aizvietošanas autentifikācijas vaicājums kļūst:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
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 datubāzē kā:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABULA Lietotāji
Tieši tāpat mēs esam izmantojuši SQLI uzbrukumu, lai izdzēstu visu lietotāju tabulu.
Protams, var izdarīt daudz sliktāk, jo, atkarībā no atļautajām SQL atļaujām, uzbrucējs var mainīt vērtības, izlikt galdus (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 minējām vairākas reizes iepriekš, 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 ievadītajam, kā mēs to izdarījām, veicot vienkāršu aizstāšanu iepriekš minētajā veidnes vaicājumā.
SQLI uzbrukums ir viegli novērsts, ko sauc par izejmateriālu sanitizēšanu (vai izkļūšanu). 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 vienreizējā citātu pēc O izraisītu virknes priekšlaicīgu pārtraukšanu. 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'--
/ nepareizā puse:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Tā kā vienīgā cena pēc mana lietotāja tiek izlaista (tas nozīmē, ka tiek uzskatīta par mērķa vērtības sastāvdaļu), datubāze tiešām meklēs lietotāja vārdu
'myuser'--'.
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 TABLE Users;--
/ nepareizā puse:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Vienkārši izvairoties no vienotās cenas pēc Roberta, gan semikolu, gan defises iekļaujas UserName meklēšanas virknē, tāpēc datubāze burtiski meklēt
'Robert'; DROP TABLE Users;--'
nevis izpildīt tabulu dzēst.
Kopsavilkumā
Kaut arī tīmekļa uzbrukumi attīstās un kļūst sarežģītāki vai koncentrējas uz atšķirīgu ienākšanas vietu, ir svarīgi atcerēties, ka ir 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žu veidu uzbrukumus, 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.
