Hacker kraakt Kaspersky-website met sql-injectie

Kaspersky, ontwikkelaar van onder andere antivirus-software, heeft toegegeven dat zijn website afgelopen weekend met behulp van een sql-injectie is gekraakt. Inmiddels lijkt ook de site van Bitdefender door dezelfde hacker met succes te zijn belaagd.

Een hacker met de nickname Unu stelt op Hackersblog dat hij afgelopen weekend via een sql-injectie toegang heeft verkregen tot de database van usa.kaspersky.com. Unu claimt dat hij onder andere gebruikersnamen en activatiecodes probleemloos kon opvragen. Bovendien laat Unu aan The Register weten dat hij dagenlang via e-mail contact heeft proberen te zoeken met de beheerders met de mededeling dat de site een gapend gat in zijn beveiliging had. Omdat hij geen enkele reactie ontving zou hij alsnog de website van het beveiligingsbedrijf hebben gekraakt, maar de hacker benadrukt dat hij geen gevoelige gegevens heeft buitgemaakt. Unu stelt echter dat een kwaadaardige hacker met de opvraagbare gegevens veel schade had kunnen aanrichten.

Volgens een verklaring van Kaspersky is usa.kaspersky.com afgelopen zaterdag inderdaad door een hacker aangevallen. De kraak zou snel zijn gedetecteerd en volgens de Russische bouwer van virusscanners is het beveiligingsgat binnen 30 minuten gedicht. Verder claimt Kaspersky dat de hacker geen gevoelige informatie heeft bemachtigd. De Russische ontwikkelaar van antivirus-software wil verder niet ingaan op de zaak.

De kraak wordt door sommigen beschouwd als een aanzienlijk gezichtsverlies voor Kaspersky, mede doordat de website sinds 2000 al tientallen keren zou zijn gekraakt. Kaspersky is echter niet het enige slachtoffer van Unu; de hacker claimt inmiddels ook de site van Bitdefender met behulp van een sql-injectie te hebben gekraakt.

Reacties (74)

[henkiskaal]

Check dit is, hun site is vol met XSS probleempjes

http://xssed.com/search?key=kaspersky

en dit is de eerste die toegevoegd is:
Date submitted: 08/03/2007

Dat is toch echt redelijk oud!

Hier een voorbeeld:
http://usa.kaspersky.com/trials/trialsreg.php?aw=Trials+Page&ref="><script>alert("So anti-virus cant secure their pages?");</script>&chapter=146538207

Ben benieuwt hoe dit gaat aflopen!
XSS staat los van MySQL injections, maar het zou mogelijk kunnen zijn om dit uit te voeren!

Stel je is voor, je registreert je op de site van kaspersky en je krijgt een login + pass om je code te kunnen opvragen. Dit wordt altijd onthouden door een cookie.
De XSSer stuurt een link (met een iframe ofzo) dat hij die cookie steelt en daarmee inlogt om je key op te vragen.
Veranderd je gegevens (of kopieert het voor andere doeleinden) en je bent de lul.

Nou zeg ik niet dat mogelijk is om dit uit te voeren maar in theorie is het haalbaar.

Just my 2 cent

[Reactie gewijzigd door henkiskaal op 23 juli 2024 06:57]

[Verwijderd]

Als je die XSS'jes ook live controleert (dus niet alleen de mirrors van www.xssed.com), dan zie je dat deze aanvallen al niet meer mogelijk zijn.

Neemt uiteraard niet weg dat het slecht is dat deze foutjes ooit in de site hebben gezeten. Uiteraard maakt iedereen wel eens fouten, maar een bedrijf in de beveiligingsindustrie zou zich niet mogen vertonen met zo'n lekke website. Daarnaast komen SQL injections en XSS mogelijkheden nooit alleen: vaak is het dat de programmeur van de betreffende (web)applicatie gewoon niet weet dat het mogelijk is (en dus niet dat hij/zij het over het hoofd heeft gezien).

