» »

Javascript DOM based XSS vulnerability

Javascript DOM based XSS vulnerability

Joze_K ::

ok, sem naredil neko spletno stran..
potem jo spustim skozi: https://crashtest-security.com/
kjer preišče za ranljivosti v kodi.. najdene sem uspel kar nekako zatreti razen tele Javascript.. a ima kdo idejo kako?

Finding Type: DOM based Cross-Site Scripting (XSS)
Information
The potentially vulnerable code was found on url 'https://www.spletnastran.si/iskalnik#re.... An attacker may be able to inject JavaScript using the the code 'location.href' at line 375:23 and control its display using the code 'window.location' at line 375:16

Risk 6.1 Description
DOM based Cross-Site Scripting (XSS) allows an attacker to send malicious code to a different user by modifying the DOM environment in the browser of the user.


problem poskušam rešiti kar v 4 korakih:
1) $query = JustABC_validation($_POST["query"]);
function JustABC_validation($str) { 
	// $str = stringToReplace.replace('/[^a-zA-Z0-9]/gi', ''); 
	$sub_string = preg_replace("/^([^a-zA-Z0-9])*/", "", $str,1);
	$sub_string = strrev(preg_replace("/^([^a-zA-Z0-9])*/", "",strrev($sub_string),1));
	return $sub_string;
} 


2) $query = str_ireplace("javascript", "", $query);
3) $query = str_ireplace("script", "", $query);
4) $query = htmlspecialchars($query);

torej, v prvem koraku poskušam preveriti ali so posredovane samo črke in številke
v drugem in tretjem poskušam izločiti besede javascript in script
in v četrtem še posebne znake pretvoriti v neškodljivo kodo

ideje sem vlekel iz: https://excess-xss.com

AMPAK
crashtest še dalje javlja to napako

očitno je moje razmišljanje o smeri reševanja te napake nepravilno.. a zna kdo predlagati rešitev tega problema

hvala, J

Spura ::

Najlazji nacin da zatres XSS je da uporabis Content-Security-Policy header, ki izklopi vse inline JS skripte razen tvojih. Tele PHP fore z replaceom posebnih znakov pri webu in SQLu so zastarele.

Zgodovina sprememb…

  • spremenil: Spura ()

Joze_K ::

Spura je izjavil:

Najlazji nacin da zatres XSS je da uporabis Content-Security-Policy header, ki izklopi vse inline JS skripte razen tvojih. Tele PHP fore z replaceom posebnih znakov pri webu in SQLu so zastarele.


ok NGNIX server.. a misliš tole:
add_header Content-Security-Policy "default-src 'self'" always;


imel sem vklopljene tele direktive, pa sem jih moral odstraniti, ker mi je po vklopu le teh se rušila struktura (design strani), pa je admin vse tole izključil... ampak tale zgoraj navedena je verjetno ta, kar si mislil? (hvala!)
add_header X-Frame-Options "deny" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'" always;


a je potem tole zadosti, da javascripta več ne javlja? (ker se mi zdi, da sem imel isti problem tudi ko je tole bilo vklopljeno.. no ja, nisem siguren)

Spura ::

Ne vem glede tega https://crashtest-security.com/, ampak ce imas "default-src 'self'" in pa "frame-ancestors 'none'" potem so XSS napadi nemogoci, kar pa tale security test mogoce ne razume. Potem tudi ne bos rabil replaceov delat.

Ta direktiva pa prepreci loadanje kakrnihkoli js, css, fontov ali cesarkoli iz drugih siteov, kar ponavadi pomeni da se stran ne prikaze pravilno. Resitev za to da je da dodas vec direktiv, ki eksplicitno omogocijo dolocene urlje. Katere rabis je najlazje videt tako, da odpres developer konzolo v browserju in gledas za katere prenose ti v js konzolo napise error.

Torej razsiris header na nekaj takega:

