[php] verborgen php code in images

[Verwijderd]

Om te voorkomen dat een hacker zo maar op systemen hackt door een plaatje up te loaden met daarin verstopt code om de server te kraken (omdat jpeg automatisch wordt uitgevoerd) ben ik opzoek naar een oplossing voor dit probleem. Recent is dit ook al voor gekomen bij een andere site waarbij toen de site was gehacked.

Ik weet dat je images kan controleren op bepaalde data, maar volgens mij wordt dan de code ook al uitgevoerd. Ik heb ook al verschillende sites afgezocht, maar kan niet echt een oplossing hiervoor vinden.

Heeft iemand zich hier al veel verder in verdiept en kan mij hierbij wellicht helpen, bv een check o.i.d. om te controleren of er code verstopt zit in plaatjes?

[AtleX]

Je $_FILES[] bevat ook het mime-type, daar kan je op controleren.

code:

            [name] => gifje.gif
            [type] => image/gif
            [tmp_name] => ******************
            [error] => 0
            [size] => 2658

[ Voor 59% gewijzigd door AtleX op 19-07-2004 16:09 ]

[Verwijderd]

Okay dan!

Daar had ik inderdaad ook nog niet aan gedacht

thxz

[Verwijderd]

Ik ben bang dat ik je niet helemaal volg. Nou ben ik nooit een beveiligingsheld geweest, maar...


Een server hacken door een JPEG te uploaden? Een JPEG wordt "automatisch uitgevoerd"? Ten eerste is een JPEG data en geen code, dus kàn hij helemaal niet uitgevoerd worden. Ten tweede, hoezo wordt een JPEG automatisch gewhatsamafoogled als hij geupload wordt? Dat is specifiek aan het systeem waarmee je 't upload, maar ik ga ervan uit dat meeste scripts/servers niet zullen proberen meteen een willekeurig bestand wat geupload wordt uit te voeren.


Nou ken ik wel het fenomeen dat je BMPs kan voorzien van "malicious" data, en dat je bijvoorbeeld buffer overflows kan veroorzaken in de viewer (lees: Internet Explorer) en op zo elke code die je wilt kunt draaien. Maar op die manier raak je alleen nog maar de clients die het betreffende plaatje bekijken, niet de server.


Bovendien valt dat mime-type gewoon te vervalsen... dus daar schiet je ook niet veel mee op. En als het er om gaat dat er scripts/executables geupload worden met de naam van een plaatje... nou... ik zou sowieso nooit files uitvoeren die door willekeurig wie geupload kunnen worden. De entiteit aan de andere kant van de lijn vertrouw je namelijk nooit .


Dus ehm... zou je wat meer uitleg kunnen geven?

[ Voor 11% gewijzigd door Verwijderd op 19-07-2004 16:19 ]

[NMe]

Als je een php bestand uploadt met de jpg extensie, en er staat een script op de server dat include aan de hand van get data (bijvoorbeeld), dan zou dit een leak kunnen zijn. Helemaal zeker ben je nooit, maar je kan het beste naar het mime type kijken, en als je alleen maar images mag uploaden, dan zou je met de GD lib kunnen kijken of die images te openen zijn zonder fouten. Geen enkele methode is natuurlijk echt 100% veilig...

[Skinkie]

NMe84 schreef op 19 juli 2004 @ 16:32:
Als je een php bestand uploadt met de jpg extensie, en er staat een script op de server dat include aan de hand van get data (bijvoorbeeld), dan zou dit een leak kunnen zijn. Helemaal zeker ben je nooit, maar je kan het beste naar het mime type kijken, en als je alleen maar images mag uploaden, dan zou je met de GD lib kunnen kijken of die images te openen zijn zonder fouten. Geen enkele methode is natuurlijk echt 100% veilig...

waarom zou je een jpg plaatje via include door een server heel laten gaan? Het is ubertraag, er treed geen caching op... verzin zelf nog tien redenen...

[NMe]

Skinkie schreef op 19 juli 2004 @ 16:36:
[...]

waarom zou je een jpg plaatje via include door een server heel laten gaan? Het is ubertraag, er treed geen caching op... verzin zelf nog tien redenen...

Je snapt niet wat ik bedoel... Stel, er staat een script op je server dat deze regel bevat:

PHP:

include($_GET["file"]);

