upload controleren op type (php)

On Aug 18, 11:52 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
> On Mon, 18 Aug 2008 23:23:32 +0200, Warden Dave <wardend...@mnsys.invalid>
> wrote:

> > dat kan net zo goed iets
> > zijn als bijv. PHP-script. Het is overigens geen nieuw onderwerp.
> > Zie o.a. deze suggesties & opmerkingen:
> >http://ha.ckers.org/blog/20070604/pa...-through-getim...
>
> Yup, goede verhalen. Ik zelf sla nooit user uploads op als bestand. Een
> prepared statement gebruiken voor een blob naar een database, en precies
> dezelfde blob weer teruggeven bij opvragen, dat is toch wel veiliger, en
> bovendien naar mijn idee makkelijker te administreren (zeker bij een
> systeem met 'gebruikers' houd ik nogal van ON DELETE CASCADE functies,
> handig zo'n database die direct gerelateerde info opruimt :) ). Met de
> juiste instellingen is het ook maar marginaal trager dan via het
> bestandssyteem serveren van de inhoud.

Dan ga je dus uit van het achteraf opruimen. Het zondermeer opslaan
en tonen is zo fout. Waarom zou je er achteraf geen sql,xss injecties
in kunnen oproepen?

Hans


> --
> Rik Wasmus

"Rik Wasmus" <luiheidsgoeroe@hotmail.com> wrote:
> Warden Dave <wardendave@mnsys.invalid> wrote:
>> "Rik Wasmus" <luiheidsgoeroe@hotmail.com> wrote:

>>> Waarschijnlijk zegt MSIE wat anders (n.a.w. 'image/x-jpeg' o.i.d.),
>>> wat je natuurlijk makkelijk kunt controleren door de $_FILES array
>>> te dumpen en te controleren. Verder is dit een 'user-supplied'
>>> waarde, ofwel: totaal onbetrouwbaar. Ik kan als ik dat wil best wel
>>> een nare executable uploaden en beweren dat het een jpeg is.
>>>
>>> Om te controleren of iets een plaatje is (waar ik wat mee kan)
>>> gebruik ik normaal de GD functie getimagesize(): relatief laag
>>> resource gebruik, en je weet zeker dat je het als plaatje kunt
>>> interpreteren:

>> Maar ja... ook met het gebruik van 'getimagesize' weet je dat een paar
>> velden een vorm hebben die verwacht wordt, meer niet. Over de verdere
>> inhoud van het bestand weet je dan nog niets;

> Tja, we hebben hier 2 kanten van de thread, waar het mee begon is
> 'hoe kan ik zien wat voor plaatje het is', waarvoor getimagesize() prima
> geschikt is (in ieder geval beter dan extensie of mime-type controleren),
> waarbij je er van uit gaat dat als die deze test doorstaat je er in
> ieder geval iets mee kan (zoals dimensies aanpassen met de GD functies).
> Als mensen moedwillig verkeerde gebroken plaathes gaan uploaden is het
> een ander verhaal.

Ehm, maar dat is nou precies waar jij over begon. :) ("ofwel: totaal
onbetrouwbaar" etc.) Ik ga in op dat door jou voorgestelde gebruik van
'getimagesize' en "je weet zeker...", na je angstaanjagende vertelling.

>> dat kan net zo goed iets
>> zijn als bijv. PHP-script. Het is overigens geen nieuw onderwerp.
>> Zie o.a. deze suggesties & opmerkingen:
>> http://ha.ckers.org/blog/20070604/pa...-getimagesize/

> Yup, goede verhalen. Ik zelf sla nooit user uploads op als bestand. Een
> prepared statement gebruiken voor een blob naar een database, en precies
> dezelfde blob weer teruggeven bij opvragen, dat is toch wel veiliger,
<knip>

Enfin, nu is in ieder geval aanvullend gewaarschuwd dat je niet weten kunt
wat iets zijn mag dat buiten de controle valt... ;)

WD

On Tue, 19 Aug 2008 00:18:01 +0200, Warden Dave <wardendave@mnsys.invalid>
wrote:

> "Rik Wasmus" <luiheidsgoeroe@hotmail.com> wrote:
>> Warden Dave <wardendave@mnsys.invalid> wrote:
>>> "Rik Wasmus" <luiheidsgoeroe@hotmail.com> wrote:
>
>>>> Waarschijnlijk zegt MSIE wat anders (n.a.w. 'image/x-jpeg' o.i.d.),
>>>> wat je natuurlijk makkelijk kunt controleren door de $_FILES array
>>>> te dumpen en te controleren. Verder is dit een 'user-supplied'
>>>> waarde, ofwel: totaal onbetrouwbaar. Ik kan als ik dat wil best wel
>>>> een nare executable uploaden en beweren dat het een jpeg is.
>>>>
>>>> Om te controleren of iets een plaatje is (waar ik wat mee kan)
>>>> gebruik ik normaal de GD functie getimagesize(): relatief laag
>>>> resource gebruik, en je weet zeker dat je het als plaatje kunt
>>>> interpreteren:
>
>>> Maar ja... ook met het gebruik van 'getimagesize' weet je dat een paar
>>> velden een vorm hebben die verwacht wordt, meer niet. Over de verdere
>>> inhoud van het bestand weet je dan nog niets;
>
>> Tja, we hebben hier 2 kanten van de thread, waar het mee begon is
>> 'hoe kan ik zien wat voor plaatje het is', waarvoor getimagesize() prima
>> geschikt is (in ieder geval beter dan extensie of mime-type
>> controleren),
>> waarbij je er van uit gaat dat als die deze test doorstaat je er in
>> ieder geval iets mee kan (zoals dimensies aanpassen met de GD functies).
>> Als mensen moedwillig verkeerde gebroken plaathes gaan uploaden is het
>> een ander verhaal.
>
> Ehm, maar dat is nou precies waar jij over begon. :) ("ofwel: totaal
> onbetrouwbaar" etc.) Ik ga in op dat door jou voorgestelde gebruik van
> 'getimagesize' en "je weet zeker...", na je angstaanjagende vertelling.

Jaja, klopt wel, maarrr, ik zei daarna ook dat 'geldige' plaatjes nog
prima injecties met zich mee konden dragen :).

