'Ajax is handig voor hackers'

Ajax blijkt niet alleen populair bij websites zoals Google Maps en MySpace.com, maar wordt ook steeds vaker misbruikt door hackers. Tijdens de Black Hat beveiligingsconferentie trokken presentaties over het gebruik van Ajax volle zalen. De eerste keer dat een Ajax-aanval veel aandacht kreeg, was afgelopen oktober toen een jeugdig lid van MySpace een Ajax-gebaseerde worm schreef, waarmee leden aan de vriendenlijst van de hacker werden toegevoegd. Hij wilde zich hiermee populairder laten lijken, maar het resultaat was dat MySpace een dag gesloten moest worden. Recentere gevallen zijn de Yamanner-worm van juni, die e-mailadressen van Yahoo-gebruikers verzamelde en ze doorstuurde naar spammers en Spaceflash, de software die adware installeerde bij meer dan een miljoen MySpace-gebruikers.

Sociale netwerkingsites geven een valse indruk van veiligheid, aldus Dave Cole van Symantec. 'Je verwacht niet aangevallen te worden wanneer je Joe Bob's pagina bezoekt'. MySpace geeft in een reactie aan dat veiligheidsmaatregelen zijn genomen en wanneer deze toch worden gebroken, dat dan zal worden opgetreden. Experts verwachten echter dat Ajax-aanvallen nog wijdverspreider zullen worden. Een presentatie van SPI Dynamics' Hoffman toonde aan hoe Ajax gebruikt kan worden om op websites in te breken die gebruikt worden voor het verhandelen van aandelen en transacties te manipuleren. Als voorproefje op wat komen gaat, gaf Jeremiah Grossman van WhiteHat Security een demonstratie hoe hackers via MySpace een Ajax-aanval kunnen uitvoeren en een programma diep in het interne netwerk van een bedrijf kunnen loslaten.

Reacties (44)

Wat een gelul.

Ajax is niet het probleem.

Ajax geeft je echt niet meer kansen als hacker, het geeft je als programmeur hoogstens een of twee nieuwe pagina's die je netjes moet beveiligen.

Het probleem is dat de meeste mensen niet weten waar ze mee bezig zijn, de php beveiligingen hebben ze ondertussen redelijk onder de knie, en ook xss aanvallen weten ze ondertussen af te wenden, maar nu gaan ze rustig weer bezig met een nieuwe techniek die ze niet snappen.

Ajax is geen product, het is een werkwijze, en een hele simpele (als je weet wat je doet), zeker op de server is dit 100% af te schermen. Dat een crappy ajax implementatie niet correct de login controlleert, maar hem via een url argument mee krijgt is niet een ajax probleem, dat is een programmeur die lui en onwetend is.

Je hebt gelijk dat Ajax als technologie je niet meer kansen geeft als hacker. Echter de strekking van dit artikel is dat door de nieuwheid en de wijdverspreidheid, hackers wel meer kansen krijgen. In plaats van een simpele statische html-pagina wordt immers steeds meer met Ajax gedaan. Wanneer dat niet goed wordt gedaan, krijgen hackers meer kansen. In dat opzicht is Ajax dus gunstig voor hackers, aangezien het geen ingebouwde beveiliging heeft tegen hackers

Ajax is toch gewoon een verzamelnaam voor het samen gebruiken van technieken die al lang bestonden... Dus om nou te zeggen dat het door ajax komt....

Aan de andere kant is een echte Ajax pagina vele malen lastiger te doorgronden. doordat vele dingen heel erg onderwaten gebeuren. Wat dat beteft wordt het dus zeker niet makkelijker. Check dit geintje maar eens: http://www.potix.com/zkdemo/userguide/

killercow heeft 100% gelijk.

Je gaat er nu van uit dat er een statische pagina vervangen wordt door een ajax pagina?

Dat is niet wat er gebeurt natuurlijk, want dan heb je het over compleet verschillende "producten".

Wat er vervangen wordt, is een dynamische php pagina, door een dynamische php+ajax pagina.