Ik vermoed dan ook dat de website zelf niet gemaakt wordt door Kaspersky. Hooguit door een aparte afdeling.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:57]

[henkiskaal]

Als je me post goed hebt gelezen gaf ik een voorbeeld die werkt

gewoon copy & paste en zie het resultaat

Ik denk inderdaad ook dat ze dit door iemand anders laten uitvoeren, maar als er gevoelige data is op te vragen is dat natuurlijk niet goed!

[MicGlou]

De kraak zou snel zijn gedetecteerd en volgens de Russische bouwer van virusscanners is het beveiligingsgat binnen 30 minuten gedicht.

Al het zo makkelijk te fixen is, dan vind ik het een enorm lakse houding van Kasperksy, dat wekt absoluut geen vertrouwen. Als ze al zo omgaan met hun eigen systeem, dan zou je je af kunnen vragen hoe ze met jouw gekocht beveiligingssoftware omspringen, als ze daar ook makkelijk te dichten lekjes in laten zitten

[Moartn]

De vergelijking website <--> eigen software is niet zo makkelijk te maken bij Kaspersky. De website wordt waarschijnlijk door een compleet andere afdeling gemaakt/onderhouden, als dat ding uberhaupt al in eigen beheer is gebouwd (grote kans dat ze dat hebben uitbesteed).

Dit alles neemt niet weg dat zoiets natuurlijk niet voor mag komen natuurlijk, bij geen enkel professioneel bedrijf. Het allerergste is natuurlijk wel dat ze niet op de mailtjes hebben gereageerd: als ze dat wel hadden gedaan hadden we er waarschijnlijk nooit iets over gehoord.

[aap]

Het allerergste is natuurlijk wel dat ze niet op de mailtjes hebben gereageerd: als ze dat wel hadden gedaan hadden we er waarschijnlijk nooit iets over gehoord.

Hoeveel bedrijven met vergelijkbare aantallen klanten ken je die binnen een dag op e-mail reageren? Ik wil niets goed praten, maar tussen alle mailtjes van gebruikers die zich afvragen hoe ze hun AV software installeren op smaak X van versie Y van Windows, valt zo'n bericht van een eerlijke hacker misschien niet direct op.

[Verwijderd]

Makkelijk te fixen heeft geen enkele relatie met makkelijk te detecteren. Ook jouw computer heeft waarschijnlijk lekken die binnen het half uur te beveiligen zijn, maar zolang je er geen weet van hebt zit je maar te gokken. Het zijn nooit de dingen waar je het eerst aan denkt die uiteindelijk het lek veroorzaken. En zelf al denk je beveiligd te zijn voor iets dan zijn er vaak lekken in die beveiliging zelf waar jij niks van afweet maar de hacker wel.

[Olaf van der Spek]

Al het zo makkelijk te fixen is,

Als je *weet* waar het lek zit, is het makkelijk te fixen ja. Alle code checken op zo'n lek is een heel stuk lastiger.

[Keypunchie]

Kans is groot dat Kaspersky hun website gewoon out-sourced heeft.

Is ook een grote kans dat die niet eens Kaspersky software gebruiken voor de beveiliging. Ja, het staat lullig, maar denk niet dat je er te veel conclusies uit moet trekken over de kwaliteit van Kaspersky.

[Madje]

SQL-Injectie = ?
Is dat zoiets als enorm veel records proberen te inserten om vervolgens in te breken en rechten te bemachtigen?

[The Zep Man]

SQL-Injectie = ?
Is dat zoiets als enorm veel records proberen te inserten om vervolgens in te breken en rechten te bemachtigen?

Nee. SQL injectie is SQL code injecteren in bijvoorbeeld een invulformulier om ervoor te zorgen dat je een bestaande SQL query kan annuleren en je eigen SQL query erin kan stoppen. Dit kan bij websites die hun invoer niet (goed) controleren. Met behulp van (bijvoorbeeld) stored procedures zijn veel van dit soort zaken zo te voorkomen. Over het algemeen is het een bewijs van slecht programmeren wanneer dit mogelijk is.