Erg onveilig, dat weet ik, maar er zijn zat scripts die dit hebben. Als een "hacker" nou een "jpg" uploadt met PHP code erin, en dan dat PHP script start met: "index.php?file=/upload/hack.jpg", dan wordt die code dus uitgevoerd en zijn de rapen gaar. En zo zijn er meer manieren om code uit te voeren...

[eborn]

NMe84 schreef op 19 juli 2004 @ 16:38:
Erg onveilig, dat weet ik, maar er zijn zat scripts die dit hebben. Als een "hacker" nou een "jpg" uploadt met PHP code erin, en dan dat PHP script start met: "index.php?file=/upload/hack.jpg", dan wordt die code dus uitgevoerd en zijn de rapen gaar. En zo zijn er meer manieren om code uit te voeren...

Klopt, maar dan zou ik eerder de scripts die zo verschrikkelijk vies includen aanpassen. Je bent toch bezig: of je moet alle uploads beveiligen of je zorgt dat zo'n include niet mogelijk is. Het laatste lijkt me veel nuttiger, omdat je op die manier ook externe includes tegengaat. Even er vanuit gaande dat je file-url-wrappers (of hoe heet dat ding) aan hebt staan.

[Michali]

Je kunt beter readfile() of file_get_contents() gebruiken voor dat soort dingen. Include alleen files die je zelf hebt geschreven zodat je zeker weet dat er niets mis kan gaan. Verder kun toch ook van de file system functies gebruken?

offtopic:
Ligt het nou aan mij of is de gehele documentation weg? http://nl2.php.net/manual/nl/

[Olaf van der Spek]

Michali schreef op 19 juli 2004 @ 16:59:

offtopic:
Ligt het nou aan mij of is de gehele documentation weg? http://nl2.php.net/manual/nl/

Andere mirror/site: http://www.php.net/manual/nl/

[Johnny]

Het parsen van PHP bestanden gaat toch op extensie? Dat betekent dat zodra een .php bestand wordt opgevraagd de webserver het eerst laat verwerken door PHP en dan opstuurt. Als het een .jpg extensie heeft zou het gewoon het bestand met een image/jpeg mime-type naar de client sturen die er vervolgens niets mee kan en het negeert.

edit:

Oh, NMe84 zegt het al... maar dat is inderdaad nogal een ranzige manier om veiligheidslekken te maken.

[ Voor 16% gewijzigd door Johnny op 19-07-2004 19:37 ]

[Verwijderd]

Als de hacker de bestanden op de server niet kan lezen, kan je het als volgt beveiligen:

In het include bestand:

code:

$dit_is_een_echt_include_bestand=TRUE;

In het andere bestand:

code:

include($file);
if (!$dit_is_een_echt_include_bestand) { die("Aaargh! Een hacker!!!") }

[RwD]

Verwijderd schreef op 19 juli 2004 @ 19:37:
Als de hacker de bestanden op de server niet kan lezen, kan je het als volgt beveiligen:

In het include bestand:

code:

$echt_include_bestand=TRUE;

In het andere bestand:

code:

include($file);
if (!$echt_include_bestand) { die("Aaargh! Een hacker!!!") }

Misschien een stomme vraag, maar is op die manier de code niet al uitgevoerd voordat je jouw test doet?

[ Voor 6% gewijzigd door RwD op 19-07-2004 19:49 ]

[Verwijderd]

Verwijderd schreef op 19 juli 2004 @ 19:37:
Als de hacker de bestanden op de server niet kan lezen, kan je het als volgt beveiligen:

In het include bestand:

code:

$dit_is_een_echt_include_bestand=TRUE;

In het andere bestand:

code:

include($file);
if (!$dit_is_een_echt_include_bestand) { die("Aaargh! Een hacker!!!") }

lol, dit is ook 1 van de ranzige methodes om het te doen... tis namelijk NIET safe.
je moet een define en isdefined oplossing maken, dat is tenminste niet te bepalen door client.

[Verwijderd]

RwD schreef op 19 juli 2004 @ 19:48:
Misschien een stomme vraag, maar is op die manier de code niet al uitgevoerd voordat je jouw test doet?

Ik wist wel dat er iets mis was...

[Olaf van der Spek]

Verwijderd schreef op 19 juli 2004 @ 19:52:
Ik wist wel dat er iets mis was...

Iets?
Het is een van de zoniet de brakste oplossing.

[Verwijderd]

OlafvdSpek schreef op 19 juli 2004 @ 20:02:
[...]

