Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 365 reacties
Submitter: Z-Dragon

Hacker 'GrayHatHacks' is er zaterdag in geslaagd om de FOK-website te kraken. Met behulp van zogeheten 'sql injecties' wist de hacker door de beveiliging heen te dringen. Ook was de site tijdelijk onbereikbaar vanwege een ddos-aanval.

Danny Roodbol, eigenaar en beheerder van FOK, bevestigt de hack en geeft uitleg over de gebruikte hackmethode. Zo wist de hacker zich door een fout in de weblogsoftware van FOK toegang te verschaffen tot de database van de site en op deze manier een groot aantal md5-hashes, wachtwoorden in gecodeerde vorm, te bemachtigen. Via een website die md5-hashes berekent, konden twee wachtwoorden van FOK-teamleden, waaronder die van Roodbol, worden achterhaald. Met het account van die laatste werd uiteindelijk ook het hackbericht geplaatst, evenals enkele forumberichten op FOK. Roodbol roept leden op hun wachtwoord te wijzigen, zodat daar geen misbruik van kan worden gemaakt. Het lek is inmiddels gedicht, zo weet Roodbol te melden.

GrayHatHacks, naar eigen zeggen een jeugdige hacker die nog thuiswoont, had op de site van FOK een nieuwsbericht geplaatst dat de site door hem op 15:00 uur was gehackt, waarbij gebruik werd gemaakt van de zogeheten 'sql injecties', een bekende methode om sites te kraken. In totaal was hij met de hack ongeveer twee uur kwijt.

De hacker claimt met de hack geen kwaad in de zin te hebben gehad. “Deze hacker kiest er bewust niet voor om ernstige schade aan te richten omdat hij een GREY HAT HACKER is”, aldus de posting van GrayHatHacks, daarbij refererend aan de hackerterm 'grey hat'. Ook konden de FOK-beheerders contact met hem leggen via het e-mail-adres greyhathacks@hotmail.com voor 'gratis een betere beveiliging'.

Op een besloten GoT-draadje uitte de FOK-eigenaar onder de nickname 'Danny' zijn ongenoegen over de GoT-reacties op de hack van de FOK-site. In hetzelfde draadje werd ook commentaar afkomstig van de hacker geplaatst.

Overigens wijst Roodbol in zijn posting van zaterdagavond op FOK erop dat de site plat heeft gelegen als gevolg van een ddos-aanval. Deze zou niet samenhangen met de hack van de wachtwoorden. Ook vrijdag lag de site eruit. Momenteel is de site slechts sporadisch te bereiken.

[update 23:55 uur] Inmiddels heeft de ddos-aanval zich ook uitgebreid naar andere websites, waaronder die van Tweakers.net. Na een korte downtime wisten de systeembeheerders van deze site de aanvallen te pareren. FOK en GeenStijl zijn op het moment van het schrijven van deze update nog onbereikbaar

FOK-website hack

Gerelateerde content

Alle gerelateerde content (22)
Moderatie-faq Wijzig weergave

Reacties (365)

1 2 3 ... 11
SQL injecties zijn eigenlijk de fout van de beheerder / developer.
Je voordeur open laten staan, je portemonnee achter het raam leggen en verbaasd zijn dat deze wordt gestolen.

WhiteHat Hackers zeggen dat de deur open staat.
GreyHat Hackers jatten de portemonnee eerst maar brengen de portemonnee later weer terug.
BlackHat Hackers houden de portemonnee en wachten tot er weer 1 ligt.

Ik heb me er zelf ook wel eens mee bezig gehouden om de beveiliging van m'n eigen sites te testen.

Voorbeeld van sql insertions (comic):
http://imgs.xkcd.com/comics/exploits_of_a_mom.png

[Reactie gewijzigd door bglnelissen op 24 augustus 2009 11:01]

Toch knap dat steeds vaker jonge mensen hier in slagen. Gelukkig dat de hacker geen kwaad in de zin had. Ik wilde eergisteren ook naar deze site, maar toen was die al down ;)

[Reactie gewijzigd door Joseph op 23 augustus 2009 14:47]

Een hacker die geen kwaad in de zin heeft die meld het lek zonder dat hij verder iets doet.

Hij heeft wel degelijk schade gedaan, namelijk toegang verschaft tot 2 accounts, en vervolgens een publiek bericht geplaatst op de frontpage via deze accounts. Hij heeft tevens beschikking over/toegang verschaft tot alle gebruikersgegevens...

Daarmee heeft de hacker ook keurig de wetjes tegen computercriminaliteit overtreden...

Ga het nou niet goedpraten, dit is gewoon fout en Danny is terecht wat pissed off, en daardoor ook terecht voorzien van een wat minder ontwikkeld gevoel voor humor in het draadje op GoT.
Ik vind het een grote blunder van zo een grote website als Fok.nl.

Als GrayHatHacks dit niet had gedaan, dan heeft al die tijd iemand anders (die wel kwaad in de zin had) ook de wachtwoorden kunnen stelen zonder verder iets te veranderen aan het uiterlijk van de website, of iemand daarvan op de hoogte te brengen. Wie weet, mischien is dit in het verleden ook al gebeurt bij de Fok.nl site (het is immers een behoorlijk stomme fout als je nu nog steeds MD5 hashes gebruikt, als al maanden bekend is dat deze niet meer veilig zijn).

Vergeet niet dat heel veel mensen op meerdere websites dezelfde wachtwoorden gebruiken. Met deze gestolen wachtwoorden is het dus zomaar mogelijk om in iemands gmail, paypal, steam, bol, amazon etc account te komen. Met alle nare gevolgen van dien.

Ik vind het dan ook een 2e grote blunder dat er niet wordt gecommuniceerd met de FOK.nl leden dat ze er verstandig aan doen om op ALLE websites waar de Fok.nl leden hetzelfde wachtwoord gebruiken dit moeten wijzigen. Jullie MD5 hash (en dus wachtwoorden) liggen op straat.

Ik moet zelf ook nog even checken of ik uberhaubt ooit lid ben geworden (kan ik me trouwens niet meer herhinneren) en welk wachtwoord/email ik daarbij heb gebruikt. Alleen dat kan niet omdat de website plat ligt.

Ik begreep dat de SQL injectie mogelijk was door een fout in de 'weblog' software. Wellicht is dit een commercieel of open-source stukje software. Ik ben heel erg benieuwd of dit door een onbekende bug, of nalatigheid met het updaten van het pakket door Fok.nl is. Wellicht kunnen ze een deel van de schade verhalen op de leverancier van deze software, al lijkt me dat zeer onwaarschijnlijk.