Volgens een verklaring van Kaspersky is usa.kaspersky.com afgelopen zaterdag inderdaad door een hacker aangevallen. De kraak zou snel zijn gedetecteerd en volgens de Russische bouwer van virusscanners is het beveiligingsgat binnen 30 minuten gedicht. Verder claimt Kaspersky dat de hacker geen gevoelige informatie heeft bemachtigd.

Hij heeft toch gegevens meegenomen en hij had de keuze om ook gevoelige gegevens mee te nemen. Kaspersky klinkt stoer, maar ze zijn in feite veels te traag. Een goed geprogrammeerde IDS zou dit kunnen herkennen en hierop actie kunnen ondernemen (verbindingen sluiten, IP's bannen, etc.).

[J__F__K__]

Meestal gebeurt SQL injectie via invul formulieren op de website. Dit is mogelijk als de ingevoerde gegevens niet goed gecontroleerd worden en direct ingevuld worden in een sql statement. Het is te voorkomen door gebruik te maken van stored procedures of door de ingevoerde gegevens door een safe sql functie te halen.

Een heel bekend voorbeeld is het volgende. Dit voorbeeld zou je geen gegevens bieden, maar wel een login zonder wachtwoord mogelijk maken. Als je een username en de namen van de velden in de tabel kent is dat voldoende:

De code die op de server draait ziet er als volgt (pseudo code):
[code]... = "SELECT * FROM users WHERE
username = \"" + $Username + "\" AND password = \"" + $Password + "\""
[/code]

Als je nu als wachtwoord invoert:
[code]" OR "" = "[/code]
zorgt de resulterende [code]OR "" = ""[/code] er voor dat je zonder wachtwoord kunt inloggen.

Dit is enkel een simpel bekend voorbeeld. Er is veel meer mogelijk met soortgelijke technieken.

[Reactie gewijzigd door J__F__K__ op 23 juli 2024 06:57]

[Cyw00d]

SQL injectie is simpelweg een SQL commando invoeren/onderscheppen.

Edit: nog betere uitleg:

http://nl.wikipedia.org/wiki/SQL-injectie

[Reactie gewijzigd door Cyw00d op 23 juli 2024 06:57]

[daft_dutch]

De beste uitleg

anyway Waar het bij veiligheid omgaat is om code en data gescheiden te houden.
Zodat de code niet onverwacht gaat functioneren doordat de data anders is.
(zoals sql injectie en cross site scripting)

Dat is bij sql niet echt aan de orde. daar zit het door elkaar in de sql statement.
Wat je wel kunt doen is de data op integriteit controleren voordat je het in een sql statement jast.

De data escapen is daar een simpel voorbeeld van. Helaas is escapen niet sql onafhankelijk waardoor men niet goed sql onafhankelijk kan coderen.

edit:btw die 30 minuten oplos tijd is ook niet te controleren. Doordat de hacker reeds gemeld had waar de lek zich bevond. konden ze niet zo goed na het gehack als nog de mail er bij genomen hebben en dat op gelost.

[Reactie gewijzigd door daft_dutch op 23 juli 2024 06:57]

[Blokker_1999]

De informatie die je verstuurd om een site op te vragen aanpassen zodat je bijkomende SQL commandos kan invoeren en op deze manier toegang krijgt tot de gegevens in de SQL database.

[Maxxi]

usa.kaspersky-labs.com
Mon Feb 9 09:55:00 2009
Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.7m DAV/2 PHP/5.2.4 with Suhosin-Patch mod_apreq2-20051231/2.6.0 mod_perl/2.0.3 Perl/v5.8.7

Unix dus ze draaien geen Kaspersky op hun webserver ;-)

[Verwijderd]

