PHP - Säkerhetsbrist att använda PHP_SELF på detta sätt i HTML formulär?

Permalänk
Medlem

PHP - Säkerhetsbrist att använda PHP_SELF på detta sätt i HTML formulär?

Är den här koden sårbar mot XSS?:

<form method="post" action="<?php echo $_SERVER["PHP_SELF"]; ?>">

Jag har läst artiklar som säger att det är det och att man borde använda htmlspecialchars() methoden för att fixa det:

<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">

Men jag lyckas inte få någon JavaScript att köras när jag försöker emulera en XSS exploit. Jag lägger en script tagg i URL:en till formuläret precis som artiklarna säger att man ska kunna göra och det händer ingenting. Här är ett exempel på hur jag försöker injicera kod:

Permalänk
Hedersmedlem

Jo, det är sårbart. Jag kan trigga skriptet genom att bara kopiera din kod. Kolla i källkoden av den genererade sidan för att se hur det tolkas.

Anropar jag `http://localhost/test.php/%22%3E%3Cscript%3Ealert('hacked')%3C/script%3E`, där `test.php` har innehåll:

<!doctype html> <meta charset="utf-8"> <title>Test</title> <form method="post" action="<?=$_SERVER['PHP_SELF']?>">

så får jag pop-upen att visas. Källkoden för det renderade dokumentet blir:

<!doctype html> <meta charset="utf-8"> <title>Test</title> <form method="post" action="/test.php/"><script>alert('hacked')</script>">

Det är mig veterligen en anledning till att `$_SERVER['PHP_SELF']` generellt inte är rekommenderad att använda överhuvudtaget: använd `$_SERVER['SCRIPT_NAME']` i stället, där det går (vilket är mer eller mindre överallt — det är fritt att komma med motexempel ).

Notera också att en tom `action` på ett formulär automatiskt reflekterar tillbaka till nuvarande dokument, så det är sällan skriptnamnet behöver tas fram överhuvudtaget. En länk likt `<a href="?a=katt">` pekar också på nuvarande dokument med motsvarande query-sträng tillagd.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av phz:

Jo, det är sårbart. Jag kan trigga skriptet genom att bara kopiera din kod. Kolla i källkoden av den genererade sidan för att se hur det tolkas.

Anropar jag `http://localhost/test.php/%22%3E%3Cscript%3Ealert('hacked')%3C/script%3E`, där `test.php` har innehåll:

<!doctype html> <meta charset="utf-8"> <title>Test</title> <form method="post" action="<?=$_SERVER['PHP_SELF']?>">

så får jag pop-upen att visas. Källkoden för det renderade dokumentet blir:

<!doctype html> <meta charset="utf-8"> <title>Test</title> <form method="post" action="/test.php/"><script>alert('hacked')</script>">

Det är mig veterligen en anledning till att `$_SERVER['PHP_SELF']` generellt inte är rekommenderad att använda överhuvudtaget: använd `$_SERVER['SCRIPT_NAME']` i stället, där det går (vilket är mer eller mindre överallt — det är fritt att komma med motexempel ).

Notera också att en tom `action` på ett formulär automatiskt reflekterar tillbaka till nuvarande dokument, så det är sällan skriptnamnet behöver tas fram överhuvudtaget. En länk likt `<a href="?a=katt">` pekar också på nuvarande dokument med motsvarande query-sträng tillagd.

Jag vet att det var ett tag sedan tråden var aktiv, men jag har några ytterligare funderingar. Vad skulle en hacker kunna göra med den här sårbarheten? Jag har ingen förståelse för vad som kan åstadkommas genom att injicera JavaScript i URL:en för ett formulär, hur skulle det kunna skada mina användare?

Kan passa på att tacka dig för ditt första svar också, mycket informativt.

Permalänk
Hedersmedlem
Skrivet av Murloc:

Jag vet att det var ett tag sedan tråden var aktiv, men jag har några ytterligare funderingar. Vad skulle en hacker kunna göra med den här sårbarheten? Jag har ingen förståelse för vad som kan åstadkommas genom att injicera JavaScript i URL:en för ett formulär, hur skulle det kunna skada mina användare?