Natuurlijk is het als gebruiker ook niet verstandig om op verschillende websites hetzelfde wachtwoord te gebruiken. Maar voornamelijk met het opkomen van het 'web 2.0' is er werkelijk een stormvloed aan websites waar je een wachtwoord moet opgeven. Het is praktisch bijna onmogelijk om overal een ander wachtwoord voor te verzinnen. We moeten echt heel snel over op OpenID, of een variant daarvan.

edit:

Door de kleine suggestie in het 'nieuwe' gelinkte nieuwsartikelL
Het is niet bekend of de aanval gerelateerd is aan de hack van FOK zaterdagavond
Zou ik het erg op prijs stellen als iemand van tweakers kan bevestigen of tweakers dezelfde kwetsbaarheden heeft (unsalted md5 in combinatie met sql injecties).. Zo weet ik in ieder geval dat mijn MD5 hash niet op straat ligt.

[Reactie gewijzigd door DutchStoner op 24 augustus 2009 00:53]

1) werd gecommuniceerd, staat zelfs als breaking news in zo'n kadertje op de frontpage
2) veel valt er niet te communiceren als de site plat ligt ...
1) site is plat, en zover ik heb gezien is er niet specifiek gecommuniceerd dat ALLE gestolen wachtwoorden van Fok.nl op het gehele internet onveilig zijn geworden.

2) een nieuwe domeinnaam met hostingpakket is binnen 1 uur geregistreerd en actief. Verder zijn er zo tientallen andere manieren om te communiceren. (twitter, hyves, myspace, facebook, etc). Voor zover ik weet hebben ze daar al een bestaand fok-account.

En Fok.nl is lijkt me groot genoeg om een landelijk pers-bericht de deur uit te doen.

[Reactie gewijzigd door DutchStoner op 24 augustus 2009 00:23]

Als je van iets willekeurigs samen met het wachtwoord een hash maakt dan is de hash wel degelijk anders dan op andere willekeurige site.
Ja, dat klopt. Maar dat is hier dus niet het geval. Salt heet die techniek trouwens.

GrayHatHacks heeft ook de wachtwoorden van de beheerders kunnen achterhalen, dan lijkt het mij dat de wachtwoorden zonder salt opgeslagen zijn, of GrayHatHacks had toegang tot de salt-key.

Het is naar mijn weten onmogelijk om in te loggen met een MD5 hash of salted MD5 hash. Als dit wel het geval was dan hadden ze te maken met een ernstige SQL-injectie bug in het login-script.

[Reactie gewijzigd door DutchStoner op 24 augustus 2009 00:33]

Het is niet helemaal netjes geweest nee, maar die jongen wilde natuurlijk ook heel graag laten zien waartoe hij in staat is geweest.

Fok wordt gewezen op de beveiligingslek, die hacker krijgt de roem dat hij dit gevonden heeft...

Liever zo dan alles weg ;)
Als je wil laten zien waar je toe in staat bent, dan stuur je een mailtje naar het beheer van FOK (Danny dus) en leg je uit wat je kunt doen. Je had bijvoorbeeld ook het PM systeem kunnen gebruiken als je er in kon hacken om een PM achter te laten met "I was here" of zoiets.

Zoals de hacker het nu gedaan heeft wil hij duidelijk publieke aandacht trekken, en niet simpelweg FOK wijzen op de fouten. :P
Klopt, maar veel aangegeven lekken worden genegeerd, zelfs al wijs je mensen er op, en die ondernemen pas actie als ECHT het fout gaat.

Deze hack(st?)er heeft dat mogelijk wel gedaan, en die vond dat mogelijk moreel onverantwoord(fok.nl is voor sommige mensen nog al heel erg belangrijk) dat hij/zij geen aandacht kreeg, en deed het dus op deze manier, of zoekt eeuwige roem door een frontpage te hacken.

tip voor de volgende keer aan de beste hacker, meld de dreiging, stuur een vervolmailtje, en mail naar iemand anders van het bedrijf als je nog steeds genegeerd word dat je het publiek in de media gooit wat het lek en de potentiele risico's ervan zijn. Doelbewust beveiligingen omzeilen is nl. strafbaar, ook als je nog bij je ouders woont.
Precies, op die manier heb ik ook toevallig een keer een SQL Injection gevonden op het sport gedeelte van FOK.

Wilde een pagina opvragen uit m'n geschiedenis, en ipv op enter te drukken raakte ik de single quote eerst nog. Kreeg meteen een SQL error, en een dump van de query die fout ging. Heb gewoon even een e-mail gestuurd van goh volgens mij kan ik de hele website slopen omdat SQL Injectie mogelijk is.

Netjes een reactie terug gehad dat ze het op gingen lossen met een bedankje er in voor het melden van het probleem.
En juist als er al eerder meldingen gemaakt zijn mag de beheerder of wie dan ook verantwoordelijk is zich dood schamen dat zijn meuk weer met een bekende methode (SQL-injectie) te hacken is.

De beheerder kan pissed worden maar feit blijft dat hij geen aanpassingen gemaakt heeft om SQL injecties te voorkomen wat je jaren na de eerste injecties nu eigenlijk wel mag verwachten.
Deze jongen kon als aangeven dat er een lek was zonder de website te veranderen.

Dus er wordt wel degelijk schade aangericht, alhoewel minimaal natuurlijk...


Ries
Helaas is het vaak zo dat enkel melden niet echt leidt tot vlotte actie.
De melding komt in de molen terecht en het duurt vaak langer dan nodig voordat het lek weg is.
Bron?
Als ik gewezen word op een probleem, helemaal van deze magnitude zou ik er namelijk direct achteraan gaan.
Ik kan me niet voorstellen dat er mensen zijn die er zo luchtig mee omgaan dat ze het in een molen flikkeren.
Dat is niet geheel waar hoor...

een paar maanden geleden was er een security risk voor apache.. de ontwikkelaars wisten dit al heel lang... de hacker heeft zelfs melding gemaakt (zoals hier boven een paar beschreven)... alleen het oh zo grote apache zegt dood leuk:
...after RSnake had contacted the Apache security team. Their response, while quick, was not quite what he expected:
DoS attacks by tying up TCP connections are expected. Please see: http://httpd.apache.org/d...sc/security_tips.html#dos
bron: http://lwn.net/Articles/338407/

even voor de goede orde het gaat hier niet om een ddos attack :)
This is NOT a TCP DoS, because it is actually making a full TCP connection, not a partial one, however it is making partial HTTP requests. It's the equivalent of a SYN flood but over HTTP.
bron: http://ha.ckers.org/slowloris/