Kaspersky heeft een heeeeele lange tijd wel een Linux versie gehad Of ze die nog hebben weet ik niet, maar mischien kunnen ze deze zeker nog wel intern draaien. Ik heb zelf toen der tijd deze aan Smba gekoopt : http://markmail.org/message/2kev6qdakogtxsnj

Overigens heeft SQL injectie niets met virussen te maken.

Wat ik hier zo lees is dat iedereen het maar overt 'escapen' heeft, dat wil zeggen je houdt zelf rekening met de veiligheid, beter kun je dit overlaten aan een goed ORM model zoals JPA, hibernate en anderen.

Als je zelf je SQL's aan elkaar wilt knopen dan nogmaals (was al gezegt hierzo) gebruik prepared statements en ga niet klooien met stringetjes aan elkaar plakken.

Grt,
Ries

[cariolive23]

Pfffff, ORM.... Nu is Hibernate niet de meest beroerde ORM-tool, maar het blijft behelpen. ORM bindt je met hand en voeten aanelkaar en je mag vervolgens in de applicatie het wiel opnieuw gaan uitvinden. Dingen die een DBMS veel beter en sneller kan, moeten dan ineens binnen de applicatie/ORM-laag worden uitgevoerd. Dat kan, maar niet zonder performance penalty. Gebrek aan performance is dan ook een keuze, het is niet zo dat een database langzaam is, ORM is gewoon geen vervanger van de DBMS-laag.

ORM degradeert een database tot niet meer dan een kladblok. En van een kladblok hoef je niet al te veel verwachten.

[frickY]

Enige gezichtsverlies wat ze wat mij betreft leiden is de laksheid.

De kwaliteit van de website, die ongetwijfeld door een externe partij is ontwikkelt, zegt niets over hun anti virustechnologie.
Het spreekt zelfs voor hen dat dergelijke hackpogingen gedetecteerd worden.

[kimborntobewild]

Enige gezichtsverlies wat ze wat mij betreft leiden is de laksheid.

Voor een AV-bedrijf kan dat anders juist behoorlijk veel impact hebben. Dat woordje 'enige' lijkt me hier dan ook niet goed gekozen.

De kraak zou snel zijn gedetecteerd en volgens de Russische bouwer van virusscanners is het beveiligingsgat binnen 30 minuten gedicht.

Natuurlijk zeggen ze dat 't snel is gedetecteerd. Maar weet jij HOE 't is gedetecteerd?
Dat kan gewoon visueel gebeurt zijn, bijv. als Unu een plaatje op de frontpage had veranderd naar een piratenvlag ofzo. In geen enkel opzicht spreekt die verklaring van Kaspersky dan ook voor hen, zoals jij dat beweert.
Als er AL een automatisch systeem voor was om een hackpoging te detecteren, dan is 't dichten van zo'n hack na 30 minuten zelfs nog traag te noemen. Ik geloof er i.i.g. helemaal niks van dat er één of ander geavanceerd automatisch detectie-systeem aanwezig was die iets nuttigs met hackpogingen doet.

Weet je trouwens HOE ze 't gedicht hebben? Door blijkbaar de betreffende pagina gewoon uit te schakelen?!: "...and kaspersky.com.my remains offline, presumably in an attempt to audit the site for web application vulnerabilities before putting it back online"... Mooie manier van 'dichten'... Dat heeft ongetwijfeld langer dan 30 minuten geduurd. Ze hebben 't dus hoogstwaarschijnlijk na 30 minuten offline gehaald, maar toen nog niks gefixt.

De kwaliteit van de website, die ongetwijfeld door een externe partij is ontwikkelt, zegt niets over hun anti virustechnologie.

M.i. wel. Het is voor mij een signaal dat 't management niet deugt. Wat wel degelijk óók zijn weerslag kan hebben op de kwaliteit van de AV-software.

Het spreekt zelfs voor hen dat dergelijke hackpogingen gedetecteerd worden.

Vanwege deze zin is 't onbegrijpelijk dat je momenteel op 2 groene blokjes bent gemodereerd...

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 06:57]