Iets?
Het is een van de zoniet de brakste oplossing.

Je hebt me overtuigd met je sterke argumenten.

[Verwijderd]

NMe84 schreef op 19 juli 2004 @ 16:38:
Je snapt niet wat ik bedoel... Stel, er staat een script op je server dat deze regel bevat:

PHP:

include($_GET["file"]);

Erg onveilig, dat weet ik, maar er zijn zat scripts die dit hebben. Als een "hacker" nou een "jpg" uploadt met PHP code erin, en dan dat PHP script start met: "index.php?file=/upload/hack.jpg", dan wordt die code dus uitgevoerd en zijn de rapen gaar. En zo zijn er meer manieren om code uit te voeren...

Madness! (maar dat had je zelf al door)

Oplossing: Plak voor ieder geupload plaatje de string "<? die %>" (nou maar hopen dat GOT dit niet include, je weet het niet...). Als je het plaatje wil tonen strip je die eerste regel weer gewoon...

Fail safe and far fetched ;-)

Simpeler:

Gebruik PHP's open_base_dir en safe_mode zodat alleen scripts in legitieme (non writeable) locaties uitgevoerd/geinclude kunnen worden.

[Soultaker]

AtleX schreef op 19 juli 2004 @ 16:07:
Je $_FILES[] bevat ook het mime-type, daar kan je op controleren.

Dat helpt niet, want die MIME-type wordt door de browser gekozen en een kwaadwillende gebruiker dan dus rustig PHP code uploaden en als MIME-type 'image/jpeg' stellen.

NMe84 schreef op 19 juli 2004 @ 16:32:
Als je een php bestand uploadt met de jpg extensie, en er staat een script op de server dat include aan de hand van get data (bijvoorbeeld), dan zou dit een leak kunnen zijn. Helemaal zeker ben je nooit, maar je kan het beste naar het mime type kijken, en als je alleen maar images mag uploaden, dan zou je met de GD lib kunnen kijken of die images te openen zijn zonder fouten.

Zoals je zelf aan aangeeft: dan maar je plaatjes controleren verhelpt het probleem niet. Je kunt altijd nog hopen dat fopen-wrappers aan staan of nog een andere methode verzinnen om van deze fout te profiteren.

Geen enkele methode is natuurlijk echt 100% veilig...

Zeker wel: je exploitable code aanpassen. Het toepassen van allerlei overbodige controles is alleen maar zonde van je tijd en resulteert in rommelige ononderhoudbare code. Je kunt je tijd en moeite beter besteden aan het schrijven van veilige en beknopte code.

Op de suggesties van Sjord en Xenna ga ik niet eens in; die vallen in dezelfde categorie van "leuk geprobeerd, maar verspilde moeite".

[ Voor 8% gewijzigd door Soultaker op 19-07-2004 21:27 ]

[NMe]

Soultaker schreef op 19 juli 2004 @ 21:26:
Zeker wel: je exploitable code aanpassen. Het toepassen van allerlei overbodige controles is alleen maar zonde van je tijd en resulteert in rommelige ononderhoudbare code. Je kunt je tijd en moeite beter besteden aan het schrijven van veilige en beknopte code.

Bij een groot project van meerdere pagina's van 10,000+ regels code is het niet altijd even makkelijk om alle bekende exploits eruit te halen, en en dan hebben we het nog niet eens over exploits die later pas bekend worden...

Soultaker schreef op 19 juli 2004 @ 21:26:
Op de suggesties van Sjord en Xenna ga ik niet eens in; die vallen in dezelfde categorie van "leuk geprobeerd, maar verspilde moeite".

Waar is jouw fail-safe oplossing voor het uploaden van images dan?

[Verwijderd]

NMe84 schreef op 19 juli 2004 @ 16:38:
[...]

Je snapt niet wat ik bedoel... Stel, er staat een script op je server dat deze regel bevat:

PHP:

include($_GET["file"]);

Erg onveilig, dat weet ik, maar er zijn zat scripts die dit hebben. Als een "hacker" nou een "jpg" uploadt met PHP code erin, en dan dat PHP script start met: "index.php?file=/upload/hack.jpg", dan wordt die code dus uitgevoerd en zijn de rapen gaar. En zo zijn er meer manieren om code uit te voeren...

Das dan een erg domme hacker want hij kan net zo goed een .php file includen en zichzelf de moeite besparen.

[Olaf van der Spek]

