Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Website beveiliging
Bij deze mijn eerste input ....
Ik heb gemerkt dat er op security.nl eerder info te vinden is over hoe je andermans website kunt hacken, dan dat er info is over hoe je je eigen websites kunt beveiligen. Daar wil ik iets mee doen.
Allereerst wil ik opmerken dat je niet eerst hoeft te leren een inbreker te zijn om de deur van je eigen huis op slot te doen. Ook het 'kennen van je vijand' is niet nodig. Jezelf zijn, gezond verstand en de ervaring van anderen zou afdoende moeten zijn.
Je krijgt per slot van rekening ook niet iedere dag de meest geavanceerde inbraak ter wereld bij je thuis, maar eerder de kleine crimineeltjes met een schroevedraaier. Tenzij je natuurlijk de bezitter bent van een mega-fortuin. Maar daar gaat het hier niet over.
In mijn eigen logs kan ik zien dat het aantal aanvallen sterk is op toegenomen. Op sommige sites zelf tot 5 per dag tegen 0 per dag. Suffe XSS- en PHP-inclusion-aanvallen van tutorial-kiddies. Niet schadelijk, maar wel vervelend.
Een paar jaar geleden is het zo'n debiel zelfs gelukt om een aantal van mijn [onbelangrijke en weinig bezochte] sites te de-facen met een fijne politieke boodschap. Funhacken. Pfffff.
Toen ik daarna ging studeren op beveiliging, dacht ik, kwam ik voornamelijk informatie tegen die mij moesten leren hoe te hacken. Kennelijk had nog nooit iemand de moeite genomen om tegenmaatregelen te nemen.
Ook nu blijkbaar nog niet. Want het is lastig om bijvoorbeeld hier op security.nl te achterhalen dat er tools bestaan als:
XSS me / SQL inject me: firefox add-on om kwetsbaarheden aan het licht te brengen in je website
http://labs.securitycompass.com/index.php/exploit-me/
Acunetix scanner: software die je website scanned op kwetsbaarheden
http://www.acunetix.com/cross-site-scripting/scanner.htm
.....
Een verademing voor webontwikkelaars van kleine sites en cms'en. Toch? Net als onderstaande documenten:
- http://www.securityfocus.com/infocus/1768 (oud, maar toch ...)
- http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
- http://www.phpfreakz.nl/downloadz/webprogrammers_hacking_huide.pdf (ook oud, maar dat is het idee van een fiets ook ...)
- en ik had het webprogrammers_security_huide.pdf genoemd .... (huide???)
.....
Voor een kleine beveiliger is het met bovenstaande informatie al goed mogelijk om filters en checks te progrmmeren in het project.
Nou is het me wel opgevallen dat veel web-programmeurs meer weten dan ze denken, maar vaak geen zin hebben om de extra functionaliteit van de beveiling te implementeren. Dan is het natuurlijk 'Eigen schuld, dikke bult!'
RiesArt
Ik heb gemerkt dat er op security.nl eerder info te vinden is over hoe je andermans website kunt hacken, dan dat er info is over hoe je je eigen websites kunt beveiligen. Daar wil ik iets mee doen.
Allereerst wil ik opmerken dat je niet eerst hoeft te leren een inbreker te zijn om de deur van je eigen huis op slot te doen. Ook het 'kennen van je vijand' is niet nodig. Jezelf zijn, gezond verstand en de ervaring van anderen zou afdoende moeten zijn.
Je krijgt per slot van rekening ook niet iedere dag de meest geavanceerde inbraak ter wereld bij je thuis, maar eerder de kleine crimineeltjes met een schroevedraaier. Tenzij je natuurlijk de bezitter bent van een mega-fortuin. Maar daar gaat het hier niet over.
In mijn eigen logs kan ik zien dat het aantal aanvallen sterk is op toegenomen. Op sommige sites zelf tot 5 per dag tegen 0 per dag. Suffe XSS- en PHP-inclusion-aanvallen van tutorial-kiddies. Niet schadelijk, maar wel vervelend.
Een paar jaar geleden is het zo'n debiel zelfs gelukt om een aantal van mijn [onbelangrijke en weinig bezochte] sites te de-facen met een fijne politieke boodschap. Funhacken. Pfffff.
Toen ik daarna ging studeren op beveiliging, dacht ik, kwam ik voornamelijk informatie tegen die mij moesten leren hoe te hacken. Kennelijk had nog nooit iemand de moeite genomen om tegenmaatregelen te nemen.
Ook nu blijkbaar nog niet. Want het is lastig om bijvoorbeeld hier op security.nl te achterhalen dat er tools bestaan als:
XSS me / SQL inject me: firefox add-on om kwetsbaarheden aan het licht te brengen in je website
http://labs.securitycompass.com/index.php/exploit-me/
Acunetix scanner: software die je website scanned op kwetsbaarheden
http://www.acunetix.com/cross-site-scripting/scanner.htm
.....
Een verademing voor webontwikkelaars van kleine sites en cms'en. Toch? Net als onderstaande documenten:
- http://www.securityfocus.com/infocus/1768 (oud, maar toch ...)
- http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
- http://www.phpfreakz.nl/downloadz/webprogrammers_hacking_huide.pdf (ook oud, maar dat is het idee van een fiets ook ...)
- en ik had het webprogrammers_security_huide.pdf genoemd .... (huide???)
.....
Voor een kleine beveiliger is het met bovenstaande informatie al goed mogelijk om filters en checks te progrmmeren in het project.
Nou is het me wel opgevallen dat veel web-programmeurs meer weten dan ze denken, maar vaak geen zin hebben om de extra functionaliteit van de beveiling te implementeren. Dan is het natuurlijk 'Eigen schuld, dikke bult!'
RiesArt
Reacties (6)
05-06-2009, 19:11 door
riesart
sorry, ik reageerde op mezelf ... :-;
Beveiliging is een manier van denken.
Als je eenmaal snapt dat je user-input altijd moet wantrouwen, dan ben je al een heel eind. Met die wetenschap kun je oude code doorspitten en waar nodig verbeteren. Daar leer je al iets van. Vervolgens ga je die kennis bij nieuwe projecten toepassen. Voor je het weet kijk je altijd kritisch naar user-input en programmeer je al voor 80% veilig.
De laatste 20% bereik je door het geheel te overzien, van de context van het geheel tot en met de details. Als je controle hebt over je programma en niet zomaar wat code hebt gekopieerd, leer je welke aannames je wel en niet kunt maken. Aannames over (shared) libs, aannames over (al dan niet versleutelde) verbindingen tussen systemen, aannames over de validiteit van RSS-feeds. Je leert hoe je moet controleren of informatie legitiem is en wat je er vervolgens mee moet doen.
In de artikelen die jij aanraadt worden alleen de details beschreven. Reguliere expresies om SQL Injection te voorkomen, huh? We leven in 2009, een tijd waarin elk DBMS een escape-functie heeft of geparameteriseede SQL-queries faciliteert. Waar je vroeger pleisters moest plakken, zorg je tegenwoordig dat je je niet meer snijdt.
Zelfs als je beveiligings-guru bent kun je fouten maken. Nou ja, Daniel Bernstein niet, maar dat is een uitzondering. Een ongeluk zit in een klein hoekje, en applicaties zijn niet meer zo eenvoudig als vroeger. Zorg er daarom voor dat je defensief programmeert (deny unless permited) en dat een gat in je front-end of database niet gelijk je OS of SAN compromitteert. Schijf bewust veilig code maar doe ook aan damage control.
…en voor er vragen komen, ja, ik ben OS3'er. Shoot me :)
Als je eenmaal snapt dat je user-input altijd moet wantrouwen, dan ben je al een heel eind. Met die wetenschap kun je oude code doorspitten en waar nodig verbeteren. Daar leer je al iets van. Vervolgens ga je die kennis bij nieuwe projecten toepassen. Voor je het weet kijk je altijd kritisch naar user-input en programmeer je al voor 80% veilig.
De laatste 20% bereik je door het geheel te overzien, van de context van het geheel tot en met de details. Als je controle hebt over je programma en niet zomaar wat code hebt gekopieerd, leer je welke aannames je wel en niet kunt maken. Aannames over (shared) libs, aannames over (al dan niet versleutelde) verbindingen tussen systemen, aannames over de validiteit van RSS-feeds. Je leert hoe je moet controleren of informatie legitiem is en wat je er vervolgens mee moet doen.
In de artikelen die jij aanraadt worden alleen de details beschreven. Reguliere expresies om SQL Injection te voorkomen, huh? We leven in 2009, een tijd waarin elk DBMS een escape-functie heeft of geparameteriseede SQL-queries faciliteert. Waar je vroeger pleisters moest plakken, zorg je tegenwoordig dat je je niet meer snijdt.
Zelfs als je beveiligings-guru bent kun je fouten maken. Nou ja, Daniel Bernstein niet, maar dat is een uitzondering. Een ongeluk zit in een klein hoekje, en applicaties zijn niet meer zo eenvoudig als vroeger. Zorg er daarom voor dat je defensief programmeert (deny unless permited) en dat een gat in je front-end of database niet gelijk je OS of SAN compromitteert. Schijf bewust veilig code maar doe ook aan damage control.
…en voor er vragen komen, ja, ik ben OS3'er. Shoot me :)
06-06-2009, 09:10 door
riesart
We leven idd in 2009 met ecape-functies. Maarrrr waar is de info voor de beveiligers te vinden dan? Dat is mijn punt.
shoot!
shoot!
De Webmaster Hacking guide van PHPFreakz is misschien verouderd maar is wel een goed begin om de meest gebruikte hacks op te lossen. Toen ik deze voor het eerst las wist ik al het één ander over beveiliging maar onderdelen als UBB XSS was compleet nieuw voor me!
Verschillende leden zijn al bezig om de Webmaster Hacking guide min of meer te porteren naar de Wiki.
http://wiki.phpfreakz.nl/Categorie:Beveiliging
Zelf wil ik ook nog enkele Wiki's toevoegen in deze categorie maar door tijdgebrek kom ik daar helaas niet aan toe.
Zo zijn onderdelen als rollen beperking en wegsite onderdelen onder aparte systeem gebruikers te draaien twee dingen waar ik het één en ander of kwijt wil.
- Sebastiaan Stok
Verschillende leden zijn al bezig om de Webmaster Hacking guide min of meer te porteren naar de Wiki.
http://wiki.phpfreakz.nl/Categorie:Beveiliging
Zelf wil ik ook nog enkele Wiki's toevoegen in deze categorie maar door tijdgebrek kom ik daar helaas niet aan toe.
Zo zijn onderdelen als rollen beperking en wegsite onderdelen onder aparte systeem gebruikers te draaien twee dingen waar ik het één en ander of kwijt wil.
- Sebastiaan Stok
Je kunt focussen op allerlei losse aanvallen en technieken, maar dan loop je altijd twee stappen achter. Want er komen elke maand weer nieuwe aanvallen, nieuwe systemen, nieuwe programmeertalen en nieuwe interfaces.
Waar het om gaat zijn de concepten. HTML injection, SQL injection en XSS zijn precies hetzelfde: er wordt ingebroken op de syntaxis van de omgeving (HTML-tags worden toegevoegd, SQL-statements worden verbogen, JavaScript wordt toegevoegd). Ook het voorkomen van de aanvallen doe je op precies dezelfde manier: door te voorkomen dat invoer van derden ik kan breken op de syntaxis van je geconstrueerde code. Dit kun je doen door bepaalde karakters te vervangen (< door < in HTML, ' door \' in SQL) of door built-in functies te gebruiken die dat voor jou doen (htmlspecialchars() en mysql_real_escape_string() in php).
Die kennis kun je doortrekken naar het inlezen van RSS-feeds. Je kunt een RSS-feed inlezen en deze één op één kopiëren als uitvoer naar je home-made feed reader. Dat is niet veilig, want je loopt risico op HTML-injection. Als je de RSS-feed inleest in DOM, de informatie analyseert en controleert, en pas indien alles goed is de inhoud van de RSS-feed (zonodig escaped) kopieert naar je feed reader ben je veilig.
Waar het om gaat zijn de concepten. HTML injection, SQL injection en XSS zijn precies hetzelfde: er wordt ingebroken op de syntaxis van de omgeving (HTML-tags worden toegevoegd, SQL-statements worden verbogen, JavaScript wordt toegevoegd). Ook het voorkomen van de aanvallen doe je op precies dezelfde manier: door te voorkomen dat invoer van derden ik kan breken op de syntaxis van je geconstrueerde code. Dit kun je doen door bepaalde karakters te vervangen (< door < in HTML, ' door \' in SQL) of door built-in functies te gebruiken die dat voor jou doen (htmlspecialchars() en mysql_real_escape_string() in php).
Die kennis kun je doortrekken naar het inlezen van RSS-feeds. Je kunt een RSS-feed inlezen en deze één op één kopiëren als uitvoer naar je home-made feed reader. Dat is niet veilig, want je loopt risico op HTML-injection. Als je de RSS-feed inleest in DOM, de informatie analyseert en controleert, en pas indien alles goed is de inhoud van de RSS-feed (zonodig escaped) kopieert naar je feed reader ben je veilig.
"Verschillende leden zijn al bezig om de Webmaster Hacking guide min of meer te porteren naar de Wiki.
http://wiki.phpfreakz.nl/Categorie:Beveiliging"
Ik vroeg me al af hoe het kwam dat onderdelen van mijn artikel op de Wiki van phpfreakz terecht zijn gekomen. Het bovenstaande verklaart het :) Trouwens, leuk om je hier ook op security.nl te zien Sebastiaan.
In de nabije toekomst ben ik van plan om meer over web beveiliging te schrijven, dus stay tuned!
Groet, Sijmen
http://wiki.phpfreakz.nl/Categorie:Beveiliging"
Ik vroeg me al af hoe het kwam dat onderdelen van mijn artikel op de Wiki van phpfreakz terecht zijn gekomen. Het bovenstaande verklaart het :) Trouwens, leuk om je hier ook op security.nl te zien Sebastiaan.
In de nabije toekomst ben ik van plan om meer over web beveiliging te schrijven, dus stay tuned!
Groet, Sijmen
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
