EineWebanwendung (auchOnline-Anwendung,Webapplikation oder kurzWeb-App) ist einAnwendungsprogramm, das auf Techniken desWorld Wide Webs basiert und über einenWebbrowser ausgeführt wird. Anders alsDesktopanwendungen odermobile Apps werden Webanwendungen nicht auf dem Client-Gerät des Benutzers installiert und erfordern kein speziellesBetriebssystem. Webanwendungen dienen meist zur Nutzung einesOnlinediensts.
Die meisten Webanwendungen funktionieren nach demClient-Server-Modell. Dabei kommuniziert derWebbrowser auf dem lokalen Gerät des Benutzers mit einem entferntenWebserver, der dann dieDatenverarbeitung durchführt und die Ergebnisse an den Webbrowser zurücksendet.
Teile der Ausführungslogik führt man dennoch möglichst nicht erst auf dem Server, sondern bereits auf dem Client-Gerät aus, vor allem zur vorläufigenValidierung. Eingabefehler werden so bereits lokal erkannt. Rückmeldungen an den Nutzer erfolgen dadurch sofort ohne ein Warten auf die Rückantwort von einem fernen Server.MittelsAjax-Technik werden nur Teilbereiche der Inhalte im Webclient aktualisiert, ohne die Webseite erneut aufrufen zu müssen.Eine solche Verteilung kann bis hin zu einerFat-Client-Architektur ausgebaut werden (sieheSingle-Page-Webanwendungen).
Schematischer Datenfluss bei einer Client-Server-Webanwendung
Man startet eine Webanwendung, indem man z. B. im Browser dieURL des Webservers eingibt und damit eine Anfrage (HTTP-Request) sendet. Der Webserver nimmt die Anfrage entgegen und übergibt sie an die Webanwendung. Dieses erzeugt oder lädt denHTML-Quellcode einer Webseite, welche vom Webserver zurück zum Browser des Benutzers geschickt wird (HTTP-Response). DieseWebseite ist die grafische Benutzeroberfläche der Webanwendung. Betrachtet man dieSchichtenarchitektur einer Webanwendung, wird diePräsentationsschicht im Webbrowser ausgeführt (Thin Client). Teile der Logikschicht und Datenhaltung werden serverseitig ausgeführt.
Durch Anklicken einesHyperlinks auf dieser Webseite oder Ausfüllen und Absenden eines Formulars startet man eine erneute Anfrage an den Webserver. Hierbei werden typischerweise weitere Informationen, wie z. B. die in dem Formular getätigten Eingaben (HTTP POST), die Parameter des Links (HTTP GET) und die Daten einesHTTP-Cookie an den Webserver übermittelt und als Eingabe durch die Webanwendung verarbeitet. Über Schnittstellen wie z. B. dasCommon Gateway Interface oderFastCGI wird die Webanwendung innerhalb des Webservers eingebunden. Auf diese Weise werden Anfragen an die Webanwendung weitergeleitet und die Ausgaben der Webanwendung als Antwort zurückgesendet. Die Abarbeitung eines solchen HTTP-Requests durch die Webanwendung nennt man auchRequest Cycle.
Bei der Benutzung von Web-Apps werdenSessiondaten (z. B. Bestelldaten eines Webshops) serverseitig in Datenbanken oder Dateien gespeichert. Benutzerbezogene Daten können auch clientseitig durch HTTP-Cookies gespeichert werden. Serverseitige Sitzungsinformationen verbrauchen – je aktive Benutzersitzung – Serverressourcen. Ebenfalls erschweren serverseitige Sitzungsinformationen eine horizontale Skalierung der Webanwendungen. Alternative Architekturansätze für Webanwendungen wieSingle-Page-Webanwendungen oder dasREST-Paradigma kombinieren daher die serverseitige mit der clientseitigen Ausführung.
Während eine Webanwendung einst nur den HTML-Quellcode der Webseiten erzeugte, werden seither auch Bilder, Animationen, Videos, Audiodateien und PDF-Dokumente erzeugt.
Webanwendungen weisen den Vorteil auf, dass sie auf beliebigen Endgeräten betrieben werden können. Das Endgerät benötigt einenWebbrowser, der die erforderlichen Webstandards (wieHTML5 oderJavaScript) unterstützt. Im Bereichmobiler Apps existieren Plattform-spezifische Schnittstellen zur Anwendungsentwicklung. Hierbei muss für jede Zielplattform eine eigene Implementierung umgesetzt werden. Solche Umsetzungen werden als native App bezeichnet. Webanwendungen können hingegen auf allen Plattformen ausgeführt werden. Sie werden als mobile Web-App bezeichnet.
Eine Webanwendung läuft in der Regel auf dem Webserver, kann aber auch auf einen oder mehrere Applicationserver ausgelagert sein, welche von einem oder mehreren Webservern mit Benutzeranfragen bedient werden. Dabei kann man zwei Architekturen unterscheiden:
Standalone
Die Webanwendung ist ein eigenständiges Binärprogramm oder ein von einem eigenständigen Binärprogramm interpretiertes Skript, welches für jede Anfrage neu gestartet wird. Man nennt solche Anwendungen meist CGI-Programme.
Integriert
Die Webanwendung ist Teil des Webservers oder ein vom Webserver interpretiertes Skript. Es muss nicht mehr für jeden Request Cycle ein Programm gestartet werden. Beispiele:PHP,Perl,Python,Ruby (jeweils durch entsprechende Module des Webservers interpretiert), JavaServlet,JavaServer Pages oderASP.NET.
Eine Webanwendung wird klassischerweise verstärkt serverseitig ausgeführt. Als Verteilungsvarianten liegen ebenfalls Ansätze vor, welche eine client-lastigere Ausführung einer Webanwendung vorsehen. Der Webclient wird hierbei zu einer zunehmenden unabhängigen Einheit, um serverseitige Ressourcen zu entlasten[1]. Diese Ansätze sind insbesondere fürB2C-Anwendungen – wie z. B.Facebook oderGmail – relevant, da bei solchen Projekten mit großen Benutzerzahlen zu rechnen ist. Es kann ebenfalls dieUser Experience verbessert werden, da nicht für jede Interaktion mit dem Webclient eine Client-Server-Kommunikation ausgelöst werden muss, welche die Reaktionszeiten von Webanwendungen verlangsamt.
Rich Internet Application
EineRich Internet Application (RIA) setzt per Definition ein höheres Maß an Programmlogik im Client voraus, um beispielsweise Berechnungen anstatt auf dem Server auf dem Client durchzuführen. Strenggenommen handelt es sich bei Webprojekten mit Webanwendungen, dieJavaScript (inkl.Ajax),Java-Applets etc. einsetzen, auch um RIAs, sofern diese Elemente an der Interaktion mit dem Benutzer beteiligt sind.
Single-Page-Webanwendungen
EineSingle-Page-Webanwendung (SPA) kombiniert den RIA-Ansatz mitWebservices. Hierbei wird die vollständige Präsentationsschicht einer Webanwendungclientseitig umgesetzt. Ebenfalls können weitere Funktionalitäten des serverseitigen Fachkonzepts sowie eine Datenhaltung als Zwischenspeicher für einen Offlinebetrieb der Webanwendungen auf dem Client ausgeführt werden.[1] Es handelt sich somit um eine Fat-Client-Architektur für Webanwendungen. Bei diesem Ansatz ist der Webserver lediglich für die Verteilung von Javascript-, CSS- und Bilddateien und für die Bereitstellung von Nutzdaten über Webservices verantwortlich (z. B. perREST-API). Durch solche Ansätze entstehen häufig sogenannteHybrid-Apps. Sie vereint die Vorteile von Native Apps und Web-Apps, indem sie auf die Softwarekomponenten des mobilen Endgeräts zugreifen und gleichzeitig unterschiedliche Plattformen bedienen kann.
Mit einemWebservice stellt ein Webserver Informationen in einem strukturierten Format zur Verfügung, das nicht primär zur direkten Anzeige gedacht ist. Die Verwendung vonXML genügt alleine nicht zur Abgrenzung gegen eine Webanwendung, da diese seit der Einführung vonXHTML auch auf XML zurückgreifen. Bei einem Webservice sind XML-Daten aber zur Weiterverarbeitung in einem beliebigen Programm auf dem Client gedacht. Hierbei ist selbst die Interaktion mit einem Benutzer keine zwingende Voraussetzung. Als Datenformat wird ebenfalls dasJSON-Format eingesetzt. Dies bietet Vorteile bei der Konsumierung durch einen Javascript-basierten Webclient, da so das Parsen von XML-Strukturen entfällt.
Webanwendungen setzen auf dem Computer des Benutzers nur einen Webbrowser voraus, welcher in der Regel schon vorhanden ist. Im Gegensatz zu herkömmlichen Desktop-Anwendungen ist keine weitere Installation von Software notwendig, wenn man von Browser-Plugins wie Flash absieht. Dadurch erreichen Webanwendungen einen hohen Grad anPlattformunabhängigkeit, sofern viele Browser unterstützt werden.
Muss die Logik einer Webanwendung geändert werden, sind Änderungen nur an einer zentralen Stelle – auf dem Webserver – notwendig, was sich günstig auf die Wartungskosten auswirkt. Hierdurch ergeben sich auch Sicherheitsvorteile: Sicherheitslücken können sofort behoben werden, auch sind selbst bei vollständiger Kompromittierung der Webanwendung im Regelfall keine anderen Programme auf dem Anwender-System gefährdet.
Für die Nutzung einer Webanwendung wird eine Verbindung zum Webserver benötigt. DieDatenrate der Verbindung muss außerdem auf die Anforderungen der Webanwendung ausgelegt sein. Dieser Umstand schließt Webanwendungen für eine Reihe von Einsatzszenarien, wie Zugriff auf gewisse native Schnittstellen aus. Webanwendungen identifizieren angemeldete Benutzer per Session-ID. Daraus können sich Sicherheitsprobleme ergeben (siehe unten).
Webanwendungen sollten im Idealfall mit allen Webbrowsern richtig funktionieren. In der Praxis ist dies allerdings keineswegs selbstverständlich, da die Browser HTML – trotz bestehender Standards (W3C) – unterschiedlich interpretieren. Die leichte Abweichung in der Darstellung zwischen verschiedenen Browsern ist meist unerheblich, verheerender sind Unterschiede in der JavaScript-Interpretation, weshalb häufigBrowserweichen verwendet werden müssen, teilweise sogar für unterschiedliche Browser-Versionen. Außerdem ist durch den oben dargestellten Request-Cycle nur eine asynchrone Verarbeitung möglich, was eine Reihe von Anwendungsgebieten (z. B. die Bearbeitung von Videos) als Webanwendung ausschließt oder deutlich erschwert. Weiterhin sind die Möglichkeiten zur Implementierung von Nutzerinteraktionsmöglichkeiten sowie der Zugriff auf Hardwareressourcen des Clients deutlich eingeschränkter.
Für eine Webanwendung ist es notwendig, Benutzereingaben zu empfangen. Die heute hierfür verwendeten HTML-Formulare sind erstmals im Entwurf für „HTML+“ vom 8. November 1993 enthalten.[2] Aber schon die erste HTML-Version vonTim Berners-Lee bot mit dem „Isindex“-tag eine Möglichkeit, Parameter an den Webserver zu schicken. Die Parameter wurden dabei an die URL angehängt, der Vorläufer der HTTP-Get-Methode.Das erste größere System, das hiervon Gebrauch machte, war sehr wahrscheinlich ein Web Interface zum "SPIRES-HEP", einer Datenbank derStanford-Universität.[3] Dieser Urahn aller heutigen Webanwendungen ging 1991 online.
Der erste Webbrowser, der eine umfangreiche Unterstützung für HTML-Formulare implementierte, war der NCSA Mosaic 2.0 im Dezember 1993; damals der Browser mit der größten Verbreitung. Die erste serverseitige Schnittstelle zum Empfang von Formulardaten war „htbin“. Diese wurde am 4. November 1993 als Teil der Version 2.13 des W3C-HTTP-Servers veröffentlicht. Bereits am 11. Februar 1994 folgte im Release 2.15 beta die CGI-Schnittstelle, die bis heute im Gebrauch ist. CGI ist von der verwendeten Programmiersprache unabhängig. Für die ersten Webanwendungen wurdeC oderPerl verwendet. Perl bot sich wegen der mächtigen Funktionen zur Verarbeitung von Zeichenketten an.
Die erste Webanwendung, die von einer breiten Öffentlichkeit wahrgenommen wurde, entstand ebenfalls an der Stanford-Universität. Zwei Studenten entwickelten aus ihrer persönlichen Bookmarkverwaltung das WebverzeichnisYahoo. Als Programmiersprache verwendeten sie Perl.
In den folgenden Jahren gab es Weiterentwicklungen der CGI-Schnittstelle, welche die Performance verbesserten. Im Frühjahr 1997 veröffentlichteSun Microsystems die Servlet Technologie. Servlets sind Java-Programme, die CGI-Programmen sehr ähnlich sind. Der Hauptunterschied besteht darin, dass ein HTTP-Request nicht in einem eigenen Prozess, sondern lediglich einem eigenen Thread abgearbeitet wird. Dies brachte einen gewaltigen Performancegewinn.
Das Verfahren, Webseiten aus HTML-Code zusammenzusetzen, der fest im Programmcode hinterlegt war, barg jedoch ein großes Problem: Es war umständlich zu programmieren und ermöglichte keine Trennung von Logik und Inhalt. Dieses Problem wurde von mehreren Seiten auf ähnliche Weise gelöst. Der Programmcode für die dynamisch erzeugten Ausgaben wurde in das sonst statische HTML eingebettet. Diesen Ansatz verfolgen die SprachePHP, die um das Jahr 1997 aus einem Perl basierten Projekt entstand,JavaServer Pages, die auf Servlets basieren, undActive Server Pages (ASP) von Microsoft.
In der Zeit des großen Internet-Booms um die Jahrtausendwende erlebten Webanwendungen einen gewaltigen Schub. Viele der von der Börse gefeierten Firmen derNew Economy bauten ihr Geschäftsmodell auf einer Webanwendung auf. Die übertriebenen Erwartungen führten 2001 zum Platzen der sogenanntenDotcom-Blase. In dieser Zeit wurden aber auch Webanwendungen wie z. B.eBay, Yahoo undGoogle geboren, die heute zu einem selbstverständlichen Teil des Web-Lebens geworden sind.
Seit dem Einzug vonAJAX werden bei Webanwendungen zunehmend die clientseitigen Ressourcen beim Betrieb der Anwendung einbezogen. Durch den Wunsch nach mehr Interaktivität wurde es nötig, mehr Inhalte per AJAX nachzuladen und die DOM-Struktur der aktuellen Ansicht dynamisch zu erweitern. Die hierzu benötigte Steuerungslogik wird mitJavaScript umgesetzt und im Webbrowser ausgeführt. Der klassische Seitenwechsel ist hierdurch nicht mehr zwingend erforderlich, um neue Seiteninhalte darzustellen. Das Paradigma vonSingle-Page-Webanwendungen basiert auf einer ausschließlich clientseitigen Ausführung der Präsentationsschicht einer Webanwendung.
Als akademische Disziplin ist dasWeb Engineering entstanden, das Methoden desSoftware Engineering auf die Entwicklung von Webanwendungen überträgt.
Durch die Verbreitung internetfähiger, mobilerSmartphones undTabletcomputer verbreitet sich die Verwendung der AbkürzungWeb-App zunehmend.
Die Kompetenzen von klassischen Webdesignern und mobilen Web-App-Entwicklern unterscheiden sich maßgeblich in dem Punkt, dass der Fokus im mobilen Internet im Kontext und nicht (nur) im Inhalt liegt. Besonders das User Interface ist ein wichtiger Faktor bei der Entwicklung von mobilen Web-Apps.
Sicherheit von Webanwendungen ist ein zu weites Feld, um es hier allumfassend zu behandeln. Darum beschränkt sich dieser Abschnitt auf die Beschreibung allgemein bekannter Angriffsmöglichkeiten im Zusammenhang mit Webanwendungen. Angriffe gegen eine Webanwendung können durch die Vermeidung von Sicherheitslücken während der Implementation verhindert, oder durch den Einsatz von vorgeschaltetenWeb Application Firewalls erschwert oder abgewehrt werden.
SQL-Injection – Anfrageparameter mit SQL-Steuerzeichen versehen
Cross-Site-Scripting (XSS) – Einbinden von fremden Skripten zu Manipulation des Webauftritts
