Webanwendung

Grundidee und Zweck

Eine Webanwendung, auch Online-Anwendung, Webapplikation oder Web-App genannt, ist ein Anwendungsprogramm, das auf Techniken des World Wide Webs basiert und über einen Webbrowser ausgeführt wird. Sie wird im Gegensatz zu Desktopanwendungen oder mobilen Apps nicht auf dem Endgerät installiert und benötigt kein spezielles Betriebssystem. Meist dient sie der Nutzung eines Onlinedienstes.

Für die Nutzung genügt grundsätzlich ein Webbrowser. Dadurch sind Webanwendungen weitgehend plattformunabhängig, sofern der verwendete Browser unterstützt wird. Eine Änderung an der Anwendungslogik muss normalerweise nur zentral auf dem Webserver vorgenommen werden. Das erleichtert Wartung und schnelle Sicherheitskorrekturen.

Funktionsweise und Datenfluss

Die meisten Webanwendungen arbeiten nach dem Client-Server-Modell. Der Webbrowser auf dem Gerät des Benutzers ist der Client; ein entfernter Webserver übernimmt wesentliche Teile der Verarbeitung und sendet die Ergebnisse zurück.

Beim Start gibt der Benutzer beispielsweise eine URL ein. Der Browser sendet dadurch einen HTTP-Request an den Webserver. Dieser übergibt die Anfrage an die Webanwendung. Sie erzeugt oder lädt HTML-Quellcode, der als HTTP-Response an den Browser zurückgesendet wird. Die gelieferte Webseite bildet die grafische Benutzeroberfläche. In der Schichtenarchitektur läuft die Präsentationsschicht im Browser als Thin Client; Teile der Logikschicht und der Datenhaltung werden serverseitig ausgeführt.

Durch Hyperlinks oder das Absenden von Formularen entstehen weitere Requests. Dabei können Formulareingaben per HTTP POST, Linkparameter per HTTP GET und HTTP-Cookies übertragen werden. Schnittstellen wie Common Gateway Interface (CGI) oder FastCGI verbinden die Webanwendung mit dem Webserver. Die Verarbeitung eines HTTP-Requests wird Request Cycle genannt.

Teile der Logik werden möglichst schon auf dem Client ausgeführt, etwa zur vorläufigen Validierung von Eingaben. Fehler können dadurch sofort angezeigt werden. Mit Ajax werden nur Teilbereiche der Inhalte aktualisiert, ohne die gesamte Webseite erneut aufzurufen. Webanwendungen können neben HTML auch Bilder, Animationen, Videos, Audiodateien und PDF-Dokumente erzeugen.

Sessiondaten, beispielsweise Bestelldaten eines Webshops, werden häufig serverseitig in Datenbanken oder Dateien gespeichert. Benutzerbezogene Daten können auch in HTTP-Cookies auf dem Client liegen. Serverseitige Sitzungsdaten verbrauchen pro aktiver Sitzung Serverressourcen und erschweren die horizontale Skalierung.

Architektur, mobile Nutzung und Verteilung

Eine Webanwendung läuft meist auf einem Webserver, kann aber auch auf einen oder mehrere Applicationserver ausgelagert sein. Es gibt zwei grundlegende Architekturen:

• Bei einer Standalone-Anwendung ist die Webanwendung ein eigenständiges Binärprogramm oder ein von einem solchen Programm interpretiertes Skript. Für jede Anfrage wird sie neu gestartet; typische Beispiele sind CGI-Programme.
• Bei einer integrierten Anwendung ist sie Teil des Webservers oder wird von diesem interpretiert. Für jeden Request Cycle muss kein neues Programm gestartet werden. Beispiele sind PHP, Perl, Python und Ruby über entsprechende Webserver-Module sowie Java Servlets, JavaServer Pages und ASP.NET.

Bei client-lastigeren Verteilungsvarianten übernimmt der Webclient mehr Aufgaben. Das kann Serverressourcen sparen und die Reaktionszeit sowie die User Experience verbessern, weil nicht jede Interaktion eine Client-Server-Kommunikation erfordert.

Eine Rich Internet Application (RIA) verlagert per Definition ein höheres Maß an Programmlogik auf den Client, etwa Berechnungen. Webprojekte mit JavaScript, Ajax oder Java-Applets können als RIA gelten, wenn diese Elemente an der Benutzerinteraktion beteiligt sind. Eine Single-Page-Webanwendung (SPA) verbindet den RIA-Ansatz mit Webservices. Die vollständige Präsentationsschicht wird clientseitig ausgeführt; zusätzlich können Teile der Fachlogik und eine Datenhaltung als Zwischenspeicher für den Offlinebetrieb auf dem Client liegen. Der Webserver verteilt dann vor allem JavaScript-, CSS- und Bilddateien und stellt Nutzdaten über Webservices, beispielsweise eine REST-API, bereit. Diese Fat-Client-Architektur kann zu Hybrid-Apps führen, die Vorteile von Native Apps und Web-Apps verbinden.