>>> dat kan net zo goed iets
>>> zijn als bijv. PHP-script. Het is overigens geen nieuw onderwerp.
>>> Zie o.a. deze suggesties & opmerkingen:
>>> http://ha.ckers.org/blog/20070604/pa...-getimagesize/
>
>> Yup, goede verhalen. Ik zelf sla nooit user uploads op als bestand. Een
>> prepared statement gebruiken voor een blob naar een database, en
>> precies dezelfde blob weer teruggeven bij opvragen, dat is toch wel
>> veiliger,
> <knip>
>
> Enfin, nu is in ieder geval aanvullend gewaarschuwd dat je niet weten
> kunt
> wat iets zijn mag dat buiten de controle valt... ;)

En dat kan nooit kwaad, zeker niet als het over PHP gaat waar er een
ontzettende bult aan code zo lek is als een mandje ;)
--
Rik Wasmus

On Tue, 19 Aug 2008 00:05:16 +0200, Hans W <hans.wolters.nlo@gmail.com>
wrote:

> On Aug 18, 11:52 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
>> On Mon, 18 Aug 2008 23:23:32 +0200, Warden Dave
>> <wardend...@mnsys.invalid>
>> wrote:
>
>> > dat kan net zo goed iets
>> > zijn als bijv. PHP-script. Het is overigens geen nieuw onderwerp.
>> > Zie o.a. deze suggesties & opmerkingen:
>> >http://ha.ckers.org/blog/20070604/pa...-through-getim...
>>
>> Yup, goede verhalen. Ik zelf sla nooit user uploads op als bestand. Een
>>
>> prepared statement gebruiken voor een blob naar een database, en
>> precies
>> dezelfde blob weer teruggeven bij opvragen, dat is toch wel veiliger,
>> en
>> bovendien naar mijn idee makkelijker te administreren (zeker bij een
>> systeem met 'gebruikers' houd ik nogal van ON DELETE CASCADE functies,
>> handig zo'n database die direct gerelateerde info opruimt :) ). Met de
>> juiste instellingen is het ook maar marginaal trager dan via het
>> bestandssyteem serveren van de inhoud.
>
> Dan ga je dus uit van het achteraf opruimen.

Huh, verklaar je nader? Verkijk je niet op de ON DELETE CASCADE, dat is
een zijtak qua administratie, maar heeft niets met het beveiligingsverhaal
te maken.

> Het zondermeer opslaan
> en tonen is zo fout.

Dat hangt van de applicatie af. In geval van enkel plaatjes: ja (of
specifiek filpmjes, etc), in geval van 'vrije upload' waarbij min of meer
willekeurige binaries zijn toegestaan echter... Als er bijvoorbeeld ergens
documentatie wordt geupload, kan dat plain text, pdf, doc, odf, zip, gz en
nog zoveel meer zijn. Elk van die bestandstypen afvangen, begrijpen,
opschonen en controleren, dat is zowat onbegonnen werk.

> Waarom zou je er achteraf geen sql,xss injecties
> in kunnen oproepen?>

XSS met behoorlijk wat moeite heel misschien, maar door een content-type
mee te geven wordt dit door iedere redelijke UA in ieder geval niet
uitgevoerd. SQL absoluut niet, daarvoor hebben we prepared statements bij
invoeren, en gooien we de rauwe binaire data terug zonder er iets mee te
doen bij uitvoeren. Dat MSIE ooit script tags in jpeg's uitvoerde mag
hopelijk wel als verleden tijd bestempeld worden, en het is ook meer een
taak van de UA om dat soort zaken te voorkomen dan van je zelf. Jouw taak
is om er voor te zorgen dat er op je server en in de browser zelf geen
rare zaken worden uitgevoerd (i.e. als iets in de UA geinterpreteerd wordt
moet het 'schoon' zijn), maar als je 'vrije upload' hebt, en ook 'vrije
download', dan is het beste wat je kunt doen mensen waarschuwen dat je
daar weinig controle over hebt, en aangeven dat als zij iets downloaden
het hun taak is daar verder met zorg / gezond argwanen mee om te gaan.
Natuurlijk verwijder je iets als blijkt dat er iets gedownload wordt wat
niet door de beugel kan, maar ze mogen je wel grof geld betalen als je
alles van tevoren zou moeten controleren, of je hebt schrikbarend tijd
teveel.

Maar misschien zie ik iets over het hoofd, hoe denk jij dat dit een XSS
attack zou kunnen veroorzaken?
--
Rik Wasmus

"Rik Wasmus" <luiheidsgoeroe@hotmail.com> wrote:
> On Tue, 19 Aug 2008 00:18:01 +0200, Warden Dave:


>> Ehm, maar dat is nou precies waar jij over begon. :) ("ofwel: totaal
>> onbetrouwbaar" etc.) Ik ga in op dat door jou voorgestelde gebruik van
>> 'getimagesize' en "je weet zeker...", na je angstaanjagende vertelling.

> Jaja, klopt wel, maarrr, ik zei daarna ook dat 'geldige' plaatjes
> nog prima injecties met zich mee konden dragen :).