En elak användare som upptäckte denna sårbarhet skulle kunna iscensätta en "reflekterad XSS-attack": skapa en "elak" URL och försöka lura personer att klicka på denna. Denna URL skulle exempelvis kunna innehålla en skripttagg som laddar och kör ett externt okontrollerat skript som om det kom från den attackerade sidan. Detta gör att man bryter den "same-origin policy" som är till för att skydda data som hör till en viss sida från att läsas av alla andra.

Eftersom detta elaka skript som injicerats nu, vad webbläsaren anbelangar, körs från den "riktiga" sidan så har det access till exempelvis kakan som verifierar användarens inloggade session på denna sida. Skriptet kan stjäla dessa data, skicka dem till tredje part, som helt plötsligt kan iscensätta en lokal inloggad webbläsarsession som användaren vars kaka stals.

Beroende på vad det är för konto och vilken sida så kan detta ha lite olika implikationer, där man själv kan fundera på vilken skada det skulle kunna göra att någon annan skulle kunna initiera en session där de är inloggade som din användare på en viss sida. Av extra intresse är administratörskonton, och då administratörerna i sig ofta är kända så kan en attackerare utföra riktade attacker just mot dessa personer.

Generellt så riskerar man att ens sida blir en vektor för "cross-site scripting" (XSS) om man tillåter okontrollerad användardata möjligheten att köras som skripttaggar.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av Murloc:

Jag vet att det var ett tag sedan tråden var aktiv, men jag har några ytterligare funderingar. Vad skulle en hacker kunna göra med den här sårbarheten? Jag har ingen förståelse för vad som kan åstadkommas genom att injicera JavaScript i URL:en för ett formulär, hur skulle det kunna skada mina användare?

Kan passa på att tacka dig för ditt första svar också, mycket informativt.

XSS TL;DR:

  • Hackare kan göra allt användare kan göra i deras namn (tex posta inlägg i användarens namn, läsa hans PM)

  • Använda dina besökare som DDoS mot andra hemsidor (kina gjorde nyligen en sån attack mot github)

  • Få användare att göra saker för att de litar på hemsidan (tex ge ut sitt lösenord eller köpa något)

Tänk att sweclockers hade ett sånt XSS hål du postade. Då skulle en hacker kunna skicka en URL till användare och när en användare trycker på URLen så körs javascript kod. Javascript koden skulle kunna läsa användarens alla PM, skicka PM, skapa nya inlägg i användarens namn. I inläggen kan man lägga in URLen och volia snart har alla på sweclockers tryckt på länken.

Hacker kan också fejk logga ut användaren och visa en ruta där det står "Du har blivit utloggad pga säkerhetskäl, logga in igen för att skriva inlägg". När användaren sen loggar in igen så skickas lösenord och användarnamn till hackaren. Man kan alltså utnyttja användarens tillit till en hemsida.

Visa signatur

Programmerare -> PHP | HTML | CSS | JS | Java.

Permalänk
Medlem

Jag har hittat en hemsida vars sökfunktion verkar vara sårbar. Jag lyckas få kod att exekvera när jag skriver in >'>"><img src=x onerror=alert("Hello")>. Hur hade jag kunnat utnyttja det här säkerhetshålet om jag var ett illasinnat XSS och JavaScript proffs? Man kan ju inte göra som nämns i inläggen ovan och skicka URL:er till folk för att få kod att köras med detta säkerhetshål.

Jag ska så klart meddela hemsideägaren angående detta, men det vore bra om jag kunde skicka med lite information angående varför detta bör fixas.

Permalänk
Hedersmedlem
Skrivet av Murloc:

Jag ska så klart meddela hemsideägaren angående detta, men det vore bra om jag kunde skicka med lite information angående varför detta bör fixas.

En länk till denna tråd eller Wikipediaartikeln om XSS borde räcka .

Sårbarheter "gömda" bakom formulär är inga bekymmer att trigga via exempelvis att auto-sändande formulär från en tredjepartssida. Man ger användaren länken till denna tredjepartssida, som vid sidladdning automatiskt skickar iväg en POST-förfrågan med skräddarsydda data.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem

Måste en användare vara inloggad på sidan när den klickar på en XSS-länk för att få sin kaka snodd, eller kan koden ligga och vänta på att användaren ska logga in och sen sno den?