beveiliging | xss, versie 2

Waarom voer je een striptags uit terwijl je daarna htmlentities doet? Als je nou bijvoorbeeld een tekst heb over HTML zal je niet <p> kunnen type, want deze wordt weggehaald, terwijl deze prima door de htmlentities kan worden geplaatst op het scherm.

Verder een mooie aanvulling op je vorige

webmakerij, de enige tags die je wil, moet je toevoegen daarboven..
lees anders eerst even het script..
en waarom ik eerst strip tags doe? htmlspecialchar filtert sommige exploits niet, die strip tags wel filterd..

op dit gebied dol je me niet zo makkelijk kerel..
echt niet..



~huib

strip_tags is meestal niet nodig als je je htmlentities goed aanpakt

Ik heb het over een < (dan teken), htmlentities zal deze omzetten in &lt; waardoor HTML het niet meer ziet als een tag.

Ik stel mij even een website voor waar het gaat over HTML: Iemand typt in: "Hiervoor gebruik je <h1> en sluit je af met </h1>", deze persoon wil dus geen kop maken maar wil puur als tekst tags plaatsen. Door jouw filter wordt er echter dit getoond: "Hiervoor gebruik je en sluit je af met"

dus wel... open deze pagina in ie: http://ha.ckers.org/weird/ascii.cgi
die laat htmlentities gewoon door hoor;)

web - lees mijn edit

Mooie tut ik mis alleen het gedeelte achter de schermen, jij geeft aan dat je met name alle $_GET waarden goed moet controleren. Ik mis de controle van de $_POSt waarden. Wie zegt mij dat de data welke ik ga verwerken echt van het formpje wat ik er voor gemaakt had. Mischien heeft iemand op www.badsite.com mijn form wel nagemaakt. (Dus dingen als strlen() enz)

Ook mis ik de reden waarom de checks nodig zijn. Jij noemt je tut XSS maar ik heb geen code gezien welke gebruikt wordt op badsite.com om mij te hacken via mijn slecht gecontroleerde $_GET.
En je had nog iets over include() kunnen zeggen. Dat is volgens mij ook een redelijk gat in de beveiliging (voor de versies tot PHP5)

Voor de rest vind ik het een prachtige tut duidelijk, helder en netjes geschreven en praktisch zonder spelfouten.

Klaasjan

klaasjan, ik gaf het voorbeeld van embedded commands, dat kan alleen via get variabelen, dus je hebt waarschijnlijk mijn doel van dat stukje niet goed begrepen;)

waarom de checks nodig zijn? lees deel 1, daar leg ik het gevaar van xss attacks wat dieper uit. ik heb , geloof ik, ook wat gezegt over include(), maar ik ga ervan uit dat de meeste mensen dat wel weten, als ik het kort noem.

~huib

Mooie tutorial, ik zal hier zeker rekening mee gaan houden.

dankje robert;)

(robert en ik zijn het eens geworden;))

Ik heb een vraagje. Ik heb via $_GET['id'] een nummerieke waarde(dus het db field ID) deze controleer ik simpel door



Dit is toch net zo veilig als je zeker weet dat je een nummerieke waarde krijgt?

Dit staat helemaal bovenaan mijn pagina.

@Jurgen

Als is_numeric() precies die waardes doorgeeft die jij wil dan is dat beste veilig.
Maar wat als je deze controle nu eens vergeten bent of totaal verkeerd is.
Dan zit je wel even raar te kijken als je database leeg is, bijvoorbeeld.

Je kunt denk ik het beste een filter maken die bijvoorbeeld alle $_POST of $_GET waardes eerst gaat filteren. Dus niet filteren als je geen $_POST of $_GET waardes nodig hebt.

In PHP 5.2.0 hebben ze hier een soort gelijke oplossing voor bedacht namelijk de filter extensie.

Ik maak hier (nog) geen gebruik van omdat ik mijn eigen filter heb gemaakt.

Ja ik gebruik deze controle enkel op id's dus niet dat mensen invoeren id=Hallo

en vervolgens mijn foutmelding zegt: geen id's gevonden bij(hallo)

daarom wil ik dat het ID strikt nummeriek is zodat je niet dat soort fratsen krijgt. Ook is het dan toch beveiligt tegen XSS. Want stel je vertaalt ze naar ASCII dan krijg je nog de # en & tekens erin die niet nummeriek zijn en volgens mijn filter naar de index wordt gestuurd. Ik heb het getest met de java popup en deze schijnt niet tevoorschijn te komen omdat mijn filter helemaal bovenaan de pagina staat.

Kijk eens naar ctype om de input te controleren.

ctype_digit() doet toch hetzelfde als is_numeric() enkel controlleert ctype_digit() of het een integer is en is_nummeric() kan ook een string zijn zolang de string maar een integer is. Wat ik wel moet inbouwen is dus dat er geen honderdste ingevoerd kunnen worden. Ik ga dit denk ik doen met number_format()

ctype_digit != is_nummeric

dat snap ik. Ik zeg ook niet dat ze hetzelfde zijn. Ze controleren enkel op hetzelfde en geven een andere output. Om met je variabelen te rekenen is het beter idd om ctype_digit te gebruiken maar voor een id te checken maakt dit vrij weinig uit toch.

>> "en, misschien nog wel belangrijker, als ik iets filter (weghaal), zorg er dan altijd voor dat je er een lusje omheen zet, om te kijken of er niet, zoals in voorbeeld 1, na het filteren een goede tag is ontstaan."

Die snap ik niet. Hoezo helpt dat? Wat doet dat 'lusje' ? Ben geen *_replace() expert, maar snap wel beetje hoe alles werkt. Het nut van die haakjes snap ik echter niet...

Wel goed artikeltje! Misschien iets meer uitleg over sessions en cookies hijacken.

"Die snap ik niet. Hoezo helpt dat? Wat doet dat 'lusje' ? Ben geen *_replace() expert, maar snap wel beetje hoe alles werkt. Het nut van die haakjes snap ik echter niet..."

nou kijk: als ik op <script> filter, en dat, als het voorkomt, weghaal, dan is de volgende stap van de hacker:
<sc<script>ript>
<script word weggehaald, en er word een volgende <script> tag gevormt..
snap je? dat moet je dus in een lusje zetten, zodat ie alle tags die door het filter zijn ONTSTAAN ook filtert..

edit:Misschien iets meer uitleg over sessions en cookies hijacken.

nah, zijn al genoeg artikelen over te vinden.. over xss zelf nog geen eentje, dus vond het niet zo nodig;)

ik snap wel niet veel van php ! ja ik begrijp wat de bedoeling van de meeste scripts is, en kan hier en daar erin wel wat veranderen en aanpassen, maar om zelf een script te schrijven ? ik zou niet weten hoe.
Maar als ik deze tut goed begrijp is alle php die gebruik maakt een andere verbinding om aan de database te geraken onveilig voor je website? dus ik bedoel waarvan de data is opgeslagen in een admin.