Zelf getest op een eigen server (1pc heeft 5 seconden nodig om de server plat te krijgen)

dus sommige dingen gaan wel in de grote molen... want zover ik weet is het nog steeds niet opgelost. en kan je nog steeds gebruik maken van deze methode

[Reactie gewijzigd door ponsjuh op 24 augustus 2009 16:51]

Ik zie het probleem echt niet. Hij had volledige toegang tot fok, hij had dus net zo makkelijk alles kunnen deleten, de helft kunnen corrupten of stiekem her en der wat accounts aanmaken met hogere machten dan normale users. Zodra die dan een tijdje bestaan en in de backups dus ook aanwezig zijn kan hij zijn slag dan slaan om alsnog de boel om zeep te helpen.

Dit is by far de meest effectieve manier, iets hacken en dat laten zien (ook aan publiek). Dat maakt het 1. eenvoudig voor de 'getroffenen' om het op te lossen en 2. belangrijk voor hun om het a.s.a.p. op te lossen vanwege dat het nu deels bekend is. :)
Je mag je afvragen wat een grotere fout is, het verkrijgen van toegang tot een tweetal accounts of een site dusdanig blijkbaar slecht in elkaar zetten dat iemand met weinig moeite zich een weg naar binnen kan banen. Misschien was het netter geweest om enkel Fok op de hoogte te brengen van de potentiele hack, deze heeft er iets meer gebruik van gemaakt. En zolang de hacker zich enkel even profileert lijkt het me niet zo'n ramp, sterker nog het lijkt me als gebruiker prettiger om op de hoogte te zijn dat iemand dit kon dan dat de admins stilzwijgend de boel dichtzetten en doen alsof er niets aan de hand was.
Overigens is het niet de eerste keer natuurlijk dat een discussie als deze voorkomt en zla het ook niet de laatste keer zijn. De keuze dat iets fout is hangt af van de optiek van hoe iemand ernaar kijkt. En imo.. en zo zullen er nog wel meer zijn zolang de schade geen directe kostenpost tot gevolg heeft is het niet meer dan een waarschuwing. Een ander zoals bv de FBI die Mckinnon veroordeelt vanwege ettelijke miljoenen schade vanwege dat de FBI opeens veel geld moest investeren in het beveiligen van hun systemen.
let wel.. goed en fout is volledig afhankelijk van hoe iemand het bekijkt.
Alles kan gehacked worden en het is belachelijk om dan ook de fout bij een site te leggen. We zouden er beter aan doen om overal zo weinig mogelijk beveiliging te moeten hebben en de mensen leren dat zo'n gedrag niet kan.
Als je enkel de beveiliging verscherpt ben je gewoon verstrikt in een neerwaarts spiraal van tijdverspilling waar hackers uiteindelijk toch doorgeraken.

Kan niet wachten op de dag dat ik geen sloten meer moet gebruiken op huizen of auto's.
Precies!

ooit had ik ook een forumsite. Die werd ook gehackt, en kwam er nooit meer in.
Ik had niet op tijd geupdated, en als 'waarschuwing' had de hacker vele sites gehacked die nog de oude software gebruikten.

Zelf vind ik dit een beetje rare gedachtengang. Net zoiets als iemand een kogel door het hoofd jagen omdat je hem wilt waarschuwen voor gevaar.

Als ik de site weer terug had gehad... ja, dan had het een waarschuwing geweest.. maar dat gebeurde dus niet.

Ik zou maar wat graag in een wereld willen leven waar je de deur gewoon open kan laten staan...
De site slecht in elkaar zetten is geen misdrijf.

De slecht in elkaar gezette delen misbruiken is WEL een misdrijf.

Daarmee is ook duidelijk wat de grotere fout is!


Ik heb geen ENKEL begrip voor deze "hacker".

Er zijn ook wel degelijk kosten verbonden aan deze hack. Inkomstenderving door adverteerders die wegblijven? Ik hoop dat Fok! hem aanklaagt, en er veroordeling uitsleept, en daarnaast via een civiele procedure domweg de schade verhaald...

Hij had het moeten melden dat er een lek zat, Fok de kans geven dit te repareren. Als je zelf een site zou beheren zou je het er absoluut mee eens zijn. Dat de site jou niet bevalt (ik kom er ook niet) doet niets af aan deze feiten.

[Reactie gewijzigd door Ronald op 23 augustus 2009 15:26]

De site slecht in elkaar zetten is geen misdrijf en juridisch heb je gelijk. Maar eerlijk is eerlijk: als je zo'n grote website hebt en je neemt niet de moeite om hem fatsoenlijk te beveiligen is het niet gek dat adverteerders wegblijven oid. Dus juridisch hebben ze bij fok niks fout gedaan ofzo maar dat neemt niet weg dat het deels hun eigen schuld is.
als je een bank opent zonder beveiliging ga je toch ook niet zeuren als hij overvallen wordt hoop ik? :|
Het is mischien naief, maar het is en blijft een misdrijf.

Laat jij de voordeur open staan in Amsterdam? Naief, maar diefstal is desondanks een misdrijf. Is het verstandig om puur op de wet te leunen? Nee natuurlijk.

Echter is het misbruikte lek in de software van Fok een tikkeltje beter verstopt als een sleutel onder de bloempot, laat staan dat de voordeur open stond ;)
Ik dacht nochtans dat het openlaten van je voordeur / auto etc. weldegelijk verboden is. Verder is het fijn te weten dat een site die van sommigen veel persoonlijke informatie bevat erg slecht beveiligd is.

[Reactie gewijzigd door blissard op 23 augustus 2009 15:51]

bewust, misschien maar niet alles zeker niet in software staat bewust open. OP een site kan je ook niet zomaar naar binnen. Je zal er toch moeite voor moeten doen, bv een raampje op 9 hoog in klimmen, als je het dan toch ergens mee wil vergelijken.

Die staat bewust open, maar zonder dat je daar het risico van in ziet.
Het is niet bij wet verboden. Sommige gemeentes verbieden het in de APV, maar dat is dan zogezegd ter bestrijding van overlast. Maar het is geen uitlokking van diefstal om je fiets onbeheerd achter te laten.
Een site die lek is bewust lek laten (waardoor privacygevoelige informatie 'op straat' kan liggen) zou strafbaar kunnen zijn. Het is een soort nalatigheid die tot gevolg heeft dat andere (privacy)wetgeving wordt geschonden.