[xoniq]

Daarom: Altijd goed je MySQL codes escapen.

[neothor]

Uberhaupt alle user input controleren

[seppevs]

Of nog beter: stored procedures gebruiken!

[cariolive23]

Ook daar kan SQL-injection op plaatsvinden, het kost de hacker hooguit wat extra pogingen om de boel te hacken. Gebruik prepared statements, ook wanneer je met stored procedures werkt.

Verder zou het verboden moeten worden dat programmeurs zomaar een database gebruiken, dat gaat keer op keer weer verkeerd. Zie de vele, vele voorbeelden van SQL-injection...

Met stored procedures, views en het intrekken van rechten op de onderliggende tabellen, is de boel uitstekend dicht te spijkeren. Wanneer je alleen de views A en B mag gebruiken, kun je onmogelijk view C gebruiken. GRANT en REVOKE zijn niet voor niets uitgevonden. Behalve een superuser heeft niemand rechten nodig op tabellen en hoeft dus niemand ooit een SELECT, INSERT, UPDATE of DELETE uit te voeren op deze tabellen. By by SQL-injection! En het maakt dan niet uit hoe de applicatie met de queries omgaat, een user kan alleen die dingen uitvoeren die hij mag uitvoeren. Er kan dus nooit sprake zijn van SQL-injection.

Ps. Wel zorgen voor de juiste rollen binnen de database, anders gaat het natuurlijk niet werken.

Voorkomen SQL injection op database niveau

[Reactie gewijzigd door cariolive23 op 23 juli 2024 06:57]

[Bacchus]

Werkt dat dan inmiddels al beter dan "ronduit irritant" in PHP+MySQL?

[Woy]

Het gebruik van Stored Procedures garandeert op geen enkele manier dat er geen SQL Injection mogenlijk is.

Gebruik van Prepared ( of ook wel parameterized ) queries genoemd is al een stuk beter, dan gebeurt het escaping ( als het goed is ) centraal op een punt, en kun je niet per ongeluk nog een keer vergeten.

[kokx]

Bij prepared statements vind er eigenlijk helemaal geen escaping plaats. De data wordt apart van de query gestuurd waardoor data niet eens geparsed wordt en SQL injection daarin dus onmogelijk is.

[Verwijderd]

Als je parameters voor je stored procedure gebruikt, voorkom je ook SQL injection.

Ik vind dat er hier wat veel op MySQL + PHP wordt geconcentreerd. PHP is een onbeveiligd zooitje. MySQL heb ik al te lang niet meer gezien. Ik hoop echt niet dat grote beveiligingsbedrijven met PHP aan het klooien gaan.

[2playgames]

PHP is zo veilig als het programma dat er op draait. Helaas zijn er door het lage instapniveau van PHP gewoon veel PHP-prutsers die niet genoeg aan beveiliging doen.

[Reactie gewijzigd door 2playgames op 23 juli 2024 06:57]

[CMG]

Gewoon Parameters met MSSQL, hoef je geen SP voor te gebruiken...

[.oisyn]

Die twee dingen staan los van elkaar. Zelfs als je user-input controleert moet je nog steeds zorgen dat je tekstuele data goed format voordat je het aan een systeem voert. Bovendien, wat valt er in dit geval te controleren? Mag je bijvoorbeeld geen ' gebruiken in een post op een forum, omdat dat toevallig speciale betekenis heeft voor een database?

@jvsjmedia.nl: waarom specifiek MySQL? Da's net zoiets als zeggen dat je je Opel altijd op slot moet doen

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:57]

[Verwijderd]

Tuurlijk mag je wel ' gebruiken, echter wordt dit door nette websites intern bij binnenkomst gelijk omgemieterd in "'" of een andere code die niet verkeerd geïnterpreteerd kan worden.

[YaPP]

