Hacker bemachtigt inloggegevens Heroes of Newerth
Een hacker heeft via sql-injectie gebruikersnamen en wachtwoorden weten te bemachtigen van de gratis speelbare moba-game Heroes of Newerth. De game is offline gehaald en spelers wordt geadviseerd om hun wachtwoord te wijzigen als ze dat ook voor andere accounts gebruiken.
Een hacker die schuilgaat achter de nick Ryan_HTP heeft via sql-injectie toegang gekregen tot de database van S2 Games, de uitbater van Heroes of Newerth. De hacker wist de database te downloaden met gebruikersnamen en wachtwoorden van spelers van de de gratis speelbare moba-game. De database was beveiligd, maar de inbreker wist die eenvoudig te omzeilen. Hij heeft S2 van de hack op de hoogte gesteld, waarop het Amerikaanse bedrijf de servers van de game offline haalde.
Ryan_HTP stelt dat hij de kwetsbaarheden van het systeem openbaar zal maken, maar zal dat pas doen als S2 de gaten in de beveiliging gedicht heeft. S2 Games raadt spelers ondertussen aan om het wachtwoord van hun HoN-account nog niet te wijzigen. De ontwikkelaar raadt spelers echter wel aan om het wachtwoord van andere accounts te wijzigen als dat hetzelfde was als van hun HoN-account. Ryan_HTP maakt bij zijn inbraak gebruik van een bekende methode. Er worden de laatste jaren veel accountgegevens gestolen via sql-injectie, een methode die erg eenvoudig uit te voeren is. Zo werden eerder dit jaar accountgegevens buitgemaakt van Adobe, Yahoo en Bol.com.
Reacties (25)
Natuurlijke kwalijk dat het gebeurd,
waren de wachtwoorden gehashed, salted?
waren de wachtwoorden gehashed, salted?
Ik denk het niet, kreeg vanochtend ineens dat iemand op mijn steam wou inloggen.
De wachtwoorden hadden elk een korte en unieke salt welke de hacker ook heeft weten te bemachtigen en waren gehashed met MD5. Door gebruik te maken van een nieuw gegenereerde rainbow table is het dan niet moeilijk om simpele wachtwoorden weer terug te zetten naar de originele tekst (het is al jaren bekent dat MD5 niet meer veilig is).
De hacker bood de logingegevens van accounts aan voor $35. Door eerst zelf in te loggen op een aantal accounts van streamers heeft hij deze dienst geadverteerd en is de lek naar buiten gekomen. De hacker is zelf vol bezig geweest met een misbruiken van de gegevens die hij heeft bemachtigd en hij is dus zeker niet behulpzaam geweest voor S2 Games.
De hacker bood de logingegevens van accounts aan voor $35. Door eerst zelf in te loggen op een aantal accounts van streamers heeft hij deze dienst geadverteerd en is de lek naar buiten gekomen. De hacker is zelf vol bezig geweest met een misbruiken van de gegevens die hij heeft bemachtigd en hij is dus zeker niet behulpzaam geweest voor S2 Games.
[Reactie gewijzigd door Zerotorescue op dinsdag 18 december 2012 16:13]
Toch belachelijk dat er nog zo veel websites/systemen zijn waar men zich niet heeft beveiligd tegen SQL-injectie. Het is niet alsof dat een moeilijke beveiliging is.
En dan zijn er ook schrikbarend veel databases waar wachtwoorden er als plaintext in staan, vraag me af of dat hier ook het geval is.
En dan zijn er ook schrikbarend veel databases waar wachtwoorden er als plaintext in staan, vraag me af of dat hier ook het geval is.
Nee, er stond encriptie op de wachtwoorden, maar de salt die S2 gebruikte was erg kort, als we Ryan_HTP moeten geloven. Zo kort, dat hij makkelijk te raden was.
Goed bezig, dit kan ik wel waarderen. Hacken, op de hoogte stellen maar vervolgens wel je methode uit de doeken te doen. Hier kunnen we met elkaar van leren + schade is minimaal.
Toch blijf ik mij verbazen over de hoeveelheid SQL-injecties die er nog altijd gedaan worden. Als ontwikkelaar heb ik op school er nooit echt wat over gehoord. Ik heb zowel MBO als HBO gedaan, waarin de definitie genoemd is van SQL injectie, een basis principe wordt uitgelegd en daar houdt het bij op. Naar mijn mening heeft de overheid/onderwijs nog een boel te verbeteren. Zolang ontwikkelaars/webdesigners/al het ander programmeer gespuis niet een idee kunnen vormen over beveilgingsproblemen en er zelf geen ervaring mee op doen, zal dit een groot probleem blijven. Ik denk dat als het onderwijs studenten zou leren hacken, met ethische achtergrond kunnen we dit soort problemen meer tackelen en voorkomen, blijft men waakzaam op beveiliging en leren we gezamelijk over normen en waarden...
Toch blijf ik mij verbazen over de hoeveelheid SQL-injecties die er nog altijd gedaan worden. Als ontwikkelaar heb ik op school er nooit echt wat over gehoord. Ik heb zowel MBO als HBO gedaan, waarin de definitie genoemd is van SQL injectie, een basis principe wordt uitgelegd en daar houdt het bij op. Naar mijn mening heeft de overheid/onderwijs nog een boel te verbeteren. Zolang ontwikkelaars/webdesigners/al het ander programmeer gespuis niet een idee kunnen vormen over beveilgingsproblemen en er zelf geen ervaring mee op doen, zal dit een groot probleem blijven. Ik denk dat als het onderwijs studenten zou leren hacken, met ethische achtergrond kunnen we dit soort problemen meer tackelen en voorkomen, blijft men waakzaam op beveiliging en leren we gezamelijk over normen en waarden...
SQL injectie is al decennia de meest gebruikte kwetsbaarheid op websites. Veel ontwikkelaars vergeten om de termen die gebruikers in hun queries invoeren goed te cleansen, zodat als iemand bijv. als gebuikersnaam Ryan_HTP'; DROP TABLE invoert, de hele database verdwijnt. Het is heel makkelijk te doen, en ook heel makkelijk op te lossen, door gewoon alle apostrofjes of puntkomma's uit de queries te halen. Helaas wordt dat soms gewoon niet gedaan, en dan ben je al kwetsbaar. Omdat zoveel web-toegankelijke services/websites/games met een achterliggende SQL-database werken, kome deze injecties behoorlijk vaak voor.
Dat ethisch hacken zou ik me, zelfs als we het onderwezen zouden krijgen, niet aan wagen. Ik wil eerst duidelijke wetgeving zien die vaststelt dat ik niet opgepakt wordt als ik geen schade aanricht, en ook niet aan de USA wordt uitgeleverd als daar iets gebeurt.
Dat ethisch hacken zou ik me, zelfs als we het onderwezen zouden krijgen, niet aan wagen. Ik wil eerst duidelijke wetgeving zien die vaststelt dat ik niet opgepakt wordt als ik geen schade aanricht, en ook niet aan de USA wordt uitgeleverd als daar iets gebeurt.
met een 'drop table' verdwijnt een tabel, niet een database.
En met het gebruik van ORM-en sterft goed db/sql gebruik uit.
En met het gebruik van ORM-en sterft goed db/sql gebruik uit.
Ik moet eerlijk zeggen dat jouw oplossing wel echt dramatisch is.
Wat doe je dan met plaatsnamen als 's-Hertogenbosch?
Tekens uit je query filteren is geen oplossing, in het beste geval sla je dan onvolledige gegevens op. En in het slechtste geval is er nog steeds een injectie mogelijk.
Wat je moet doe nis prepared statements gebruiken en de functies die in in een taal zitten ingebakken op queries te escapen.
Filteren wat er de database in gaat is nooit handig, wat je wilt altijd de rauwe data behouden!
Wat doe je dan met plaatsnamen als 's-Hertogenbosch?
Tekens uit je query filteren is geen oplossing, in het beste geval sla je dan onvolledige gegevens op. En in het slechtste geval is er nog steeds een injectie mogelijk.
Wat je moet doe nis prepared statements gebruiken en de functies die in in een taal zitten ingebakken op queries te escapen.
Filteren wat er de database in gaat is nooit handig, wat je wilt altijd de rauwe data behouden!
Inderdaad je wilt rauwe data behouden, maar dat kan natuurlijk nooit. Dat betekent dat je "executable" code in de database kan kloppen welke bij uitvoer direct kan worden uitgevoerd. (teminste als je praat over rauwe data)
Wat ik hoop dat je bedoelt is dat idd niet tekens etc gaat verwijderen maar escapen / encoden van je data. Voor het de database in gaat moet het encode worden welke bij ophalen kan worden gedecode. Het strippen van tags <script> etc moet je ook niet in de database willen hebben staan.
Wat ik hoop dat je bedoelt is dat idd niet tekens etc gaat verwijderen maar escapen / encoden van je data. Voor het de database in gaat moet het encode worden welke bij ophalen kan worden gedecode. Het strippen van tags <script> etc moet je ook niet in de database willen hebben staan.
Je kunt het beste prepared statements gebruiken. Dan heb je geen last van sql injecties en hoef je niet te klooien met escapen van je data. Dit gaat eenvoudig met PDO of mysqli functies (in PHP).
Als je vervolgens ook zorgt dat alle data die je weer op je website gaat weergeven voorziet van htmlspecialchars, ben je ook nog eens veilig voor XSS.
Als je vervolgens ook zorgt dat alle data die je weer op je website gaat weergeven voorziet van htmlspecialchars, ben je ook nog eens veilig voor XSS.
Dit is al de derde site dit jaar die gehackt is waar ik ben aangesloten. Word hier echt schijtziek van. Ben blij dat ik een oud wachtwoord nog op HoN had. Deze zwerft toch al rond op het web.
Wel goed dat hij eerst S2 op de hoogte brengt voordat hij alles het web op slingert.
Wel goed dat hij eerst S2 op de hoogte brengt voordat hij alles het web op slingert.
[Reactie gewijzigd door Renzzie op dinsdag 18 december 2012 11:12]
Ik speel zo af en toe HoN en heb dit nieuws een beetje gevolgd de afgelopen dagen.
Hij heeft S2 niet zozeer op de hoogte gebracht, hij heeft de aandacht gevraagd door de inlog gegevens van een paar grote namen binnen het spel openbaar te maken. Daarnaast verkocht hij voor 35$ per account de inlog gegevens.
Hij heeft S2 niet zozeer op de hoogte gebracht, hij heeft de aandacht gevraagd door de inlog gegevens van een paar grote namen binnen het spel openbaar te maken. Daarnaast verkocht hij voor 35$ per account de inlog gegevens.
Als dat echt zo is mogen ze van mij dit soort mensen zo het gevang in slingeren. Als je doet alsof je het voor het testen van de beveiliging doet en het bedrijf dan op de hoogte stellen zodat ze dit kunnen verbeteren is het prima. Maar dan moet je die gegevens niet op internet zetten of verkopen, daar heb je alleen de gebruikers mee en die kunnen daar niks aan doen.
"Veel ontwikkelaars vergeten om de termen die gebruikers in hun queries invoeren goed te cleansen, zodat als iemand bijv. als gebuikersnaam Ryan_HTP'; DROP TABLE invoert, de hele database verdwijnt. Het is heel makkelijk te doen, en ook heel makkelijk op te lossen, door gewoon alle apostrofjes of puntkomma's uit de queries te halen"
Ik kan mij niet voorstellen dat yahoo , bol.com en andere zich hier niet tegen beveiligen.. dit leer je toch op elke ict opleiding...
Kan iemand hier uitleg over geven?
Ik kan mij niet voorstellen dat yahoo , bol.com en andere zich hier niet tegen beveiligen.. dit leer je toch op elke ict opleiding...
Kan iemand hier uitleg over geven?
Het probleem is vaak dat input-sanering niet hoog op de prioriteit staat bij de ontwikkeling en implementatie van een database, en dat de verantwoordelijkheid bij verschillende mensen kan worden doorgeschoven. Dus kan het best gebeuren dat dit over het hoofd word gezien. Dat het echter bij dergelijke grote bedrijven gebeurt, is wel vrij triest.
Je verwachtingen van ict opleidingen zijn op dat gebied duidelijk te hoog. Ik heb zelf niet zo lang geleden mijn hbo informatica (software engineering) afgerond en SQL injectie is alleen zijdelings ter sprake gekomen tijdens een vrijblijvend hoorcollege over testen. De focus ligt maar voor een beperkt deel op programmeren waardoor je op dat gebied niet veel verder komt dan de basics.dit leer je toch op elke ict opleiding... Kan iemand hier uitleg over geven?
Er worden wel regelmatig aanpassingen doorgevoerd in het lesprogramma maar er gaan meestal toch wel een aantal jaar voorbij tussen het moment dat iets voor wordt gesteld en daadwerkelijk toe wordt gevoegd aan de opleiding. Daarnaast zijn er allerlei partijen die voorkeuren hebben en met name het bedrijfsleven is er daar 1 van. Die geven de voorkeur aan zaken als professionele vaardigheden, teamgericht werken, itil, project management technieken etc. Vergeet tevens niet dat een aanzienlijk deel van de ontwikkelaars een lagere opleiding danwel geen relevante opleiding heeft of lang geleden zijn opleiding af heeft afgerond.
Ietsjes meer on topic: Er zijn ook meer geavanceerde vormen van SQL injectie zoals blind SQL injection. Daarnaast moet je alle data die van een 'onbetrouwbare' bron komt escapen voordat die in een SQL statement gebruikt wordt. Met name in het geval van URL parameters wordt nog wel eens vergeten dat die gemakkelijk door de gebruiker te manipuleren zijn. Zelfs als je dus wel maatregelen neemt om SQL injectie te voorkomen is het nog steeds mogelijk dat je iets over het hoofd hebt gezien.
Overigens mag je dan wel van een (voldoende ervaren) programmeur verwachten dat deze SQL injectie voorkomt maar om de kwaliteit te waarborgen zal je dat ook moeten controleren. Dat kan bijvoorbeeld door codereviews of door (black box) security tests. Als het fout gaat kan je als organisatie tenslotte ook de programmeur niet verantwoordelijk houden voor de schade maar zal de organisatie de gevolgen moeten dragen.
Dus hij is eigenlijk gewoon een goed persoon die laat weten dat hun beveiliging lek is.
Een doorsnee webdeveloper weet hoe hij SQL-injectie kan voorkomen (bvb via PDO http://www.php.net/manual/en/book.pdo.php).
Dan vraag ik me af hoe al die grote bedrijven toch genaaid worden met een ongeveer de eenvoudigste hack die er is.
Also: Use a framework!
Dan vraag ik me af hoe al die grote bedrijven toch genaaid worden met een ongeveer de eenvoudigste hack die er is.
Also: Use a framework!
Ik vermoed dat er ook nooit een echte web developer (dus met verstand van zaken die weet wat hij doet) aan te pas is gekomen. We hebben al programmeurs, dus waarom zouden we nog een programmeur inhuren? Omdat iemand die net aan C# kan waarschijnlijk geen idee heeft hoe je een veilig web interface bouwt. De maker van de loonstrookjes heeft wat te veel recht in eigen hand genomen en wat te weinig bij de professionals om advies heeft gevraagd. Als het werkt is het wel goed, soort van denken.
Ik heb bovendien het idee dat Amerikanen een erg sterke passieve drang hebben als het op beveiliging aan komt. Als iemand een misdaad pleegt, dan pakken we die wel even hardhandig aan. Dat is een belangrijk deel van de beveiliging. Helaas maakt dat actief iets aan je beveiliging doen niet overbodig. Men probeert problemen te weinig te voorkomen. Als er iets gebeurt lossen we dat dan wel op. Hetzelfde bij de schietpartij die er laatst was, waarbij 27 of zo mensen omkwamen. Rustig wapens legaliseren, en vervolgens je verbazen als zo nu en dan een gek een aantal mensen neer knalt. Er leven daar gekken die dat doen, en ze krijgen vrijelijk vuurwapens. Tot zover het spreekwoord "Don't give a monkey a gun"... Maar in dat soort gevallen is achteraf reageren gewoon te laat. Het zou geld en levens kunnen schelen als ze maar wat actiever waren.
Ik heb bovendien het idee dat Amerikanen een erg sterke passieve drang hebben als het op beveiliging aan komt. Als iemand een misdaad pleegt, dan pakken we die wel even hardhandig aan. Dat is een belangrijk deel van de beveiliging. Helaas maakt dat actief iets aan je beveiliging doen niet overbodig. Men probeert problemen te weinig te voorkomen. Als er iets gebeurt lossen we dat dan wel op. Hetzelfde bij de schietpartij die er laatst was, waarbij 27 of zo mensen omkwamen. Rustig wapens legaliseren, en vervolgens je verbazen als zo nu en dan een gek een aantal mensen neer knalt. Er leven daar gekken die dat doen, en ze krijgen vrijelijk vuurwapens. Tot zover het spreekwoord "Don't give a monkey a gun"... Maar in dat soort gevallen is achteraf reageren gewoon te laat. Het zou geld en levens kunnen schelen als ze maar wat actiever waren.
[Reactie gewijzigd door Amanoo op dinsdag 18 december 2012 13:02]
Jammer genoeg gebeurt dit al te vaak. Ik werkte in het verleden ook voor firma's, waar je doel was: CODE SCHRIJVEN. Men sprak niet van goede code schrijven, nee, men sprak van opleveren van code, om zoveel mogelijk inkomsten te hebben. Gevolg was, SQL injectie ... zo simpel als hel. Databank Data corruptie ( data dat niet correct weggeschreven was, of incorrect weggeschreven enz ) wegens geen beveilig op dat query transacties, enz enz.
Ik kan er een boek over schrijven. Wat ik ook gedaan had, om de management in een poging van "idealisme" hun proberen te laten inzien dat het bedrijf ging ondergaan als ze zo verder deden. 4 Jaar later ... Was al lang weg toen ( idem met alle andere deftige programmeurs ).
Het blijft verbazen dat SQL Injecties mogelijk blijven heden dagen. Er zijn genoeg tools om dit te verhinderen. En een beetje programmeur schrijft zijn eigen wrapper functie, als dat niet aanwezig is. Maar als de bedrijfscultuur gefocust is op productie, en niet kwaliteit. Of Managers dat hun gaan moeien met de coderen.
Vaak word er te veel geschoten op de programmeurs, terwijl die vaak aan handen & voeten gebonden zijn.
Off-topic:
En nu we spreken over "schieten". Wat er in de VS gebeurt is, is jammer ( ik antwoord hierop omdat het voorkomt in je post ). MAAR! Zoals altijd, word weeral een meerderheid veroordeeld, voor de daden van een absolute minderheid. Zowat iedere burger in de VS heeft een vuurwapen ( toch met het aantal op de markt ). En zijn van deze schiet partijen, uitzonderingen dat om de x jaar voorkomen.
Jammer genoeg is het bestraffen van de legale wapenbezitters, niet de oplossing. Veel van die wapen bezitters, doen correcte hun handelingen. Wapen & Ammo niet samen. Vergunningen in orde. Wapens in Kluis. Enz... Maar dat verhinderd niet als iemand ter huizes aan de wapens kan, en deze dan misbruikt.
Hier in Europa, hoor je ook de mensen zot doen, nadat er iets gebeurt. Over reageren... Waarom hebben ze messen bezit niet strenger gemaakt / verboden, toen er een zot weerloze kinderen neerstak in België. Maar toen een andere zot een jachtgeweer gebruikte op een oppasster & kleine, toen ineens gingen ze de wapenwet strenger maken.
Dubbele standaard ...
Nu wordt weeral iedereen dat een beetje pc-gamer is, en niet erg sociaal veroordeeld voor de daden van één persoon. Zeker als je mensen ziet schrijven als: "De persoon dat boven ons woont is ook zoals dat, moeten we nu schrik hebben van die persoon". *uch*
------------------
Het probleem met heel wat van de Frameworks is, dat je even veilig bent als NIETS! Je kent de code niet, je weet niets af van de kern structuur ( als je er niet dagelijks in werkt, ga je ook niet weten hoe de code "communiceert" met elkaar ).
Gevolg is, dat je jezelf soms nog meer open stelt naar potentieel bugs, dan met een eigen project, en soms simpele beveilig praktijken. Vergeet ook niet, dat Framework up to date gehouden dienen te worden. Ik beheerde de servers van een bepaalde staat organisatie, waar men websites kon opzetten van "locale" afdelingen. Ik ga niet zeggen wie of wat, maar laat me stellen, de ROMMEL dat mensen op de webhosting smeten. Verouderde frameworks, code dat amateur toestanden was al wat. En ondanks dat we de servers up to date hielden, kregen we regelmatig mails / tel binnen van websites dat "ineens" niet meer werkte. Tot op het punt toen de mensen dat zich bezig hielden met de servers, opgestapt waren, daarna ging de server regelmatig plat. Men update de servers niet meer, gevolg => inbraken dat op lagere ring niveau kwamen ( via de "frameworks" ).
Tijd geleden was er weeral een inbraak hier gereporteerd, met een verouderde dotNuke Framework. Dat ding had bugs van het ontstaan ( ik kende het toen het eerste op de markt kwam ). En te bedenken dat mensen het nog gebruikte nu!
Een framework is goed om in team te kunnen werken, maar al te vaak worden bedrijven verleid door framework x, y, z, en het eind resultaat is vaak dat eenmaal men te veel gecodeerd heeft in dat framework, dat men erin vast zit. De ontwikkelaars zetten de ontwikkeling van de framework op een laag pitje, en voor je het weet, heb je geen support meer op dat framework. Of je moet "upgraden" naar versie 2.0, 3.0 ... met soms 1000de regels code dat moeten herschreven worden, en zo nieuw bugs introduceren.
Bedrijven zijn soms beter af hun eigen systemen te ontwikkelen, en deftig van de grond op. Maar ja ... kost tijd he. Tijd = Geld = ... En dan als de problemen later komen, wegens de shortcuts, dat men nam, dan legt men gewoon de schuld bij de programmeurs. Zal wel hun schuld geweest zijn.
Beveilig begint bij de eerste stappen van de ontwikkeling van een applicatie. En buiten huis vlug vlug een basis gaan halen voor je toekomstige projecten, is jammer genoeg voordeliger, maar vaak ook nefast voor de toekomst.
Ik kan er een boek over schrijven. Wat ik ook gedaan had, om de management in een poging van "idealisme" hun proberen te laten inzien dat het bedrijf ging ondergaan als ze zo verder deden. 4 Jaar later ... Was al lang weg toen ( idem met alle andere deftige programmeurs ).
Het blijft verbazen dat SQL Injecties mogelijk blijven heden dagen. Er zijn genoeg tools om dit te verhinderen. En een beetje programmeur schrijft zijn eigen wrapper functie, als dat niet aanwezig is. Maar als de bedrijfscultuur gefocust is op productie, en niet kwaliteit. Of Managers dat hun gaan moeien met de coderen.
Vaak word er te veel geschoten op de programmeurs, terwijl die vaak aan handen & voeten gebonden zijn.
Off-topic:
En nu we spreken over "schieten". Wat er in de VS gebeurt is, is jammer ( ik antwoord hierop omdat het voorkomt in je post ). MAAR! Zoals altijd, word weeral een meerderheid veroordeeld, voor de daden van een absolute minderheid. Zowat iedere burger in de VS heeft een vuurwapen ( toch met het aantal op de markt ). En zijn van deze schiet partijen, uitzonderingen dat om de x jaar voorkomen.
Jammer genoeg is het bestraffen van de legale wapenbezitters, niet de oplossing. Veel van die wapen bezitters, doen correcte hun handelingen. Wapen & Ammo niet samen. Vergunningen in orde. Wapens in Kluis. Enz... Maar dat verhinderd niet als iemand ter huizes aan de wapens kan, en deze dan misbruikt.
Hier in Europa, hoor je ook de mensen zot doen, nadat er iets gebeurt. Over reageren... Waarom hebben ze messen bezit niet strenger gemaakt / verboden, toen er een zot weerloze kinderen neerstak in België. Maar toen een andere zot een jachtgeweer gebruikte op een oppasster & kleine, toen ineens gingen ze de wapenwet strenger maken.
Dubbele standaard ...
Nu wordt weeral iedereen dat een beetje pc-gamer is, en niet erg sociaal veroordeeld voor de daden van één persoon. Zeker als je mensen ziet schrijven als: "De persoon dat boven ons woont is ook zoals dat, moeten we nu schrik hebben van die persoon". *uch*
------------------
Het probleem met heel wat van de Frameworks is, dat je even veilig bent als NIETS! Je kent de code niet, je weet niets af van de kern structuur ( als je er niet dagelijks in werkt, ga je ook niet weten hoe de code "communiceert" met elkaar ).
Gevolg is, dat je jezelf soms nog meer open stelt naar potentieel bugs, dan met een eigen project, en soms simpele beveilig praktijken. Vergeet ook niet, dat Framework up to date gehouden dienen te worden. Ik beheerde de servers van een bepaalde staat organisatie, waar men websites kon opzetten van "locale" afdelingen. Ik ga niet zeggen wie of wat, maar laat me stellen, de ROMMEL dat mensen op de webhosting smeten. Verouderde frameworks, code dat amateur toestanden was al wat. En ondanks dat we de servers up to date hielden, kregen we regelmatig mails / tel binnen van websites dat "ineens" niet meer werkte. Tot op het punt toen de mensen dat zich bezig hielden met de servers, opgestapt waren, daarna ging de server regelmatig plat. Men update de servers niet meer, gevolg => inbraken dat op lagere ring niveau kwamen ( via de "frameworks" ).
Tijd geleden was er weeral een inbraak hier gereporteerd, met een verouderde dotNuke Framework. Dat ding had bugs van het ontstaan ( ik kende het toen het eerste op de markt kwam ). En te bedenken dat mensen het nog gebruikte nu!
Een framework is goed om in team te kunnen werken, maar al te vaak worden bedrijven verleid door framework x, y, z, en het eind resultaat is vaak dat eenmaal men te veel gecodeerd heeft in dat framework, dat men erin vast zit. De ontwikkelaars zetten de ontwikkeling van de framework op een laag pitje, en voor je het weet, heb je geen support meer op dat framework. Of je moet "upgraden" naar versie 2.0, 3.0 ... met soms 1000de regels code dat moeten herschreven worden, en zo nieuw bugs introduceren.
Bedrijven zijn soms beter af hun eigen systemen te ontwikkelen, en deftig van de grond op. Maar ja ... kost tijd he. Tijd = Geld = ... En dan als de problemen later komen, wegens de shortcuts, dat men nam, dan legt men gewoon de schuld bij de programmeurs. Zal wel hun schuld geweest zijn.
Beveilig begint bij de eerste stappen van de ontwikkeling van een applicatie. En buiten huis vlug vlug een basis gaan halen voor je toekomstige projecten, is jammer genoeg voordeliger, maar vaak ook nefast voor de toekomst.
Ik moet zeggen dat hoewel jouw verhaal prima met mijn verwachtingen klopt, ik alsnog wel behoorlijk van schrik van zulke laksheid. Van mij mogen er wetten en boetes komen tegen dergelijk gedrag. Het zet de privacy van burgers behoorlijk op het spel.
offtopic:
Ik vind wel dat het bij schietwapens anders ligt dan bij messen. Messen zijn wat lastiger te verbieden, je gebruikt ze niet alleen om levende wezens mee neer te steken, maar ook om je eten te bereiden, of op de bouw. Vuurwapens hebben weinig ander doel dan verwonden en doden. Tja, ik zou ook wel graag alle misdrijven die met een mes gebeuren zien verdrijven, maar ik ben zelf niet in staat om te zien hoe je daar voor kan zorgen zonder normale burgers zwaar te beperken in het dagelijks leven. Een vuurwapen is wat minder "dagelijks leven" dan een mes. Verder denk ik wel dat ik liever tegenover een gek met een mes sta, dan een gek met een pistool. Lijkt me makkelijker om van weg te rennen.
Ik vind wel dat het bij schietwapens anders ligt dan bij messen. Messen zijn wat lastiger te verbieden, je gebruikt ze niet alleen om levende wezens mee neer te steken, maar ook om je eten te bereiden, of op de bouw. Vuurwapens hebben weinig ander doel dan verwonden en doden. Tja, ik zou ook wel graag alle misdrijven die met een mes gebeuren zien verdrijven, maar ik ben zelf niet in staat om te zien hoe je daar voor kan zorgen zonder normale burgers zwaar te beperken in het dagelijks leven. Een vuurwapen is wat minder "dagelijks leven" dan een mes. Verder denk ik wel dat ik liever tegenover een gek met een mes sta, dan een gek met een pistool. Lijkt me makkelijker om van weg te rennen.
Dus als je een framework gebruikt ben je veilig?
Beetje raar dat we toch nog af en toe een bericht krijgen als weer een framework een fout bevatte.
En het leuke van een framework, is dat wanneer de website live is. En 4 updates verder van de framework er een grote fout wordt gevonden, en het framework is op de schop gegaan. Je alles kan gaan aanpassen.
Frameworks hebben hun voordelen, maar ik zou beveiliging niet als een pluspunt beschouwen. Ik zou dat maar lekker zelf afhandelen.
Beetje raar dat we toch nog af en toe een bericht krijgen als weer een framework een fout bevatte.
En het leuke van een framework, is dat wanneer de website live is. En 4 updates verder van de framework er een grote fout wordt gevonden, en het framework is op de schop gegaan. Je alles kan gaan aanpassen.
Frameworks hebben hun voordelen, maar ik zou beveiliging niet als een pluspunt beschouwen. Ik zou dat maar lekker zelf afhandelen.
[Reactie gewijzigd door TrisBe op dinsdag 18 december 2012 12:59]
Je hebt natuurlijk frameworks en je hebt "frameworks".
Neem nu Drupal bijvoorbeeld: een content management framework waarvan het databankgebeuren een schil is bovenop PDO. Als je je netjes aan de gedocumenteerde standaarden houdt, kan je gewoonweg geen SQL-injectie tegenkrijgen.
Niets houdt een slecht programmeur echter tegen de databank alsnog foutief te querien. Machinegeweren hebben ook een ingebouwde veiligheid, dat wil daarom niet zeggen dat je er eender wie mee laat omgaan... Hetzelfde geldt voor databanken.
Neem nu Drupal bijvoorbeeld: een content management framework waarvan het databankgebeuren een schil is bovenop PDO. Als je je netjes aan de gedocumenteerde standaarden houdt, kan je gewoonweg geen SQL-injectie tegenkrijgen.
Niets houdt een slecht programmeur echter tegen de databank alsnog foutief te querien. Machinegeweren hebben ook een ingebouwde veiligheid, dat wil daarom niet zeggen dat je er eender wie mee laat omgaan... Hetzelfde geldt voor databanken.
De laatste keer dat ik een mooi fout vond was dat toch echt door een webdeveloper die zijn eigen systeem in een ASP CMS had gebouwd. Hierin zat een SQL injectie, en later bleek zelfs de admin wachtwoorden plaintext te zijn omdat meneer de webdeveloper de rode waarschuwingsbericht gewoonweg had genegeerd waarin stond dat een benodigde plugin niet was geïnstalleerd, die voor de encryptie zorgde.
Dit zal waarschijnlijk niet de enige zijn, en het probleem is heel simpel: een leek word ingehuurd om iets te maken, googled even naar opties, installeert wat stuff en gaat wat in elkaar zetten zodat z'n baas blij is en gaat vrolijk weg, terwijl een volgende persoon word ingehuurd omdat het systeem niet meer werkt/problemen geeft/meer opties nodig heeft en kan 1.) stuiten op de fouten en dit fixen en daarna nog z'n ding implementeren of 2.) bouwt er weer z'n eigen schil omheen om de baas tevreden te houden door de lage kosten.
Wat soms ook het geval is, is dat een intern iemand simpelweg word aangewezen voor projecten die hij of zij op dat moment niet kunnen maken, en doen een spoedcursus PHP/ASP en MySQL/MSSQL om het project toch af te kunnen maken...
Dit zal waarschijnlijk niet de enige zijn, en het probleem is heel simpel: een leek word ingehuurd om iets te maken, googled even naar opties, installeert wat stuff en gaat wat in elkaar zetten zodat z'n baas blij is en gaat vrolijk weg, terwijl een volgende persoon word ingehuurd omdat het systeem niet meer werkt/problemen geeft/meer opties nodig heeft en kan 1.) stuiten op de fouten en dit fixen en daarna nog z'n ding implementeren of 2.) bouwt er weer z'n eigen schil omheen om de baas tevreden te houden door de lage kosten.
Wat soms ook het geval is, is dat een intern iemand simpelweg word aangewezen voor projecten die hij of zij op dat moment niet kunnen maken, en doen een spoedcursus PHP/ASP en MySQL/MSSQL om het project toch af te kunnen maken...
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