Ik zag dat 1 paar berichten later in de draad, maar besloot dat m'n
aanvullende opmerkingen, over bijv. zo'n PHP-script met integers (bin)
ingevoegd op de juiste plaats, toch nog nuttig waren, omdat 'getimagesize'
voor een moment op een 'echte plaat'-detector had geleken.

WD

Warden Dave wrote:
> Maar ja... ook met het gebruik van 'getimagesize' weet je dat een paar
> velden een vorm hebben die verwacht wordt, meer niet. Over de verdere
> inhoud van het bestand weet je dan nog niets; dat kan net zo goed iets
> zijn als bijv. PHP-script. Het is overigens geen nieuw onderwerp.
> Zie o.a. deze suggesties & opmerkingen:
> http://ha.ckers.org/blog/20070604/pa...-getimagesize/

Het wordt steeds ingewikkelder (voor mij althans :-)
Heeft het, voor de beoordeling van het type bestand nu wel of niet zin om
'mime' uit getimagsize() te gebruiken in plaats van 'type' uit de array
$_FILES ?

--
Nico

:
> Warden Dave wrote:
> > Maar ja... ook met het gebruik van 'getimagesize' weet je dat een paar
> > velden een vorm hebben die verwacht wordt, meer niet.
> > http://ha.ckers.org/blog/20070604/pa...-getimagesize/
>
> Heeft het, voor de beoordeling van het type bestand nu wel of niet zin om
> 'mime' uit getimagsize() te gebruiken in plaats van 'type' uit de array
> $_FILES ?

Jij wilt weten of een plaat van een geldig type is, en wat dat type dan
is. Is er in dat verband iets ongeldig, dan geef je bij de upload een
foutmelding. Toch?

In dat geval neem ik 'type' uit $_FILE en de bestandsextensie. Komen
beide overeen (dus bv. "image/x-jpeg of /pjpeg of /jpeg" en ".jpg") dan
beschouw ik het als .jpg-plaatje en behandel het zo. Ik gebruik dan dus
de jpg-functies voor bewerking. Opslaan onder een door mij opgelegde naam
met .jpg-extensie en het is goed.

De genoemde bezwaren gaan grotendeels over eventueel geinjecteerde
server-side code. Als ik het goed begrijp, is dat geen gevaar zolang het
plaatje maar niet door de PHP-parser wordt gestuurd (lees: geen .php-
extensie heeft - of een andere extensie die de webserver als php-
parsebaar beschouwt).


--
Erick

Erick T. Barkhuis wrote:
>> Warden Dave wrote:
>>> Maar ja... ook met het gebruik van 'getimagesize' weet je dat een
>>> paar velden een vorm hebben die verwacht wordt, meer niet.
>>> http://ha.ckers.org/blog/20070604/pa...-getimagesize/

>> Heeft het, voor de beoordeling van het type bestand nu wel of niet
>> zin om 'mime' uit getimagsize() te gebruiken in plaats van 'type'
>> uit de array $_FILES ?

> Jij wilt weten of een plaat van een geldig type is, en wat dat type
> dan is. Is er in dat verband iets ongeldig, dan geef je bij de upload
> een foutmelding. Toch?

Klopt!!

> In dat geval neem ik 'type' uit $_FILE en de bestandsextensie. Komen
> beide overeen (dus bv. "image/x-jpeg of /pjpeg of /jpeg" en ".jpg")
> dan beschouw ik het als .jpg-plaatje en behandel het zo. Ik gebruik
> dan dus de jpg-functies voor bewerking. Opslaan onder een door mij
> opgelegde naam met .jpg-extensie en het is goed.
>
> De genoemde bezwaren gaan grotendeels over eventueel geinjecteerde
> server-side code. Als ik het goed begrijp, is dat geen gevaar zolang
> het plaatje maar niet door de PHP-parser wordt gestuurd (lees: geen
> .php- extensie heeft - of een andere extensie die de webserver als
> php- parsebaar beschouwt).

Duidelijk. Bedankt Erick!

--
Nico

:
> Erick T. Barkhuis wrote:
> >> Warden Dave wrote:
> >>> Maar ja... ook met het gebruik van 'getimagesize' weet je dat een
> >>> paar velden een vorm hebben die verwacht wordt, meer niet.
> >>> http://ha.ckers.org/blog/20070604/pa...-getimagesize/
>
> >> Heeft het, voor de beoordeling van het type bestand nu wel of niet
> >> zin om 'mime' uit getimagsize() te gebruiken in plaats van 'type'
> >> uit de array $_FILES ?

> > In dat geval neem ik 'type' uit $_FILE en de bestandsextensie. Komen
> > beide overeen (dus bv. "image/x-jpeg of /pjpeg of /jpeg" en ".jpg")
> > dan beschouw ik het als .jpg-plaatje [...]
>
> Duidelijk. Bedankt Erick!

Graag gedaan. Overigens moet ik er bij vermelden dat ik in alle
uploadscripts die ik heb gemaakt _ook_ getimagesize() gebruik -
bijvoorbeeld om de <img>-attributen op te vragen of om een thumbnail aan
te maken. Rolt daar een foutmelding uit, dan krijgt de uploadende
bezoeker ook doorgaans een melding "sorriekennie" om z'n oren.



--
Erick