Tuurlijk mag je wel ' gebruiken, echter wordt dit door nette websites intern bij binnenkomst gelijk omgemieterd in "'" of een andere code die niet verkeerd geïnterpreteerd kan worden.

Neen: nette websites gebruiken "prepared statements" zodat je niet eens de kans krijgt om het onveilig te schrijven.

Het gaat in alle gevallen om het combineren van strings uit verschillende bronnen. In diverse talen hebben sommige tekens een speciale betekenis. In een shell commando moet je geen &, " of ' tegenkomen. In een reguliere expressie hebben tekens als { [ * + , ] } e.d. een speciale betekenis. In een HTTP of SMTP header wil je geen enter teken zien (dat zal de volgende header inluiden).

De oplossing is altijd hetzelfde:

"string van een bepaald type" + escape-functie( jouw data ) + " rest van de string"

Dat is bijvoorbeeld in PHP

$sql = 'select * from table where username = \'' . mysql_real_escape_string( $username, $dbh ) . '\'';

$shell = "/usr/bin/something " + escapeshellcmd( $userinput );

$http = "Location: " . eigen-escape-functie( $url );

$url = "http://www.mysite.com/?q=" . urlencode( $userinput );

$regexp = '/some pattern' . preg_quote( $userinput ) . '/';

// en tot slot, jawel:
$html = "<p>Html code: " . htmlentities( $userinput ) . "</p>";

Dit is even aanleren, maar zo schrijf je wel veilige code.

Als je handig bent, programmeer je de HTML template en database API's op een dusdanige manier dat je default altijd goed zit. Bijvoorbeeld:

$results = $db->select( "select * from table where username = ?", array( $username ) );
foreach( $results as $record ) ...

[Reactie gewijzigd door YaPP op 23 juli 2024 06:57]

[.oisyn]

Je haalt dingen door elkaar. De ' is een html entity, voor je database kan ie gewoon als \' erin. Als de invoer nooit gebruikt gaat worden als html uitvoer is het onzin om er ' van te maken. Maar dit is ook helemaal niet het controleren van user-invoer, dit is het formatten van data voor een bepaald systeem (in jouw geval HTML). Dat is helemaal niet alleen gelimiteerd aan user-invoer, voor strings die gewoon in je code staan moet het net zo goed.

Het controleren van user-invoer is kijken of de data-integriteit wel klopt. Zoals bijvoorbeeld bij een veld dat om een nummer vraagt ook daadwerkelijk controleren of de data wel een nummer is en geen arbitraire string. Of kijken of het opgegeven topic id voor een nieuwe post wel correct is en er rechten voor zijn. Dát is controleren op user input, niet het formatten van een string.

Juist de hele denkwijze dat een waarde toch alleen voor een bepaald systeem gebruikt gaat worden (zoals de post met een ' erin die als ' in de database gaat, wat toevallig ook SQL injection voorkomt) zorgt ervoor dat er op een gegeven moment fouten ontstaan. Op het moment dat je die post weer uit de database trekt en ik een tekst-mailtje wilt versturen heb je weer helemaal niets aan die '. Sterker nog, als je de post ergens anders voor gaat gebruiken waarvoor & weer een speciale betekenis heeft ben je als nog de sjaak. Wat is dan jou oplossing, de post ook voor dat systeem alvast escapen voor het de database ingaat? Waarom denk je dat magic_quotes_gpc in PHP tegenwoordig default uit staat? Omdat het een onzinnige feature dat een schijnveiligheid creëert en wat uiteindelijk keer op keer weer de soep in loopt.

Programmeurs zouden steeds keer op keer na moeten denken als ze een invoer X hebben wat een systeem Y in gaat. En daarbij doet het er echt compleet niet toe waar die X nou vandaan komt (user input of niet), en wat Y nou precies is (database, HTML, command line opdracht, etc.)

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:57]

[Sfynx]

Waarom denk je dat magic_quotes_gpc in PHP tegenwoordig default uit staat? Omdat het een onzinnige feature dat een schijnveiligheid creëert en wat uiteindelijk keer op keer weer de soep in loopt.

