[PHP] Beveiliging (Input validation) en Monitoring (Ban)

[tim427]

Na jaren lang webapplicaties te hebben geschreven en altijd netjes alle input van de gebruikers ($_GET, $_POST, $_COOKIE) strip (regexp) naar alleen alphanumeric tekens of alles escape met funties als "mysql_real_escape_string()" / "htmlspecialchars()" vraag ik me af hoe jullie dit doen?

Zo kan ik me voorstellen dat er een aantal tweakers mooie standaard scripts hebben gemaakt die praktisch boven elke php-code geplaatst kan worden en meteen een stukje veiliger is.

Daarnaast heb ik een brainstormpje; "naast de input validation, wil je misschien ook monitoren en eventueel (automatisch) acties daar aan vast laten koppelen"

Situatie-schets: Je hebt een website met een contact-/registratie-formulier ($_POST) en een enkele index.php die aan de $_GET['p']-value kan zien welke pagina geladen moet worden vanuit de database.

Hierbij zou men kwetsbaar zijn voor de POST en GET input van de gebruiker. Deze input wordt natuurlijk netjes gestript tot het hoog nodige en zou daarmee veilig moeten zijn tegen SQL-injections en Cross Site scriptings.

Maar nu het idee: Vlak voordat de values gestript worden zou je kunnen detecteren of het hier om een aanval gaat, door te kijken wat voor input er binnen komt. Zodra men bijvoorbeeld drie keer iets probeert wat lijkt op een aanval kun je het script met "die('banned');" voortijdig laten stoppen of zelfs in iptables/.htaccess volledig blokkeren. Daarnaast weet je zelf ook wanneer je onder vuur ligt.

Nu kun je natuurlijk gewoon kijken of er "verboden woorden" in de input voorkomt zoals: 'LIMIT','UNION','SELECT','NULL','BOOLEAN','MODE','WHERE','TRUNCATE'

Maar wat nou als je een user hebt met als naam "selectvracht", "modewinkel", "limiteddeals", etc.

Hebben jullie hier wel eens over nagedacht/gebrainstormed? Gebruiken jullie al iets soort gelijks? Leuke ideeën om dit op een goede manier te detecteren?

[storeman]

Ik zou eerder verdacht zijn op andere tekens, zoals:
';)(

Deze kunnen namelijk je query breken en zijn uiteraard zelden geldig als username. Natuurlijk heb je meer velden dan een username of een ander id veld. Daarom zou je dergelijke tekens kunnen opslaan in combinatie met je keywords.

Echter ben ik geen voorstander van deze validatie. Ik sla soms een query op in de database, omdat bepaalde statistiek-functies eenvoudig aanpasbaar moeten zijn. Deze mogelijkheid, hoe zelden ook van toepassing, sluit je wel uit.

En wat als je een forum applicatie hebt waarbij deze input ook voor kan komen. Zelfs in combinatie met die speciale tekens. Op dit forum kan ik prima zeggen:

'; DROP DATABASE tweakers_7; '

[tim427]

Ja dat klopt. Nog eventjes benadrukken dat ik de input al strip/escape. En dit puur als extra beveiliging kan dienen (een ban na mogelijke aanval) maar ook als monitor voor jezelf.

Het gaat hier niet om een forum waarbij dit soort woorden wel mogen, maar eerder om een specifieke webshop bijvoorbeeld.

En juist omdat een "verboden woordenlijstje" veel false-positives kan geven wil ik met jullie brainstormen voor een iets betere algoritme

[Barryvdh]

Als je PDO met prepared statements gebruikt, beveilig je iig makkelijker tegen SQL injectie. Dan kan je ook niet per ongeluk een keertje vergeten je input te escapen (en je hoeft niet overal lelijk te gaan escapen/strippen) (Of een ORM, die dat werk voor je doet natuurlijk)

Bannen zou ik niet zoveel in zien, als je zorgt dat SQL injectie niet mogelijk is, hoef je dus ook niet bang te zijn dat ze na 20 pogingen wel ineens iets vinden..

[Johnny]

tim427 schreef op maandag 28 januari 2013 @ 22:23:
Na jaren lang webapplicaties te hebben geschreven en altijd netjes alle input van de gebruikers ($_GET, $_POST, $_COOKIE) strip (regexp) naar alleen alphanumeric tekens of alles escape met funties als "mysql_real_escape_string()" / "htmlspecialchars()" vraag ik me af hoe jullie dit doen?

