2008 Jaar van de SQL-injecties

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

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

25/01/2020 17:27:16
 
Wouter DS

Wouter DS

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.