Identitätsprinzip (Webanwendungen)

Das Identitätsprinzip ist eine Art, Webanwendungen und Internetseiten so zu gestallten und darzustellen, dass Benutzer bei einem Phishing-Angriff misstrauisch werden, zurückhaltender mit dem Angeben von Daten sind und im Erfolgsfall die gefälschte Webseite erkennen, bevor sensible Daten übermittelt wurden. Dazu muss aus dem Umgang mit der Website, aber auch aus der gesamten Kommunikation mit dem Internetauftritt erkennbar sein, dass der Internetdiensteanbieter bestimmte Muster durchgängig einhält. Zeigt sich im Kontext einer Webanwendung ein auffälliges, nicht den bekannten Mustern entsprechendes Verhalten, wird ein Endbenutzer automatisch misstrauisch und verhält sich zurückhaltender, so dass es einem Angreifer deutlich schwerer fällt, sein Ziel zu erreichen. Diese Konventionen sollten bei hohen Sicherheitsanforderungen (z.B. Konto-Login, etc.) den Benutzern darüber hinaus explizit mitgeteilt werden. Im Weiteren sollten Verhaltenshinweise für den Fall der Verletzung der Konventionen genannt werden. (z.B. Seite umgehend verlassen, an eine E-Mail Adresse melden, etc.) Das Prinzip, welches auch der Corporate Identity eines Unternehmens zugrunde liegt, nämlich die Schaffung einer unverwechselbaren Identität und eines Wiedererken­nungseffektes, wird mit dieser Maßnahme auch auf Webanwendungen angewandt.^[1]

Ansatzpunkte

• Vermeidung von Popups, um Cross-Site-Scripting (XSS) zu verhindern, sowie zu verhindern, dass es möglich ist, ein betrügerisches Fenster so vor der Seite einer authentischen Website zu positionieren, dass es den Anschein hat, dass das Fens­ter zu der Website gehört.^[2]
• Vermeidung von irreführenden, verschiedenen und bunten Werbebannern. Sie führen dem Benutzer immer wieder Überraschendes und nicht im Kontext der Website stehendes vor die Augen und befinden sich dabei im Vertrauenskontext der Website: Das Vertrauen, wel­ches dem Anbieter entgegen gebracht wird, überträgt sich auf den Inhalt des Werbebanners.
• Nutzung fester und einprägsamer Mail-Absendeadressen für Newsletter etc, wie z.B. [e-mail]. "Noreply" sollte vermieden werden. Trotz der leichten Fälschbarkeit von E-Mail-Adressen würde wahrscheinlich ein Angreifer die Absenderkennung verfälschen. Trotzdem ist es im Sinne dieser Maßnahme wichtig, auf Durchgängigkeit der Konventionen zu achten.
• Ein SSL-Serverzertifikat sollte niemals fehlerhaft sein. Immer wieder trifft man auf den Fall, dass der Servername, wie er in der URL steht, nicht exakt mit dem im Zertifikat eingetragenen Namen übereinstimmt. Dies führt zu einer Warnmel­dung des Browsers, die geeignet ist, die Benutzer nicht nur zu verunsichern, son­dern auch dazu führen kann, dass Derartiges zukünftig als normal hingenommen wird. Ebenso sollte das Überschreiten der Gültigkeitsdauer eines Zertifikats ver­mieden werden.
• Unerwartetes und Überraschendes sollte generell vermieden werden. Dazu gehört auch, dass ein Benutzer nicht ohne besonderen Grund ausgeloggt wird bzw. erneut zum Login aufgefordert wird (ein besonderer Grund besteht dennoch, wenn der Be­nutzer zu lange inaktiv geblieben ist). Ein Angreifer hätte es dann leichter, einem Benutzer bei Bestehen einer entsprechenden Sicherheitslücke eine gefälschte Lo­gin-Seite unterzuschieben, nachdem der Login für den Nutzer zur Routine wird.

Literatur

• Hacking Exposed: Web Applications: Web Application Security Secrets and Solutions von Joel Scambray, Vincent Liu und Caleb Sima beim Verlag Mcgraw-Hill Professional; 3. Auflage. (1. November 2010); ISBN-13: 978-0071740647
• Sichere Webanwendungen: Das Praxisbuch von Mario Heiderich, Christian Matthies, Johannes Dahse und fukami beim Verlag Galileo Computing; 1 Auflage (11. Dezember 2008); ISBN-13: 978-3836211949

Weblinks

• Sicherheit von Webanwendungen - Maßnahmenkatalog und Best Practices | Herausgegeben vom Bundesamtes für Sicherheit in der Informationstechnik; Version 1, August 2006
• Improving Web Application Security: Threats and Countermeasures

Referenzen

1. ↑ http://www.securenet.de/ueber-securenet/veroeffentlichungen/was-hat-phishing-mit-web-application-security-zu-tun.html
2. ↑ http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de//archive/provos-2008a.pdf