Zo kan ik me voorstellen dat er een aantal tweakers mooie standaard scripts hebben gemaakt die praktisch boven elke php-code geplaatst kan worden en meteen een stukje veiliger is.

Daarnaast heb ik een brainstormpje; "naast de input validation, wil je misschien ook monitoren en eventueel (automatisch) acties daar aan vast laten koppelen"

Situatie-schets: Je hebt een website met een contact-/registratie-formulier ($_POST) en een enkele index.php die aan de $_GET['p']-value kan zien welke pagina geladen moet worden vanuit de database.

Hierbij zou men kwetsbaar zijn voor de POST en GET input van de gebruiker. Deze input wordt natuurlijk netjes gestript tot het hoog nodige en zou daarmee veilig moeten zijn tegen SQL-injections en Cross Site scriptings.

Maar nu het idee: Vlak voordat de values gestript worden zou je kunnen detecteren of het hier om een aanval gaat, door te kijken wat voor input er binnen komt. Zodra men bijvoorbeeld drie keer iets probeert wat lijkt op een aanval kun je het script met "die('banned');" voortijdig laten stoppen of zelfs in iptables/.htaccess volledig blokkeren. Daarnaast weet je zelf ook wanneer je onder vuur ligt.

Nu kun je natuurlijk gewoon kijken of er "verboden woorden" in de input voorkomt zoals: 'LIMIT','UNION','SELECT','NULL','BOOLEAN','MODE','WHERE','TRUNCATE'

Maar wat nou als je een user hebt met als naam "selectvracht", "modewinkel", "limiteddeals", etc.

Hebben jullie hier wel eens over nagedacht/gebrainstormed? Gebruiken jullie al iets soort gelijks? Leuke ideeën om dit op een goede manier te detecteren?

Het klopt dat heel veel mensen hier al over hebben nagedacht. Maar de oplossingen zitten niet op dit niveau. Het strippen van gereserveerde woorden is geen goed idee en helemaal onnodig.

Je kan perfect een veilige applicatie maken waarbij iemand "die('banned');" kan invoeren, dit opslaan in de database en weergeven aan de gebruiker.

Voor PHP/MySQL is iedereen het er inmiddels over eens dat je PDO met prepared statements moet gebruiken als je SQL-injecties wil voorkomen. Omdat dit standaard nogal wat omslachtig werkt gebruiken veel mensen een "scriptje" daarvoor, maar dan gaan ze ook meteen een stapje verder, want waarom zou je steeds handmatig bijna dezelfde SQL-queries blijven schrijven? Dat noemen we dan een ORM (Object-relational mapping)

RedbanPHP is een voorbeeld van een simpele ORM waarmee je direct aan de slag kan en wat je mooie, veilige overzichtelijke code oplevert.

Output escaping met bijvoorbeeld htmlspecialchars() doe je altijd op het moment dat je data gaat weergeven, omdat verschillende uitvoermogelijkheden verschillende vormen van escaping nodig hebben.

Als je deze werkwijzen hanteert, en ook zorgt dat de character encoding overal goed staat (alles hetzelfde) ingesteld dan is je applicatie voor jou veilig aan de serverkant.

Andere dingen zoals security updates van je server-software, de browser van de client zijn ook belangrijk maar vallen in principe buiten dit domein.

Bepaalde IP-adressen blokkeren op deze manier die jij voorstelt is een beetje vergezocht en waarschijnlijk ook niet effectief. Iemand kan dan je website voor hele organisaties onbereikbaar maken terwijl iemand die SQL-injecties kan bedenken ook wel kan uitvogelen hoe hij je website vanaf een ander IP kan benaderen.

[tim427]

Thanks voor de inzichten!

Ik zal zeker eventjes naar RedbanPHP kijken!

Maar stel, je hebt een bestaande webapplicatie die security-technisch heel slecht in elkaar zit, deze is door een derde partij geleverd en kan niet zomaar herschreven worden danwel wachten op de leverancier heeft geen zin.

Dan kun je bovenin de index.php (die eigenlijk alles processed) het volgende plaatsen:

