Ajax Security Basics
http://www.securityfocus.com/infocus/1868/1
1) Ajax allgemeines
Asynchron -> Client-side scripting lang. + XmlHttpRequest (XHR) obj + XML
Client: meist JavaScript, wg Browserverträglichkeit
XHR: "Herz" der Technologie! Client-script sendet mit XHR Anfragen an den Server, dort Auswertung mit bekannten Frrameworks (J2EE, PHP, .NET)
XML: Datenformat (nicht in jedem Fall verwendet!), stattdessen z.B. oft JSON (JavaScript Object Notation), da leichter zu parsen und weniger Overhead
-> "Alte" Technologien "reloaded"!
Kombination ermöglicht höchste Interaktivität
-- gutes Bild im Text zeit Asynchron ablaufende Calls, teilweise von User oder automaitisiert --
2) Schüsse für Security
Alte Probleme with a twist!
Keine Best Practices vorhanden, da kann viel schief gehn.
3) Testen
Beginn des Penetrationtests -> "Footprining", dh Anfragen/Antworten loggen und verstehen.
Danach Manipulieren der Anfragen
-> Erschwert bei Ajax, da evt viele Anfragen im Hintergrund abgeschickt werden können, ohne dass Auswirklungen direkt sichtbar sind.
Veränderungen des Variablenstatus überprüfen.
Authorisierung überprüfen (Seiten nur indirekt aufgerufen werden auch!)
4) Ergebnis
Neue Möglichkeiten => Neue Sicherheitsrisiken
Tester müssen ihre Tools und ihre Methodik erweitern um Ajax Applikationen zu testen. Das Wissen ist im Prinzip da, aber die Tests sind komplexer.
1) Ajax allgemeines
Asynchron -> Client-side scripting lang. + XmlHttpRequest (XHR) obj + XML
Client: meist JavaScript, wg Browserverträglichkeit
XHR: "Herz" der Technologie! Client-script sendet mit XHR Anfragen an den Server, dort Auswertung mit bekannten Frrameworks (J2EE, PHP, .NET)
XML: Datenformat (nicht in jedem Fall verwendet!), stattdessen z.B. oft JSON (JavaScript Object Notation), da leichter zu parsen und weniger Overhead
-> "Alte" Technologien "reloaded"!
Kombination ermöglicht höchste Interaktivität
-- gutes Bild im Text zeit Asynchron ablaufende Calls, teilweise von User oder automaitisiert --
2) Schüsse für Security
Alte Probleme with a twist!
Keine Best Practices vorhanden, da kann viel schief gehn.
- Client Side Security Controls - schöne Sache, aber nur zusätzlich, servers-seitige Kontrollen trotzdem ABSOLUT notwendig, da Anfragen manipuliert werden können
- Größere Angriffsfläche - AJAX steigert die Systemkomplexität, dadurch gibt es mehr Angriffspunkte. Viele kleine Server-Seiten für viele kleine Funktionalitäten möglich
- Überbrücken von Service zu User - B2B - Authentifizierung, Authorisierung, Eingabevalidierung durch Middle Tear Systen?, Aufruf von Webservices durch den Client mittels JS/XML statt service proxies im Server!
- Neue Möglichkeiten von Cross-Site-Scripting (XSS) - Gefährlichere Variante, da in nicht sichtbaren Anfragen möglich, Auswirkungen auch u.U. nicht direkt spürbar
3) Testen
Beginn des Penetrationtests -> "Footprining", dh Anfragen/Antworten loggen und verstehen.
Danach Manipulieren der Anfragen
-> Erschwert bei Ajax, da evt viele Anfragen im Hintergrund abgeschickt werden können, ohne dass Auswirklungen direkt sichtbar sind.
- State - Problem, dass manche Anfragen abhängig sind vom Status eines (anderen) Objekts, also anders aussehen oder garnicht stattfinden
- Timer-Events - Requests können periodisch durch Timer getriggert werden. Im Hintergrund? Woher weiß mans?
- Dynamische DOM Updates - [DOM = Dynamic Object Modes] - JavaScript Sniplet zum Erweitern von Serverseiten mit dem eval() Befehl. Gefahr bei Behandlung im Client! (-> XSS!)
- XML Fuzzing - Versteht das Test-Tool XML?
Veränderungen des Variablenstatus überprüfen.
Authorisierung überprüfen (Seiten nur indirekt aufgerufen werden auch!)
4) Ergebnis
Neue Möglichkeiten => Neue Sicherheitsrisiken
Tester müssen ihre Tools und ihre Methodik erweitern um Ajax Applikationen zu testen. Das Wissen ist im Prinzip da, aber die Tests sind komplexer.
intrance - 3. Jul, 11:10