FBI roept softwareontwikkelaars op einde aan SQL Injection te maken
De FBI heeft softwareontwikkelaars opgeroepen om een einde aan SQL Injection te maken, een klasse van beveiligingslekken die al sinds 1998 bestaat, maar nog altijd voorkomt. "Ondanks wijdverbreide kennis en documentatie van SQL Injection-kwetsbaarheden, alsmede beschikbaarheid van effectieve oplossingen, blijven softwareontwikkelaars producten met deze kwetsbaarheid ontwikkelen, wat veel klanten risico laat lopen", aldus de FBI en het Cybersecurity and Infrastructure Security Agency (CISA) van het Amerikaanse ministerie van Homeland Security (pdf).
Bij SQL Injection kan een aanvaller SQL-opdrachten op een systeem uitvoeren. Zie dit Security.NL achtergrondartikel voor meer details. In 2007 werd SQL Injection nog als een 'onvergeeflijke' kwetsbaarheid bestempeld. Zeventien jaar later is het probleem nog altijd op grote schaal aanwezig. De MITRE Corporation, de organisatie achter het Common Vulnerabilities and Exposures (CVE) systeem om kwetsbaarheden mee te identificeren, stelde vorig jaar nog dat SQL Injection in de Top 3 van meestvoorkomende beveiligingslekken staat.
Vandaag roepen de FBI en het CISA softwareleveranciers en fabrikanten op om hun code op de aanwezigheid van SQL Injection te controleren. Daarnaast moeten alle klanten hun leveranciers vragen of ze een dergelijke controle hebben uitgevoerd. Mocht uit deze controle blijken dat de code kwetsbaar is voor SQL Injection, moeten ontwikkelaars meteen beginnen met het implementeren van oplossingen, aldus de oproep van de Amerikaanse overheidsdiensten. "Het toepassen van security in producten vanaf het begin kan SQL Injection voorkomen."
Volgens de FBI en het CISA is SQL Injection nog steeds succesvol omdat softwareontwikkelaars gebruikersinvoer niet als mogelijk kwaadaardig beschouwen. Als oplossing wordt het gebruik van parameterized queries met prepared statements aangeraden, om zo SQL-code van gebruikersinvoer te scheiden. "Deze scheiding zorgt ervoor dat het systeem gebruikersinvoer als data behandelt en niet als uitvoerbare code, waardoor het risico wordt geëlimineerd dat malafide gebruikersinvoer als SQL-statement wordt gezien."
Daarbij zien de overheidsdiensten een belangrijke rol weggelegd voor bestuurders en topmanagers om kwetsbaarheden zoals SQL Injection te voorkomen. Zo moet er in de organisatie prioriteit worden gegeven aan proactieve maatregelen, zoals het toepassen van veilig programmeren, waaronder het gebruik van parametrized queries, en het afhankelijk zijn van reactieve maatregelen te verminderen. Daarnaast moet topmanagement ervoor zorgen dat hun organisatie audits uitvoert om kwetsbaarheden zoals SQL Injection te detecteren.
Binnen google Cloud, AWS en Azure heb je de keuze een WAF erbij 'te klikken'.
Al die snelle swontwikkelaars, waarom maken ze hun product niet gewoon goed?
Nee, men crosst liever in de de snelle leasebolide naar de volgende cursus voor een nieuwe CXXX lettercombinatie
achter de naam te plakken. Of wil sw architect worden en zo. Of wil hacker worden. Veel sexier dan patcher.
Software is niet meer zo innovatief als vroeger. Het is een rem op de vooruitgang.
Het boeit niemand, anders was er al lang een oplossing voor.
Ik schrijf dit niet om lullig te doen over hoe je schrijft, maar het illustreert heel aardig hoe makkelijk zoiets gaat. Software "gewoon goed" maken vergt dat je dit nooit doet, of het altijd weet te herstellen. Sta daar eens bij stil. Houd jij dat vol als er management in je nek staat te hijgen omdat ze het te langzaam vinden gaan en te duur vinden worden? Dat soort tijdsdruk is een regelrechte vijand van de zorgvuldigheid die je nodig hebt om kwaliteit te kunnen leveren.
Reken maar dat SQL injections dan ineens verleden tijd zijn.
Reken maar dat SQL injections dan ineens verleden tijd zijn.
Joepie - de eerste programmeur die met z'n huis en jaarinkomen garant staat voor een bugje hebben we hier in de comments !
En knul, wijs eens naar je github portfolio van leuke software , gpl, bsd ?
En nu sta jij keihard garant dat een bug die men 'grote nalatigheid' vindt erg genoeg is om je helemaal uit te kleden ?
Effectiever is om de bestuurders van de organisaties die er gebruik van maken hoofdelijk voor aansprakelijk te stellen.
....
Fouten maken hoort bij het leven. Tijd / budget / mankracht om alles foutloos te doen is er niet. Niet bij de politie, niet bij de overheid, niet in een ziekenhuis, en ook niet bij software ontwikkelaars.
Ik schrijf dit niet om lullig te doen over hoe je schrijft, maar het illustreert heel aardig hoe makkelijk zoiets gaat. Software "gewoon goed" maken vergt dat je dit nooit doet, of het altijd weet te herstellen. Sta daar eens bij stil. Houd jij dat vol als er management in je nek staat te hijgen omdat ze het te langzaam vinden gaan en te duur vinden worden? Dat soort tijdsdruk is een regelrechte vijand van de zorgvuldigheid die je nodig hebt om kwaliteit te kunnen leveren.
Spot on opmerking!
Effectiever is om de bestuurders van de organisaties die er gebruik van maken hoofdelijk voor aansprakelijk te stellen.
Effectiever is om de bestuurders van de organisaties die de software leveren er hoofdelijk voor aansprakelijk te stellen.
FTFY.
Wat is je punt? M'n hand kan niet tegen vuur, dus nee, die ga ik niet letterlijk in 't vuur steken, ookal weet ik 100% zeker dat SQL injections in onze code niet mogelijk zijn. Je hand letterlijk in 't vuur steken is iets wat alleen idioten doen; die vraag van de directeur was dus ook gewoon belachelijk.
Wat is je punt? M'n hand kan niet tegen vuur, dus nee, die ga ik niet letterlijk in 't vuur steken, ookal weet ik 100% zeker dat SQL injections in onze code niet mogelijk zijn. Je hand letterlijk in 't vuur steken is iets wat alleen idioten doen; die vraag van de directeur was dus ook gewoon belachelijk.
Precies dat. Overigens hoef je je geen zorgen te maken als je 100% zeker bent, dan zal het vuur je hand namelijk niet deren... :-)
Effectiever is om de bestuurders van de organisaties die er gebruik van maken hoofdelijk voor aansprakelijk te stellen.
Effectiever is om de bestuurders van de organisaties die de software leveren er hoofdelijk voor aansprakelijk te stellen.
FTFY.
werknemer = werknemer.
Effectiever om de developers met hun jaarinkomen garant te laten staan dat ze geen bugs maken.
Wat is je punt? M'n hand kan niet tegen vuur, dus nee, die ga ik niet letterlijk in 't vuur steken, ookal weet ik 100% zeker dat SQL injections in onze code niet mogelijk zijn. Je hand letterlijk in 't vuur steken is iets wat alleen idioten doen; die vraag van de directeur was dus ook gewoon belachelijk.
En als ie gevraagd had om je jaarsalaris erop in te zetten ?
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Information Security Officer (Operationele Techniek)
bij HHNK
Heb jij een passie voor informatiebeveiliging en wil je jouw expertise inzetten in een organisatie met impact? Solliciteer nu! Bij HHNK hechten we veel waarde aan de veiligheid van onze informatie en systemen. Met een breed scala aan operationele techniek (OT) voor onze taken, is het essentieel om deze veilig te houden.
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.