PHP:

$_GET = preg_replace("/[^a-zA-Z0-9@.-_]/", "", $_GET);
$_POST = preg_replace("/[^a-zA-Z0-9@.-_]/", "", $_POST);
$_COOKIE = preg_replace("/[^a-zA-Z0-9@.-_]/", "", $_COOKIE);

Inprincipe wordt het dan wel heel lastig om dan nog code uit te voeren, toch?

Maar omdat het met zo'n workaround is beveiligd wil je misschien wel heel graag weten of er een aanval aan de gang is, zodat men kan inspringen tijdens zo'n inval (automatisch bijvoorbeeld).

Ik moet toegeven dat het "PDO met prepared statements" en "ORM" voor mij nieuw zijn. Ik zal me daar zeker voor inlezen! Nu ik weet dat er dit soort technieken bestaan, voelt bovenstaande gelijk een stuk meer "dirty". Maar helaas soms kan het niet anders.

[glashio]

tim427 schreef op maandag 28 januari 2013 @ 23:04:

PHP:

$_GET = preg_replace("/[^a-zA-Z0-9@.-_]/", "", $_GET);
$_POST = preg_replace("/[^a-zA-Z0-9@.-_]/", "", $_POST);
$_COOKIE = preg_replace("/[^a-zA-Z0-9@.-_]/", "", $_COOKIE);

Inprincipe wordt het dan wel heel lastig om dan nog code uit te voeren, toch?

Ikdenkhetwel:)

[storeman]

Ik vind het heel grof om alles maar te strippen. Meestal zal het wel zo'n beetje werken op die manier, je hebt echter twee nadelen:

- Je applicatie gaat zich onverwacht gedragen
- Je applicatie gaat zich onverwacht gedragen

[tim427]

glashio schreef op maandag 28 januari 2013 @ 23:09:
[...]
Ikdenkhetwel:)

Die ":" en ")" mogen niet

Maar een spatie mag er nog wel tussen inderdaad. My bad, had dit even snel getypt.

storeman schreef op maandag 28 januari 2013 @ 23:09:
Ik vind het heel grof om alles maar te strippen. Meestal zal het wel zo'n beetje werken op die manier, je hebt echter twee nadelen:

- Je applicatie gaat zich onverwacht gedragen
- Je applicatie gaat zich onverwacht gedragen

Tja, nu gaat het hier om een specifieke applicatie waarbij niet meer teken nodig zijn (geen forum, geen CMS, etc.)

Ik ben me nu aan het inlezen over ReadBeanPHP, dat ziet er super interessant uit! Thanks voor deze tip.

Maaaarrr... Dit gaat nu over de veiligheid zelf. De applicaties zijn verder wel veilig (test regelmatig met verschillende web applicatie scanners en sql-injectors). Maar PDO/ORM kan dit wel veel netter maken!

Nu dus vraag nummer twee: Monitoring. Het lijkt mij namelijk super interessant om te weten wanneer er iets geprobeerd wordt en zodra er iets gebeurt gewoon keihard te bannen via iptables/.htaccess waardoor de server resources bespaard blijven. sqlmap.org probeerd bijvoorbeeld ruim 10.000 combinaties, door dit na 3 pogingen al te blokkeren kan een hoop traffic/resources/mogelijkheden beperken, niet waar?

[Gomez12]

tim427 schreef op maandag 28 januari 2013 @ 23:19:
[...]
Tja, nu gaat het hier om een specifieke applicatie waarbij niet meer teken nodig zijn (geen forum, geen CMS, etc.)

Waarom dan uberhaupt nog free text accepteren, waarom niet alle mogelijkheden afvangen in een case-statement?
Zeker met web en copy-paste mogelijkheden is het makkelijk om een teken erin te krijgen wat jij niet leuk vindt maar wat geen kwaad kan. En waardoor door jouw simpele filtering de gebruiker niet snapt waardoor het fout gaat.

Nu dus vraag nummer twee: Monitoring. Het lijkt mij namelijk super interessant om te weten wanneer er iets geprobeerd wordt en zodra er iets gebeurt gewoon keihard te bannen via iptables/.htaccess waardoor de server resources bespaard blijven. sqlmap.org probeerd bijvoorbeeld ruim 10.000 combinaties, door dit na 3 pogingen al te blokkeren kan een hoop traffic/resources/mogelijkheden beperken, niet waar?