Dat is echt de meest nutteloze en irritante feature die ze in PHP hebben gestopt... Je invoer is direct al vernacheld met backslashes, dus als je er nog wat transformaties op wil uitvoeren voordat het de database in gaat, dan kan je al problemen krijgen.

En simpelweg een aantal bekende karakters escapen met addslashes() (wat magic_quotes_gpc doet) is ook niet altijd genoeg, elke database server heeft niet voor niets z'n eigen escape functie (zoals mysql_real_escape_string()) omdat er altijd wel een aantal uitzonderingen zijn die bij een bepaalde database ook behandeld moeten worden, denk aan het invoeren van binaire BLOB data e.d..

[Sfynx]

Informatie in een database moet zo neutraal mogelijk zijn. Dus zeker niet overal HTML entities gebruiken voor speciale tekens, maar gewoon de juiste tekst-encoding (latin1, utf8, whatever).

Wil je eens dezelfde data als uitvoer laten dienen op iets dat geen HTML begrijpt, dan moet je het heen en weer gaan lopen transformeren, onnodig en te complex, daardoor ook foutgevoelig, en het gaat totaal voorbij aan het doel van die HTML entities.

Encoden naar HTML entities doe je vlak voordat je het in een HTML-pagina naar een browser stuurt, of HTML e-mail o.i.d., nergens anders.

[Reactie gewijzigd door Sfynx op 23 juli 2024 06:57]

[Big Womly]

Prepared statements is bij mijn weten DE oplossing, maar beide oplossingen zijn wel een mooie aanvulling.

[BlackShadow]

Idd. Dit zou toch niet mogen voorvallen. Door zulk nieuws begin ik me altijd zorgen te maken over mijn eigen code, SQL statements escapen is nu toch wel basiskennis. Of zie ik dingen over het hoofd?

[latka]

Als je prepared statements gebruikt hoef je niet te escapen. Wellicht is het ontstaan door 2 programmeurs waarbij de een het frontend doet en denkt die ander doet wel prepared statements in het backend terwijl de ander denkt dat het frontend de boel al voldoende 'escaped' bij binnenkomst...

[wizzkizz]

Gewoon standaard prepared statements gebruiken. Dan voorkom je dat probleem. Van alle queries die ik naar de DB stuur in een webapp gaat 99,5% met prepared statements en die enkele keer dat het niet kan/erg onpraktisch is, wordt alle input grondig gevalideerd en ge-escaped. Dan voorkom je dat je het een keertje vergeet en alsnog de sjaak bent. SQL-injectie is helemaal niet moeilijk te voorkomen.

[Verwijderd]

Dat zeg je nu wel zo makkelijk... Maar in hoeverre wordt jouw site dan ook zo hard aangevallen?

Misschien dat je wel degelijk steken hebt laten vallen, maar dat niemand het is opgevallen. Een site als die van Kaspersky ligt natuurlijk onder het vergrootglas, en het kleinste foutje wordt daar benut.

[Verwijderd]

misschien moet je dat lijstje er bij halen wat een paar week/maand geleden terug ergens hier werd gelinkt. meest gemaakte security-fouten in web-achtige dingen ofzo (wie weet het linkje nog?)

[Ram0n]

De zoekfunctie is je vriend, dit artikel dus

[Verwijderd]

Beter nog, niet rechtstreeks van SQL queries gebruik maken maar je eigen protocol ontwikkelen. Zo ben je zeker dat enkel en alleen de functionaliteit die je nodig hebt blootgesteld wordt, goed gecontroleerd wordt, en bovendien lastig te ontcijferen is voor hackers.

[Nick_S]

Security through obscurity noemen we dat. Meestal geen goede methode.

en bovendien lastig te ontcijferen is voor hackers.

Je gaat ze nog uitdagen, ook? Dat wordt alleen maar mooi gevonden.

