Sites van Belgische banken ING en Dexia gehackt

Een Roemeense hacker is erin geslaagd sites van de Belgische banken Dexia en ING binnen te dringen door middel van een sql-injectie. Ook sites van de bank HSBC France en de Italiaanse nationale postdienst bleken vatbaar voor sql-injecties.

Een Roemeense hacker die zichzelf 'Unu' noemt, heeft inmiddels al heel wat sites kunnen binnendringen met sql-injecties. Onder andere sites van het Britse parlement, Orange en Yahoo bleken kwetsbaar. Unu heeft nu Dexia, ING, HSBC France en Poste Italiana aan dit rijtje toegevoegd. Van de hacks is die van HSBC France het omvangrijkst: Unu claimt dat hij volledige toegang kreeg tot de Microsoft SQL-server van de bank en dat de wachtwoorden van de beheerders in platte tekst te vinden waren. Bovendien werd op mails naar de beheerder, naar abuse en naar security gereageerd met standaardmails die meldden dat de betreffende personen op vakantie waren.

De hack van ING Belgie betreft de site van de Gift Shop. De url toont aan dat hiermee toegang is verkregen tot de ING-server, zij het beperkt. Volgens Unu moet verdere toegang niet moeilijk zijn en ook hier waren de wachtwoorden van de beheerder onversleuteld opgeslagen. Ook kon hij klantgegevens inzien, inclusief wachtwoorden. "Dit betekent dat er een gebrek aan veiligheid was", erkent Ilse De Muyer, woordvoerster van ING tegenover VTM Nieuws, die overigens beweert dat er geen link is met bankgegevens van klanten.

Niet alleen kreeg de Roemeen toegang tot de Dexia-database, ook kwam hij erachter dat load_file execution mogelijk was, waarmee hij nagenoeg volledig beheer kon verkrijgen over de Ubuntu-server van Dexia na het injecteren van kwaadaardige code in een beschrijfbare map. Volgens Dexia ging de oorspronkelijke hack om een site met koersinformatie die werd beheerd door een externe partij en zou deze site geen link hebben met de bankgegevens van klanten. De laatste hack die Unu op zijn site meldt, is die van de site van Poste Italiane, waarbij hij toegang verkreeg tot de Oracle-backend. De hacker zou geen gegevens buitgemaakt of gepubliceerd hebben en de banken enkel op de beveiligingsproblemen hebben willen wijzen.

Reacties (105)

[Janoz]

Goed, ik zal wel weer een berg commentaar over mijzelf afroepen, maar waarom wordt er in dergelijke omgevingen überhaupt gebruik gemaakt van php? Die taal heeft niet eens pas recent geparameteriseerde query ondersteuning out of the box.

@roeleboel & zwippie: Kijk maar naar de screenshots van de hack

[Reactie gewijzigd door Janoz op 26 juli 2024 17:05]

[Anoniem: 95122]

Jawel, dat heeft die wel:
http://nl2.php.net/pg_prepare
http://nl3.php.net/manual/en/mysqli.prepare.php
http://nl.php.net/manual/en/pdo.prepared-statements.php
http://wiki.phpfreakz.nl/PreparedStatements

Meer dan genoeg ondersteuning voor prepared (en dus geparametiseerde) query's out of the box.

[johnbetonschaar]

En voor de database drivers die geen prepared statements ondersteunen kan je stored procedures gebruiken via mssql_init, mssql_bind, mssql_execute (voor MS SQL) etc.

[cariolive23]

Een stored procedure zal je daarbij niet helpen, je moet nog steeds een query vanuit je applicatie naar de database sturen. En wanneer deze query is geinjecteerd met een stuk extra SQL, ben je nog steeds het bokje.

Daarnaast zijn er nog mogelijken om fouten in SP's te maken, hierdoor kun je zelfs in de SP nog weer een SQL injection krijgen. Het opbouwen en uitvoeren van dynamische queries binnen een SP zijn een bron van ellende.

In PostgreSQL moet je quote_literal() en quote_ident() gebruiken om veilig dynamische queries in je SP's op te bouwen. Andere databases zullen soortgelijke mogelijkheden hebben, anders is het gebruik van dynamische queries niet veilig. En dus niet bruikbaar.

