BEVEILIG je site! Dit moet je doen.

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ozzie PHP

Ozzie PHP

12/01/2011 13:13:19
Quote Anchor link
Tijd voor een leuk topic dacht ik zo! Gestimuleerd door een ander topic van vandaag, kwam ik op het idee om een algemeen beveiligingstopic te starten. Er bestaan (o.a. op PHPhulp) veel vragen en tutorials over specifieke beveiligingsproblemen. Nu lijkt het me een leuk / goed / interessant idee om in deze topic heel kort telkens één specifiek beveiligingsprobleem onder de aandacht te brengen en wel op deze manier: titel, korte omschrijving van wat het beveiligingsprobleem inhoudt, een voorbeeld, hoe bescherm je je ertegen (uitleg / links). Het doel is uiteindelijk dat dit een uitgebreid topic wordt waarin je alle vormen van beveiliging kunt terugvinden die van jouw site een VEILIGE SITE maken!

Laat ik zelf dan maar aftrappen, en hopelijk volgen er nog vele andere bruikbare reacties. Iedereen is vrij om te posten, maar wel graag op deze manier: titel, korte omschrijving van wat het beveiligingsprobleem inhoudt, een voorbeeld, hoe bescherm je je ertegen (uitleg / links). Op deze manier krijgen we hopelijk een mooi beveiligingstopic wat telkens weer kan worden aangevuld indien nodig.

En dan nu de allereerste:

Cross Site Request Forgery (CSRF)

Omschrijving:
Een CSRF aanval is vrij vertaald een "kruis website aanvraag vervalsing". Er wordt via een andere website een valse aanvraag op jouw website gedaan.

Bij zo'n CSRF attack is er sprake van 2 websites:

1) een website die jij vertrouwt en waarop je moet inloggen (voorbeelden: webmail, marktplaats, twitter)
2) een kwaadaardige website

Voorbeeld:
Persoon A (genaamd Anke) ziet dat een veilingsite ondersteuning biedt voor externe afbeeldingen. (Afbeeldingen waar het volledige URL voor dient ingevuld te worden.) Anke besluit om een aanbieding te plaatsen voor haar oude auto. Op de aanbieding kan geboden worden. Het bieden op de auto geschiedt door de volgende link:

http://www.naamveilingwebsite.nl/bieden?aanbieding=1020&bedrag=[HIER HET BIEDBEDRAG]

Anke weet dit en besluit een tweede advertentie te plaatsen, waarin ze een nieuwe Porsche aanbiedt. Dit keer plaatst Anke de bovenstaande link als externe afbeelding en stelt het bod in op 100.000 euro. Persoon B genaamd Bert komt op de website en ziet de advertentie van Anke. Wanneer Bert de advertentie van Anke opent, heeft hij ongemerkt 100.000 euro geboden op de oude auto, omdat de browser die Bert gebruikt de externe afbeelding probeerde te laden en dus de link heeft geopend. Het lijkt nu alsof Bert daadwerkelijk een bod van 100.000 euro heeft gedaan, terwijl hij in feite slachtoffer is geworden van CSRF.

Hoe bescherm je je er tegen?
Door gebruik te maken van "tokens". Kijk hier voor meer uitleg.
 
PHP hulp

PHP hulp

06/08/2020 00:58:53
 
Karl Karl

Karl Karl

12/01/2011 14:17:23
Quote Anchor link
Nog een mooier voorbeeld, op de oude phphulp kon je vrienden van iemand worden. Dan moest je naar diegene zijn profiel gaan en dan op een linkie klikken. Dit ging via een url met GET data.
Dus was er iemand / waren er mensen zo slim geweest om dit te gebruiken: in topic plaatste ze dan een img naar die url toe, en dan deden ze de waarde random. Dat betekende dus dat er mensen zomaar 'opeens' vriend werd van iemand anders.
 
Bas Cost Budde

Bas Cost Budde

12/01/2011 17:33:31
Quote Anchor link
Een goede reden om met een GET-request geen data-wijzigingen toe te staan. Zoals het bedoeld is in REST (je weet wel? REpresentational State Transfer)

Edit: termen gebruiken, dan de goede termen :)
Gewijzigd op 12/01/2011 21:24:13 door Bas Cost Budde
 
Ozzie PHP

Ozzie PHP

12/01/2011 18:00:11
Quote Anchor link
Bas, inderdaad een zeer goede toevoeging om te stellen dat je via een GET request geen data-wijzigingen moet doorvoeren. Kun je (voor de volledigheid van dit topic) omschrijven wat REST inhoudt?

(Ik hoop dat er mensen zijn die deze topic gaan aanvullen met andere beveiligingsproblemen op de manier zoals omschreven in de beginpost.)
 
Bas Cost Budde

Bas Cost Budde

12/01/2011 22:17:12
Quote Anchor link
REST is een manier van inrichten die in zo min mogelijk woorden de koppeling tussen client er server zo goed mogelijk, maar/en zo los mogelijk regelt. Elk request van de client is bedoeld om een bepaalde "staat" te bereiken, en bevat alle informatie die nodig is voor die staat.

Zie ook http://en.wikipedia.org/wiki/Representational_State_Transfer

HTTP leent zich goed voor RESTful requests. Er is een beperkt aantal opdrachten, methods, werkwoorden, functies; noem het. De meest gebruikte zijn GET en POST. Die woorden geven ook heel duidelijk het onderscheid aan: met GET verlang je informatie, met POST verlang je verandering.
Kijk, het HTTP-protocol zegt dit: Requests using GET (and a few other HTTP methods) "SHOULD NOT have the significance of taking an action other than retrieval". (http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods)

