Forum » Programiranje » 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?
problem poskušam rešiti kar v 4 korakih:
1) $query = JustABC_validation($_POST["query"]);
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
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 ::
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:
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.
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;
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)
To niti teoretično ni res.
Popravek: to dejansko blokira veliko večino XSS
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!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Zgodovina sprememb…
- spremenil: MrStein ()
MrStein ::
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!
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 ::
Funkcionalnost headerja X-Frame-Options je že vključena v CSP header, tako da je bolje samo tega uporabiti (Content-Security-Policy)
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)
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 ::
.... nekako tako...
A $query sploh kje uporabiš?
Funkcionalnost headerja X-Frame-Options je že vključena v CSP header, tako da je bolje samo tega uporabiti (Content-Security-Policy)
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 ::
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 ::
.... nekako tako...
A $query sploh kje uporabiš?
Funkcionalnost headerja X-Frame-Options je že vključena v CSP header, tako da je bolje samo tega uporabiti (Content-Security-Policy)
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!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Inline JS v HTML; varnost, XSS, ...Oddelek: Programiranje | 1780 (1388) | MrStein |
» | Content-Security-Policy problemOddelek: Izdelava spletišč | 1514 (1331) | poweroff |
» | Nginx ne pošlje vseh HTTP headerjevOddelek: Izdelava spletišč | 1173 (1040) | BaRtMaN |
» | [php] brisanje nedovoljenih znakovOddelek: Izdelava spletišč | 1436 (1284) | keworkian |
» | PHP - stringiOddelek: Izdelava spletišč | 1784 (1607) | pehape |