Advertentie | |
|
22-08-2005, 21:06 | ||
Verwijderd
|
Citaat:
Ik zat alleen te denken dat hij mensen op de link zou laten klikken om hun afbeeldingen te laten weergeven. Dan zou men naar een gevaarlijke pagina kunnen verwijzen in plaats van een afbeelding. Zat even in de verkeerde richting te denken |
23-08-2005, 19:20 | |
omg, dat menen jullie niet. Valt me tegen van je Enlightenment
wat dacht je van plaatjes die verwijzen naar bv javascript:alert(document.cookie); lijkt me niet de bedoeling. En alleen javascript eruit filteren is niet goed (geen blacklists). Je moet werken met whitelists, dus links toestaan die beginnen met http:// en anders zelf http:// voor zetten, zodat dingen als javascript niet meer werken. Foei Foei Laatst gewijzigd op 23-08-2005 om 19:23. |
24-08-2005, 22:07 | |
wat jij doet is niet netjes imo, jij plant er meteen http:// ervoor. Je kan toch ook plaatjes hebben met een relatief pad naar een bestand op de server...
Daarnaast krijg je dan problemen als $avatar al begint met http://. Het is imo netter om eerst te kijken of een link met http begint, zoja htmlspecialchars erover en in de src. Zoniet zelf http:// ervoor zetten(zoals jij dat doet in je voorbeeld) en dan pas in de src zetten. En je kan browsers brak noemen of niet, maar dit werk in zowel IE als Opera: <img src="javascript:alert('xss');"> en dit ook <img src="javascript://alert('xss');"> [edit] vb zet een spatie tussen java en script, maar het hoort dus aan elkaar [/edit] En daarnaast werken ook alle varianten waarin je een van de karakters van src vervangt door de html/hex code. Dus met htmlspecialchars alleen kom je er niet uit Laatst gewijzigd op 24-08-2005 om 22:10. |
24-08-2005, 22:16 | ||
Citaat:
Als je de avatar zelf serveert, dan zorg je zelf voor de URL, zoals: <img src="/images/avatar.php?id=39908" alt="Avatar" /> Mijn voorbeeld gaat duidelijk over externe avatars, en daar vul je dus zelf al http:// in. Dan omzeil je ook het probleem dat brakke browsers in de SOURCE van een document (waar staat het plaatje?) opeens actieve code gaan uitvoeren. Daarnaast prefereer ik htmlentities() boven htmlspecialchars() omdat eerstgenoemde veel meer potentieel schadelijke karakters escaped naar HTML elements.
__________________
Per undas adversas (tegen de stroom in)
|
25-08-2005, 10:41 | |
Toch wel aardig een security breach dan. Actieve code hoor je niet overal te pas en te onpas uit te voeren. Alleen in specifiek daarvoor bestemde delen, zoals <script></script>. Als je het Microsoft-style overal tussenin kan proppen werk je security exploits in de hand. Maargoed, met http:// ervoor zou redelijk veilig moeten zijn. Je kunt er altijd nog een str_replace('java','',$str) filter overheen gooien, die alles met "java" weghaalt.
__________________
Per undas adversas (tegen de stroom in)
|
25-08-2005, 11:01 | |
htmlentities() is toch niet echt netjes, hoor. Het is in principe valide om een image-naam te hebben met bijvoorbeeld een é erin, en die zou dan moeten worden geescaped met urlencode(), niet met htmlentities().
Volgens mij kan je het best een mooie regex maken die checkt of het een valide URL is (begint met http://, daarna een hostname, daarna slashes met path-onderdelen erin, eventueel kan je de extensie checken).
__________________
Slechts beschikbaar via naamzoek/privebericht.
|
25-08-2005, 13:49 | |
Ik denk dat je http:// helemaal niet wilt opslaan in je database, je wilt toch enforcen dat het http:// moet worden dus waarom opslaan dan? Gewoon hardcoded src="http://'.$pad.'" erin zetten en $pad zou dan www.bla.com/img.jpg kunnen zijn. Bij het invoeren van een externe avatar zou je kunnen controleren en evt. filteren op schadelijke elementen.
Over e met dakjes enzo: dat is idd nieuw, alhoewel dat geloof ik met punycode werd weergegeven? Ik weet niet wat urlencode ermee doet. Maar wat dat betreft heb je gelijk. Wellicht dat je een combinatie van htmlspecialchars() en urlencode() kunt gebruiken, zoals: urlencode(htmlspecialchars($avatar)) Je wilt iig niet dat $avatar de SRC tag kan escapen doordat iemand invult: " onload="javashit:
__________________
Per undas adversas (tegen de stroom in)
|
25-08-2005, 16:39 | |
Werkt dat dan? Dan zou <br> ook moeten werken (<br>) en dat werkt toch echt niet. Maar ben wel benieuwd, dus jij zegt dat je met HTML elements ook onload="blabla" kunt invoegen?
En de combinatie met urlencode, htmlspecialchars en http:// ervoor, is dat niet waterdicht?
__________________
Per undas adversas (tegen de stroom in)
|
25-08-2005, 17:36 | ||
Citaat:
Diakritische tekens zijn alleen nieuw in domeinnamen, maar niet in de padnamen, dat is nog wel even een verschil. urlencode() maakt er zo'n %20-achtige code van, (%20 is de ' ' spaties, die kom je waarschijnlijk het vaakst tegen). Zoals ik dus al suggereerde is een combinatie van urlencode() en htmlspecialchars() inderdaad al een stukje beter, maar het zou kunnen dat dat nog niet goed genoeg is, zoals Dr HenDre suggereert. Ik denk nog steeds dat de regex het beste is.
__________________
Slechts beschikbaar via naamzoek/privebericht.
|
25-08-2005, 18:50 | ||
Citaat:
maar dit werkt: <img src="j ;avascript:alert('blaa');" /> dit werkt niet: <img src="http://echteplaatje.jpg/" onload="javas cript:alert('xss');" /> (ik probeer hier mal. invoer te simuleren) Verder ben ik t idd met manzuhai eens, dat regex het beste werkt (mits je een goeie hebt natuurlijk) het filmpje waar ik het over had incl pp presentatie, zeer leerzaam geweest voor mij Presentatie Bijbehorende video (Real Video) Laatst gewijzigd op 25-08-2005 om 19:01. |
26-08-2005, 18:37 | ||
Citaat:
|
Ads door Google |
27-08-2005, 16:55 | ||
Citaat:
en wat regexp betreft ben ik het helemaal met je eens, je moet sowieso altijd zorgen dat alles wat je in je database opslaat altijd goed is. Uitvoer kan alle kanten op, en kan makkelijk worden uitgebreid. Invoer wordt minder vaak uitgebreid. Als je maar zorgt dat alles goed je database in komt dan hoef je je bij uitvoer geen zorgen te maken. Hehe, ik weet haast zeker dat je ogen 2 rondjes om zn as draaien als je ziet hoe vaak dat over het hoofd wordt gezien en hoeveel sites zulke fouten bevatten. Kijk naar iedere willekeurige zelfgemaakte forum. Geen een tegen gekomen die daar rekening mee hield. Zelfs dit forum niet, op t fotoboek kon je in je profiel kei simpel javascript uitvoerne, en ik heb daar zelfs een keer stiekem misbruik van gemaakt (meteen effe biechten). Je steelt cookie en het is geen kunst om als iemand anders in te loggen. Maar die lek is gelukkig gefixt |
28-08-2005, 01:07 | |||
Citaat:
Citaat:
__________________
Per undas adversas (tegen de stroom in)
|
28-08-2005, 14:48 | ||
Citaat:
Het enige wat waardeloos was qua beveiliging was(/is ?) het fotoboek |
29-08-2005, 12:25 | ||
Citaat:
__________________
Per undas adversas (tegen de stroom in)
|
Advertentie |
|
29-08-2005, 14:25 | ||
Citaat:
Natuurlijk! Het is niet open source, dus automatisch OMG EVIL!!!1111
__________________
What experience and history teach is this — that people and governments never have learned anything from history, or acted on principles deduced from it.
Laatst gewijzigd op 29-08-2005 om 14:34. |
|
|