Koppel dit aan de bewerkingen die je op een object (database-record) wil kunnen uitvoeren:
- nieuwe maken
- nieuwe opslaan
waarom is 'nieuwe maken' en 'nieuwe opslaan' verschillend? Omdat je voor het maken van een nieuw object moet weten welke indeling het systeem verlangt. Zeg maar, een invoerformulier.
- lijst tonen
- object tonen
- object bewerken
- object opslaan
- object wissen

Zeven basishandelingen, uit te drukken met deze werkwoorden:
NEW
CREATE
LIST
RETRIEVE
EDIT
UPDATE
DELETE

Het HTTP-protocol schrijft een aantal methoden voor. Onze browsers doen dat niet helemaal mee, we lossen alles met GET en POST op. Wie kent PUT, DELETE?

Wat is nu de informatie die de server nodig heeft om zo'n werkwoord goed uit te voeren? In ieder geval over welk object het gaat. In veel frameworks geef je dat in de url mee, bijvoorbeeld als eerste 'woord' achter de hostnaam. Voor het voorbeeld gaan we uit van het type 'boek'.

NEW is een vraag aan de server: welke indeling hanteer jij voor het boek? dat wordt dus een GET-request. De client heeft zelf geen object in de hand, dus de url ziet er zo uit:
GET boek/new
CREATE is een verzoek aan de server: sla dit object op. De client heeft een object in de hand. De url wordt
POST boek [+postdata]
Merk op dat deze betekenis van POST de originele betekenis is. Met POST dien je een nieuw element in.
LIST is weer een vraag aan de server: welke objecten zijn er? De client heeft geen specifiek object op het oog. De url wordt
GET boek
Veelal is 'list' of 'index' ook een gebruikte term, als het url-schema een methode verlangt. Maar dat hoeft niet perse; je mag je urls immers zelf mishandelen met htaccess en allerlei programmatechnieken.
RETRIEVE vraagt wel om een specifiek object. De client moet dus een identificatie meegeven. Nu komen onze primaire sleutels in de database, of object-identifiers, goed van pas! Laten we vragen om boek 1:
GET boek/1
Willen we het boek (het structuur-object "rondom" het boek he) ook bewerken, dan is een ander verzoek op zijn plaats. Net als bij NEW willen we immers een bewerkformulier. Vaak is dat hetzelfde formulier, alleen ditmaal ingevuld. Soms ook niet; de definitie van een object kan maken dat je sommige velden alleen kunt invullen bij het aanmaken van een nieuw object. In ieder geval is dit het verzoek:
GET boek/edit/1
of
GET boek/1/edit
De gewijzigde informatie moet weer naar de server. Die moet dus de staat van het object aanpassen. Wat is de url? Die zie je aankomen:
POST boek/1 [+postdata]
... waarom geen 'update' erachter? Dat mag wel hoor, als je graag een werkwoord tegenkomt in de url. Echt nodig is het niet; een POST-verzoek met een specifiek objectnummer zal wel een bijwerkopdracht zijn.
Tenslotte wil je ook wel eens een object verwijderen:
POST boek/1/delete
Discussie over de gehanteerde werkwoorden is natuurlijk altijd mogelijk. Waarom zou je ervan uitgaan dat bij het ontbreken van een werkwoord wel 'update' bedoeld zal zijn, en niet 'delete'? Ik vind: dat is de minst destructieve handeling.
 
Ozzie PHP

Ozzie PHP

12/01/2011 23:31:02
Quote Anchor link
Bas Cost Budde op 12/01/2011 22:17:12:
HTTP leent zich goed voor RESTful requests. Er is een beperkt aantal opdrachten, methods, werkwoorden, functies; noem het. De meest gebruikte zijn GET en POST. Die woorden geven ook heel duidelijk het onderscheid aan: met GET verlang je informatie, met POST verlang je verandering.
Bovenstaande is de kern van de zaak en hier ga ik in ieder geval in de toekomst nog beter op letten! Dankjewel voor je bijdrage Bas.

Tot zover hebben we gesproken over Cross Site Request Forgery en het belang van het juiste gebruik van GET en POST. Wat is er nog meer nodig om een site veilig te maken? Wie komt met het volgende onderwerp?
 
Ocirina Ocirina

Ocirina Ocirina

12/01/2011 23:33:33
Quote Anchor link
Html tags invoeren of iets anders gevaalijks bij een formulier?
 
Ozzie PHP

Ozzie PHP

12/01/2011 23:35:15
Quote Anchor link
Oke, leg maar uit... graag volgens de structuur zoals in de beginpost, dus: titel, korte omschrijving van wat het beveiligingsprobleem inhoudt, een voorbeeld, hoe bescherm je je ertegen (uitleg / links). Alvast bedankt voor je bijdrage.
 
Ocirina Ocirina

Ocirina Ocirina

12/01/2011 23:39:32
Quote Anchor link
Ik ga het een en ander proberen uit te leggen, ik heb nu heel even geen tijd.
Ook ben ik net nieuw met php dus zal het niet super zijn maar ik ga mijn best doen!
 
Ozzie PHP

Ozzie PHP

12/01/2011 23:45:30
Quote Anchor link
Oke, alleen graag je reactie plaatsen als je zeker weet dat het klopt. Mocht er iets toch niet blijken te kloppen dan kun je de informatie altijd achteraf nog aanpassen.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.