http://www.hardened-php.net/advisory_152005.67.html
http://www.hardened-php.net/advisory_142005.66.html

http://www.heise.de/security/news/meldung/62827



Bugfix:
http://blog.s9y.org/archives/36-CRITICAL-BUGFIX-RELEASE-Serendipity-0.8.2.html

http://news.com.com/The+security+risk+in+Web+2.0/2100-1002_3-6099228.html

CSS

http://www.it-observer.com/articles/1062/ajax_security

1) Vorteile von Ajax
Früher: Submit -> leerer Bildschrim -> laden -> neue Seite
Heute: Ajax (mit DHTML) kommuniziert hinter den Kulissen

2) Funktionsweise
JavaScript kommuniziert im Hintergrund mit dem Server
Backbone: JavaScripts XMLHttpRequest object, ausgelöst durch Tastendrücke, Timer; arbeitet im Hintergrund bzw asynchron
XML im Name irreführend (kommt vom Name des JS Objekts), man kann alles mögliche vom Server holen, zB auch JavaScript und on the Fly einfügen.
Best Practice: XML(?), Manipulation mit JS recht einfach.

3) Trouble with Ajax (anhand eines Reiseveranstalter-Beispiels)

• Neuartige Technologie: Neuartige Technologie, Best Practices fehlen, dubiose Eigen-Konventionen?
• Unkonventionelles Design: Teils Client, teils Server. Ein Entwickler für beide Seiten => 2 verschiedene Sprachen gleichzeitig programmieren; bei verschiedenen Teams: wer ist für Sicheres Coding verantwortlich?
• Zu viele Skripte: Ohne Planung: Viele kleine Skripte = mehr zu managen, mehr Raum für Fehler, versteckt in Client-JavaS-Code werden vergessen?
• Darfs etwas mehr sein?: Ajax verleitet dazu viel mehr einzubauen als man eigentlich braucht
• Unsichere Kommunikation - Bei vielen Anfragen kann eine die verschlüsselt werden sollte übersehen werden
• Serverseitige Zugriffskontrollen - Session Cookies oder andere Tokens damit Daten an den richtigen Benutzer gehen
• Serverseitige Validierung - Ajax Controls erlauben Validierung zur Laufzeit => Gefahr da mit Proxy Anfragen, die dann wirklich abgeschickt werden, manipulierbar sind.
  "Normale" Server-Validierung ist daher Pflicht! Zusätzliche Frage, ob Ajax-Controls sicher sind, dh ob die Parameter ihrer Aufrufe angreifbar sind.
• Clientseitige Validierung - JavaScript Code on the Fly mit eval() birg auch Risiken. Aktuell ausgeführter Code ist nicht sichtbar, falls ein Hacker den Server unterwandern kann (Serverhack/Man-in-the-Middle) können so zB Cookies/Session IDs ausgelesen werden o.ä.

4) Summary
Ajax toll, neue Möglichkeiten, aber man muss aufpassen

Größtes Problem: Komplexität der Client-side Scripte + evt höhere Anzahl server-seitiger Scripte. Scripte nicht sichtbar -> weniger intuitiv testbar, Coding-Standards zur Sicherheit müssen weiter eingehalten werden (zB server-seitige Validierung etc)

Tips
Planen und Vereinfachen der Ajax Calls, Standardformat zum Austausch das gewissen Konventionen entspricht (XML?!)

Best Practices von Seiten wie Open Web Application Security Project übernehmen (Zugriffkontrolle, Validierung)
Sensitive Daten über SSL schicken

Auch mit Ajax-Controls mit Validierugnsfunktion muss die finale Validierung am Server nach dem Submit durchgeführt werden.

Schwer lesbarer Client-side Code schützt keine Geschäftsgeheimnisse.

Tolle Ideen sollte man sich für spätere Versionen aufheben und das wichtige in der ersten Version realisieren.

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.

• 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

Spezialisiertes Testen nötig, Standard-Web-Aplikationstests reichen u.U. nicht aus


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?

Aufgabe vom Tester ist festzustellen, ob die sichere Struktur noch vorhanden ist.
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.