Verwijderd schreef op 19 juli 2004 @ 22:28:
Das dan een erg domme hacker want hij kan net zo goed een .php file includen en zichzelf de moeite besparen.

En hoe krijgt hij die .php file op de server?

[NMe]

Verwijderd schreef op 19 juli 2004 @ 22:28:
Das dan een erg domme hacker want hij kan net zo goed een .php file includen en zichzelf de moeite besparen.

Wat Olaf al zegt: als je op mime types en extensies en dergelijke controleert, dan krijg jij geen standaard php file op die server...

[Janoz]

Als je vervolgens ook nog zorgt dat een bezoeker nooit mbv get, post of cookie vars rechtstreeks de te includen file kan bepalen (Geen gebruik te maken dus van include($_GET('action')) maar bv een case) ben je niet gevoelig voor deze hack manier.

[Verwijderd]

Soultaker schreef op 19 juli 2004 @ 21:26:
Zeker wel: je exploitable code aanpassen. Het toepassen van allerlei overbodige controles is alleen maar zonde van je tijd en resulteert in rommelige ononderhoudbare code. Je kunt je tijd en moeite beter besteden aan het schrijven van veilige en beknopte code.

Evident, vandaar ook mijn 'madness'.
Als je site dat soort includes bevat ben je wel erg ver van huis.
Janoz heeft natuurlijk gelijk maar laten we er eens van uitgaan dat het een puzzletje is...

Op de suggesties van Sjord en Xenna ga ik niet eens in; die vallen in dezelfde categorie van "leuk geprobeerd, maar verspilde moeite".

Erg stoer.

Leg maar eens uit: Hoe kan een geuploade 'gif' met php code waar je <? die ?> voor zet nog als include exploit gebruikt worden? Het is een simpel trucje maar volgens mij lost het deze hypothetische exploit toch mooi op ;-)

'Leuk geprobeerd' klinkt meer als een beetje bluffen, en zoals iedereen weet heeft beveiligen niks met bluf te maken. Kaarten op de tafel dus, hoe ga jij mijn 'die' beveiliging kraken? ;-)

[ Voor 8% gewijzigd door Verwijderd op 19-07-2004 23:05 ]

[Infinitive]

Verwijderd schreef op 19 juli 2004 @ 23:03:
'Leuk geprobeerd' klinkt meer als een beetje bluffen, en zoals iedereen weet heeft beveiligen niks met bluf te maken. Kaarten op de tafel dus, hoe ga jij mijn 'die' beveiliging kraken? ;-)

Het probleem met dat ding van jouw is dat je bij het inladen dat stukje code er weer af moet knippen. Je kan dan geen include meer gebruiken om dat ding te openen.

Dit betekent dat je dus geen data aan het interpreteren bent, maar domweg aan het inladen (bijv. met fpasstrough() en varianten) en direct outputten. Maar dat alleen zorgt al voor het niet uitvoeren en dus was het zonder te knippen al veilig genoeg geweest. Ofwel, je beveiliging is overbodig en onnodig gecompliceerd

offtopic:
Die manier van includen (zoals de TS aangaf) heeft een merkwaardige analogie met het openen van bijlagen in Outlook...

[ Voor 12% gewijzigd door Infinitive op 19-07-2004 23:20 ]

[Soultaker]

Verwijderd schreef op 19 juli 2004 @ 23:03:
Leg maar eens uit: Hoe kan een geuploade 'gif' met php code waar je <? die ?> voor zet nog als include exploit gebruikt worden? Het is een simpel trucje maar volgens mij lost het deze hypothetische exploit toch mooi op ;-)

'Leuk geprobeerd' klinkt meer als een beetje bluffen, en zoals iedereen weet heeft beveiligen niks met bluf te maken. Kaarten op de tafel dus, hoe ga jij mijn 'die' beveiliging kraken? ;-)

Ik negeer je hele plaatje-upload-script en ik misbruik de fopen-wrappers om mijn script van het internet te laten laden, of ik frot m'n scriptcode in de webserver log (met een geschikte HTTP request) om ze vervolgens te laten inlezen door PHP, of ik frot m'n scriptcode in de mailfile (via een mailtje naar de webserver) die ik vervolgens laat inlezen door PHP, of ik verzin nog een andere methode die absoluut niets met het image upload script te maken heeft.