Soms (zoals in dit geval) is het niet handig om overal een analogie voor te verzinnen :P
Dat zou lekker worden, zijn alle middenstanders illegaal bezig. :-P Het zit iets anders: als je de deur openlaat en iemand komt binnengelopen, neemt iets mee en loopt weer naar buiten, dan heeft hij niet ingebroken. Dat heeft effect op zijn strafbaarheid en jouw verzekeringsdekking.

Het gros van die persoonlijke informatie spuit de gemiddelde FOK!ker toch in de forums he, toch al volledig openbaar dus. Het is ronduit gestoord hoeveel je daar tegenkomt.
ik heb anders nooit gehoord van een boete cq gevangenistraf omdat je eigen deur openliet?
Ik denk dat FOK net zo "fout" is als die "hacker" , aangezien zij dus toegang kunnen bieden aan bijv. NAW gegevens van hun klanten....

Die horen ze toch op een betere manier te beschermen dunkt mij.

Dat er 1 hacker er nu door komt (er zelf een bericht achter gelaten heeft) zegt niet hoe vaak dat in het verleden als is gebeurt btw....
Het is niet zo dat Fok! de deur wagenwijd opengezet heeft, want een hacker moet echt wel wat moeite doen om bij de database te komen: uit deze jongen z'n posting begrijp ik dat ie er 2 uur over heeft gedaan. Ga er dan maar vanuit dat iemand die niet bekend is met hacker-methodes en tools er veel langer over gedaan zou hebben.
http://www.nu.nl/algemeen...a-misbruik-via-route.html

In dit geval is het misbruiken van slecht gemaakte onderdelen niet strafbaar. Het ligt namelijk binnen de mogelijkheden. En zo was het ook op fok, het was mogelijk een bepaalde string in een bepaald invoerveld te zetten en hiermee toegang te verschaffen tot (dus niet afgeschermde) gegevens.

Dan neemt de ns het toch sportiever dan Danny, maar dat viel te verwachten ;)
Dit is dan ook niet het zonder toestemming toegang verkrijgen tot het computersysteem.

Dat maakt het verschil tussen NS en Fok...


Nog sterker als ik het goed begrijp is het een fout in de tariefstructuur, waardoor je dit goedkopere kaartje ook via de balie zou krijgen...

[Reactie gewijzigd door Ronald op 23 augustus 2009 16:03]

Nee er is geen verschil, de 'hacker' maakt ook maar gebruik van het http protocol om sql te injecteren hoor, elke browser praat zo met een website.

Bij de ns zijn het de knoppies op de touchscreen, bij websites ligt dat net ietsje anders :)

En bij beide is het een software "fout", een fout in de tarief structuur is dus ook een software fout!
Een fout in de tariefstructuur is geen softwarefout, eerder een fout in het businessmodel van de NS.

Ook wettelijk gezien is het volgens mij niet verboden om zo'n reis te plannen (van Amsterdam naar Groningen via Groningen-Noord is toch immers een legitieme reis?).
Er is wel zoiets als verantwoordelijkheid.
Als je iets slecht maakt en je laat andere mensen er gebruik van maken, dan ben je verantwoordelijk als er iets fout gaat. Als blijkt dat je nalatig bent geweest kun je dus strafbaar zijn.
Tsja, bij inbraak/insluiping werkt het ook zo: de dader is wel strafbaar, maar de verzekering keert geen cent uit als jij je voordeur niet op slot hebt gedaan.
Lees je voorwaarden dan nog maar eens goed na! Bij de meeste verzekeraars is zowel inbraak als diefstal verzekerd zolang het maar uit de woning is. Diefstal uit de schuur is vaak niet gedekt (inbraak weer wel).

Diefstal zonder sporen van braak is wél gedekt omdat dit bij het normale gebruik van een woning hoort, je kan nu eenmaal niet leven in een bunker, kinderen horen een woning gewoon uit te kunnen en ook weer binnen kunnen komen.

Overigens heb ik geen begrip voor Hackers, er zijn andere wegen om aan te geven dat de site niet veilig is. Als je lang genoeg zoekt is elke site te kraken, het blijft tenslotte code die door mensen is geschreven, er zullen altijd fouten op blijven duiken die de veiligheid in gevaar brengen.
Tja, de verzekering is een derde partij met andere belangen. Zij zoeken altijd een uitweg om niet te hoeven betalen. Als je TV na een jaar wordt gestolen krijg je ook maar een fractie van de aankoopprijs terug, terwijl je als dief zijnde toch echt niet minder strafbaar bent.

Verzekering en wet hebben niks met elkaar te maken.
De site slecht in elkaar zetten is geen misdrijf.

De slecht in elkaar gezette delen misbruiken is WEL een misdrijf.

Daarmee is ook duidelijk wat de grotere fout is!
Inderdaad, dit laat zien dat de wetgeving aangepast moet worden zodat sites slecht in elkaar zetten strafbaar wordt (en dan heb ik het niet alleen over layout }> )
blijkbaar slecht in elkaar zetten dat iemand met weinig moeite zich een weg naar binnen kan banen.
Hoho, wel ff respect voor de hacker! Je weet helemaal niet hoeveel moeite het gekost heeft om die SQL injection te vinden, hè ;)

[Reactie gewijzigd door AxiMaxi op 23 augustus 2009 15:24]

google? of halen we de drugs ergens anders vandaan tegenwoordig?
Sorry? moet dat een flauwe grap zijn?
De wet overtreden, okay. Maar is er ook echt wat gebeurd verder? Daar valt over te discussieren maar het is in elk geval niet zo zwart/wit als jij het nu stelt.
in Duitsland kan je hiervoor al 20 jaar krijgen.. alleen al voor het inbreken zonder dat je schade veroorzaakt.
In duitsland mag je 250 rijden zonder je rijbewijs kwijt te raken. Als je dat in Nederland doet, zelfs op een lege weg, ben je het toch echt kwijt.

