2008 Jaar van de SQL-injecties

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Java Developer / Overheid / Complexiteit

Functieomschrijving Wil jij als Java Developer een bijdrage leveren aan een veiliger Nederland en je als Java Developer bezig houden met zeer complexe bedrijfskritische applicaties? Lees dan snel verder! Doorontwikkelen bedrijfskritische applicaties; Aanpassingen maken in de bestaande applicatie; Vertalen van jouw visie op continuous integration en continuous delivery; Debuggen van de applicatie; In gesprek gaan met eindgebruikers om verbetervoorstellen op te halen. Functie-eisen Minimaal HBO-werk en denkniveau; Minimaal 5 jaar werkervaring als Java Developer; Je bent minimaal OCP-Java SE 6 gercertificeerd; Je hebt kennis van Webservices en Continuous Integration; Je bent analytisch sterk en zowel klant- als resultaatgericht. Bedrijfsomschrijving Binnen

Bekijk vacature »

Senior DevOps-ontwikkelaar eIDAS

Functie­omschrijving Burgers en bedrijven veilig en betrouwbaar digitaal toegang geven tot diensten en producten van het ministerie van Economische Zaken en Klimaat. Als senior DevOps-ontwikkelaar bouw je daar letterlijk aan mee. En dat doe je bij DICTU: een van de grootste en meest vooruitstrevende ICT-dienstverleners van de Rijksoverheid. Jij werkt mee aan de doorontwikkeling van eIDAS, dat staat voor Electronic IDentification Authentication and trust Services. Deze koppeling maakt de grensoverschrijdende authenticatie op overheidswebsites binnen de Europese Unie mogelijk. Het ministerie van Economische Zaken en Klimaat heeft één moderne toegangspoort voor zijn diensten en inspecties. Enkele daarvan zijn dankzij eIDAS inmiddels

Bekijk vacature »

Front-end Developer Vue.js Meewerkend voorman

Functieomschrijving Ben jij een ervaren Front-end Developer, bedreven in Vue.js en lijkt het jou gaaf om als meewerkend voorman verantwoordelijk te zijn voor de ontwikkeling van drie junior ontwikkelaars? Werk jij graag aan diverse projecten t.b.v. het vergroten van klant- en medewerkerbeleving? Lee dan snel verder! Het onderhouden, ontwikkelen en testen van front-end software van diverse klant- en medewerkersapplicaties; Het ontwikkelen van maatwerk front-end oplossingen in Vue.js en participeren in een scrumteam; Verantwoordelijk voor het begeleiden en coachen van drie junior front-end developers; Verantwoordelijk voor code-reviews en het opstellen van de juiste documentatie zoals userstories en api ontwerp; Participeren in

Bekijk vacature »

PHP Newbie

PHP Newbie

14/02/2009 14:15:00
Quote Anchor link
Het jaar 2008 is bovenal het jaar van de SQL-injecties in websites. Dit concludeert IBM in een beveiligingsonderzoek.

De SQL-injecties stegen met 134 procent ten opzichte van vorig jaar en de kwetsbaarheid drong daarmee cross-site scripting (XSS) aanvallen terug naar de tweede plek. "SQL-injecties zijn groot geworden in 2008", zegt onderzoeker Tom Cross van ISS, de beveiligingstak van IBM, tegen Networkworld. Meer dan vijftig procent van de kwetsbaarheden die werden opgemerkt hadden betrekking op webapplicaties.
De aanvallen op websites die kwetsbaar zijn voor SQL-injecties stegen van een paar duizend begin 2008 tot enkele honderdduizenden aan het eind van het jaar. Er werden zelfs wereldwijde aanvallen geregistreerd die bij sommige bedrijven hele systemen ontregelden. Vooral bedrijven die verzuimden hun software te patchen kwamen in grote problemen, concludeert IBM. Ook het ontbreken of niet up-to-date houden van bijvoorbeeld firewall-verdediging maakt de bedrijven kwetsbaar.
Bron: webwereld.nl