Jouw oplossing lost het beveiligsprobleem niet op, maar slechts één mogelijke exploit ervan. Daar heb je dus geen kont aan. Met het toepassen van die beveiliging heb je je code dus alleen maar een stuk complexer gemaakt, een hoop tijd verspilt en het verder verwerken van je plaatjes ontzettend lastig gemaakt (zoals Infinitive al aangaf), wat de performance niet ten goede komt (je moet elk bestand nog eens kopiëren elke keer dat je 'm inleest).

[ Voor 16% gewijzigd door Soultaker op 19-07-2004 23:21 ]

[Anders]

Verwijderd schreef op 19 juli 2004 @ 16:18:
Een server hacken door een JPEG te uploaden? Een JPEG wordt "automatisch uitgevoerd"?

yeps... als je er geen verstand van hebt is het uploaden van bestanden vragen om problemen. Zie Webwereld: Talentensite Henkjan Smits niet goed beveiligd

Dinsdag, 27 april 2004 - Talentscout.nl, de site van Idols-juryvoorzitter Henkjan Smits, lijkt in grote haast in elkaar te zijn gezet. Hackers kwamen zonder veel moeite binnen.

[Verwijderd]

maar je kan het geuploade plaatje toch ook in een mysql database dumpen? dan is een file (lees: jpeg) toch niet meer executable?

of praat ik nu raar?

[Verwijderd]

Ik heb het eerlijk gezegd niet helemaal gelezen, dit topic, maar als je (al dan niet door een upload aangevoerde) files gaat includen zorg er dan voor dat de bestandsnamen op zn minst in een array staan. Tenminste, zo werk ik altijd. Is vrij veilig.

En als je mensen files laat uploaden, dan ga je die toch niet met een GET variabelen laten includen?! Is wel een heel bijzonder ranzige methode, alsdus ondergetekende

Ge-uploade afbeeldingen gaan naar een open dir, en de bestanden worden vervolgens server-side geinclude en de link wordt dus gewoon in een IMG tag geplaatst. Niks geen risico op het uitvoeren van code lijkt me!
Succes verder.

[Jacco Swart]

Euhmmm

http://nl3.php.net/features.file-upload

en dus gewoon
$_FILES[] gebruiken of denk ik nu verkeerd?

[Bosmonster]

PHP is nogal vatbaar voor allersoortige injection.. of het nu code-injection of sql-injection is.

Het is heel eenvoudig deze injections te voorkomen door enigszins fatsoenlijke code te schrijven.

[Verwijderd]

Het includen van PHP files middels een ?action= attribuut is echt niet zo'n probleem, als je de invoer gewoon controleert voordat je 'm gebruikt.

Twee checks zijn voldoende:
* De .php extensie zet je niet in de parameter, maar plak je er _altijd_ achter.
* Bestaat het bestand (lokaal)?

Middels de eerste check voorkom je dat bestanden "die geen PHP zouden horen te zijn" niet geïnclude worden. Het is dan nog aan jou om te zorgen dat die bestanden er ook niet komen, maar dat moet niet zo'n probleem zijn.

En de tweede check gaat na of het geen remote file betreft. Je zou deze check nog iets sterker kunnen maken, door te zeggen dat het bestand moet bestaan in de huidige dir of een subdir van het huidige script, om path escapes te voorkomen.

Voilà.

Veilig.

[Verwijderd]

Infinitive schreef op 19 juli 2004 @ 23:17:
Het probleem met dat ding van jouw is dat je bij het inladen dat stukje code er weer af moet knippen. Je kan dan geen include meer gebruiken om dat ding te openen.

Je bedoelt misschien 'geen <img src=' (we hebben het tenslotte over plaatjes. Klopt, onhandig is het zeker, maar het *kan*.

Dit betekent dat je dus geen data aan het interpreteren bent, maar domweg aan het inladen (bijv. met fpasstrough() en varianten) en direct outputten. Maar dat alleen zorgt al voor het niet uitvoeren en dus was het zonder te knippen al veilig genoeg geweest. Ofwel, je beveiliging is overbodig en onnodig gecompliceerd

Mijn (toegegeven onzinnige) methode maakt het onmogelijk om met dat include trucje in plaatjes verstopte scripts uit te voeren en dat was precies de bedoeling. Het is onzinnig omdat je natuurlijk die suffe includes moet fixen...

[drm]

OneOfBorg:
Het includen van PHP files middels een ?action= attribuut is echt niet zo'n probleem, als je de invoer gewoon controleert voordat je 'm gebruikt.

Twee checks zijn voldoende:
* De .php extensie zet je niet in de parameter, maar plak je er _altijd_ achter.
* Bestaat het bestand (lokaal)?

1 Check is voldoende:
Bestaat de "include" in de array $my_valid_includes.

Ik snap niet dat over dit soort dingen altijd zo moeilijk gedaan wordt met allerlei vage checks en handigheidjes...

edit:

Overigens, de hack die op webwereld genoemd wordt kan alleen maar voorkomen als het geuploade bestand ook stand alone wordt uitgevoerd als php code. Dat betekent dus puur een check op mime-type en een extensie toevoegen op basis van dat mime-type om dat te voorkomen.

[ Voor 21% gewijzigd door drm op 20-07-2004 09:41 ]

[Verwijderd]

drm schreef op 20 juli 2004 @ 09:40:
[...]
1 Check is voldoende:
Bestaat de "include" in de array $my_valid_includes.

Mjah... maar ik vind het vervelend om steeds zo'n array in mijn code aan te moeten passen als ik er weer een module bijmaak.

Dus doe ik liever niet.

[Verwijderd]

Verwijderd schreef op 20 juli 2004 @ 09:20:
Het includen van PHP files middels een ?action= attribuut is echt niet zo'n probleem, als je de invoer gewoon controleert voordat je 'm gebruikt.

Twee checks zijn voldoende:
* De .php extensie zet je niet in de parameter, maar plak je er _altijd_ achter.
* Bestaat het bestand (lokaal)?

Ik gebruik bijna altijd alleen numerieke parameters voor dat soort dingen.

Bijvoorbeeld een gegenereerd selectje:

code:

<select name="view" onChange="document.myform.submit()">
  <option value="0" SELECTED>Collapsed tree</option>
  <option value="1">Expanded tree</option>
  <option value="2">A-Z list</option>
  <option value="3">Flat list</option>
</select>

En dan in de verwerking iets als:

code:

$view=preg_replace('/\D+/','',$_REQUEST[view]);
include "view". $_REQUEST[$view] . ".php";

Ook voor andersoortige zaken gebruik ik bij voorkeur integer parameters, zo ben je minder snel geneigd fouten te maken in wat wel of niet mag. Een verkeerd nummer zal meestal geen schade aanrichten: view4.php bestaat gewoon niet.

Als je het echt dicht wil hebben gebruik je een array met de toegestane waarden. Mijn selectboxjes komen toch al uit een array dus het is een koud kunstje die parameter even te verifieren door in datzelfde array te kijken.

code:

$views=Array('Collapsed tree','Expanded tree','A-Z list','Flat list');

if (!$views[$_REQUEST[view]]) die;

echo selectbox('view',$views,$_REQUEST[view],0,
        'onChange="document.myform.submit()"');

include "view". $_REQUEST[$view] . ".php";

[ Voor 13% gewijzigd door Verwijderd op 20-07-2004 09:48 ]

[drm]

OneOfBorg:
Mjah... maar ik vind het vervelend om steeds zo'n array in mijn code aan te moeten passen als ik er weer een module bijmaak.

Je kunt de array ook uit een database halen, of inlezen uit een directory waar je "modules" in zet.

[Verwijderd]

Uh... ja, maar als het in een database staat is het hetzelfde verhaal (of ik nou de database moet aanpassen of de code, maakt me niet veel verschil).

En als je de modules altijd uit een directory haalt, vinnik 't een beetje loos om een array te maken. Je kan dan namelijk net zo goed meteen op schijf checken.

[drm]

OneOfBorg:
En als je de modules altijd uit een directory haalt, vinnik 't een beetje loos om een array te maken. Je kan dan namelijk net zo goed meteen op schijf checken.

Het verschil is dat het checken of een bestand bestaat of een entry in een array bestaat. Als ik check of "/" bestaat, dan bestaat die. Of "../.htaccess". Maar die zit niet in de array.

Maar goed, 't hoeft niet

[Verwijderd]

ik zou het checken met getimagesize... als je dan een grootte terug krijgt is het een plaatje, en anders iets anders dus

[chem]

PHP:

$view=preg_replace('/\D+/','',$_REQUEST[view]);

zou ik doen met

PHP:

$view=(int)$_REQUEST[view];

Aangezien dat aanzienlijk sneller is, en je default naar 0.

Verwijderd schreef op 20 juli 2004 @ 10:08:
ik zou het checken met getimagesize... als je dan een grootte terug krijgt is het een plaatje, en anders iets anders dus

Mjah, maar de payload kan makkelijk achteraan zitten bij het bestand.

Verder:

quote: http://nl3.php.net/include/

If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), you can specify the file to be included using a URL (via HTTP or other supported wrapper - see Appendix L for a list of protocols) instead of a local pathname.

Dus als je een include($insecurevar); doet ben je eigenlijk altijd de sjaak, als je geen goede checks uitvoert: men kan zonder upload truukjes code injecten.

[ Voor 83% gewijzigd door chem op 20-07-2004 10:22 ]

[Verwijderd]

Verwijderd schreef op 20 juli 2004 @ 09:53:
En als je de modules altijd uit een directory haalt, vinnik 't een beetje loos om een array te maken. Je kan dan namelijk net zo goed meteen op schijf checken.

Het is een veiligere manier om dingen te checken tegen een beperkte lijst van toegestane zaken. Jouw schijfcheck zou ook al weer een aantal extra checks moeten bevatten (pad ervoor plakken, checken of er geen '..' in staat).

Je beschermt jezelf ook tegen je eigen fouten door het op een 'domme' manier te doen. En, ik weet niet hoe het bij jou gaat, maar ik maak veel te vaak een foutje en meestal omdat ik probeer te slim te zijn...

[ Voor 3% gewijzigd door Verwijderd op 20-07-2004 12:38 ]

[Verwijderd]

chem schreef op 20 juli 2004 @ 10:20:

PHP:

$view=preg_replace('/\D+/','',$_REQUEST[view]);

zou ik doen met

PHP:

$view=(int)$_REQUEST[view];

Aangezien dat aanzienlijk sneller is, en je default naar 0.

Zit wat in, maar ik programmeer 50/50 in PHP en Perl, dus ik ben geneigd methoden te gebruiken die werken in beide talen. (vandaar ook de preg)

Dit is trouwens de eerste keer dat ik zie dat PHP type-casting heeft en dat je dat zo kunt gebruiken. Ga ik toch maar eens gebruiken denk ik... Toch weer leerzaam zo'n thread

[Olaf van der Spek]

Bestandsnamen van sub-scripts zijn toch implementatiedetails?
De beste oplossing is gewoon om die helemaal niet in URLs te stoppen, dan kun je ze ook nog eens wijzigen zonder dat oudere URLs (bookmarks, etc) invalid worden.

[Marijn_S]

Het is trouwens ook mogelijk Javascript code uit te voeren in een plaatje in Internet Explorer.
Doordat Internet Explorer veel te los met de mime-type omgaat (denk ik) kan je gewoon <script>alert(document.cookie);</script> in bijvoorbeeld een .gif bestand zetten.

Hoewel het niet uitgevoerd wordt als je het plaatje via de image tag aanroept kan je wel ingelogde gebruikers (of bijvoorbeeld de admin van de website onder het mom van: "Hey, m'n plaatje doet het niet, kan je ff checken.") dat plaatje laten openen en vervolgens hun cookies jatten met alle gevolgen van dien.

Even als toevoeging aan dit topic, niet aan de oplossing want die is al gegeven natuurlijk

[Verwijderd]

OlafvdSpek schreef op 20 juli 2004 @ 10:48:
Bestandsnamen van sub-scripts zijn toch implementatiedetails?
De beste oplossing is gewoon om die helemaal niet in URLs te stoppen, dan kun je ze ook nog eens wijzigen zonder dat oudere URLs (bookmarks, etc) invalid worden.

Ja-aaaah... hoe wil je ze dan inladen?

Met een dik case-statement? Bleeehhh...

[Olaf van der Spek]

Verwijderd schreef op 20 juli 2004 @ 14:00:
Ja-aaaah... hoe wil je ze dan inladen?

Met een dik case-statement? Bleeehhh...

Bijvoorbeeld. Of een array ofzo.

[Grijze Vos]

ik gebruik tegenwoordig een .ini file, die wordt door een standaard php functie ingelezen. Werkt makkelijk, aanpassen is zo te doen, is zelfs een script voor te schrijven als je dat leuk/nodig vindt.

code:

; Modules Config Options

; Enabling modules
[enabmods]
news    = true
forum   = true
pm      = false
members = true

icm parse_ini_file()

[ Voor 41% gewijzigd door Grijze Vos op 20-07-2004 18:46 ]