Wicket und CSRF (deutsch)

Nach einer Diskussion die ich vor Kurzem zum Thema CSRF (Cross Site Request Forgery) hatte möchte ich kurz auf die Möglichkeiten zum Umgang mit diesem Angriff in Wicket eingehen. Tatsächlich handelt es sich hier um einen oft unterschätzten Angriffsvektor der eine Schwäche des Browsers und nicht der eigentlichen Webanwendung ausnutzt.

Der Angriff

Der Ablauf eines CSRF-Angriffs ist schnell erklärt.

  1. Ein Benutzer authentifiziert sich in einer Webanwendung
  2. Eine entsprechende Sitzung wird eröffnet und der Browser erhält ein Cookie
  3. Der Benutzer navigiert, ohne sich abzumelden, auf eine andere Seite (oder öffnet ein weiteres Tab/Browser-Window).
  4. Auf dieser Seite hat unser Angreifer ein entsprechendes JavaScript oder eine verstecktes Frame eingebaut mit dessen Hilfe der Browser dazu veranlasst wird eine URL innerhalb der anderen Webanwendung zu öffnen.
  5. Da das Cookie immer noch gültig ist wird dies automatisch mitgeschickt und der Angreifer hat Zugriff.

Natürlich versuchen Browserhersteller Möglichkeiten für diesen Angriff zu minimieren.

Grundsätzlich sollte man als Webentwickler aber davon ausgehen, dass diese Mechanismen nicht funktionieren.

So manchem (Jemand fühlt sich gleich angesprochen 😉 ) zuerst die Möglichkeit via AJAX und XmlHTTPRequest in den Sinn. Allerdings gibt es hier eine wichtige Beschränkung die meines Wissens in allen Browsern korrekt umgesetzt ist. Ein XmlHTTPRequest kann nur auf den Ursprungsserver abgesetzt werden. Somit sind extern nachgeladene Skripten außen vor. Hat man natürlich eine Cross-Site-Scripting-Schwäche in der Anwendung …

Die Verteidigung

Grundsätzlich ist Wicket, wie jedes andere Webframework, anfällig für diese Angriffe. Allerdings liefert es auch alles was benötigt wird um diesen Angriff deutlich zu erschweren oder ihn sogar unmöglich zu machen.

In Wicket 1.4 gibt es hierfür die CryptedUrlWebRequestCodingStrategy. Mit folgendem Code-Snipplet kann sie in der Application registriert werden.

...
    protected IRequestCycleProcessor newRequestCycleProcessor() {
        return new WebRequestCycleProcessor() {
        protected IRequestCodingStrategy newRequestCodingStrategy() {
        return new CryptedUrlWebRequestCodingStrategy(new WebRequestCodingStrategy());
    }
...
}

Wicket 1.5 bietet die gleiche Funktionalität im CryptoMapper. Der wie folgt registriert wird:

...
    @Override
    public void init() {
        super.init();
        setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
    }
...

In beiden Fällen wird von un an für jede neu erzeugte Session ein entsprechender Schlüssel erzeugt und in ihr hinterlegt. Im Folgenden wird jede URL, bevor sie ausgeliefert wird, mit diesem verschlüsselt.

Beim Aufruf einer URL in der Anwendung (via AJAX oder dem Klicken eines Links) versucht Wicket diese zu entschlüsseln. Funktioniert dies nicht, was auf alle URLs zutrifft die nicht von Wicket ausgeliefert wurden, wird eine Fehlermeldung erzeugt.

Nachteile

Alles hat seinen Preis, auch der Schutz vor CSRF-Angriffen. Man verliert die Möglichkeit BookmarkablePages zu nutzen. Auch ihre URLs werden entsprechend verschlüsselt. Da der Schlüssel für jede Session neu erzeugt wird sind diese Links spätestens nach dem Ausloggen ungültig.

Durch die Nutzung von PageMounts kann man dieses Problem abmildern da deren URLs immer verfügbar sind.

Auch mag es stören eine Schlüssel pro Session zu erzeugen da dies die Existenz einer Session voraussetzt. Via Application.getSecuritySettings().setCryptFactory() lässt sich hier ein eigenes CryptFactory registrieren welches einen applikationsweiten Schlüssel erzeugt.

Fazit

Trotz der erwähnten Nachteile sehe ich die CryptedUrlWebRequestCodingStrategy als das sicherste und bequemste Mittel zur Abwehr von CSRF-Angriffen. Wer sich Sorgen um die zusätzliche Last durch die Verschlüsselung macht wird hier demnächst noch eine kleine Lastanalyse finden.

Advertisements

Wicket Wizards (deutsch)

Wizards sind ein wichtiger Bestandteil eines jeden GUI-Frameworks.
Natürlich bietet auch Wicket entsprechende Komponenten.
Basis jedes Wizards ist die abstrakte Klasse Wizard.
Diese bringt eine entsprechende ButtonBar mit Buttons um zwischen den Einzelschritten zu navigieren und zum Bestätigen/Abbrechen.
Wer eigen Navigationsoptionen einbauen will kann Wizard.newButtonBar(String) überschreiben.
Für das Beispiel verwende ich allerdings die mitgelieferte Variante.
Der zweite Baustein ist das WizardModel.
Dieses bildet den zentralen Dreh-und ANgelpunkt für alle Wizard-Funktionen.
Es kennt alle Schritte, ihre Reihenfolge und den aktuell ausgewählten.
Fehlen nurnoch die einzelnen Schritte. Diese werden als WizardSteps implementiert und sind einfache Panels die vom Wizard gegeinander ausgetauscht werden.
Somit wird ein Wizard wie folgt erzeugt.

public class UserWizardPanel extends Wizard {
 public UserWizardPanel(String id) {
 super(id);
 setDefaultModel(new CompoundPropertyModel<User>(new User()));
 WizardModel wizardModel = new WizardModel();
 wizardModel.add(new UserCredentialsPanel(Model.of("User Credentials"), Model.of("Please give your credentials.")));
 wizardModel.add(new UserDetailsPanel(Model.of("User Credentials"), Model.of("Please give your credentials.")));
 wizardModel.add(new UserMessageToTheWorldPanel(Model.of("User Credentials"), Model.of("Please give your credentials.")));
 init(wizardModel);
 }

@Override
 protected Component newButtonBar(String id) {
 return super.newButtonBar(id);
 }

@Override
 public void onFinish() {
 System.out.println("DONE!!");
 }

@Override
 public void onCancel() {
 System.out.println("CANCEL!!");
 }
}

NoScript

Der Wizard verwendet AJAX um zwischen den Schritten hin- und herzuspringen. Im NoScript-Fall werden hieraus, wie üblich, Page-Requests wodurch Wizards auch ohne JavaScript funktionieren.

Das ganze Beispiel gibt’s hier als Quickstart.

2011 is over

A little late but my official end of 2011 was last week.

With the relase of my book on wicket and giving two talks at bedcon I finally finished the last of my new years resolutions.

Time to get going on the plans for this year.

  • There’s gonna be a (German) series of blog-posts on Wicket-related issues to supplement my book.
  • I finally got started with Scala and I am starting to work through “The Art of Software Development” by Knuth.
  • More JEE6: Since preparing the Wicket-JEE6-Talk for Bed-Con I am completely convinced that I have to become a JEE6-god. Let’s see how that goes;)

Uh, and last but not least:

  • Finally see Meshuggah live for te second time.