Zie ook het volledige rapport (PDF, 353,5 MB)
Gewijzigd op 01/01/1970 01:00:00 door PHP Newbie
 
PHP hulp

PHP hulp

05/08/2020 09:16:48
 
Wouter De Schuyter

Wouter De Schuyter

14/02/2009 14:34:00
Quote Anchor link
Ik neem aan dat je 3.5MB bedoelt?
 
Frank -

Frank -

14/02/2009 15:40:00
Quote Anchor link
Tja, programmeurs en databases... Zodra je iets roept over beveiliging wordt je afgescheept met het verhaal dat ze dat "later" zullen inbouwen. En zoals iedereen weet, staat "later" gelijk aan "nooit". En waarom niet? Omdat ze niet weten hoe het moet.

Gelukkig gaat dit niet voor iedereen op, maar blijkbaar wel veel te veel.
 
GaMer B

GaMer B

14/02/2009 15:58:00
Quote Anchor link
Tsja, het hele verhaal wordt door dit nieuwsbericht bevestigd: Na Kaspersky ook F-Secure last van SQL-injectie.
 
Frank -

Frank -

14/02/2009 16:00:00
Quote Anchor link
Zo jammer, SQL injection is heel simpel te voorkomen, zowel aan de applicatiekant als aan de databasekant. De applicatie moet het tegengaan, denk aan mysql_real_escape_string() of pg_query_params(), maar de database kan SQL injection technisch onmogelijk maken. Alleen heb je dan wel iemand met kennis van zaken nodig en geen prutsertje die nauwelijk "PHP" voutlooz weet te spellen...
 
Anne

Anne

14/02/2009 16:02:00
Quote Anchor link
door een mysql_real_escape_string is dit toch gemakkelijk te voorkomen? Of moet je nog meer doen?
 
Onbekend Onbekend

Onbekend Onbekend

14/02/2009 16:02:00
Quote Anchor link
Lol @ Frank!

Maar hoe kun je het aan de databasekant voorkomen? Want dat wil ik wel eens weten. Natuurlijk weet ik hoe het moet in PHP, maar lijkt me interessant om te weten.
 
GaMer B

GaMer B

14/02/2009 16:02:00
Quote Anchor link
Ja, het kwam voor mij ook als een totale verrassing, aangezien SQL injectie preventie er echt ingeramt wordt bij het opleiden van een (PHP) programmeur.
 
Pieter van Linschoten

Pieter van Linschoten

14/02/2009 18:11:00
Quote Anchor link
Misschien heeft het ook enigszins te maken met het feit dat van al die mensen die het erin geramt krijgen, een gedeelte denkt: "Dat kan ik ook proberen."
 
Frank -

Frank -

15/02/2009 12:40:00
Quote Anchor link
Tommy schreef op 14.02.2009 16:02:
Lol @ Frank!

Maar hoe kun je het aan de databasekant voorkomen?
Door alle overbodige en ongewenste rechten in te trekken.

Of eigenlijk, alleen die rechten toe te kennen die een gebruiker nodig heeft. Vervolgens laat je alle data ophalen en verwerken via views en stored procedures en klaar is klara. Het is dan technisch onmogelijk om data op te halen die je niet mag ophalen of data in te voeren/bij te werken/te verwijderen die je niet mag ophalen/wijzigen/verwijderen.

Met deze opzet moet je wel per (groep) gebruiker (-s) een database gebruiker aanmaken, maar dat is standaard functionaliteit van een database.

Wanneer je dit soort maatregelen niet neemt, neem je bewust het risico op SQL injection. Die risico's kun je verkleinen door een veilige applicatie te bouwen, maar dat gaat blijkbaar nogal eens fout. Ook vrij logisch, programmeurs lopen geen enkel risico waardoor veiligheid bij vele van hen geen enkele prioriteit heeft.

Tip: Ga beter testen en ga je applicatie/database hacken.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
 



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.