Donnerstag, 10. Mai, JavaOne 2007
You Are Hacked: Ajax Security Essentials for Enterprise Java Technology Developers
Diese Session behandelte, wie schon der Name vermuten lässt, die potentiellen "neuen Risiken" die zu den "alten Risiken" hinzukommen wenn man eine Webapp "Ajax enabled". Und wartete auch mit ein paar Tipps auf, wie man diesen begegnen kann.
Das Hauptproblem dieser neuen "Rich Internet Applications" ist, dass durch die Verlagerung von Applikationslogik auf den Client (weg von "thin" Browser Interfaces hin zu "thick") der geneigte Hacker automatisch mehr über die Anwendung erfährt. Die Logik und die Methoden sind nun nicht mehr hinter einem Service auf dem Server verborgen; durch den Export dieser - damit vom Client via Javascript aufrufbar - sind diese nun sichtbar und machen es einem Hacker einfacher die Anwendung zu inspizieren, Methoden auszuprobieren und auszutricksen.
- Javascript Bibliotheken unter Verwendung eines "Obfuscators" (ersetzt sprechende Methoden- und Variablennamen mit "kryptischen") schwerer lesbar machen.
- Ajax nur dort einsetzen wo wirklich sinnvoll. Bei Login Seiten zum Beispiel nicht Popups, sondern eigene "plain old" Login Seiten verwenden. Dies auch, um wegen des zeitweiligen Wechels von http auf https nicht mit der "same origin policy" der Browser in Konflikt zu geraten und umschiffen zu müssen.
- Input Validierung (auf dem Server, sich NICHT auf den Client verlassen!).
- Output encoding.
- Referer und Token (zum Beispiel API Key) Checks durchführen.
- Einsatz von CAPTCHAs.
- Die Lebenszeit von Sessions so kurz wie möglich, so lange wie nötig halten.
- Verwendung von Black- und Whitelists.
- Anzahl Requests und Bandbreiten limitieren.
- Monitoring der Anwendung.
Das grosse Problem sei, dass Sicherheits Aspekte beim Entwickeln einer Anwendung oftmals - um schneller vorwärts zu kommen - vernachlässigt werden. Erst nach der ersten Attacke kümmert man sich darum: man stopft genau das offengelegte Loch. Und dann das nächste Loch und so weiter. Sicherheit sollte daher von Anfang an ein Thema sein!
Zusammengefasst hat diese Session wohl nicht viel neues zu Tage gefördert; wird dadurch aber der eine oder andere Sinn für diese Probleme geschärft, hat sich der Besuch sicherlich gelohnt.
Garbage-Collection-Friendly Programming
Die zeitweise etwas abgehobene Session mit drei Leuten des Garbage Collector Teams von Sun dürfte manchem Kenner viele Einsichten über Garbage Collector Strategien etcetera beschert haben. Da ich mich nicht zu den GC Profis zählen tu, möchte ich mich auf ein paar Punkte beschränken die ich mir fortan (wenn nicht schon bereits bisher) zu Herzen nehmen möchte. Für Interessierte treibe ich gerne die Slides auf (was auch für die andern Vorträge gilt).
Das (mit einem Schmunzeln) erklärte Ziel der Session war es, dass die Entwickler ihre Codes und nicht das GC Team den ihrigen anpassen muss :-).
- Das Allozieren neuer (kleiner) Objekte ist effizient, nur zu also.
- Der Garbage Collector kann mit kurzlebigen immutable Objekten besser umgehen als mit langlebigen mutables.
- Explizites Garbage Collecting sollte vermieden werden, ausser man tut dies sehr bewusst und die Performance der Anwendung ist zu jenem Zeitpunkt nicht kritisch.
- Finally Block benützen um unbenötigte Referenzen abzuräumen.
- Achtung bei Inner classes, diese haben implizite Referenzen auf ihre "Mutterobjekte".
- Hat die Anwendung ein Memory Leak, kann man sich mit jmap ein Class Histogramm anzeigen lassen.