Wetten kunnen per land verschillen, en zijn niet altijd per definitie opgesteld en goedgekeurd door mensen die de wijsheid in pacht hebben.
Een hacker die geen kwaad in de zin heeft die meld het lek zonder dat hij verder iets doet.
Maat de computervredebreuk waar jij het zo moeilijk mee schijnt te hebben (wetje overtreden) heeft dan al plaatsgevonden. Hoe kan dit minder fout zijn dan, volgens jou?
Hij heeft wel degelijk schade gedaan, namelijk toegang verschaft tot 2 accounts, en vervolgens een publiek bericht geplaatst op de frontpage via deze accounts. Hij heeft tevens beschikking over/toegang verschaft tot alle gebruikersgegevens...
De "schade" bestaat uit de kosten voor reparatie van dit lek. Dat had al veel eerder moeten gebeuren, daar kan je deze jongen niet de schuld van geven.
Verderop dit draadje heb je het over te derven advertentieinkomsten, maar dat is een aanname die erg lijkt op de denkwijze van sommigen inzake gemiste inkomsten van de muziekindustrie. Snijdt geen hout imho. Geen schade dus.
Ga het nou niet goedpraten, dit is gewoon fout en Danny is terecht wat pissed off, en daardoor ook terecht voorzien van een wat minder ontwikkeld gevoel voor humor in het draadje op GoT.
Nee, het is heel fout dat een site als Fok zo slordig met persoonlijke gegevens van zijn bezoekers omgaat. Deze knaap heeft dat op een leuke manier aan de kaak gesteld.
Verwijzing naar een draadje waar de meesten hier geen toegang toe hebben lijkt me weinig bijdragen.
Het aantonen dat er SQL injectie plaats kan vinden is nog geen toegang verschaffen tot de systemen. Dan weet je dat je veel verder zou kunnen gaan, maar dat mag niet, hoort niet.

Lekken repareren kan alleen als je kennis hebt van het lek. Lekken opsporen blijkt nogal moeilijk te zijn... Microsoft/Apple/Whatever mega bedrijf lukt het zelfs niet volledig!
SQL injectie werkt volgens 1 enkel principe dat al jaren bekend is.
Duidelijk is ook zo'n beetje voor alle web-ontwikkelaars hoe je je site beschermt tegen SQL injectie. (het is niet zo moeilijk, je moet alleen even alles nalopen).
Aan de andere kant heb ik liever zo iemand die me dan een mail stuurt "zeg je bent lek, dit en dat kun je wel wat beter beveiligen" en dat ik daarmee voorkom dat de volgende die het wel leuk vind om bv de sql database te legen via diezelfde weg binnenkomt. Dat is een veel grotere schade.

[Reactie gewijzigd door Innsewerants op 23 augustus 2009 15:41]

Het probleem is dat wanneer iemand zegt: Goh, je website is lek er vaak tijden lang niets aan gebeurd. Als je een redelijk onschuldig misbruik maakt van het lek zoals deze jongen heeft gedaan door het plaatsen van een berichtje dan heeft dat veel meer impact en zullen ze het sneller oplossen dan dat ze een mailtje van hem krijgen.
Bij een mailtje zullen ze waarschijnlijk denken oh dat is een 14-jarig jochie volgende maand kijken we er wel een keertje naar als we tijd hebben en in die tijd zijn er een hoop anderen die er misbruik van kunnen maken.
-knip-
Daarmee heeft de hacker ook keurig de wetjes tegen computercriminaliteit overtreden...

Ga het nou niet goedpraten, dit is gewoon fout.
-knip-
Als met recht niet uiteindelijk rechtvaardigheid wordt bedoeld maar enkel het naleven van wetten en regels, dan is er geen fundamenteel onderscheid te duiden tussen de staat en een grote roversbende. -Aurelius Augustinus
Van álle wachtwoorden tot 7 karakters zonder gekke tekens, aangevuld met de 50.000 meest voorkomende ingewikkelder wachtwoorden is momenteel de MD5 waarde bekend en zo gratis via verschillende databases te raadplegen. Als je gammele wachtwoord dus ergens in een eenmaal gehackte database staat valt die zo te herleiden naar het oorspronkelijke wachtwoord en kan zo'n hackert zo in je allerlei andere accounts.

Mensen neem eens een fatsoenlijk ingewikkeld wachtwoord, zeker als je admin bent.
Toch knap dat er nog steeds "developers" bestaan die enorm domme fouten maakt. Een simpele salt in combinatie met sha-1 en het probleem was opgelost. Het veranderen van de passwoorden haalt hier niets uit.

Als je geen salt gebruikt en je kan de md5 met passwoord bemachtigen, is het nog maar een kwestie van een google query uit te voeren en je hebt het passwoord.
Je zit al te ver.
De SQL injectie had al niet mogelijk moeten zijn.
Structureel verkeerde manier van queries afhandelen.
(Niet structureel is erger, want dan houdt het in dat er geen generieke databasecode is)
weerom de hacker <> cracker fout

het gebruik van de woorden hacker en hacken door en voor computerinbrekers als misbruik van de term gezien; zij worden crackers of krakers genoemd.
Ach welnee, dat werd 5 jaar geleden door een select groepje zo gebruikt. De tegenwoordige betekenis is veranderd.
Ja en nee. Het verschil (*) bestaat nog steeds en kan juist in technische discussies zoals deze nuttig zijn.

Het is bovendien geen kwestie van een select groepje of geen select groepje, het is helaas een algemeen verschijnsel binnen en buiten de computertechniek dat mensen vaak ongeveer of helemaal niet zeggen wat ze bedoelen, inplaats van precies. Dan moet je vervolgens echt gaan doorvragen om boven water te krijgen waar het nou eigenlijk om ging. Deels zal dit komen door een slechte beheersing van de taal (ook grammaticaal), deels door luiheid of onwetendheid.

(*) Misschien zou je zelfs kunnen verdedigen dat het niet alleen om een crack ging maar dat er bij het vinden van het geexploiteerde gat ook hackwerk te pas kwam. Dat zal per geval verschillen.

[Reactie gewijzigd door mae-t.net op 23 augustus 2009 18:25]

5 jaar? Doe maar iets verder. meer dan 30 ofzo.
En ook niet select hoor.
Vroeger waren hackers gewoon nog goede coders en geen goede of slechte personen.
Allemaal de schuld van de film 'hackers'.
De makers waren sowieso niet goed geinformeerd.
Autisme is iets anders, maar kan wel als symptoom hebben dat je heel star en in vaste straatjes denkt. Op dat laatste aspect doel jij naar mijn idee.