Uiteraard zorg je ook voor goed beheer van databaserollen. Wanneer een rol iets niet mag, kan deze rol nog zoveel SQL injecteren, deze SQL wordt dan keurig geweigerd.

[johnbetonschaar]

Ik denk dat je met iets anders in de war bent, een stored procedure maak je 1x aan op de server en dan roep je hem aan met de parameters die je ervoor gedefinieerd hebt. De tekst van de query gaat zelfs niet eens over het lijntje, alleen de naam van de procedure en de parameter waardes (en het resultaat natuurlijk).

[cariolive23]

Ik weet uitstekend hoe stored procedures werken in PostgreSQL, SQL Server en MySQL en ik weet ook dat dit niet dé oplossing is tegen SQL injection. Zeker niet omdat de call naar de procedure nog steeds gevoelig is voor injection. Je moet tenslotte een stuk SQL van de applicatie naar de server sturen. En wanneer dat een stuk SQL is met een klein beetje extra, ben je gewoon weer terug bij af.

Daarnaast kan een sp ook dynamische queries uitvoeren, welke extra aandacht vereisen om SQL injection in je sp te voorkomen.

Ps. stored procedures en stored functions gooi ik voor het gemak even op één hoop.

[lzandman]

Zeker niet omdat de call naar de procedure nog steeds gevoelig is voor injection.

Je moet die call dan ook niet doen via SQL. Je gebruikt hier vaak speciale functies voor. In ADO.Net gebruik je bijv. de SqlCommand class. Daarin specificeer je de stored procedure naam en je voegt de parameterwaarden toe. Vervolgens is die class verantwoordelijk voor de daadwerkelijke aanroep. Hier is dus geen SQL-injection mogelijk.

[cariolive23]

En hoe zet die class dan de parameters in de stored procedure? Dat zal waarschijnlijk gebeuren met een prepared statements, dat is veilig.

En nogmaals, sql injection is ook mogelijk binnen de stored procedure, maak je hier vooral geen illusies over! PostgreSQL, en andere databases, kennen niet voor niets functies om content veilig te verwerken.

SQL Server: QUOTENAME, REPLACE
PostgreSQL: QUOTE_IDENT, QUOTE_LITERAL

Ps. Ik heb geen ervaring met .NET, alleen Java (Hibernate) en PHP.

[Janoz]

Aangepast. Ik had voor het posten nog even gezocht en vond alleen wat dingen van het Zend Framework (maar dan moet ik bekennen dat ik niet heel uitgebreid gezocht heb, aan de andere kant geeft dat ook wel weer aan hoeveel de geparameteriseerde aanpak gepromoot danwel gebruikt wordt.)

[johnbetonschaar]

Ja je gaat op deze manier zeker commentaar op je afroepen want wat je zegt is gewoon onzin van de bovenste plank. PHP heeft volgens mij al zo lang als het bestaat ondersteuning voor geparametriseerde queries, in ieder geval voor MS SQL, ik gebruikte het letterlijk 10 jaar geleden al.

[Reactie gewijzigd door johnbetonschaar op 26 juli 2024 17:05]

[Janoz]

Laat dan maar eens een stukje code van je uit 1999 zien waarin je php's geparameteriseerde query ondersteuning gebruikt.

--

Ik heb het even opgezocht. Ergens 2001 is de ondersteuning voor mssql toegevoegd. Geen 10 jaar, maar zit er niet ver naast. Het feit blijft wel dat in 999 van de 1000 tutorials over het gebruik van een database nooit dit onderdeel aangesneden wordt. Vergelijk dat eens met andere platformen waarbij geparameteriseerde queries eigenlijk gewoon de standaard approach zijn.

[Reactie gewijzigd door Janoz op 26 juli 2024 17:05]

[johnbetonschaar]

Voor MS SQL zit al support voor stored/remote stored procedures in de standaard driver sinds PHP 4, die is in 2000 gereleased. Voor MySql lijkt het er op alsof support voor prepared statements pas sinds PHP5 is gekomen via PDO en later de nieuwe mysql driver, maar voor bijvoorbeeld PostgreSQL zit het er al sinds 2002 in. Ik ga hier geen code zitten intiepen hoe je het moet gebruiken met MS SQL, de PHP documentatie is duidelijk zat.

