BEVEILIG je site! Dit moet je doen.
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.
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.
Edit: termen gebruiken, dan de goede termen :)
Gewijzigd op 12/01/2011 21:24:13 door Bas Cost Budde
(Ik hoop dat er mensen zijn die deze topic gaan aanvullen met andere beveiligingsproblemen op de manier zoals omschreven in de beginpost.)
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.
Bas Cost Budde op 12/01/2011 22:17:12:
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.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.
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?
Ook ben ik net nieuw met php dus zal het niet super zijn maar ik ga mijn best doen!