In nauwe straatjes denkend zou je kunnen zeggen: "wet op de computercriminaliteit overtreden, in het gevang ermee", maar als je wat flexibeler denkt ga je al snel de vraag stellen "wat is er nou eigenlijk gebeurd", en dan blijkt het -zeker in de context van een forum waar de nieuwsposters en leden zelf ook niet gewend zijn een blad voor de mond te nemen- erg mee te vallen. Dat het bericht dat de boel te hacken was, niet per aangetekende brief is verzonden maar met een gekraakt account op het forum zelf geplaatst is, kan je dan als dichterlijke vrijheid zien.
En vanuit welke Goddelijke regionen kom jij om anderen te mogen vertellen wat goed en slecht is?
Dat zijn universele normen en waarden.
Het is hetzelfde als bij iemand inbreken met een nagemaakte sleutel en op de muur spuiten: "Gehacked door Henkie" en vervolgens beweren dat je geen kwaad in zin had. Er moet een nieuw slot komen, muur opnieuw gewit, tijd, stress.
Hacken kost geld, nieuwe software, tijd, gemiste inkomsten.
Mee eens, de hacker had ook gewoon een PM kunnen sturen naar de admin waarin hij het lek uitlegt.
Waarom uren van je tijd verspillen om een commerciele website te helpen verbeteren?
Als je niet in dienst bent?
Natuurlijk deed hij het ook voor de lol, en aan een PM valt geen lol te beleven!
Wees blij dat hij het zo doet. Een ander had ook gewoon alles kunnen deleten of stuk maken...

Hoewel het netst natuurlijk is om eerst te waarschuwen en een termijn te geven en daarna pas (bij het niet-oplossen van het probleem) een publiek bericht achter te laten.
Terwijl de politie gewoon briefjes in open auto's legt....
Dat zijn universele normen en waarden.
Die bestaan niet, ze zijn cultureel bepaald. Zo vinden we in Europa een mensenleven zo veel waard dat we de doodstraf hebben afgeschaft, terwijl je in de VS in een aantal staten nog de doodstraf kan krijgen voor moord en je in Islamitische staten, waar de Sharia wordt toegepast, als verkracht meisje gestenigd kan worden, omdat je onreine daden hebt gepleegd.
Van mij geen waardeoordeel inzake wat "beter" is, maar er is niks universeels aan!
Er bestaan volgens mij geen universele waarden en al helemaal geen universele normen. Er zijn alleen normen en waarden die jij universeel vindt.
Wat Merethan zegt en inderdaad; Filosofisch gezien is er geen "goed" en "slecht", alleen "overleving" ;).
Even voor de duidelijkheid, het ging om een bug in de weblog. Een extern product dat op een kleine subsite. De 'grote' onderdelen frontpage en forum zitten prima in elkaar. Het is alleen jammer dat alle subsites bij de userpasswords moeten kunnen.
Dat het om een lek in een extern produkt ging rechtvaardigt niet het feit dat de wachtwoorden van gebruikers in een achterhaald hashalgoritme opgeslagen stonden.
Het is onder developers algemeen bekend dat het MD5 hash-algoritme relatief snel te bruteforcen is en dat er rainbow tables beschikbaar voor zijn en dat er tevens eenvoudig collisions voor te berekenen zijn.

De enige reden die ik kan bedenken dat een dev team zoals die van fok er toe kan besluiten om MD5 te gebruiken is calculatiesnelheid van het algoritme. Maar als dat de reden is geweest, dan nog had men naar SHA1 kunnen overstappen. SHA1 is weliswaar ook achterhaald, maar is slechts licht langzamer dan MD5. Bruteforcen, rainbow tables maken en collisions berekenen voor SHA1 is flink moeilijker/langzamer dan voor MD5.

Echter wanneer ze voldoende serverkracht tot hun beschikking hebben dan is het wellicht verstandiger om over te stappen naar SHA512 of Whirlpool. Voor deze algoritmen zijn nog geen rainbow tables beschikbaar en is het ook nog niet gelukt om er collisions voor te berekenen. Het bruteforcen van zulke algoritmes is ook dermate tijdverslindend dat het niet lonend is.

Aan de draft voor SHA3 wordt momenteel nog gewerkt.

[Reactie gewijzigd door Arcane Apex op 23 augustus 2009 23:52]

Zo extern is de blog natuurlijk ook niet :) Maar bekijk het eens van de andere kant. Waarom draait dat alles binnen een database :)
Omdat de weblog bij de usergegevens moet kunnen komen, zodat users op elke subsite kunnen inloggen zonder aparte inloggegevens daarvoor te moeten hebben, of laatste forumberichten ophalen of wat dan ook.

:P dat ophalen kan ook vanuit een rss feed ofzo, maar just to make a point
We zitten op tweakers.net en maar 1 reactie die het over het salten van de hashes heeft? Ik vind de sql injectie kwalijk, maar dat de wachtwoorden als normale md5's opgeslagen worden is bijna net zo erg. Kun je ze net zo goed als plaintext opslaan met alle rainbow tables etc tegenwoordig.
Dude... wat denk je dan :D ? FOK! is begonnen in 1999 hè. In die tijd werd daar nog helemaal niet over nagedacht en werd er gewoon voor MD5 gekozen. Ik durf te wedden dat Tweakers ook zo begonnen is.

Dan kun je wel zeggen dat het tegenwoordig algemeen bekend is dat je moet salten, maar als je nog met databaseinformatie zit over users die zich 10 jaar geleden hebben geregistreerd, dan moet je dat wel goed kunnen oplossen. Iedereen opnieuw z'n wachtwoord in laten voeren is geen oplossing.
Dat is geen reden om MD5 te blijven gebruiken. Je houdt als IT'er ook het nieuws bij en hoort dat MD5 achterhaald is. Daar ga je dan mee aan de slag. En ja, beveiliging heeft een hoge prioriteit, zeker als het om gebruikersinformatie gaat :)

Dat er nooit wat mee gebeurd is, betekent niet dat je achter de feiten aan moet lopen. Preventief handelen.
MD5 is voor dit soort doelen helemaal niet achterhaald, mits goed gebruikt.
En dat is niet het geval, kaal MD5 is slecht gebruik. Immer.
Als tweakers ook zo begonnen is, is het hier dan wel opgelost? Zo ja, dan zou fok het ook kunnen.
Het salten is een techniek die al heel lang voor die tijd bestond; toen ik met Linux 2.0 kernels werkte werkte dat al zo en die distributies hadden het overgenomen van algemeen gebruik op andere Unix systemen.
Dan kun je wel zeggen dat het tegenwoordig algemeen bekend is dat je moet salten, maar als je nog met databaseinformatie zit over users die zich 10 jaar geleden hebben geregistreerd, dan moet je dat wel goed kunnen oplossen. Iedereen opnieuw z'n wachtwoord in laten voeren is geen oplossing.
Ze hadden bijvoorbeeld de hashes de hashes kunnen laten en die opnieuw hashen met een salt. Heb je een beetje overhead erbij, maar dat zou verwaarloosbaar moeten zijn (hoe vaak wordt die hash gebruikt per sessie??) Beveiliging in orde, geen geklaag over het veranderen van wachtwoorden, enz.
Ze konden zelf de md5jes kraken en er een gezoute hash van maken zonder dat de gebruikers er wijzer over worden.
En hoe wil je dat doen? Gezien er ook collisions zijn (die wel pas optreden bij 6+ karakters, maar mijn pass. is zo lang), het enige wat ze kunnen doen is een md5 hash genereren van de huidige md5 hash + salt, of een sha1 van de huidige md5 hash etc.

