[PHP] veiligheid van een link naar een image controleren
 

Ik wil dus op mijn site de mensen de mogelijkheid geven een soort 'avatar' te linken bij hun naam. Nu zou ik graag de link die ze ingeven laten checken op allerlei slechte dingen, zoals javascripts en zo.

Zijn er daar functions voor?

Je moet gewoon kijken met een image functie of het een geldig image bestand is. Ik denk dat er wel iets als FALSE teruggegeven wordt wanneer een image niet geldig is.

Het meest veilige is om dit elke keer te laten controleren wanneer men op de link klikt. Het kan immers veranderd zijn. Dus zou je een link naar een PHP script moeten maken met bijv. als parameter de URL van de link.

Je laat dat PHP script dan gewoon een image teruggeven als het een geldig image is.

Gewoon een htmlentities() filter overheen gooien. Die zet alle special chars om in HTML elements (& gt; enzo)

Als je de link alleen als image source gebruikt wel ja. En dat is ook waarschijnlijk wat hij wil.

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 :s

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 :nono: :nono:

Javascript? Hoe wil je javascirpt uitvoeren voor een image?

echo('<img src="http://'.htmlentities($avatar).'" alt="Avatar" />');

Lijkt me redelijk veilig. Een browser zal hopelijk geen javascript gaan uitvoeren bij het ophalen van een image, ook al wordt de image geserveerd als application/x-javascript ofzo. Anders is je browser echt brak.

Wat anders wordt het als je linkt naar een pagina (en of dat een image is of wat dat bepaalt de server). Daar kan vanalles 'evils' op staan, wat wil je precies filteren dan?

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 :)

Je wilt er absoluut zeker van zijn dat het begint met http:// of https://. Je wilt geen ed2k-links toestaan of andere zooi, dat kan een serieus security breach worden bij brakke browsers zoals IE.

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.

dat was inderdaad mijn punt in mijn eerste post in dit topic, dat je ervoor moet zorgen dat een link altijd begint met http, en dat kon ik niet opmaken uit jou eerste post, vandaar :)

Verder, ik weet haast zeker dat zelfs de door vele geliefde firefox, ook javascript zal uivoeren als je dat gewoon in de source zet, maar ik heb geen firefox dus kan dat niet testen. Nogmaals in Opera en in IE werkt het wel.

Ik ga slapen, truste :)

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.

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

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:

idd, urlencode is nog steeds heel onveilig omdat je uit de src kan ontsnappen door een " en vervolgens doe je gewoon onload bnla bla of onmouseover blabla.
Anyway, ik wil er ook op wijzen dat het niet alleen javascript is dat gevaarlijk is, ook dingen als livescript, vbscript en mocha kunnen hetzelfde.
daarnaast is stringreplace compleet nutteloos op de manier waarop jij m gebruikt.
Je moet dan eerst allen html en hex codes omzetten naar "karakters" en dan pas string replace
anders kan je makkelijk dit invoeren &#106 ;avascript:alert('blaa'); en je str_replace herkent m niet.
Of %6A;

Ik had hier een hele leuke presentatie over, ik zal eens kijken of ik die nog kan vinden

Werkt dat dan? Dan zou &lt;br&gt; 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?

Lijkt mij dat je die wel wil opslaan, anders heb je een soort van halve link, dat gaat nergens over.

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

nee niet zo
maar dit werkt:
<img src="&#106 ;avascript:alert('blaa');" />
dit werkt niet:
<img src="http://echteplaatje.jpg/&quot; onload=&quot;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)

PowerPoint? :nono:

Maar als je een regexp wilt inzetten om te controleren op schadelijke elementen, zou ik dat doen op het moment dat de gebruiker zijn externe avatar instelt. En niet elke keer dat deze wordt weergegeven. Zo hoef je maar 1 keer die regexp te draaien.

Maar ik blijf het vreemd vinden dat het uitvoeren van actieve code (iets wat ik als gevaarlijk beschouw en wat zeer strict geregeld zou moeten zijn) zo makkelijk gaat. Javascript in een SRC tag? Bad idea. Javascript-enablen via HTML elements? Bad idea. Maar daar heeft de TS niets aan natuurlijk, maar ik wil daar wel mijn verbazing over uitspreken. :p

nee :) er staat hier niets in deze topic waar iedereen het over eens is

Heb je nog gerichte vragen dan? Je zou nu wel een idee moeten hebben hoe je dit aan kunt pakken. Er zijn natuurlijk meerdere manieren om dat veilig te doen.

wat is er mis met powerpoint :p

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 :)

Proprietary, Microsoft, EVIL. :o
Zelfs dit forum niet? Je schat de gedateerde forumsoftware iets te hoog in denk ik. :D

hmm, misschien wel, maar ik moet zeggen ik heb een beetje zitten kloten. In t forum kan ik niks vinden, en ook niet via inet de bekende exploits.
Het enige wat waardeloos was qua beveiliging was(/is ?) het fotoboek :)

Nouja exploits worden wel gefixed natuurlijk, maar reken maar dat er veel in vB hebben gezeten. vB is gebouwd met dezelfde mentaliteit als microsoft.

wat dacht je dan van phpbb :p

Dat forum is dood lijkt het wel. Hoe lang ook alweer sinds ze met 2.1 bezig zijn? Te lang. ;)

ze zijn inmiddels bij 2.1.17 ofzo of 18 :D

:rolleyes:

Natuurlijk! Het is niet open source, dus automatisch OMG EVIL!!!1111 :|

gaaaaaan we weer :p (n)
eindeloze, waardeloze discussie

Zij begint :bloos:

Sorry, my bad. :)

:p :D :D