In article <48a922c5$0$94226$dbd4f001@news.euronet.nl>, "Nico Schuyt"
<nschuyt(AT)gmail(DOT)com> says...
> Rob wrote:
> > In een uploadbestand gebruik ik het volgende om bestandstype en
> > -grootte te controleren
> > if (($_FILES["file"]["type"] == "image/gif")
> >>> ($_FILES["file"]["type"] == "image/jpeg")
> > && ($_FILES["file"]["size"] < 250000))
> > {
> > hier het een en ander
> > }
>
> Moet dat niet zijn:
> if (($_FILES["file"]["type"] == "image/gif") || ($_FILES["file"]["type"] ==
> "image/jpeg")) && ($_FILES["file"]["size"] < 250000)) {..}
>
>

Uiteindelijk is het geworden:

if ((($_FILES["file"]["type"] == "image/gif")
|| ($_FILES["file"]["type"] == "image/jpeg")
|| ($_FILES["file"]["type"] == "image/pjpeg"))
&& ($_FILES["file"]["size"] < 250000))

met de haakjes op de juiste plaats en pjpeg toegevoegd voor IE.
Het werkt nu.

Verder interessante discussie en linkjes over filetypes

Bedankt!
Rob

Rob:

> Uiteindelijk is het geworden:
>
> if ((($_FILES["file"]["type"] == "image/gif")
> || ($_FILES["file"]["type"] == "image/jpeg")
> || ($_FILES["file"]["type"] == "image/pjpeg"))
> && ($_FILES["file"]["size"] < 250000))

> Het werkt nu.


Zou je het niet interessant vinden om tenminste nog PNG-platen toe te
voegen?

--
Erick

On Aug 19, 1:26 am, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
> On Tue, 19 Aug 2008 00:05:16 +0200, Hans W <hans.wolters....@gmail.com>
> wrote:
> > Het zondermeer opslaan
> > en tonen is zo fout.
>
> Dat hangt van de applicatie af. In geval van enkel plaatjes: ja (of
> specifiek filpmjes, etc), in geval van 'vrije upload' waarbij min of meer
> willekeurige binaries zijn toegestaan echter... Als er bijvoorbeeld ergens
> documentatie wordt geupload, kan dat plain text, pdf, doc, odf, zip, gz en
> nog zoveel meer zijn. Elk van die bestandstypen afvangen, begrijpen,
> opschonen en controleren, dat is zowat onbegonnen werk.
>
> > Waarom zou je er achteraf geen sql,xss injecties
> > in kunnen oproepen?>
>
> XSS met behoorlijk wat moeite heel misschien, maar door een content-type
> mee te geven wordt dit door iedere redelijke UA in ieder geval niet
> uitgevoerd. SQL absoluut niet, daarvoor hebben we prepared statements bij
> invoeren, en gooien we de rauwe binaire data terug zonder er iets mee te
> doen bij uitvoeren. Dat MSIE ooit script tags in jpeg's uitvoerde mag
> hopelijk wel als verleden tijd bestempeld worden, en het is ook meer een
> taak van de UA om dat soort zaken te voorkomen dan van je zelf. Jouw taak
> is om er voor te zorgen dat er op je server en in de browser zelf geen
> rare zaken worden uitgevoerd (i.e. als iets in de UA geinterpreteerd wordt
> moet het 'schoon' zijn), maar als je 'vrije upload' hebt, en ook 'vrije
> download', dan is het beste wat je kunt doen mensen waarschuwen dat je
> daar weinig controle over hebt, en aangeven dat als zij iets downloaden
> het hun taak is daar verder met zorg / gezond argwanen mee om te gaan.
> Natuurlijk verwijder je iets als blijkt dat er iets gedownload wordt wat
> niet door de beugel kan, maar ze mogen je wel grof geld betalen als je
> alles van tevoren zou moeten controleren, of je hebt schrikbarend tijd
> teveel.
>
> Maar misschien zie ik iets over het hoofd, hoe denk jij dat dit een XSS
> attack zou kunnen veroorzaken?

Dat kan vaak op verschillende manieren. Mail Rasmus er maar eens over
en zie dat, zeer zeker in php4, er veel mogelijkheden zijn.

Over het gebruik van prepared statements ben ik het maar gedeeltelijk
met
je eens. Maar noem mij eens iets dat garantie bied tegen bijvoorbeeld
een
stuk php code die attached danwel gecat is aan een plaatje. Een ps zal
je
daar verder niet bij helpen omdat de checks vaak gewoon constateren
dat
het idd een plaatje is.

Grote probleem hierin is dat het niet zozeer op jouw server een
probleem hoeft
te veroorzaken maar dat mensen het lokaal wellicht gaan bewerken met
een
programma waarvan jij niet weet hoe het plaatjes leest. (of een ander
formaat,
ik kijk maar even naar de pdf problemen van eerder dit jaar).

Waarschuwen is goed maar alert blijven op eventuele oplossingen is
beter.

Hans
> --
> Rik Wasmus