Eine mobile Web-App läuft auf verschiedenen Plattformen, sofern das Endgerät einen Browser mit den erforderlichen Webstandards wie HTML5 oder JavaScript unterstützt. Eine native App wird dagegen jeweils für eine bestimmte Zielplattform implementiert. Bei mobilen Web-Apps ist neben dem Inhalt besonders der Nutzungskontext wichtig; auch das User Interface hat eine zentrale Bedeutung.

Abgrenzung, Vorteile und Nachteile

Ein Webservice stellt Informationen in einem strukturierten Format bereit, das nicht primär zur direkten Anzeige gedacht ist. Die Daten sind zur Weiterverarbeitung durch ein beliebiges Programm auf dem Client bestimmt; eine Benutzerinteraktion ist nicht zwingend erforderlich. Als Datenformate kommen XML und JSON zum Einsatz. XML allein grenzt einen Webservice nicht von einer Webanwendung ab, da Webanwendungen seit XHTML ebenfalls XML verwenden können. JSON ist für JavaScript-basierte Webclients vorteilhaft, weil das Parsen von XML-Strukturen entfällt.

Vorteile von Webanwendungen sind die meist bereits vorhandene Browserumgebung, der Wegfall einer zusätzlichen Softwareinstallation und die Plattformunabhängigkeit bei ausreichender Browserunterstützung. Änderungen werden zentral auf dem Webserver vorgenommen, wodurch sich Wartungskosten verringern. Sicherheitslücken können sofort behoben werden. Selbst bei vollständiger Kompromittierung der Webanwendung sind im Regelfall keine anderen Programme auf dem Anwendersystem gefährdet.

Nachteile bestehen in der erforderlichen Verbindung zum Webserver und in den Anforderungen an die Datenrate. Bestimmte native Schnittstellen und Hardwarefunktionen sind nur eingeschränkt zugänglich. Unterschiedliche Browser interpretieren HTML und JavaScript nicht immer gleich; deshalb können Browserweichen, teilweise sogar für verschiedene Browserversionen, notwendig sein. Der Request Cycle ermöglicht nur asynchrone Verarbeitung, wodurch etwa Videobearbeitung als Webanwendung ausgeschlossen oder deutlich erschwert werden kann. Auch die Möglichkeiten für Nutzerinteraktionen und der Zugriff auf Hardwareressourcen des Clients sind eingeschränkt. Die Identifikation angemeldeter Benutzer über Session-IDs kann Sicherheitsprobleme verursachen.

Entwicklung, Werkzeuge und Sicherheit

Die Entwicklung begann mit Möglichkeiten, Benutzereingaben an Webserver zu übertragen. Das HTML-Formular erschien erstmals im Entwurf für „HTML+“ vom 8. November 1993; bereits die erste HTML-Version von Tim Berners-Lee bot mit dem „Isindex“-Tag eine frühe Möglichkeit, Parameter an den Webserver zu senden. Das erste größere System dieser Art war sehr wahrscheinlich ein Web-Interface für „SPIRES-HEP“, das 1991 an der Stanford-Universität online ging. Der NCSA Mosaic 2.0 unterstützte im Dezember 1993 umfangreich HTML-Formulare. Am 4. November 1993 wurde „htbin“ veröffentlicht, am 11. Februar 1994 folgte die CGI-Schnittstelle. Im Frühjahr 1997 veröffentlichte Sun Microsystems die Servlet-Technologie. Später ermöglichten PHP, JavaServer Pages und Active Server Pages eine bessere Trennung von Logik und Inhalt. AJAX und anschließend Single-Page-Webanwendungen verstärkten die clientseitige Ausführung. Als akademische Disziplin überträgt Web Engineering Methoden des Software Engineering auf Webanwendungen.

Typische Werkzeuge sind Webframeworks wie ASP.NET MVC, Spring und Symfony für Datenhaltung, Datenverarbeitung und Darstellung, Vaadin für serverseitige ereignisbasierte Benutzeroberflächen, CSS-Frameworks wie Bootstrap für grafische Oberflächen und Responsive Webdesign sowie JavaScript-Frameworks wie Sencha Touch, jQuery UI und AngularJS für funktionale und ereignisbasierte Oberflächen und asynchrone Datenübertragung.

Wichtige Angriffsmöglichkeiten sind SQL-Injection, Cross-Site-Scripting (XSS), Session Hijacking, Cross-Site-Request-Forgery, Directory Traversal und E-Mail-Injection. Angriffe im Umfeld sind Man-in-the-Middle-Angriffe, Denial of Service und Phishing. Sicherheitslücken können durch sichere Implementierung vermieden oder durch vorgeschaltete Web Application Firewalls erschwert beziehungsweise abgewehrt werden.