Javascript DOM based XSS vulnerability @ Slo-Tech

Forum » Programiranje »
Javascript DOM based XSS vulnerability

Javascript DOM based XSS vulnerability

Joze_K :: 10. feb 2020, 08:04

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 :: 10. feb 2020, 14:21

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 (10. feb 2020 ob 14:23)

Joze_K :: 10. feb 2020, 14:44

Spura je 10. feb 2020 ob 14:21 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 :: 11. feb 2020, 01:53

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 :: 11. feb 2020, 07:08

@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 :: 12. feb 2020, 10:11

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

Spura je 11. feb 2020 ob 01:53 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 (12. feb 2020 ob 10:20)

MrStein :: 12. feb 2020, 10:17

Joze_K je 10. feb 2020 ob 08:04 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 :: 12. feb 2020, 13:02

<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 :: 12. feb 2020, 14:09

MrStein je 12. feb 2020 ob 10:11 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 11. feb 2020 ob 01:53 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 :: 13. feb 2020, 07:12

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 (13. feb 2020 ob 07:13)

Spura :: 13. feb 2020, 16:53

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

MrStein :: 13. feb 2020, 18:46

Joze_K je 12. feb 2020 ob 13:02 izjavil:


 
 .... nekako tako...

A $query sploh kje uporabiš?

Spura je 12. feb 2020 ob 14:09 izjavil:

MrStein je 12. feb 2020 ob 10:11 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 11. feb 2020 ob 01:53 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 (13. feb 2020 ob 18:48)

Joze_K :: 14. feb 2020, 08:26

MrStein je 13. feb 2020 ob 18:46 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 :: 14. feb 2020, 08:50

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 (14. feb 2020 ob 08:52)

Spura :: 14. feb 2020, 10:24

MrStein je 13. feb 2020 ob 18:46 izjavil:

Joze_K je 12. feb 2020 ob 13:02 izjavil:
 
 .... nekako tako...
A $query sploh kje uporabiš?

Spura je 12. feb 2020 ob 14:09 izjavil:
MrStein je 12. feb 2020 ob 10:11 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 11. feb 2020 ob 01:53 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 :: 14. feb 2020, 21:52

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 ...

	Tema	Sporočila	Ogledi	Zadnje sporočilo
	Tema	Sporočila	Ogledi	Zadnje sporočilo
»	Inline JS v HTML; varnost, XSS, ... HotBurek Oddelek: Programiranje	21	1780 (1388)	MrStein 1. nov 2019 12:48:19
»	Content-Security-Policy problem poweroff Oddelek: Izdelava spletišč	5	1514 (1331)	poweroff 14. mar 2018 21:27:20
»	Nginx ne pošlje vseh HTTP headerjev poweroff Oddelek: Izdelava spletišč	5	1173 (1040)	BaRtMaN 21. sep 2017 14:22:50
»	[php] brisanje nedovoljenih znakov Veron Oddelek: Izdelava spletišč	7	1435 (1283)	keworkian 14. feb 2011 22:21:59
»	PHP - stringi pehape Oddelek: Izdelava spletišč	25	1784 (1607)	pehape 12. nov 2010 19:56:59

Več podobnih tem

Zadnje novice

Zadnji članki

Išči:

Forum » Programiranje »
Javascript DOM based XSS vulnerability

Javascript DOM based XSS vulnerability