Rik Wasmus wrote in nl.internet.www.server-side:
> On Tue, 19 Aug 2008 00:05:16 +0200, Hans W <hans.wolters.nlo@gmail.com>
> wrote:
>
>> On Aug 18, 11:52 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
>>> On Mon, 18 Aug 2008 23:23:32 +0200, Warden Dave
>>> <wardend...@mnsys.invalid>
>>> wrote:
>>
>>> > dat kan net zo goed iets
>>> > zijn als bijv. PHP-script. Het is overigens geen nieuw onderwerp.
>>> > Zie o.a. deze suggesties & opmerkingen:
>>> >http://ha.ckers.org/blog/20070604/pa...-through-getim...
>>>
>>> Yup, goede verhalen. Ik zelf sla nooit user uploads op als bestand. Een
>>>
>>> prepared statement gebruiken voor een blob naar een database, en
>>> precies
>>> dezelfde blob weer teruggeven bij opvragen, dat is toch wel veiliger,
>>> en
>>> bovendien naar mijn idee makkelijker te administreren (zeker bij een
>>> systeem met 'gebruikers' houd ik nogal van ON DELETE CASCADE functies,
>>> handig zo'n database die direct gerelateerde info opruimt :) ). Met de
>>> juiste instellingen is het ook maar marginaal trager dan via het
>>> bestandssyteem serveren van de inhoud.
>>
>> Dan ga je dus uit van het achteraf opruimen.
>
> Huh, verklaar je nader? Verkijk je niet op de ON DELETE CASCADE, dat is
> een zijtak qua administratie, maar heeft niets met het beveiligingsverhaal
> te maken.
>
>> Het zondermeer opslaan
>> en tonen is zo fout.
>
> Dat hangt van de applicatie af. In geval van enkel plaatjes: ja (of
> specifiek filpmjes, etc), in geval van 'vrije upload' waarbij min of meer
> willekeurige binaries zijn toegestaan echter... Als er bijvoorbeeld ergens
> documentatie wordt geupload, kan dat plain text, pdf, doc, odf, zip, gz en
> nog zoveel meer zijn. Elk van die bestandstypen afvangen, begrijpen,
> opschonen en controleren, dat is zowat onbegonnen werk.
>
>> Waarom zou je er achteraf geen sql,xss injecties
>> in kunnen oproepen?>
>
> XSS met behoorlijk wat moeite heel misschien, maar door een content-type
> mee te geven wordt dit door iedere redelijke UA in ieder geval niet
> uitgevoerd. SQL absoluut niet, daarvoor hebben we prepared statements bij
> invoeren, en gooien we de rauwe binaire data terug zonder er iets mee te
> doen bij uitvoeren. Dat MSIE ooit script tags in jpeg's uitvoerde mag
> hopelijk wel als verleden tijd bestempeld worden, en het is ook meer een
> taak van de UA om dat soort zaken te voorkomen dan van je zelf. Jouw taak
> is om er voor te zorgen dat er op je server en in de browser zelf geen
> rare zaken worden uitgevoerd (i.e. als iets in de UA geinterpreteerd wordt
> moet het 'schoon' zijn), maar als je 'vrije upload' hebt, en ook 'vrije
> download', dan is het beste wat je kunt doen mensen waarschuwen dat je
> daar weinig controle over hebt, en aangeven dat als zij iets downloaden
> het hun taak is daar verder met zorg / gezond argwanen mee om te gaan.
> Natuurlijk verwijder je iets als blijkt dat er iets gedownload wordt wat
> niet door de beugel kan, maar ze mogen je wel grof geld betalen als je
> alles van tevoren zou moeten controleren, of je hebt schrikbarend tijd
> teveel.
>
> Maar misschien zie ik iets over het hoofd, hoe denk jij dat dit een XSS
> attack zou kunnen veroorzaken?

Ach bijna vrij simpel en ik zal een voorbeeld geven waarbij iedereen met
een niet up to date WordPress installatie niet blij van gaat worden. Ik
ga niet in de exacte details en je kan wel gebruiken waarom.

Ruim 18 maanden geleden heeft het projectteam een aantal exploits
toegezonden gekregen van hoe je WordPress kan mishandelen. Bijna elke
WordPress-installatie op deze aardkloot. De inbraakmogelijkheid van
Britse onderzoekers was al maanden daarvoor bij ze aangemeld door iemand
anders en werd afgedaan als onbelangrijk. Net zoals dat SQL-injects niet
goed worden afgevangen, wat het verkrijgen van admin-privileges erg
makkelijk maakt.

Wat heeft dat met jouw te maken heel veel, want hoewel ze alles
probeerde weg te filteren mocht admin-level alles in de database
stoppen. Is dat niet fijn. Zeker omdat ze aangaven dat niemand onder
admin werkt, maar een kleine scan door redelijk wat installaties vertelt
mij wat anders helaas. We hebben een weg naar binnen en kunnen nu dingen
in een database stoppen welke gevaarlijk kunnen zijn.

Dit zou geen probleem zijn als je de output controleert, maar omdat ze
geloven hun gebruikers wordt de output niet behandeld. Resultaat is dat
je ineens gevaarlijke content naar iedereen kan toesturen op grote
schaal. En zover bekent is dit nog steeds mogelijk bij WordPress en ik
wil geen verkeerde wakker maken, maar je kan bijna overnacht alle
installaties geruisloos overnemen. Het wordt misschien tijd om alle
problemen met dit pakket gewoon direct naar BugTraq te sturen.

Helaas stopt het verhaal hier niet, want dit is maar een kan van het
probleem van het niet vertrouwen van data. Hier ging het alleen nog maar
om data op slinkse wijze te achterhalen. Helaas waar het artikel over
gaat is dat elke bestand met <?php ?> erin door PHP kan worden gedraait.
En meneer Rasmussen bevestigt dit ook en dat het zo ook hoort te werken.

Nu gaan mensen ineens roepen dat ze hun webserver nooit andere bestanden
dan .php laten executen door PHP. Leuk en aardig, maar er zijn duizenden
manieren waarop je dat kan laten doen en de mooiste zit in PHP zelf met
de functie eval(). Volgens mijn geheugen had dat een leuk neveneffect op
phpBB ergens in 2006 en zo zijn er nog wel veel meer.

En je roept dat het veel geld kost om vooraf alles te definieren, maar
mag ik je "Secure Coding" aanraden wat ingaat op dit probleem. Het is
een leuk dun boekje wat voor sommige misschien wel eens een eye-opener
kan zijn hopelijk. Ik gok dat Postfix _het_ voorbeeld is en blijft
waarom vooraf duidelijk controleren juist in je voordeel werkt. Daarbij
elke fatsoenlijke software engineering opleiding, wel in mijn tijd,
leerde hoe je functies moest testen en ook zo efficient mogelijk.
Blijkbaar zit dat niet meer in de knoppencursus zodat je een IDE kan
bedienen.

Over het feit van je mogelijk schadelijk content online zet en ik mag
wel zeggen dat je het bewust doen, want je neemt niet de
verantwoordelijkheid om het te controleren dan wel te schonen. Dit is
misschien een leuke voor Arnoud Engelfriet en ik weet niet of hij het
ook bespreekt in zijn nieuwe boek. Het is wel interessant om te zien
trouwens dat bijna geen enkele developer hier lijkt te leren cq code
reuse lijkt te doen of uberhaupt code tussen project wil delen. Dit
stemt mij somber over de toekomst.

B.

On Wed, 20 Aug 2008 22:41:13 +0200, Hans W <hans.wolters.nlo@gmail.com>
wrote:
> On Aug 19, 1:26 am, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
>> On Tue, 19 Aug 2008 00:05:16 +0200, Hans W <hans.wolters....@gmail.com>
>> wrote:
>> > Het zondermeer opslaan
>> > en tonen is zo fout.
>>
>> > Waarom zou je er achteraf geen sql,xss injecties
>> > in kunnen oproepen?>
>>
>> XSS met behoorlijk wat moeite heel misschien, maar door een
>> content-type
>> mee te geven wordt dit door iedere redelijke UA in ieder geval niet
>> uitgevoerd. SQL absoluut niet, daarvoor hebben we prepared statements
>> bij
>> invoeren, en gooien we de rauwe binaire data terug zonder er iets mee
>> te
>> doen bij uitvoeren.

>> Maar misschien zie ik iets over het hoofd, hoe denk jij dat dit een XSS
>>
>> attack zou kunnen veroorzaken?
>
> Dat kan vaak op verschillende manieren. Mail Rasmus er maar eens over
> en zie dat, zeer zeker in php4, er veel mogelijkheden zijn.

Wie, en doe me dat adres, mnaar voor dat ik hem lastig val, in welke
situaties? Als ik een binaire stream met PHP ergens naartoe gooi, en ik
geef (in geval van een HTTP protocol) een correct of fallback content-type
mee, hoe denk je dat het de server beïnvloedt???

> Over het gebruik van prepared statements ben ik het maar gedeeltelijk
> met
> je eens.

Waarom? Er wordt sowieso totaal geen SQL geinterpreteerd in je aangeboden
variabele als je _echte_ prepared statements gebruikt... Eventuele
mankementen in prepared statements wil ik zeer zeker weten!

> Maar noem mij eens iets dat garantie bied tegen bijvoorbeeld
> een
> stuk php code die attached danwel gecat is aan een plaatje.

Door te voorkomen dat een plaatje ooit op de server geinterpreterd wordt?

> Een ps zal je
> daar verder niet bij helpen omdat de checks vaak gewoon constateren
> dat het idd een plaatje is.

Dat is wat ik al een hele tijd geleden zei.

> Grote probleem hierin is dat het niet zozeer op jouw server een
> probleem hoeft
> te veroorzaken maar dat mensen het lokaal wellicht gaan bewerken met
> een
> programma waarvan jij niet weet hoe het plaatjes leest. (of een ander
> formaat,

Hmjah, als virussen via plaatjes verspreid kunnen worden (en dat kan), en
je hebt een upload die plaatjes uitlevert (vrij normaal), dan kan het
zeker zo zijn dat iemand dat virus via jou oploopt. Niet iets wat je wil.
Aan de andere kant is zo'n vrije upload ook niet iets wat je aan ieder wil
geven. Het is een kwestie van specialisatie. Ben je een flickr.com dan kun
je wellicht over elke upload een hopelijk adequate virusscanner heen
gooiden, de meeste mensen met normale virtual hosting kunnen dat echter
niet.

> ik kijk maar even naar de pdf problemen van eerder dit jaar).
>
> Waarschuwen is goed maar alert blijven op eventuele oplossingen is
> beter.

Absoluut, als mensen je de tools aanbieden, en je daar de tijd/geld/ruimte
voor hebt om ze toe te passen: prima, doe dat. Maar je kunt van jou niet
verwachten dat jij pdf's gaat controleren op een mogelijke security
breach, waarvan:
a) Je wellicht niet op de hoogte bent, aangezien er honderden
bestandformaten door je systeem gaan.
b) Er geen handzame check is om dit op je eigen server te controleren
c) Er nog geen informatie is, alleen 'dat het kan' (genoeg van die
zaken...)