Nope, wat is het nut van het geautomatiseerd beperken?
Zeker bij iets als een webshop / webapplicatie zou ik niet te snel gaan bannen op ip. Grotere bedrijven gebruiken proxy's, vodafone / kpn / t-mobile etc gebruiken proxy's.
Jij hoeft maar 1 grappenmaker tegen te komen en alle vodafone gebruikers kunnen niet meer bij jouw site.

Het middel is imho al heel snel erger dan de kwaal. Als je het al wilt doen zorg dan in ieder geval dat je checks goed zijn (en niet half) en dat je het pas gaat doen na een onnatuurlijk hoog aantal zodat je echt alleen de bots treft.

Wil je er echt actief mee bezig zijn, dan gooi je je ip-bans zo hoog dat ze echt niet door een mens gehaald kunnen worden en je gooit een logscanner over je logs heen die elke dag/uur een net rapportje in je mailbox dumpt zodat je zelf kan beoordelen of het kwade wil is of slechts een menselijke fout en op basis van die inschatting kan je altijd nog gaan bannen

[Struikrover]

Ik denk eigenlijk dat veel developers die serieus werk aan het doen zijn een framework gebruiken geschreven in de taal waarin ze werken, om het hun zoveel makkelijker te maken.

Niet alleen omdat ze zich dan geen zorgen meer hoeven te maken om het escapen van input omdat dit vaak gebeurt door speciale functies binnen het framework aan te roepen voor deze gegevens, maar ook omdat ze nog veel meer handigheden bieden die zorgen dat de devver niet steeds het wiel opnieuw hoeft uit te vinden.

Frameworks bevatten allerlei componenten die het je een berg handiger maken. Verdiep je er maar eens in, je zult er echt geen spijt van krijgen

Ik noem een paar voorbeelden:

Java: Spring
PHP: Symfony2 (zijn nog legio andere te noemen, cakePHP, Silex, Laravel, Yii, etc. etc.)
Python: Django (geen Unchained )

[ Voor 13% gewijzigd door Struikrover op 29-01-2013 01:41 ]

[GlowMouse]

Volgens mij zoek je https://phpids.org/

[tim427]

Gomez12 schreef op dinsdag 29 januari 2013 @ 01:25:
[...]

Waarom dan uberhaupt nog free text accepteren, waarom niet alle mogelijkheden afvangen in een case-statement?
Zeker met web en copy-paste mogelijkheden is het makkelijk om een teken erin te krijgen wat jij niet leuk vindt maar wat geen kwaad kan. En waardoor door jouw simpele filtering de gebruiker niet snapt waardoor het fout gaat.


[...]

Nope, wat is het nut van het geautomatiseerd beperken?
Zeker bij iets als een webshop / webapplicatie zou ik niet te snel gaan bannen op ip. Grotere bedrijven gebruiken proxy's, vodafone / kpn / t-mobile etc gebruiken proxy's.
Jij hoeft maar 1 grappenmaker tegen te komen en alle vodafone gebruikers kunnen niet meer bij jouw site.

Het middel is imho al heel snel erger dan de kwaal. Als je het al wilt doen zorg dan in ieder geval dat je checks goed zijn (en niet half) en dat je het pas gaat doen na een onnatuurlijk hoog aantal zodat je echt alleen de bots treft.

Wil je er echt actief mee bezig zijn, dan gooi je je ip-bans zo hoog dat ze echt niet door een mens gehaald kunnen worden en je gooit een logscanner over je logs heen die elke dag/uur een net rapportje in je mailbox dumpt zodat je zelf kan beoordelen of het kwade wil is of slechts een menselijke fout en op basis van die inschatting kan je altijd nog gaan bannen

Zit wat in inderdaad! Maar stel dat je de "ban-monitor" als volgt opsteld: "60 vervboden woorden binnen een minuut" en daarna bannen".

Dit zijn onmenselijke aantallen, dan kun je een aanval "extra" afweren en resources/traffice besparen door deze keihard te blokken. Desnoods voor een (half)uur, omdat een aanval meestal niet langer duurt.