Edit: @je eigen edit:
Ik kan niet zo veel zeggen over bijvoorbeeld ASP of ColdFusion want dat heb ik nooit gebruikt, bij JSP bijvoorbeeld is de manier om met databases te werken inderdaad wat professioneler gedocumenteerd als ik het me goed herinner. Maargoed we hebben het hier wel over het jaar 2001, ik durf niet eens te zeggen of ASP toen uberhaupt al gebruikt werd voor professionele websites met grote databases. Uiteindelijk doet het er ook niet heel erg veel toe hoe lang geleden het precies was dat je nette DB toepassingen kon schrijven met PHP, het kan tegenwoordig 100% zeker, en dat is al sinds PHP5 het geval, die bestaat ook alweer een flink aantal jaar.

PHP is oorspronkelijk ook begonnen als een huis-tuin-en-keuken server script taal, in tegenstelling tot ASP of JSP. Je hebt er ook veel minder voor nodig en alles is vrij beschikbaar om een PHP servertje op te zetten, in tegenstelling tot de commerciele oplossingen of JSP, daar is *veel* meer werk voor nodig om dat op te zetten op je thuis servertje, terwijl je bij PHP gewoon de standaard Apache install van je distro erop slapt en dan heb je volledige PHP support. Dus dan is het ook niet zo vreemd dat zo veel tutorials nogal laag bij de grond zijn en niet altijd de veiligste of meest doortimmerde oplossingen laten zien.

[Reactie gewijzigd door johnbetonschaar op 26 juli 2024 17:05]

[Janoz]

Ikzelf heb, naast (naar nu blijkt iets verouderde) kennis van php ook enige ervaring met Cold fusion, ASP (.Net) en vooral veel ervaring met J2ee (jsp, jsf enz) en vind daarom dat ik toch wel redelijk wat achtergrond heb de verschillende platformen met elkaar te kunnen vergelijken en daaraan dus conclusies te kunnen verbinden over waar iets wel en waar iets niet gebruikt zou moeten worden.

PHP is oorspronkelijk ook begonnen als een huis-tuin-en-keuken server script taal, in tegenstelling tot ASP. Je hebt er ook veel minder voor nodig en alles is vrij beschikbaar om een PHP servertje op te zetten. Dus dan is het ook niet zo vreemd dat zo veel tutorials nogal laag bij de grond zijn en niet altijd de veiligste of meest doortimmerde oplossingen laten zien.

En die laagdrempeligheid is ook precies het 'probleem'. Draai het eens om. Stel, je bent een klant en je zit in een sector waarbij veiligheid toch wel redelijk belangrijk is. Hoe zou je overtuigd kunnen worden?

Geparameteriseerde queries is maar 1 ding. Hoe zit het bijvoorbeeld met unittests en metrics? En dan bedoel ik niet of ze beschikbaar zijn, maar meer bij hoeveel projecten ze daadwerkelijk gebruikt worden. Vraag een standaard J2ee ontwikkelaar of hij junit kent danwel gebruikt en in 95% van de gevallen zul je 'ja' horen. Vraag hetzelfde aan een proffesioneel php ontwikkelaar (maar dan met phpUnit uiteraard) en ik denk dat het percentage andersom is.

Als ik voor een bank acceptatie criteria voor software zou schrijven zou ik php niet afraden. Het is makkelijk te beheren en ontwikkelaars zijn ruim aanwezig, maar ik zou wel adviseren om php alleen op de view te gebruiken. Geen rechtstreekse communicatie met databases of andere externe systemen, maar enkel communicatie via een afgebakende, duidelijk gedefinieerde en goed geteste interface laag (middels webservices bv)

[johnbetonschaar]

Mee eens, hoewel ik er ook aan toe zou willen voegen dat 'professionele' websites die met andere platforms zijn gemaakt ook vaak ontzettend brak in elkaar zitten. Hoe vaak ik geen hele rare ASP fouten of Java stacktraces tegenkom op sites van bedrijven...

Uiteindelijk maakt het relatief weinig uit wat je voor platform kiest, op elk platform heb je goede en slechte ontwikkelaars. Jammer genoeg zijn de slechte ontwikkelaars op elk platform veruit in de meerderheid, en daar vallen ook de hele grote, hele dure consultancy firms onder