Als je een echte fileserver hebt draaien, heb je natuurlijk idealiter alle
laatste zaken qua virus en exploit detectie draaien, en probeer je dat
zoveel mogelijk te voorkomen. Veel mensen die gewoon op virtual hosting
zitten hebben die optie echter niet, hoe zou jij willen voorstellen dat op
te lossen?

PS: waar komen al je rare =A0 's (in de source natuurlijk, gewoon enter in
geinterpreteerde msg) vandaan in je "quoted printable' posting? Er lijkt
een dubbele filter qua newlines op te staan (eerst hard newlines op
lengte, gevolgd door 'softe' newlines op een iets andere, en kortere,
lengte...), dat maakt in mijn nieuwsgroep reader het wel irritant om te
lezen :P. Of is dit weer het zoveelste rare issue van Google Groups?
(Eternal september... d'r komt natuurlijk ook weer een echte 'september
flood' aan...)

[/houdt op veel te laat op de avond te posten]
--
Rik Wasmus

On Thu, 21 Aug 2008 00:13:46 +0200, blacklistme <blacklistme@xs4all.nl>
wrote:

> Rik Wasmus wrote in nl.internet.www.server-side:
>> On Tue, 19 Aug 2008 00:05:16 +0200, Hans W <hans.wolters.nlo@gmail.com>
>> wrote:
>>
>>> On Aug 18, 11:52 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:

>>>> Yup, goede verhalen. Ik zelf sla nooit user uploads op als bestand.
>>>> Een
>>>>
>>>> prepared statement gebruiken voor een blob naar een database, en
>>>> precies
>>>> dezelfde blob weer teruggeven bij opvragen, dat is toch wel veiliger,
>>>> en
>>>> bovendien naar mijn idee makkelijker te administreren (zeker bij een
>>>> systeem met 'gebruikers' houd ik nogal van ON DELETE CASCADE
>>>> functies,
>>>> handig zo'n database die direct gerelateerde info opruimt :) ). Met
>>>> de
>>>> juiste instellingen is het ook maar marginaal trager dan via het
>>>> bestandssyteem serveren van de inhoud.
>>>
>>> Dan ga je dus uit van het achteraf opruimen.
>>
>> Huh, verklaar je nader? Verkijk je niet op de ON DELETE CASCADE, dat is
>> een zijtak qua administratie, maar heeft niets met het
>> beveiligingsverhaal
>> te maken.
>>
>>> Het zondermeer opslaan
>>> en tonen is zo fout.
>>
>> Dat hangt van de applicatie af. In geval van enkel plaatjes: ja (of
>> specifiek filpmjes, etc), in geval van 'vrije upload' waarbij min of
>> meer
>> willekeurige binaries zijn toegestaan echter... Als er bijvoorbeeld
>> ergens
>> documentatie wordt geupload, kan dat plain text, pdf, doc, odf, zip, gz
>> en
>> nog zoveel meer zijn. Elk van die bestandstypen afvangen, begrijpen,
>> opschonen en controleren, dat is zowat onbegonnen werk.
>>
>>> Waarom zou je er achteraf geen sql,xss injecties
>>> in kunnen oproepen?>
>>
>> XSS met behoorlijk wat moeite heel misschien, maar door een content-type
>> mee te geven wordt dit door iedere redelijke UA in ieder geval niet
>> uitgevoerd. SQL absoluut niet, daarvoor hebben we prepared statements
>> bij
>> invoeren

>> Maar misschien zie ik iets over het hoofd, hoe denk jij dat dit een XSS
>> attack zou kunnen veroorzaken?
>
> Ach bijna vrij simpel en ik zal een voorbeeld geven waarbij iedereen met
> een niet up to date WordPress installatie niet blij van gaat worden. Ik
> ga niet in de exacte details en je kan wel gebruiken waarom.

Ik heb geen kennis van precieze wordpress implementaties, en ik neem aan
dat als er een lek in zit (altijd wat met die populaire packages), dat er
ergens online over gezeurd dan wel terecht geklaagd wordt. URL graag, of
ik geloof het niet... Ik pas er voor om zelf die code na te lopen, zeker
aangezien ik die zooi zelf niet gebruik :P

> Wat heeft dat met jouw te maken heel veel, want hoewel ze alles

jou

> probeerde weg te filteren mocht admin-level alles in de database
> stoppen. Is dat niet fijn. Zeker omdat ze aangaven dat niemand onder
> admin werkt, maar een kleine scan door redelijk wat installaties vertelt
> mij wat anders helaas. We hebben een weg naar binnen en kunnen nu dingen
> in een database stoppen welke gevaarlijk kunnen zijn.

'We'? En wat is 'in een database stoppen' gevaarlijk? Niet dat je dat
absoluut niet wil, en zeker eeeen fenomenaal lek zou zijn, maar om het in
perspectief te zetten, ik zou meer bezorgd zijn over (eventueel
vertrouwelijke zaken) UIT een database te halen dan erin zetten...

> Dit zou geen probleem zijn als je de output controleert, maar omdat ze
> geloven hun gebruikers wordt de output niet behandeld. Resultaat is dat
> je ineens gevaarlijke content naar iedereen kan toesturen op grote
> schaal. En zover bekent is dit nog steeds mogelijk bij WordPress en ik
> wil geen verkeerde wakker maken, maar je kan bijna overnacht alle
> installaties geruisloos overnemen. Het wordt misschien tijd om alle
> problemen met dit pakket gewoon direct naar BugTraq te sturen.

Kijk, als je een kant en klaar pakket gebruikt, dan moet je zeker daar op
af gaan, je hoort alle updates bij te houden, en als een pakket geen
publieke bug tracking bijhoudt is het zeker in HTTP contreien vrij direct
verdacht, en derhalve een pakket dat je niet wil gebruiken.

> Helaas stopt het verhaal hier niet, want dit is maar een kan van het
> probleem van het niet vertrouwen van data. Hier ging het alleen nog maar
> om data op slinkse wijze te achterhalen. Helaas waar het artikel over
> gaat is dat elke bestand met <?php ?> erin door PHP kan worden gedraait.

En elk bestand met C code kan worden gecompiled en uitgevoerd... Wat is je
punt?

> En meneer Rasmussen bevestigt dit ook en dat het zo ook hoort te werken.

Maar als er zo'n groot lek in zit, dan zou je dat toch van de daken moeten
schreeuwen, zeker met zo'n populair systeem? Leef je uit, seg waar het
fout gaat, en als ik dat kan bevestigen heb ik zo een pubiek van duizenden
mensen die dachten dat het goed zat die als een gek bezig gaan die lekken
te dichten.

> Nu gaan mensen ineens roepen dat ze hun webserver nooit andere bestanden
> dan .php laten executen door PHP. Leuk en aardig, maar er zijn duizenden
> manieren waarop je dat kan laten doen en de mooiste zit in PHP zelf met
> de functie eval(). Volgens mijn geheugen had dat een leuk neveneffect op
> phpBB ergens in 2006 en zo zijn er nog wel veel meer.

Als je een eval() statment kunt uitvoeren op een server op een willekeurig
bestand of string van code zit het probleem veel eerder dan dat eval()
statament. Zo'n statement hoort niet uitvoerbaar te zijn tenzij de
programmeur beslist dan bepaalde invoer om strak afgebakende redenen
eval()baar is, en onder welke omstandigheden. Eval() zelf is absoluut niet
iets wat he een lek kunt noemen (alhoewel je eval()'s en soortgelijke
zaken wel ten allen tijde hoort te vermijden tenzij het niet anders kan).
Verder ben ik nooit onder de indruk van phpBB geweest, en vind ik het
ondanks de verbeteringen die ze de laatste tijd hebben gemaakt nog steeds
driewerf niets.

> En je roept dat het veel geld kost om vooraf alles te definieren, maar
> mag ik je "Secure Coding" aanraden wat ingaat op dit probleem.

'Secure Coding', 502,000 hits op google, en de meeste top-hits geen over
programmeer fouten, die we natuurlijk allemaal hier niet maken :). Het
gaat hier over bestanden / willekeurige bitstreams uitleveren, en dat is
heel ander koek. Tenzij je zelf die bestanden maakt (waarbij je als je je
systeem een beetje schoon houdt er van uit kan gaan dat die exploit-free
zijn) heeft dat niets met de huidige discussie te maken, meer met het
algemene onbenul van de willekeurige beginneling/stagaire die denkt iets
in elkaar te kunnen zetten.

> Het is
> een leuk dun boekje wat voor sommige misschien wel eens een eye-opener
> kan zijn hopelijk. Ik gok dat Postfix _het_ voorbeeld is en blijft
> waarom vooraf duidelijk controleren juist in je voordeel werkt. Daarbij
> elke fatsoenlijke software engineering opleiding, wel in mijn tijd,
> leerde hoe je functies moest testen en ook zo efficient mogelijk.
> Blijkbaar zit dat niet meer in de knoppencursus zodat je een IDE kan
> bedienen.

Wat heeft dit te maken met bestanden uploaden en uitleveren? Goede
lekvrije code schrijven is afgrijselijk genoeg blijkbaar ook een kunst
voor veel mensen die sich danwel scripters dan wel programmeurd noemen,
maar:
1) een willekeurige bit-stream interpreteren als een bepaald bestand
2) een parser schrijven die interpreteerd wat dat bestand precies gaat
uitvoeren
3) controleren of al de uitvoerende taken door de beugel kunnen
4) controleren welke van alle mogelijke gebruikers applicaties lekken
hebben die eventueel misbruikt worden door die uitvoering