Als er van een statische html pagina naar een ajax pagina ge-updrage wordt kun je ook stellen dat het dynamisch maken van een pagina een security probleem is. (en dat is natuurlijk ook zo, als de programmeur niet weet wat hij doet), maar das is niet speciek een ajax probleem.

De enige reden dat dit in het nieuws is, is dat er allerlei consultants geld willen verdienen aan deze nieuwe hippe tech, die ze zelf niet kunnen schrijven. Ze kunnen nu alweer al hun security guides verkopen (de zelfde die je ook gekocht hebt om je php/asp site te beveiligen)

eindelijk iemand die het snapt

Daarom zou iedere programmeur in de dop EERST een security course moeten doorlopen alvorens te gaan programmeren. Er zijn zoveel standaard security issues (SQL insertion, cookie stealing... you name it) die door de helft van de wereld over het hoofd gezien wordt in hun eigen 'CMS'.

Ajax is niet het probleem, zie bovenstaande.

Kan iemand mij in begrijpelijke taal uitleggen wat een Ajax gebruik exact is?

Ajax is dhtml icm asynchrone webrequest via ofwel iFrames ofwel via het XMLHttpRequest in javascript (activex in IE6 of lager).

Grappig genoeg is het IFrame al beschikbaar sinds IE3 ergens in 1995 of zo en het XMLHttpRequest al sinds IE5 (of 5.5) ergens in 1998/1999 maar pas nu wordt de technologie populair.

Wat hebben IFrames met AJAX van doen

( )

AJAX is een concept, er wordt informatie uitgewisseld tussen de browser en de server. Wat voor informatie dat is, en wat er mee gedaan wordt, is irrelevant. Voor het versturen en ontvangen van die informatie kun je onder andere gebruik maken van het XmlHttpRequest object, én IFrames. Je POST of GET informatie naar een bepaalde pagina in een IFrame, en leest de informatie van die pagina vervolgens weer uit. Alleen nog even met CSS die IFrame mooi onzichtbaar maken, en tadâa!

Uit de wikipedia:

Ajax (Asynchronous Javascript And XML) is een term voor het ontwerp van interactieve webpagina's waarin asynchroon gevraagde gegevens worden opgehaald van de webserver. Daardoor hoeven dergelijke pagina's niet in hun geheel ververst te worden. Zo'n pagina is te vergelijken met een applicatie die in de browser draait.

http://nl.wikipedia.org/wiki/Ajax_(webdesign)

Als een browser geen javascript lek heeft, heeft een ajax aanval niet zoveel zin. Natuurlijk zijn hedendaagse browser soms vatbaar voor javascript aanvallen vanwege lekken, maar ze komen steeds minder voor.

Dus om nu Ajax als potentieel gevaar te zien mbt attacks op een random page gaat mij wat ver.

Waar men wel veel meer bij na moet denken is het feit dat het verkeer tussen browser en server heel anders verloopt en daar, wanneer de programmatuur wat minder slim is opgezet, wellicht wel security issues kunnen ontstaan doordat bv het verkeer niet gecrypt is.

de genoemde virussen maakten geen gebruik van lekken in browsers, maar van webbased applicaties die dmv injection uitgebuit kunnen worden.

de betreffende javascript werden ook geinclude vanaf het Yahoo danwel MySpace domein en de geldende 'sandbox-veiligheid' laat dat toe...
helaas biedt dat al voldoende mogelijkheden om bv handelingen binnen de applicatie uit te voeren zoals het versturen van berichten en gegevens via de betreffende applicatie.

met andere woorden.....
wacht nog liever een tijdje totdat je ajax gaat gebruik voor o.a. ordersystemen. En laat het product/techniek maar eens volwassen worden.

Met andere woorden,

Als je geen kennis van een techniek hebt, gebruik het dan niet voor mission critical data.