[Reactie gewijzigd door johnbetonschaar op 26 juli 2024 17:05]

[hackerhater]

Ik werk professioneel met PHP bij verschillende online spellen en sites
Tot nu toe 150 hackpogingen op mijn code, 0 gelukt (in 3/4 jaar tijd)

De taal heeft er bar weinig mee te maken. Het gaat om de programmeur die de programma's schrijft, al ben ik wel met je eens dat beveiliging vaak een ondergeschoven kindje is bij cursussen

Mijn code is zo moeilijk te hacken omdat ik de userinput compleet niet vertrouw.

[MatthiasDS]

in tegenstelling tot de commerciele oplossingen of JSP, daar is *veel* meer werk voor nodig om dat op te zetten op je thuis servertje

Over commerciële oplossingen kan ik niet veel zeggen, maar een tomcat (voor java-apps) heb je op 1-2-3 running hoor.

[johnbetonschaar]

Als je weet hoe het moet wel, maar de eerste paar keer heb ik toch behoorlijk zitten klooien met server.xml's en web.xml's en weet ik niet wat om het fatsoenlijk draaiend te krijgen. Voor iemand zonder ervaring is het vrij frustrerend om de server 20x opnieuw te moeten starten met gekke server errors wanneer je een nieuwe context wilt toevoegen. Wil je speciale logging etc. erbij dan wordt het nog ingewikkelder. Maargoed verder werkt het best mooi en als je weet wat je moet doen is het redelijk eenvoudig, maar bij lange na nog niet zo eenvoudig als PHP. Daar installeer je gewoon apache en mod_php via de package manager van je distro en dan kan je aan de slag.

[MatthiasDS]

Als je weet hoe het moet wel, maar de eerste paar keer heb ik toch behoorlijk zitten klooien met server.xml's en web.xml's en weet ik niet wat om het fatsoenlijk draaiend te krijgen.

Okee, maar dan ben je niet bezig met een server opzetten maar gewoon het maken van enterprise java applicaties. Ik dacht dat je het puur op het opzetten van een server had.

Uiteindelijk moet je gewoon weten hoe het moet. Een WAR samenstellen met web.xml en een paar html-pagina's zal voor mij sneller gaan dan een PHP-install werkende krijgen omdat ik ook niet weet hoe dat moet. Als je beide werkwijzen kent, denk ik niet dat het zo'n verschil zal geven.

[roeleboel]

- waar lees jij dat het over php gaat?
- 't is niet omdat er php gebruikt wordt dat er per definitie onveilig is, ook php kan veilig zijn.

[zwippie]

Misschien heb je gelijk hoor, maar waar zie je staan dat het om php sites gaat?

[Faust]

Goed dat deze hacker er is: hij is slimmer dan andere, kwaadwillende hackers (sneller althans).
En hiermee is hij ze voor, de bedrijven kunnen alle lekken patchen voordat kwaadwillende hackers ermee aan de haal kunnen gaan
Respect voor deze hacker dus.

[BeosBeing]

Er is toch ook ooit eens iemand geweest (jaren geleden) die de bankgirocentrale had gehackt en voor iedere transactie 1 cent genereerde en naar zijn rekening stortte. Dat liep ook best lekker, totdat hij bij toeval werd ontdekt. Had hij na 1 of 2 maanden zich opnieuw toegang verschaft en zijn aanpassing weer verwijderd, dan was het nooit ontdekt.

[YopY]

Sja, dat was een gok dus - ga je nu stoppen of speel je nog een ronde door met het risico om alles te verliezen.

Maar om te zeggen dat het nooit ontdekt werd gaat wat ver - d'r worden wel uitgebreide logs van transacties bijgehouden, neem ik aan.

[Anoniem: 52211]