.... dat hoort zeker niet tot je taken. Mocht je een bericht van een lek
doorkrijgen, en je krijgt het gereedschap en de mogelijkheid om deze te
detecteren, natuurlijk filter je zulke bestanden eruit. Maar zoals jij
beweert zou ik MS Office (wellicht nog onbekende) lekken moeten kunnen
voorspellen in bestanden en die blokkeren? Kom nu zeg, ga bij een
antivirus bedrijf werken, en geef de rest van de gemeenschap het
gereedschap om direct dat soort zaken te detecteren en te elimineren.

> Over het feit van je mogelijk schadelijk content online zet en ik mag
> wel zeggen dat je het bewust doen, want je neemt niet de
> verantwoordelijkheid om het te controleren dan wel te schonen.

Hangt er van af. Ik ga absoluut geen service beginnen met vrije upload,
maar ik heb wel mensen die willekaurige bestanden online zetten voor hun
klanten/publiek die dat als service aanbieden (documentatie, applicaties,
etc.). Jan met de pet iets laten uploaden en weer verspreiden via mijn
server daar ga ik niet aan beginnnen, vanwege begrijpelijke redenen
waarover we het nu wel gehad hebben, maar je snapt toch zelf ook wel dat
je niet de illusie moet hebben dat door 'goede code op de server' er
ineens geen binaries in en uit kunnen gaan met kwade bedoelingen?