[Reactie gewijzigd door RobertMe op 23 augustus 2009 16:09]

Of je voegt een extra colom toe aan je tabel, nieuwwachtwoord bijv. Als nieuwwachtwoord is ingevuld gebruik je die, anders gebruik je oudwachtwoord. En de eerste keer dat er succesvol wordt ingelogt gebruik je het ingegeven wachtwoord om nieuwwachtwoord te vullen, waarna je oudwachtwoord leegt. Merkt ook niemand iets van.
Ik vindt het woord "praktisch" beter staan :Y)
Huidig: MD5(pass)
Beter: MD5( MD5(pass) . $salt)

Simpel, doeltreffend, praktisch, klaar. Kom jij aanzetten met je "zelf de wachtwoorden gaan kraken" :') !
Nog beter: md5($pass . $global_salt . $user_specific_salt);
Ja... maar $pass is niet beschikbaar, want in de database staat alleen MD5($pass).
Je kunt een kolom Salt aanmaken en elke user die obv MD5 correct inlogt die salt verstrekken. Bij zulke users (waar Salt niet leeg is) accepteer je in de toekomst enkel een pass die klopt met Salt.

Alleen users die (bijna) nooit inloggen zullen op die manier nog een MD5 in de db overhouden, en bij die users kun je er bijv. voor kiezen om de MD5 weg te gooien en ze een standaard password toe te mailen dat ze vervolgens zelf kunnen veranderen.

Op die manier hebben de 'normale' gebruikers er geen last van en verdwijnt gevoelige informatie van sporadische gebruikers.
Gooi er dan ook gelijk een sha1 tussendoor ;)
Tja, MD5 is geen encryptie, het is een hash van de password.
Er zijn genoeg methodes te vinden om encryptie toe te passen op passwords die in een SQL table worden opgeslagen.
Tja er zijn allemaal mooie methoden met SHA dit en dat... maar MD5 plus een salt is praktisch onbreekbaar. Rainbow tables zijn ook maar beperkt beschikbaar, tot 12 karakters ofzo.

Ook leuk: hash = MD5 (MD5 (password) + salt).
Dus eerst je password hashen, dan een salt toevoegen en het resultaat nogmaals hashen. :)
Daar zijn de devvers nu ook achter. Te laat, dat wel, maar ze gaan er mee bezig.
Als een hacker er lang genoeg aan zit, is elke site te hacken. Kijk maar naar dat staaltje blackhat werk bij Kevin Mitnick. Of dit nou een "slechte beveiliging" betekent of een goede hacker laat ik in het midden. Het is altijd een heads up verhaal, waarbij beveiligen moeilijker is als het hacken. SQL injection is nou niet echt een bijzonder hoogstaand iets en ook niet echt een nieuw iets. Het is alleen lastig te bestrijden zonder jezelf te beperken in je code.

Motivatie van de hacker? Tof doen door te laten zien dat hij wel door de beveiliging heen komt. Ik vraag me af of die knakker serieus gedacht heeft dat Danny hem zou mailen op dat hotmail adres.

En die DDoS, een trap na? Wel erg toevallig dat ze tegelijk aankomen, die hacker en die DDoS.
SQL injection is nou niet echt een bijzonder hoogstaand iets en ook niet echt een nieuw iets. Het is alleen lastig te bestrijden zonder jezelf te beperken in je code.
8)7 SQL injection is gemakkelijk te voorkomen en dit zonder jezelf te beperken in code...
Die DDoS was vrijdagavond en zaterdagavond ook al even. Lijkt los te staan van de hack.
Kevin Mitnick kwam vooral aan zijn wachtwoorden door social engineering en niet door programmeren/sql injecties/e.d
Hacker is erg jong.
Hij zal waarschijnlijk serieus gedacht hebben dat Danny bij hem aan kwam kloppen, met de woorden, wow, wat geweldig dat je erin bent gekomen, je moet een supergoede hacker zijn, wil je ons svp helpen door ons te leren hoe we dit in het vervolg kunnen voorkomen alsjeblieft?
Bewijst maar weer hoe sterk de gemiddelde beveiliging is in SQL van de communitysites vooral. Opzich niet eens zo erg. Liever FOK gehackt dan GoT (wat weliswaar beter is beveiligd).
Precies, je zou denken dat een website als FOK! zijn zaken beter op orde heeft. Vooral qua SQL injecties wat gewoon niet moeilijk is om te voorkomen.
De weblogsoftware burningCat is gehacked, die wordt gebruikt op onder andere de FOK!weblog. Dat is niet door FOK! zelf ontwikkeld, maar mag door FOK! worden gebruikt.
Kleine aanvulling daarop :). De software is vrij specifiek voor FOK! geconfigureerd om allerlei redenen. Waarschijnlijk hebben tussentijdse server upgrades ervoor gezorgd dat de configuratie (die vrij ad hoc was) niet meer afdoende was. De manier waarop de SQL injection was gedaan, was juist een van de testcases voor implementatie en die is toen succesvol doorstaan.

Waarschijnlijk zijn er bij serverupgrades geen tests gedaan wat het effect was van deze upgrade :).
Ik ben het wel met Jeoh eens.. als er één website goed beveiligd word geacht te zijn, dan Tweakers / FOK wel...
Behalve dan voor de mensen die hetzelfde password hadden voor hun FOK account als voor hun GoT account.
Behalve dan voor de mensen die hetzelfde password hadden voor hun FOK account als voor hun GoT account.
Aangenomen dat de accountnaam of een eventueel zichtbaar e-mail adres hetzelfde is.

Naast de mogelijkheid tot SQL injectie is een ander zwak iets het gebruik van MD5 in hun database voor user credentials. Tenzij salt gebruikt wordt, is het gebruik van MD5 af te raden omdat daarmee bij wachtwoorden (relatief korte strings) het mogelijk is om het eventueel gebruikte wachtwoord erbij te zoeken binnen een korte tijd.

Met behulp van een MD5 en een collision is het mogelijk om op de betreffende site in te loggen. Echter, al heb je het originele wachtwoord, dan kan je bij veel gebruikers bij andere diensten inloggen waarvan zij gebruik maken, omdat daarbij hetzelfde wachtwoord gebruikt wordt.

[Reactie gewijzigd door The Zep Man op 23 augustus 2009 14:57]

