Gepubliceerd: Dinsdag 3 februari 2009
Het jaar 2008 is bovenal het jaar van de SQL-injecties in websites. Dit concludeert IBM in een beveiligingsonderzoek.
Toon volledig artikel
En bijna 100% van alle kwetsbare webapplicaties waren in PHP geschreven, door mensen die denken dat ze programmeur zijn.
@Lennart: Helemaal mee eens. Toch is het niet helemaal de fout van de PHP 'programeurs' (maar wel 90% fout van deze) PHP zou vanuit het begin een goede prepared statement interface gemaakt moeten hebben en dit zo moeten promoten.
Grt,
Ries
Veel van deze webapplicaties bieden wel degelijk geparametriseerde query functies aan, zo niet via PDO, dan wel via een eigen API. Men moet deze API dan wel gebruiken en dat gebeurt schijnbaar niet in alle gevallen. Als PHP zelf een goede (native) prepared statement interface gehad zou hebben, dan is het dus maar de vraag of dat geholpen had.
Edit: uit het rapport kan ik geen relatie vinden tussen SQL injecties en de webapplicaties in de Top 10. Dan zou ik eerder voor het jaar van de XSS / CSRF kiezen.
lijkt me niet helemaal juist. Ik ben helaas diverse ASP sites tegengekomen die met name aan de inputvalidatie niets deden en daarmee de deur openzetten. Dus naast PHP is ook verkeerd ASP gebruik verantwoordelijk hiervoor. Met name het onderling uitwisselen van scripts ( beter goed gejat dan slecht bedacht) is daar debet aan. Ze kopieren vaak veel meer dan ze nodig hebben voor een bepaalde taak. Amateuristisch maar vooral gevaarlijk.
Inderdaad. Daarnaast is het niet de taak van de programmeertaal om dit af te dwingen. Elke database-module in PHP die me zo snel te binnen schiet heeft de mogelijkheid om dingen te escapen. Ja, je moet wel zelf de functie aanroepen, maar een taal die je dwingt om op een bepaalde manier te werken is ook niet goed.
Voorbeeld: rvantwisk heeft het over parameterized queries, maar ik vind dat zelf ondingen en werk liever met arrays met key/value pairs (vind ik veeeeel flexibeler bij ingewikkelde queries). Ik moet er niet aan denken dat ik gedwongen zou zijn PQ's te gebruiken - dat was ik denk ik nooit aan PHP begonnen :)
Dat minstens 9 op de 10 websites door volstrekte prutsers worden gemaakt, daar kunnen we het dan wel weer over eens zijn :)
Daarnaast is het niet de taak van de programmeertaal om dit af te dwingen.
Klopt maar programeeromgevingen zouden wel eerder moeten kiezen om invoer functionaliteiten default zeer restrictief te maken zodat leestekens die veel in script of sql gebruikt worden niet gebruikt kunnen worden
En dan als je invoerfuncties wil waarin wel leestekens moeten voorkomen die veel in script of sql gebruikt worden dat je dan speciale unrestricted invoerfuncties zou moeten gebruiken.
En dan als je invoerfuncties wil waarin wel leestekens moeten voorkomen die veel in script of sql gebruikt worden dat je dan speciale unrestricted invoerfuncties zou moeten gebruiken.
Dit is een veel voorkomende misvatting. Het maltraiteren van je gebruikersdata is echt niet de oplossing. Personen met de achternaam O'Donnel willen deze graag kunnen gebruiken, nederlanders moeten over drop kunnen schrijven en engelstaligen kunnen natuurlijk niet zonder Table of Update.
De oplossing is het context-afhankelijk escapen van data. Dus als je tekst als HTML uitvoer geeft (of mixt met HTML), dan moet je waar nodig karakters naar entities converteren. Op het moment dat je deze data in een SQL query gebruikt moet je een escaping gebruiken die voor SQL geldt (prepared statements / query parameters automatiseren zulks).
Voor een inleiding verwijs ik geïnteresseerden naar Wittens excellente "Safe String Theory for the Web" en naar Drupals "Input, the root of all evil"
Het probleem met o.a. SQL-injectie is aan de ene kant gebrek aan kennis/zin van de programmeurs om dit te voorkomen.
Verder als de lekken eenmaal in de site zitten, dan zijn de klanten totaal ongeinteresseerd in dat ze een risico lopen.
Ik heb vorig jaar een broefballontje opgelaten om dit bij klanten op de lossen. Resultaat 0. Het moet eerst misgaan.
Deze berichtgeving is dus alleen interessant voor geinteresseerde technici.
Om te kunnen reageren, dient u ingelogd te zijn.
1 jaar geleden: 11 februari 2011
2 jaar geleden: 11 februari 2010
3 jaar geleden: 11 februari 2009
4 jaar geleden: 11 februari 2008
14 jaar geleden: 11 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