> Dit is
> misschien een leuke voor Arnoud Engelfriet en ik weet niet of hij het
> ook bespreekt in zijn nieuwe boek. Het is wel interessant om te zien
> trouwens dat bijna geen enkele developer hier lijkt te leren cq code
> reuse lijkt te doen of uberhaupt code tussen project wil delen. Dit
> stemt mij somber over de toekomst.

Je schermt ermee dat je dit met goede code zou kunnen afschermen. Ik bied
je bij deze direct een ton aan euro's als je mij de code kunt geven die
van een willekeurig geupload bestand alle mogelijke exploits, virussen en
wormen kunt filteren, want ik zou daar goud geld aan verdienen.

Als je dat niet kan, verzoek ik je uit te leggen hoe ik een interface kan
schrijven voor een klant (die al dan niet een virus heeft) die een stukje
documentatie in MS Word formaat wil uploaden (waarin al dan niet dat
hypothetische virus zit) waarbij mijn stukje code ervoor zorgt dat het
vanwege dat virus niet online komt te staan.

Virusscanners draaien, je eigen libraries zoveel mogelijk up to date
houden, direct packages lozen of blokkeren die veiligheidslekken hebben,
en verder veilig coden, dat is toch wel alles wat je kunt doen IMO.
--
Rik Wasmus