Maar leer eerst eens waar je het over hebt. Ajax kun je prima gebruiken, je moet er alleen (net zoals bij de normale pagina's) op letten dat je dingen als logins enzo op de correcte manier in je serverside code opneemt.

De beveiligingsfout zit niet in websites die zelf Ajax technieken gebruiken, maar de websites die user-content niet goed valideren en dus kwaadaardige Ajax (javascript) code op de pagina mogelijk maken.

Hoezo? Dat soort dingen moet je zoiezo op je intranet draaien en afsluiten van de buitenwereld, kan er nix gebeuren.

Ik verwerk AJAX hier toch wel in de backend, scheelt behoorlijk wat server load (laadtijden).

Nogal naief gedrag wat jij vertoond...heel veel misbruik van systemen vindt juist plaats door interne en vertrouwde mensen. De techniek moet dus gewoon veilig zijn.

Een groot probleem met JavaScript is dat het toegang verleend tot in je bedrijfsnetwerk. Als ik op mijn site domain.com een js plaats die een aanroep doet naar de interne webserver op jou werk, icm een exploit, dan heb ik je zo gehacked.

Intranet, Extranet of Internet. Het is allemaal onveilig omdat de programmeurs niet denken aan bepaalde zaken. En gebruikers die bepaalde dingen niet installeren (of juist wel ). Installeer NoScript in FireFox, dan kan je zelf bepalen wat je wil uitvoeren en wat niet.

Wanneer gaan we een browser nou weer eens gebruiken waar hij voor bedoeld is? Oftewel een bladerprogramma. Al die interactieve shit op het web tegenwoordig.

Tijd om weer terug te gaan naar de Netscape 2 tijd.

Dat vind ik nogal een onzinnige reactie. Wat heeft al 'die interactieve shit' te maken met veiligheid? Het is niet noodzakelijk dat veiligheid hevig leidt onder de aanwezigheid van dit soort mogelijkheden in browsers.

Bovendien is het wel conservatief om te stellen dat 'al die interactieve shit' wel weg kan uit browers. Ik vind het, als developer, juist fantastisch dat de gebruikerservaring op het internet de afgelopen jaren fors veranderd is door de komst van Flash, Ajax, e.d. Die uitbreidingen breiden het aantal mogelijkheden dat je als ontwerper of developer hebt gigantisch uit. En ja, natuurlijk is het risico op een beveiligingslek dan ook groter (complexere code = groter risico). Maar nogmaals; dat is niet een noodzakelijke relatie. En eerlijk gezegd vind ik het dat wel waard ook.

Het punt is niet eens zozeer dat de code 'complexer' wordt, maar dat er uitvoerbare code uit allerlei hoeken en gaten van het net wordt getrokken door je browser. Niet alle technieken die voor het dynamisch bijladen van programmatuur worden gebruikt zijn even goed beveiligd. Iedereen die de historie van en problemen met ActiveX heeft gevolgd weet dat.

Natuurlijk zijn al die nieuwe mogelijkheden heel erg mooi, alleen wordt er van gebruikers wel verwacht dat ze onderschied kunnen maken tussen een partij die betrouwbaar is en 1 die dat niet is. Als je ziet dat er nog steeds hele volksstammen zijn die op de vraag "You're computer is probabley infected, do you want to perform a free online scan' met OK antwoorden hoef je daar niet al te veel van te verwachten. De gemiddelde gebruiker is al nauwelijks op de hoogte van het verschil tussen data en code en zou dat ook niet hoeven zijn.

Probleem is wel dat dit onderscheid steeds meer aan het vervagen is, met name op webpages en in Office documenten. Uiteraard krijg je hier functionaliteit voor terug, maar maakt het ook het te beveiligen gebied steeds groter. De vraag is waar de balans tussen die twee ligt.

Snap al jullie argumenten niet echt.

Nee we willen niet terug naar het stenen tijdperk. Maar laten we het even anders formulieren.

Zo je iedere gebruiker toegang willen geven tot scripttalen, compilers en meer van dat soort meuk. Want laten we eerlijk zijn, met de huidige scripting mogelijkheden in browsers _ZIJN_ het halve (zo niet hele) scripting engines.

Waar we vroeger zo veel mogelijk deden om _gewone_ gebruikers maar geen script interpreters, compilers en meer van dat soort meuk te geven zit het tegenwoordig gewoon in browser.

En ja, alles integreren maakt onveilig, het maakt nl. onoverzichtelijk. Of zitten jullie wel allemaal te wachten op ICQ met ingebouwde fileserver, ingebouwde webserver, ingebouwde.... je browser is niet echt anders vandaag de dag. Ingebouwde ActiveX (bij IE), JavaScript, VBScript, vaak Flash interpreter, java interpreter, etc etc.

Even kijken naar de toekomst visie: alles in de browser... hmm...

Ik ben het wel met je eens. Waarom zou je complexe(re) programma's altijd maar via de browser uit willen rollen? Centraal beheer van content kan het niet zijn, want dat kan met een web enabled desktop applicatie ook.

Beheer van de applicatie zelf ook niet. Als je de logica zoveel mogelijk server side houdt en bijvoorbeeld op basis van web services ontwikkelt, dan hoeft er client side weinig spannende zaken te hebben draaien anders dan een soort van GUI schilletje die alleen met jouw server kan praten.

dus jij bent niet voor de vooruitgang van technologie? Je kijkt zeker liever naar een oude zwart/wit tv (met 1 zender op woensdag middag) dan naar een digitale breedbeeld, mooie kleuren, lekker scherp en build in teletekst, radio/tv gids, ect....

een browser gaat elke keer een nieuw tijdperk in.. Het wordt alleen moeilijker gemaakt door die domme hackers.

Die domme hackers dwingen mensen gewoon na te denken over de veiligheid van hun ontwerp en code.

Dat vind ik niet zo dom. Liever dat ze het op de BlackHat conferentie aan de wereld laten zien dan op een achteraf zolderkamertje miljoenen computers infecteren om zo de nodige pegels op te strijken.

HD Moore die in de afgelopen maand een browserbug per dag publiceerde kreeg niet voor niets naast de browserfabrikanten ook een stel criminelen op zijn dak die niet blij waren dat het lek dat zij al jaren misbruikten door hem gepubliceerd was...

Als er geen hackers/misbruikers waren dan hoefden zij ook niets duidelijk te maken

dat bedoelde dvogel zeer waarschijnlijk

als je wil praten kan je ook bij mensen gaan, op cafe,...

de "vooruitgang" is dus dat iedereen alleen voor z'n pc zit te chatten en blogs vol te schrijven
mooie vooruitgang is dat

Vroegah woonden we ook met zijn allen in één grot...
Lekker gezellig met zijn tientallen in een warm grotje... en toen gingen we in eens in boerderijen wonen, met een stuk minder mensen. Gezellig he?

Wat jij of ieder ander individue vindt is niet relevant, het is relevant wat de massa vind. Hoe stom dat ook klinkt

Dus jij wil eigenlijk gewoon tweakers.net sluiten omdat je vind dat er alleen maar content geboden moet worden op het internet i.p.v. applicaties (zoals dit messageboard).

Een webbrowser biedt de functionaliteit om op een uniforme manier applicaties te leveren bij de klant. Volgens mij is de webbrowser de meeste kost-effectieve om applicaties te leveren en the beheren voor een grote groep gebruikers.

Ik snap de ophef over AJAX alleen niet. Naar mijn mening is het qua security niet veel anders dan het posten van HTML formulieren. Daarbij moet je ook gewoon de data valideren die je binnen krijgt.

Behalve dat je op MSIE momenteel het lekke mandje ActiveX nodig hebt om de meeste AJAX sites (gebaseerd op XMLHttpRequest) te draaien.

Tijd om weer terug te gaan naar de Netscape 2 tijd.

Ja en laten we ook weer paard en wagen gebruiken, dan zijn we meteen van alle verkeersongelukken af.

een slecht iets voor zo iets goeds als Ajax...alleen denk ik dat dit soort dingen ook best kunnen zonder Ajax maar op de oude manier. Je moet alleen iets meer moeite doen.

Het is maar wat je een goed iets noemt...ik vind het nogal een behoorlijke workaround om het stateless zijn van het http protocol te omzeilen.

Ajax is gewoon heel veel kunst en vliegwerk door het gebuik van "extensies" (xml, javascript) op de aloude HTTP om de interactie (browser) minder "stateless" te maken.

Mijns inziens is Ajax niet DE oplossing, maar het is op het moment de enige oplossing voor directe interactie. (ipv dat je iets via HTTP naar de back-end van een webserver stuurt en dan eens een keer wat terugkrijgt, php etc.) wat ik dan maar snel even "indirecte interactie" noem.

Door het feit dat Ajax veel kunst en vliegwerk om een bestaand protocol heen is (HTTP) is dat zo en zo een concept wat veiligheids technisch niet is aan te bevelen.

Ajax is een manier van werken. niet echt een technologie. Vind "Ajax" ook een rukterm, zo'n marketisch kapstok. Mensen kunnen wel roepen "ajax is het probleem niet"....maar dat is wel zo....het is een manier van werken die steeds populairder gaat worden.....En Ajax is door haar 2-weg interactie aard per definitie al onveiliger dan strict klassiek HTTP.

Het spijt me dat ik het zo moet zeggen lenny_z, maar wat een hoop onzin bij elkaar:

het gebuik van "extensies" (xml, javascript) op de aloude HTTP

Ajax is door haar 2-weg interactie aard per definitie al onveiliger dan strict klassiek HTTP

xml en javascript zijn geen extensies op http. http is een communicatieprotocol dat tussen browsers en webservers wordt gebruikt.
Als je een pagina opvraagt voert je browser een http request uit naar een webserver. De meest gangbare smaken zijn hierbij GET of POST requests.
Ajax is een werkwijze - dank killercow - waarbij de webprogrammeur dit soort requests door - bijvoorbeeld - javascript of iframes laat uitvoeren. Deze requests vragen pagina's op dezelfde manier op als wanneer je een webadres intikt in de adresbalk of een formulier "submit".

Een voorbeeld van Ajax; ik stel mij de MySpace situatie als volgt voor (speculatief, ik weet niet hoe het is gegaan):
- op een profiel pagina staat een link: "add this user to my contacts"
- in de html code ziet de link er als volgt uit:
<a href="/add.asp?id=2345">add this user to my contacts</a>.
12345 is in dit voorbeeld de user id van het "jeugdig lid".
- gebruiker voegt de tags <iframe src="/add.asp?id=2345" style="visibility:hidden"></iframe> toe aan zijn naam, waardoor de pagina automatisch wordt opgevraagd, zodra iemand die pagina bezoekt. Als de add pagina nu zonder verdere vragen user 12345 toevoegt zodra hij met ?id=12345 wordt aangeroepen staat zijn naam inclusief die code direct en ongemerkt bij de bezoeker zijn contacten en zodra iemand die ziet... je raad het al, dan wordt je snel populair.

Dit is nu Ajax: geen "http extensies" of "2-weg interactie" wat je daar ook mee moge bedoelen, gewoon zeer simpele http get in simpele html, maar zonder "harde", zichtbare paginaovergangen.

De fout in dit voorbeeld is dat de programmeur van de add pagina er geen rekening er mee heeft gehouden dat de "add" pagina op een andere manier dan door een klik op de mooie "add user" link kon worden opgevraagd. Ook is het niet slim om html in een naam toe te laten.

Bij een nuttige toepassing van Ajax kun je bijv. met een klik op een link gegevens (bijv. in xml formaat) binnen een onzichtbaar iframe laten ophalen en de inhoud van dat iframe vervolgens weer met javascript uitlezen en in je zichtbare pagina verwerken, zonder dat de gebruiker een "cls" ervaring heeft.

Wat doet het aandeel Ajax door dit nieuws eigenlijk ?

Het zit em gewoon in de naam Ajax