Dat was Superman III (http://en.wikipedia.org/wiki/Superman_III#Plot)

Maar daarna heeft iemand het ook eens in het echt gedaan vziw.

Op de wiki pagina hierboven vind ik dat de techniek 'salami-slicing' heet, dus waarschijnlijk wordt/werd dit wel meer gedaan.

http://en.wikipedia.org/wiki/Salami_slicing

[DNA_Saint]

Je weet niet of hij slimmer is. Hij publiceert het als eerst, maar misschien zijn er al 100 voor hem geweest, die alles stilletjes hebben verkocht...

[bgever]

Waar rook is, is vuur...

[Anoniem: 296829]

Toch wel slecht dat zoveel dingen kunnen worden " gehacked" door SQL injecties
Eerst fok en enkele andere websites
en nu 2 banken

Zeker voor een bank waar je verwacht dat het goed in orde is

[bluppfisk]

Hoe makkelijk is het eigenlijk je te verdedigen tegen SQL injecties? Is het niet voldoende mysql_escape_chars() te gebruiken om nu maar een php-voorbeeld te geven?

SQL-injecties gaan er toch vanuit dat je de SQL server doet geloven dat je datastring ten einde is, en dat nu weer commando's komen doordat je ergens een dubbele of enkele quote gebruikt? Of heb ik dat helemaal fout?

[Anoniem: 146814]

dus dan bedoel je zoiets als:

mysql_query("select * from users where id=".mysql_escape_string($_REQUEST['id']));

dan zeg ik:
pagina?id=1 union select * from users

Je hoeft maar 1 gat te vergeten en er is een ingang.

[bluppfisk]

zo ga je ook niet met mysql om.

mysql_query("select * from users where id='".mysql_escape_string($_REQUEST['id'])."'");

levert dat probleem niet op.

Ik weet niet of jouw code een fout oplevert of niet, maar je moet inderdaad niet alleen escapen, je moet ook je aanhalingstekens zetten. Maar ook dat zou een professionele programmeur toch allang niet meer mogen fout doen?

[Maghiel]

Of je gebruikt gewoon prepared statements:

[code]
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id=?");
$stmt->bind_param("i", $id);
$stmt->execute();
[/code]

[Nickname55]

Je kan ook eerst controleren of $_REQUEST['id'] wel een getal is. Dan hoef je heel niet te escapen.

[hackerhater]

voor ints werkt dit beter :
mysql_query("SELECT * FROM users WHERE id=".intval($_REQUEST['id'])." ");

Slimme hacker als ie daar langs komt

[Maaark]

of ctype_digit gebruiken toch?

[Grauw]

Nee je hebt gelijk. Het is bizar hoe vaak je ziet dat zgn. ‘professionele’ programmeurs zoiets simpels als escaping van tekens (niet alleen in SQL maar bijv. ook in HTML wat weer tot XSS-kwetsbaarheden leidt) niet op orde hebben.

[YopY]

Hoe makkelijk is het eigenlijk je te verdedigen tegen SQL injecties? Is het niet voldoende mysql_escape_chars() te gebruiken om nu maar een php-voorbeeld te geven?

Dat is één optie, je kunt ook prepared queries gebruiken. Maar ja, het is (relatief) belachelijk eenvoudig om SQL injectie te voorkomen. Dit soort gevallen geeft aan dat de ontwikkelaar geen standaardmanier gebruikt om queries uit te voeren, en/of dat hij het overzicht verloren heeft over waar wel escaping in gebruikt wordt en niet. Maar meestal is het het eerste - zelfs als je een eenvoudige php programmeur bent, kun je redelijk eenvoudig een wrapper functie om mysql_query() schrijven die de bijgevoegde parameters escapet.

[Keypunchie]

Zit wel een verschil tussen "de bank" hacken of de website van een bank hacken. Dat je in het ene systeem van een bank komt betekent nog absoluut niet dat je bij de financiele systemen kunt komen. Vaak zijn het ook verschillende partijen die de verschillende systemen beheren. Leuk dat je dan een of andere cadeausite kunt kraken, maar dan ben je nog nergens.

[Pixeltje]

Als er wachtwoorden en gebruikersnamen van beheerders 'in platte tekst' op de server slingeren, wat slingert er dan nog meer?

Snap je wat ik bedoel? Het is op zijn minst de moeite waard om daar (intern) onderzoek naar te doen. Als Bank wil je echt niet te boek staan als 'die bank die toen gehackt is'.

[Data-base]

Heel veel mensen vergeten dat security niet iets is wat je zomaar even doet. Sterker nog, het is niet iets wat je eenmalig doet en klaar. Het is een voortdurend process.

Sterker nog, het is een voortdurend process wat bakken vol met geld kost. Belangrijke instanties maken vaak goed overwogen keuzes over wat het kost om een systeem tot bepaalde mate te beveiligen en vergelijken dit met wat het zou kosten als iemand de security hole vindt en deze misbruikt. Daarbij wordt ook de kans meegenomen dat iemand uberhaupt zon fout vindt. (Zie ook ISO 27001, 27002 en de rest van de 27000 serie van iso).

Ik denk dat het dan ook aannemlijk is dat bij de risk anaylis van ing in dit geval is onderzocht is dat de webshop los staat van het financiele systeem en dat het dus niet de moeite waard is om zich daar goed tegen te beveiligen. Want vergeet niet, als de bank meer geld zou verliezen door een hack dan dat het zou kosten om het systeem te beveiligen dan zullen ze dat zeker weten doen.

Overigens wil ik het hiermee absoluut niet goedpraten wat er is gebeurd gezien, maar gezien het budget van banken ook niet oneindig is, moeten er keuzes gemaakt worden. Zolang een bank mij kan garanderen dat ik bij een hack, wat duidelijk hun schuld is, mijn schade wordt vergoed maak ik me geen zorgen.

[JoJo_nl]

ms-sql server draaien zonder encryptie op de passwoorden ... klinkt toch als een tekortkoming in de instellingen eerder dan een gat in de beveiliging... zoals je kan lezen ging het om een hack van de database van de website welke niet gekoppeld zijn aan klantendatabases. moe je mij eens uitleggen hoe ik zonder klantgegevens iets kan bestellen op die sites
loadfile execution aan laten staan is ook niet zo best plan doorgaans.. lol..

[musiman]

In MS SQL zit een security breach, waardoor de wachtwoorden van alle sql users in klare tekst in het GEHEUGEN staan. Zie verderop voor meer info hierover.

[musiman]

Dit neemt niet weg dat een bank een hoger potentieel risico vormt. Wanneer je de controle hebt over diens website (het gezicht van de bank richting klant), dan kun je eenvoudig de klant valse informatie voorschotelen of bijvoorbeeld als man-in-the-middle transacties afvangen.

[XyritZz]

FOK wordt door een groep vrijwilligers gemaakt, website van banken door professionals. Dat lijkt me toch een belangrijk verschil, want van vrijwilligers kun je geen topkwaliteit verwachten terwijl je dat van een professional wel kunt.

Wat dat betreft is het 10x erger dat de website van een bank gehacked wordt dan die van FOK.

En hoewel de hacker heus niet zomaar rekeningen kan gaan plunderen is het hacken van de website natuurlijk wel de ultieme kans to phishing. Extra URL toevoegen "Ga direct naar internetbankieren" met een valse URL er onder en klaar ben je, weinig klanten die daar met argwaan naar kijken omdat de link op een voor hun vertrouwde omgeving staat.

[himlims_]

Volgens Unu moet verdere toegang niet moeilijk

Volgens Unu was toegang niet mogelijk, ... toch is de harcker daarin succesvol geweest [..]

@RefriedNoodle; Daarmee doe ik op 't verleden, 'vroeger' zei men dat de huidige setup veilig is. Echter is het tegendeel gebleken.

[picture] <-- lelijk

[Reactie gewijzigd door himlims_ op 26 juli 2024 17:05]

[Anoniem: 19339]

Hij zegt dat het niet moeilijk moet zijn, niet dat het niet mogelijk is, toch?

[BRAINLESS01]

niet moeilijk, wel mogelijk...

[bbr]

Controle - Controle.
Da's wel heel slecht.
Je kan gewoon een aantal mensen zien die user+pwd hetzelfde hebben.

[Anoniem: 317249]

Sorry maar zo goed als elke site met een database is kwetsbaar voor SQL injecties. Er bestaan sites zoals Zone-h die heel goed weergeven welke sites er allemaal worden gehackt op die manier. Wachtwoorden mogen dan wel vaak in Md5 worden 'encrypted' maar als je de md5sum gewoon in google intypt krijg je meestal nog de plain text versie ook. Omdat het vaak standaard passwords zijn die dus al bekend zijn. Sorry maar inplaats van alle hackers altijd maar te straffen, moet men er eens over na denken om zo'n iemand die er echt wat van af weet in dienst te nemen. En niet iemand die HBO ICT heeft gestudeerd en nog nooit zelf iets heeft gehackt....

[sys64738]

Wat een onzin..... echt nog geen 1 procent van alle sites met een database erachter is kwetsbaar voor SQL injectie. Je doet net voorkomen alsof SQL injecties nou eenmaal een gevolg is van het maken van database-backed webapplicaties. Als je je applicatie goed opzet (en gebruik maakt van de juiste tools/frameworks) is er niks aan de hand en kan echt niemand je database op een andere manier benaderen dan jij in gedachte had.

Ik dacht sowieso dat ik hier een retro-artikel aan het lezen was. SQL injectie in 2009?!?! Als je daar nu nog kwetsbaar voor bent, loop je vrij dramatisch achter en moest je maar eens goed na gaan denken of een job in systeemontwikkeling wel echt iets voor jou is (en anders zou je leidinggevende dat zeker eens moeten doen!).

Dit zou voor mij als klant trouwens wel een reden zijn om mijn geld (en gegevens) toch maar eens ergens anders onder te brengen....

[Reactie gewijzigd door sys64738 op 26 juli 2024 17:05]

[Anoniem: 317249]

Waar breng jij je geld dan wel graag onder. Paypal? Waar grote aantallen accounts per dag gehackt worden?
Sorry maar sommige databases zouden helemaal niet direct aan het internet vast moeten zitten, of ze moeten op een andere manier opgezet worden. Want waar slaat het op dat sites zoals de ING zoveel privé informatie online hebben staan. Dat kan prima op een interne server.
En nothing is secure, dat is iets wat volgens mij toch algemeen bekend is. SQL injecties gebeuren nogsteeds elke dag, en nogsteeds bijna elke dag bij aardig grote bedrijven. Dus blijkbaar is het nog helemaal hot.
Wat denk je van al die 'Kleine' crews die de hele dag niks anders doen dan SQL injecties uitvoeren bij duizenden sites?

[Janoz]

Zo ongeveer alle PayPal hacks gebruiken social enginering en geen sql-injection. Daarnaast is het wel degelijk mogelijk om 100% te kunnen garanderen dat er geen sql-injections in je applicatie code zitten. Sql-injections zijn daarmee de meest simpel te voorkomen beveiligingsgaten.

Ik ben het echter wel met je eens dat bepaalde data behoorlijk van het internet afgeschermd zou moeten worden. Ikzelf zie meer in SOA georienteerde architectuur waarbij de database enkel binnen een heel klein domein bereikbaar is. Alle data wordt ontsloten via duidelijk gespecificeerde interfaces. Hierdoor heb je veel meer controle over welke gegevens wel en welke gegevens niet en op welke manier de gegevens aangeboden worden.

[Rannasha]

Plain text wachtwoorden... da's wel heel erg slecht. Zelfs voor een simpel forumpje dat ik zelf in elkaar prog neem ik de moeite (2 minuutjes extra werk) om met (salted) hashes van de wachtwoorden te werken. Onbegrijpelijk dat dit op dergelijke niveaus nog verkeerd kan gaan.

[musiman]

Nou, wat dacht je van de mentaliteit van bijvoorbeeld Microsoft over de mogelijkheid tot het verkrijgen van alle SQL users/beheerders' wachtwoorden wanneer je administrator rechten hebt in SQL server?
Microsoft zegt dat dit geen vulnerability is. Meer hierover kun je hier vinden.

De wachtwoorden stonden gewoon unencrypted in het geheugen...

Dit probleem geldt dus voor SQL server 2000, 2005 en 2008 die mixed authentication SQL auth en windows auth) gebruiken, omdat je zo dankzij de SQL wachtwoorden van gebruikers ook gelijk hun AD wachtwoord hebt. En ik denk zelfs dat je bij omgevingen waar die situatie er niet is, ook gevaar loopt omdat mensen vaak op elkaar gelijkende wachtwoorden gebruiken. Te denken valt aan opvolgnummers, of wachtwoorden met vergelijkbare patronen.