"default-src 'self'; frame-ancestors 'none'; font-src https://fonts.google.com; script-src https://adsense.google.com; style-src https://example.com"

Torej ko dodas vse kar rabis v te izjeme potem se bodo teli fajli nalozili. Ce pa imas dodatne inline skripte, potem pa imas dve moznosti:

eno je da vsakic ko vracas page, v to direktivo dodas nonce, torej da imas "script-src nonce-a4b51245ccff" torej da generiras random stevilko v base 64 in jo dodas v direktivo, potem pa dodas ta nonce v atribute script taga:
<script nonce="a4b51245ccff"></script>


V tem primeru bodo inline script bloki delali. Drugi nacin je da izracunas hash svojih inline skript in jih nastejes v direktivo:

"script-src sha256-a4b51245ccffa4b51245ccff"

potem bodo inline skripte kjer ima vsebina ta hash delovale. Pri racunanju hasha za pretvorbo iz stringa v bajte uporabi encoding strani.

Joze_K ::

@spura...
mega hvala, končno ena razumljiva informacija..(sem v teh vodah popolnoma gol in bos.. mi je to sploh prva php stran ever...)

še tole ne hitro.. - če prav razumem tale add_header dodelam?

add_header Content-Security-Policy "default-src 'self'" always;


ali je tudi v ostalih direktivah to potrebno?

add_header X-Frame-Options "deny" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'" always;

MrStein ::

Funkcionalnost headerja X-Frame-Options je že vključena v CSP header, tako da je bolje samo tega uporabiti (Content-Security-Policy)

Spura je izjavil:

ce imas "default-src 'self'" in pa "frame-ancestors 'none'" potem so XSS napadi nemogoci

To niti teoretično ni res.
Popravek: to dejansko blokira veliko večino XSS
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

MrStein ::

Joze_K je izjavil:


problem poskušam rešiti kar v 4 korakih:
1) $query = JustABC_validation($_POST["query"]);
function JustABC_validation($str) { 
// $str = stringToReplace.replace('/[^a-zA-Z0-9]/gi', '');
$sub_string = preg_replace("/^([^a-zA-Z0-9])*/", "", $str,1);
$sub_string = strrev(preg_replace("/^([^a-zA-Z0-9])*/", "",strrev($sub_string),1));
return $sub_string;
}


2) $query = str_ireplace("javascript", "", $query);
3) $query = str_ireplace("script", "", $query);
4) $query = htmlspecialchars($query);

crashtest še dalje javlja to napako

očitno je moje razmišljanje o smeri reševanja te napake nepravilno.. a zna kdo predlagati rešitev tega problema

S tem samo pometaš drek pod preprogo.

Problem in rešitev so tule:
code 'location.href' at line 375:23 and control its display using the code 'window.location' at line 375:16

Kako ti podatki pridejo v href in location? Če drugo ne, napiši sem te vrstice.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Joze_K ::

<input class="form-control" type="text" name="query" />
<input onclick="window.location.href=encodeURI('page#rezultatIskanja')"
 class="btn btn-outline-purple btn-sm" type="submit" value=" Iskanje " />