Wachtwoorden zuigen sowieso, een certificaat in combinatie met MS Passport ofzo zou veel beter werken.
Zover ik weet beveilig je jouw .NET Passport (tegenwoordig overigens Live ID) ook met een wachtwoord, dus per saldo schiet je daarmee eigenlijk weinig op.
Op Tweakers zitten niet voor niets "tweakers" Voor een door tweakers die vaak ook het nodige van veel computerzaken, systemen, software en beveiliging afweten. Dus ook van ant-hack/crack methodes. Bij FOK schijnt dat niet zo te zijn, getuige de "kraak" :+
Overigens zal die Ddos aanval niet van hetzelfde clubje afgekomen zijn. Dat is toch gewoon om de zaak even goed "plat"te leggen. Dus zal van iemand anders afkomen die wel kwaad in zin had.

[Reactie gewijzigd door Dutchphoto op 23 augustus 2009 16:13]

Weet je het zeker dat GoT beter beveiligd is?

De enige conclusie die ik kan trekken is dat GoT/Tweakers niet recent is gepakt, of dat het niet publiek geworden is (Autoweek heeft het 2 maanden stil weten te houden)
iemand die geen contactgestoorde nerd is, is nog geen halve zool, dat noemen ze normale mensen. :O
Ik denk dat Gamebuster doelde op de gemiddelde Fok! bezoeker. ;)
Is het echt een DDoS of is het gewoon iemand die vanaf 1 PC met slowloris/apachebench aan het pielen is?

In het laatste geval misschien geen gek idee om nginx als proxy server te draaien, dat schijnt een os van een webserver te zijn en is immuun voor slowloris.
Ik denk dat ze het verschil tussen een DDoS (distributed denial of service attack) en een DoS nog wel kennen. Daarnaast is een DoS (in vergelijking met een DDoS) best makkelijk te blokkeren met automatische ban dingen (IP heeft x requests in tijdsperiode y: ban voor z minuten).
Was het maar zo simpel als even een rate limit instellen. Dan zouden mensen die gebruik maken van een proxyserver of een mobiele verbinding dus altijd problemen hebben omdat er teveel requests worden afgevuurd.
Wat hostname denk ik bedoeld is: wanneer er onredelijk veel requests worden gedaan waarvan maar bar weinig (of geen) worden gesloten. Dat is al wat minder probleemvol.
Die ranges zijn denk ik wel duidelijk.. :) Lijkt me niet waarschijnlijk dat je op een mobiele verbinding een hostname krijgt die op een end-user verbinding subdomein ligt.
Reverse proxy doet een hoop goed voor je website.
Kijk maar naar nu.nl, die site flitst.
Is er nog geen oplossing in Apache tegen slowloris ?
Er zijn meerdere oplossingen

Denk aan: kortere time-out instellen (default is 5 minuten), anonieme proxies weigeren, zodat aanvallende computer geïdentificeerd/tijdelijk geblokkeerd kan worden, POST-requests weigeren op alle URL's behalve die vanuit een valide sessie, of gegenereerde URL's, max-clients instellen (default, dacht ik, 1024 in LInux)

Inmiddels is er ervaring met tactieken om slowloris aanvallen te herkennen en te bemoeilijken. Er is veel informatie over dit onderwerp beschikbaar voor sysadmins.
Deze jongeman is gewoon trots op zijn kunnen en wil FOK graag helpen bij het verbeteren van de beveiliging. Iemand die trots is op zijn mogelijkheden wil echter ook een stukje erkenning. Dat doet hij door het te hacken ipv braaf een mailtje sturen. Begrijpelijk...
Begrijpelijk? Wat mij betreft echt niet ... Als hij FOK! écht wilde helpen zou hij het lek eerst gemeld hebben. Maar wat hij nu gedaan heeft is wel heel laag.

Ik hoop echt dat ze hem kunnen pakken.
Hij heeft paar accounts gehacked waaronder die van Danny.
Dat is al voorbij een grens, verder is er een ddos aanval.
Toeval?
Als de hacker niets met de ddos te maken heeft dan heeft ie veel moeten F5'en om resultaat van zijn hack te zien.
spitsnieuws is ook plaat en op de website genoemd van iemand eerder heb ik dit lijstje kunnen vinden:

Geenstijl
Spitsnieuws
Website van de TROS
Website van TMF
telegraaf.nl
Website van BNN


Als straks TROS, TMF, Telegraaf en BNN ook plat zijn dan is het idd iemand van 4chan :P
Spitsnieuws ging gelijk met GS down.. Denk niet dat die gast op 4chan is, dan ben je wel heel erg stom :')
spitsnieuws is dan ook gewoon geenstijl met een spitslogo erboven. oftewel de telegraaf met een geenstijl/spitslogo erboven :)
Spitsnieuws en GS hebben dezelfde server of iets in die zin...
Ik vraag me ook werkelijk af wat de kennis en kunde is van de FOK crew. als je op hun site leest wat Danny schrijft.

Het zou via een sql injectie niet mogelijk moeten zijn om user informatie te bemachtigen... hoog uit wat bericht info e.d.
Via SQL-injectie kan je in de database, dus dan kan je ook echt bij de user informatie... Hoe wil je dat beveiligen?

Beter kan je het gewoon voorkomen dat er een SQL-injectie in zit.
Inderdaad, zoals je zelf al aangeeft: zorgen dat SQL injectie onmogelijk is. Elke iet of wat webdevver weet dat, nam ik aan. Ik begin er steeds meer aan te twijfelen.
Ze weten het meestal wel, maar zijn gewoon te lui om of vergeten een quote functie om hun input heen te doen. 99,9% van de queries gaat het goed, maar net eentje vergeten ze het. En precies bij die word je afgestraft.

Er zullen vast ook wel manieren zijn om die ene net af te vangen en alsnog te fixen voordat het in productie gaat (automatisch tests op dit soort dingen bijv.), maar die zijn bij Fok! kennelijk niet (goed genoeg) toegepast.

[Reactie gewijzigd door hostname op 23 augustus 2009 15:18]

Het feit dat men door middel van SQL injecties data kan ophalen geeft aan dat men geen kaas gegeten heeft van databases. Normaliter test je eerst de input van een user field, en als tweede gebruik je waar mogelijk is Stored Procedures.

Quotes, dubbel quotes het maakt niet uit, die dienen gewoon gefilterd te zijn, etc. Simpelweg een blunder als je het mij vraagt, een developer leert dit als basis, en iedere developer die met databases te maken heeft weet wat een SQL injection is.
1 2 3 ... 11

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True