[Reactie gewijzigd door musiman op 26 juli 2024 17:05]

[alt-92]

3x raden wat al sinds SQL2005 uit is sterk afgeraden wordt:
Juist ja, Mixed mode.

[musiman]

Neemt niet weg dat mijn laatste opmerking nog geldt. Mensen hebben de neiging dezelfde of op elkaar gelijkende wachtwoorden te gebruiken.

[TDeK]

Dat zie je bij wel meer multinationals fout gaan, o.a. T-Mobile <klik>

[lammert]

ook kwam hij erachter dat load_file execution mogelijk was, waarmee hij nagenoeg volledig beheer kon verkrijgen over de Ubuntu-server van Dexia na het injecteren van kwaadaardige code in een beschrijfbare map.

Dat klopt natuurlijk niet, want load_file wordt gedraaid met de rechten van gebruiker mysql . Op de mysql database zelf mag je dan inderdaad alles (wat al erg genoeg is natuurlijk), maar op de rest van de server nog steeds niets.

[Anoniem: 95122]

Behalve als je een local root exploit kan draaien... Ik denk dan bijv. aan het vmsplice leak.

[SPee]

Tenzij ze de gebruiker mysql ook teveel rechten op de server hebben gegeven.

[Anoniem: 198334]

Op de website van De Redactie staat dat het de goede kant uit gaat met de beveiliging van het internetbankieren, en dat het aantal inbraken, en ook het ontvreemde bedragd gedaald is tegenover de twee voorgaande jaren.