<?php if (isset($_POST["query"])) {
 $query = JustABC_validation($_POST["query"]); 
 $query = str_ireplace("javascript", "", $query);
 $query = str_ireplace("script", "", $query);
			    
 $min_length = 3;
  // you can set minimum length of the query if you want
   
 if(strlen($query) >= $min_length){ 
   include("connection.php");  

   .... nekako tako...

Spura ::

MrStein je izjavil:

Funkcionalnost headerja X-Frame-Options je že vključena v CSP header, tako da je bolje samo tega uporabiti (Content-Security-Policy)

Spura je izjavil:

ce imas "default-src 'self'" in pa "frame-ancestors 'none'" potem so XSS napadi nemogoci

To niti teoretično ni res.
Popravek: to dejansko blokira veliko večino XSS

Zanima me, katerih to ne blokira.

Joze_K ::

hm, očitno tole XSS Frame pravilo vseeno ne pomaga..

imam takole - ocena A: vse zeleno..
https://securityheaders.com/?q=www.nako...

XSS Javascript errorji pa kar ostajajo..
madona tole je že muka prava...
(Slika errorjev)

Zgodovina sprememb…

  • spremenil: Joze_K ()

Spura ::

V Content-Security-Policy si dodal unsafe, kar ubistvu spet na siroko odpira vrata za exploite.

MrStein ::

Joze_K je izjavil:



.... nekako tako...

A $query sploh kje uporabiš?

Spura je izjavil:

MrStein je izjavil:

Funkcionalnost headerja X-Frame-Options je že vključena v CSP header, tako da je bolje samo tega uporabiti (Content-Security-Policy)

Spura je izjavil:

ce imas "default-src 'self'" in pa "frame-ancestors 'none'" potem so XSS napadi nemogoci

To niti teoretično ni res.
Popravek: to dejansko blokira veliko večino XSS

Zanima me, katerih to ne blokira.

Recimo <script src='isti URL kot base/xyz'/>

Zgodovina sprememb…

  • spremenil: MrStein ()

Joze_K ::

MrStein je izjavil:


A $query sploh kje uporabiš?



ja, seveda..
tale query nato v SQL stavek dam za iskanje po bazi, npr.
$sql = "SELECT * FROM " . $tabel . " WHERE 
(`Ime` LIKE '%".htmlspecialchars($query)."%')"; 

Miha 333 ::

htmlspecialchars je za uporabo pri URLjih in ne pokrije vseh posebnih znakov pri SQL. Za SQL escaping pa imaš namensko funkcijo mysqli_real_escape_string(), vendar če si že na začetku vstavil v bazo s htmlspecialchars, je malo nerodno, ker potem imaš v bazi namesto nekaterih pravih znakov HTML entitete (predvidevam, da uporabljaš MySQL oz. MariaDB).

Zgodovina sprememb…

  • spremenilo: Miha 333 ()

Spura ::

MrStein je izjavil:

Joze_K je izjavil:



.... nekako tako...

A $query sploh kje uporabiš?

Spura je izjavil:

MrStein je izjavil:

Funkcionalnost headerja X-Frame-Options je že vključena v CSP header, tako da je bolje samo tega uporabiti (Content-Security-Policy)

Spura je izjavil:

ce imas "default-src 'self'" in pa "frame-ancestors 'none'" potem so XSS napadi nemogoci

To niti teoretično ni res.
Popravek: to dejansko blokira veliko večino XSS

Zanima me, katerih to ne blokira.

Recimo <script src='isti URL kot base/xyz'/>

Aha, torej exploit bi bil, ce bi lahko nekdo dosegel, da nek URL na moji domeni vrne skripto (brez kakih JSONov okol al pa kej), ki jo je napadalec vnesel.

Torej moj REST API bi rabil nekje nek GET handler ki vrne clean user-submitted content (recimo nek get-user-upload endpoint) in potem bi me lahko zjebal. To je kr specificno, ampak vseeno dobr vedet.

MrStein ::

Lahko tudi sestavi po kosih iz delov, ki so že del serverja. "statični" če se tako izrazimo.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Inline JS v HTML; varnost, XSS, ...

Oddelek: Programiranje
21542 (150) MrStein
»

Content-Security-Policy problem

Oddelek: Izdelava spletišč
5696 (513) Matthai
»

Nginx ne pošlje vseh HTTP headerjev

Oddelek: Izdelava spletišč
5645 (512) BaRtMaN
»

[php] brisanje nedovoljenih znakov

Oddelek: Izdelava spletišč
7874 (722) keworkian
»

PHP - stringi

Oddelek: Izdelava spletišč
251042 (865) pehape

Več podobnih tem