Struikrover schreef op dinsdag 29 januari 2013 @ 01:37:
Ik denk eigenlijk dat veel developers die serieus werk aan het doen zijn een framework gebruiken geschreven in de taal waarin ze werken, om het hun zoveel makkelijker te maken.

Niet alleen omdat ze zich dan geen zorgen meer hoeven te maken om het escapen van input omdat dit vaak gebeurt door speciale functies binnen het framework aan te roepen voor deze gegevens, maar ook omdat ze nog veel meer handigheden bieden die zorgen dat de devver niet steeds het wiel opnieuw hoeft uit te vinden.

Frameworks bevatten allerlei componenten die het je een berg handiger maken. Verdiep je er maar eens in, je zult er echt geen spijt van krijgen

Ik noem een paar voorbeelden:

Java: Spring
PHP: Symfony2 (zijn nog legio andere te noemen, cakePHP, Silex, Laravel, Yii, etc. etc.)
Python: Django (geen Unchained )

Natuurlijk gebruik ik frameworks (CodeIgnitor, python nog redelijk nieuw maar gebruik Django), maar soms is dat simpelweg niet mogelijk omdat er al een webapplicatie bestaat (derde partij).

Vandaar mijn draadje hier op T.net met twee vragen: 1) hoe simpel en effectief veilig te programmeren? Dit mocht misschien duidelijker dat het hier ook om bestaande omgeving zou gaan. 2) als extra laag: monitoren en dan eventueel automatisch bannen?

Ik kwam namelijk een tijdje terug al een paar onsuccesvolle SQL-injections tegen in de apache-log, dit heeft met doen denken om hier wat mee te doen

[Johnny]

tim427 schreef op maandag 28 januari 2013 @ 23:04:
Maar stel, je hebt een bestaande webapplicatie die security-technisch heel slecht in elkaar zit, deze is door een derde partij geleverd en kan niet zomaar herschreven worden danwel wachten op de leverancier heeft geen zin.

Dat ligt er aan wie je bent in dit geval. Als je een gemiddelde klant bent dan heb je hier geen weet van en zal je dus niks doen.

Als je als ontwikkelaar deze applicatie erft van een voorganger dan heb je inderdaad een probleem. Maar het doen van aanpassingen er aan levert dus ongewenst en onverwacht gedrag op. Zodra er iemand mee gaat werken en er achter komt dat nadat jij de applicatie hebt "beveiligd" er geen speciale tekens meer kunnen worden ingevoerd, terwijl dat voorheen wel kon dan ben je de sigaar. Dan moet je alsnog de hele applicatie gaan ombouwen waarvoor niemand gaat betalen. Je kan dus beter de beviliging op een lager niveau aanpakken. De applicatie isoleren en verhuizen naar een (virtuele) server zodat er niks anders kan worden gesloopt en dan beveiliging op een lager niveau door bijvoorbeeld HTTP-authenticatie toe te voegen.

Bij het eerstvolgende onderhoud aan de applicatie maak je een enorm ruime inschatting van de tijd die je nodig hebt en herschrijf je het hele ding.

[creator1988]

tim427 schreef op dinsdag 29 januari 2013 @ 07:38:
Zit wat in inderdaad! Maar stel dat je de "ban-monitor" als volgt opsteld: "60 vervboden woorden binnen een minuut" en daarna bannen".

Dit zijn onmenselijke aantallen, dan kun je een aanval "extra" afweren en resources/traffice besparen door deze keihard te blokken. Desnoods voor een (half)uur, omdat een aanval meestal niet langer duurt.

Om 'aanvallen' af te weren zijn heel wat efficientere methodes dan 'verboden' woorden te tellen.

[tim427]

creator1988 schreef op dinsdag 29 januari 2013 @ 11:13:
[...]

Om 'aanvallen' af te weren zijn heel wat efficientere methodes dan 'verboden' woorden te tellen.

Dat was mij ook wel duidelijk, vandaar dit draadje om kennis te delen. Er bestaan dure/betaalde oplossingen maar ongetwijfeld ook vernuftigere stukjes php code.

Deze topic had in mijn ogen twee doelen 1) hoe meest efficient input validateren 2) eventueel monitoren en daar eventueel acties aan vast te koppelen (mailtje dat je aangevallen wordt of zelf heel rigoureus een ban voor een bepaalde tijd).