[Reactie gewijzigd door Anoniem: 198334 op 26 juli 2024 17:05]

[Herko_ter_Horst]

Leuk voor De Redactie, maar dit heeft (vrijwel) niets te maken met het onderwerp. Internetbankieren != de website van een bank.

[fevenhuis]

Als u voor internetbankieren een andere website gebruikt dan degene van uw bank ben ik wel geinterresseerd wat voor een website dat is, het is dus bepaalt niet iets anders.

Als iemand via de website van uw bank malware kan installeren dan verloopt het internet bankieren ook niet zo veilig meer als de bedoeling is.

[Anoniem: 198334]

inderdaad.

Ik wilde enkel aantonen dat internetbankieren zeker en vast ok is qua beveiliging.

Hoewel dat geen excuus mag zijn om de rest zo lek als een mandje te laten zijn uiteraard.

[DNA_Saint]

SQL injections kunnen doen en dan ook nog wachtwoorden onversleuteld opslaan.
Welk dom bedrijf heeft deze sites gemaakt?

De ING en andere banken betalen tonnen voor zo'n site en dan heeft het van zulke domme fouten. Ik begin nu zelf te twijfelen of mijn ING wachtwoord wel versleuteld opgeslagen is...

[Trinitronic]

Volgens mij niet, want als een vergeten wachtwoord wil opvragen krijg je deze via post thuis. (was met postbank iig zo dat is nu ook ING)

[Dlocks]

Was/is dat niet een nieuw wachtwoord die je dan krijgt?

[DNA_Saint]

Het bedrijf dat dit gemaakt heeft moet gelijk een claim krijgen.
De admin inlog van de ING site is gewoon: ingadmin/ingadmin
Dan ben je toch aan het prutsen? Ik vraag mij dan ook echt af wie dit bedrijf heeft gekozen? Is het een vriendje van de directeur van ING ofzo?

[Seth_Chaos]

Het probleem van het bestaande management en directie van veel bedrijven is dat ze 0,0% ICT kennis in huis hebben. Ze hebben geen flauw benul hoe dit opgezet dient te worden en of hoe het functioneert. Ze besteden het werk uit, en laten contractueel vast leggen waaraan het moet voldoen. Thats it. Als er geblunderd wordt door het detachering bedrijf, dan worden de kosten simpelweg op hen verhaald.

[SYQ]

een beeeeeeetje programmeur zou een login/pw combo als hierboven nooit mogen toestaan! kijk wat voor simpele combo's je krijgt om in te loggen.. niemand die moeite neemt om een moeilijk wachtwoord te gebruiken :

http://img259.imageshack.us/img259/5395/logink.jpg