[Verwijderd]

Security through obscurity noemen we dat. Meestal geen goede methode.

Inderdaad niet als dat de énige methode is, maar in de praktijk toch nog opmerkelijk effectief hoor. Dus ik zou het zeker niet laten om dat als extra middel in de strijd te gooien. Wat jou een uur kost, kost hen dágen. Bovendien scheidt het de script kiddies van de echte hackers, zodat elke verdachte melding meteen serieus genomen kan worden.

[wizzkizz]

Waarom? Je kunt gewoon veilig gebruik maken van SQL, als je zorgt dat er ofwel goed escaped wordt of (liever nog) je gebruik maakt van stored procedures/prepared statement. Jouw methode biedt schijnveiligheid op het moment dat je echt doelwit wordt, want er zijn altijd mensen die slimmer zijn dan jij.

[MrPepper]

Typisch dat een bedrijf als Kaspersky zo'n gebeurtenis weer in de doofpot probeert te stoppen. Toch wel pijnlijk dat een bedrijf dat is gespecialiseerd in het beveiligen van computers zichzelf niet voldoende kan beschermen.

[latka]

Toch wel pijnlijk dat een bedrijf dat is gespecialiseerd in het beveiligen van computers zichzelf niet voldoende kan beschermen.

Bij de timmerman thuis lekt het dak. Ik denk niet dat de mensen die de scanner maken en virussen analyseren op assembly niveau de website zelf onderhouden.

[WPN]

dat een beveiligingsbedrijf gekraakt wordt ok...... maar het gaat meer om de manier waarop..... je zou zeggen dat sql injection een van de eerste dingen zou zijn die ze uitsluiten van gebruik bij hun website....

[Kettrick]

Dergelijke bedrijven krijgen natuurlijk ook het meeste aandacht wat dat betreft
Neem niet weg dat sql injection ronduit slordig is en dit uiteraard niet had mogen gebeuren ...

[kimborntobewild]

een bedrijf als Kaspersky

Wat bedoel je daarmee? Welke bedrijven zitten zeg maar wat jouw betreft in 't zelfde rijtje?

Volgens mij geldt dit gewoon globaal en voor allerlei soorten bedrijven (niet alleen software): onwelgevalligheden probeert bijna elk bedrijf altijd in de doofpot te stoppen. Ken jij één bedrijf die op z'n borst klopt als er iets mis is gegaan? En uit eigen beweging - in die zin dat 't bijv. niet al (bijna op 't punt dat 't) was uitgelekt door een werknemer of iemand anders?

Ik denk dat er extreem weinig bedrijven zijn die vrijwillig onwelgevalligheden naar buiten brengen.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 06:57]

[P-Nut]

geeft die hacker een baan bij kasperky!

[IStealYourGun]

Pff, als een mens eens moest weten hoeveel website hiervoor gevoelig waren. Toen ik mij iPod registreerde op de apple website kreeg ik ook promt een error met veel debug informatie, de bug is ondertussen wel hersteld. Dat heb je dan met een naam zoals "D'haese" -_-

Op die manier zou ik bij veel bedrijven kunnen worden aangenomen.

[Verwijderd]

Ik vraag me af of de site uberhaubt wel gehackt is.

Ik mag aannemen dat de activatie-servers niet in contact staan met de website....

[moppentappers]

Het probleem is dat ze gebruik maken van joomla en extensies voor joomla. Als ze die dan ook nog eens niet updaten, tsja. Toch denk ik niet dat je de kwaliteit van het product zelf in verband moet brengen met de beveiliging van de website.

[kimborntobewild]

Als ze die dan ook nog eens niet updaten...

Een goed security model zou moeten werken ZONDER updates.
En als er al updates nodig zijn: dan geeft dat dus aan dat er (totdantoe) altijd al een gat in de beveiliging heeft gezeten.
Updaten is symptoonbestrijding i.p.v. 't probleem aanpakken bij de bron.