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.