Iepriekšējā rakstā mēs uzzinājām par XSS (Cross Site Scripting) kļūdām un faktisko XSS Reflected izmantošanu. Ir vēl viens XSS veids, kas tiek uzskatīts par bīstamāku: saglabātais XSS.
Atšķirībā no Reflected, kas tieši uzbrūk dažiem upuriem, kuru mērķis ir hakeri, Stored XSS ir paredzēts vairāk upuru. Šī kļūda rodas, ja tīmekļa lietojumprogramma rūpīgi nepārbauda ievades datus pirms to saglabāšanas datu bāzē (šeit es izmantoju šo jēdzienu, lai atsauktos uz datu bāzi, failu vai citām jomām, kurās tiek glabāti lietojumprogrammas dati. web).
Izmantojot Stored XSS tehniku, hakeri to neizmanto tieši, bet viņiem tas jādara vismaz 2 soļos.
Pirmkārt, hakeri izmanto nefiltrētus ievades punktus (veidlapu, ievadi, teksta apgabalu...), lai datubāzē ievietotu bīstamu kodu.

Pēc tam, kad lietotājs piekļūst tīmekļa lietojumprogrammai un veic darbības, kas saistītas ar šiem saglabātajiem datiem, lietotāja pārlūkprogrammā tiks izpildīts hakera kods.

Šajā brīdī hakeris, šķiet, ir sasniedzis savu mērķi. Šī iemesla dēļ saglabāto XSS paņēmienu sauc arī par otrās kārtas XSS.
Ekspluatācijas scenārijs ir aprakstīts šādi:

Atspoguļotajam XSS un saglabātajam XSS ir divas būtiskas atšķirības uzbrukuma procesā.
- Pirmkārt, lai izmantotu Reflected XSS, hakeram ir jāmāna upuris piekļūt savam URL. Kas attiecas uz Stored XSS, tas nav jādara.Pēc bīstamā koda ievietošanas lietojumprogrammas datu bāzē hakeram vienkārši jāgaida, līdz upuris tam automātiski piekļūst. Cietušajiem tas ir pilnīgi normāli, jo viņi nezina, ka dati, kuriem viņi piekļūst, ir inficēti.
- Otrkārt, hakera mērķi būs vieglāk sasniegt, ja uzbrukuma brīdī upuris joprojām atrodas tīmekļa lietojumprogrammas sesijā. Izmantojot Reflected XSS, hakeris var pārliecināt vai piemānīt upuri, lai viņš pieteiktos un piekļūtu vietrādim URL, ko viņš nodrošina, lai izpildītu ļaunprātīgu kodu. Taču Stored XSS ir savādāk, jo kaitīgais kods ir glabāts Web datu bāzē, tāpēc ikreiz, kad lietotājs piekļūst saistītajām funkcijām, tiks izpildīts kaitīgais kods, un, visticamāk, šīm funkcijām ir nepieciešama autentifikācija. Vispirms piesakieties, tāpēc acīmredzami šajā laikā lietotājs joprojām atrodas sesijā.
No šīm lietām var redzēt, ka Stored XSS ir daudz bīstamāks par Reflected XSS, ietekmētie subjekti var būt visi šīs tīmekļa lietojumprogrammas lietotāji. Un, ja upurim ir administratīva loma, pastāv arī tīmekļa nolaupīšanas risks.