Herr E-Mark: Die Seite wurde neu angelegt: „Eine '''Webanwendung''' (auch '''Online-Anwendung''', '''Webapplikation''' oder kurz '''Web-App''') ist ein Anwendungsprogramm nach dem Client-Server-Mod…“

2018-08-28T07:00:35Z

Die Seite wurde neu angelegt: „Eine '''Webanwendung''' (auch '''Online-Anwendung''', '''Webapplikation''' oder kurz '''Web-App''') ist ein Anwendungsprogramm nach dem Client-Server-Mod…“

Neue Seite

Eine '''Webanwendung''' (auch '''Online-Anwendung''', '''Webapplikation''' oder kurz '''Web-App''') ist ein [[Anwendungsprogramm]] nach dem [[Client-Server-Modell]]. Anders als klassische [[Desktopanwendung]]en werden Webanwendungen also nicht lokal auf dem Rechner des Benutzers installiert und dort ausgeführt. Die Datenverarbeitung und -auswertung findet stattdessen hauptsächlich auf einem entfernten [[Webserver]] statt. Nur das Ergebnis der Datenverarbeitung wird zur Anzeige oder Ausgabe an den lokalen Client-Rechner des Benutzers übertragen ([[Thin Client]]). Genutzt wird eine Webanwendung dabei in der Regel über einen [[Webbrowser]]. Dieser übernimmt die Kommunikation mit dem Webserver (meist über das [[HTTP|HTTP-Protokoll]]) sowie die Darstellung der [[Grafische Benutzeroberfläche|Benutzeroberfläche]].

Im Gegensatz zu herkömmlichen [[Desktopanwendung]]en erfordern Webanwendungen kein spezielles [[Betriebssystem]] auf dem Rechner des Benutzers. Unter Umständen funktionieren sie aber nur mit bestimmten Webbrowserversionen oder benötigen spezielle [[Laufzeitumgebung]]en, wie z. B. [[JavaScript]] oder [[Adobe Flash|Flash]].

Durch die Nutzung zusätzlicher Techniken wie z. B. JavaScript, können Teile der Ausführungslogik vom Server auf den Client Rechner ausgelagert werden. Genutzt wird dies vor allem für die [[Validierung (Informatik)|Validierung]] eingegebener Daten bevor diese für die Verarbeitung an den Server gesendet werden. Eingabefehler werden so bereits lokal erkannt. Rückmeldungen an den Nutzer erfolgen umgehend, ohne Verzögerungen die bei einer Kommunikation mit dem Server auftreten würden. Dies lässt sich durch Einsatz der [[Ajax (Programmierung)|AJAX-Technik]] noch erweitern. Hierbei werden nur einzelne Teilbereiche der Inhalte im Webclient aktualisiert, ohne einen typischen Seitenwechsel durchzuführen. Eine solche Verteilung kann bis hin zu einer [[Fat Client|Fat-Client-Architektur]] ausgebaut werden (siehe [[Single-page-Webanwendung]]en).

Durch die Verbreitung internetfähiger, mobiler Endgeräte, vor allem [[Smartphone]]s und [[Tabletcomputer]]n, und die Relevanz von [[Mobile App|mobilen Apps]] für diese, verbreitet sich die Verwendung der Abkürzung ''Web-App'' im allgemeinen Sprachgebrauch zunehmend.

== Funktionsweise ==
=== Allgemeine Funktionsweise ===
[[Datei:Webanwendung client server 01.png|mini|Schematischer Datenfluss bei einer Client-Server-Webanwendung]]
Der Benutzer startet eine Webanwendung, indem er z. B. in einem Browser die [[Uniform Resource Locator|URL]] des Webservers eingibt und damit die erste Anfrage ([[Hypertext Transfer Protocol|HTTP-Request]]) sendet. Der Webserver nimmt diese Anfrage entgegen und übergibt sie an die Webanwendung. Dieses generiert oder lädt daraufhin den [[Hypertext Markup Language|HTML-Quellcode]] einer Webseite, welche vom Webserver zurück an den Browser des Benutzers geschickt wird (HTTP-Response). Diese [[Webseite]] ist die grafische Benutzeroberfläche der Webanwendung. Betrachtet man die [[Schichtenarchitektur]] einer Webanwendung, so wird die [[Schichtenarchitektur#Präsentationsschicht|Präsentationsschicht]] im Webbrowser ausgeführt (Thin Client). Während die Logikschicht und Datenhaltung serverseitig ausgeführt werden.

Durch das Anklicken eines [[Hyperlink]]s auf dieser Webseite oder durch das Ausfüllen und Absenden eines Formulars startet der Benutzer 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 eines [[HTTP-Cookie]] an den Webserver übermittelt und als Eingabe durch die Webanwendung verarbeitet. Über Schnittstellen wie z. B. das [[Common Gateway Interface]] oder [[FastCGI]] 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 auch [[Request Cycle]].

Typischerweise entstehen bei der Benutzung einer Webanwendung Daten, die dauerhaft gespeichert werden müssen, sogenannte ''[[Sitzung (Informatik)|Sessiondaten]]'' (z. B. Bestelldaten eines Webshops). Solche persistenten Daten werden serverseitig durch Datenbankserver oder auch in Dateien gespeichert. Benutzerbezogene Daten können ebenfalls clientseitig durch HTTP-Cookies gespeichert werden. Zu beachten ist, dass serverseitige Sitzungsinformationen - je aktive Benutzersitzung - Serverressource verbrauchen. Ebenfalls erschweren serverseitige Sitzungsinformationen eine horizontale Skalierung der Webanwendungen. Alternative Architekturansätze für Webanwendungen wie [[Single-page-Webanwendung]]en oder das [[Representational State Transfer|REST-Paradigma]] sehen daher den Einsatz von clientseitigen Lösungen vor.

Während eine Webanwendung ursprünglich nur den HTML-Quellcode der Webseiten generiert hat, werden inzwischen auch beliebige andere Elemente erzeugt. Dazu gehören vor allem Bilder, Animationen, Videos, Audiodateien und PDF-Dokumente.

=== Funktionsweise mobiler Web-Apps ===
{{Hauptartikel|Mobile App#Web-Apps|titel1=Mobile Web-Apps}}

Webanwendungen weisen den Vorteil auf, dass sie auf beliebigen Endgeräten betrieben werden können. Das Endgerät benötigt lediglich einen Webbrowser, welcher die erforderlichen Webstandards (wie [[HTML5]] oder [[JavaScript]]) unterstützt. Im Bereich von mobilen Anwendungen existieren verschiedene Plattform-spezifische Schnittstellen zur Anwendungsentwicklung. Beim Einsatz dieser Schnittstellen muss für jede Zielplattform eine eigene Implementierung umgesetzt werden. Solche Umsetzungen werden als native App bezeichnet. Webanwendungen ermöglichen es hingegen, eine Anwendung umzusetzen, welche auf allen Plattformen ausgeführt werden kann. Sie werden als mobile Web-App bezeichnet.

== Architektur ==
Eine Webanwendung läuft in der Regel auf dem Webserver, kann aber insbesondere im professionellen Bereich auch auf einen oder mehrere Applicationserver ausgelagert sein, welche von einem oder mehreren Webservern mit Benutzeranfragen bedient werden. Dabei kann man grundsätzlich 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 (Programmiersprache)|Perl]], [[Python (Programmiersprache)|Python]], [[Ruby (Programmiersprache)|Ruby]] (jeweils durch entsprechende Module des Webservers interpretiert), Java [[Servlet]], [[JavaServer Pages]] oder [[ASP.NET]].

== Verteilungsvarianten ==
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. Auf diese Weise werden die serverseitigen Ressource entlastet <ref name="SPAWandel">[http://www.w3l.de/de/fileadmin/user_upload/Single-page_Webanwendungen_2015.pdf Beschreibung des Wandels von Webanwendungen (SPA)]</ref>. Diese Ansätze sind insbesondere für [[Business-to-Consumer|B2C]]-Anwendungen - wie z. B. [[Facebook]] oder [[Gmail]] - relevant, da bei solchen Projekten mit großen Benutzerzahlen zu rechnen ist. Es kann ebenfalls die [[User 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
: Eine [[Rich Internet Application]] (RIA) setzt per Definition ein höheres Maß an Programmlogik auf dem Client voraus, mit dem beispielsweise Berechnungen anstatt auf dem Server nunmehr auf dem Client durchgeführt werden können. Strenggenommen handelt es sich bei Webprojekten mit Webanwendungen, die JavaScript (incl. AJAX), Java Applets, Flash-Animationen, ActiveX-Plugins u. ä. einsetzen, auch um RIAs, sofern diese Elemente an der Interaktion mit dem Benutzer beteiligt sind.
; Single-page-Webanwendungen
: Eine [[Single-page-Webanwendung]] kombiniert den RIA-Ansatz mit Webservices. Hierbei wird die vollständige Präsentationsschicht einer Webanwendung [[Client|clientseitig]] 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 <ref name="SPAWandel" />. 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. per [[Representational State Transfer|REST-API]]). Durch solche Ansätze entstehen häufig sogenannte [[Hybrid-App]]s. 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.

== Abgrenzung ==

; Webservice
: Mit einem [[Webservice]] stellt ein Webserver Informationen in einem strukturierten Format zur Verfügung, das nicht primär zur direkten Anzeige gedacht ist. Die Verwendung von [[Extensible Markup Language|XML]] genügt alleine nicht zur Abgrenzung gegen eine Webanwendung, da diese seit der Einführung von [[Extensible Hypertext Markup Language|XHTML]] auch auf XML zurückgreifen. Bei einem Webservice sind die 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 das [[JavaScript Object Notation|JSON-Format]] eingesetzt. Dies bietet Vorteile bei der Konsumierung durch einen Javascript-basierten Webclient, da so das zusätzliche Parsen von XML-Strukturen entfällt.

== Vergleich ==
=== Vorteile ===
Webanwendungen setzen auf dem Computer des Benutzers nur einen Webbrowser voraus, welcher auf den meisten Systemen schon vorhanden ist. Im Gegensatz zu herkömmlichen Client-Server-Anwendungen ist also keine weitere Installation von Software auf den Computern der Benutzer notwendig, wenn man von Browser-Plugins wie Flash absieht. Dadurch erreichen Webanwendungen einen hohen Grad an [[Plattformunabhängigkeit]], sofern bei der Entwicklung darauf geachtet wurde, dass alle Browser unterstützt werden.

Muss die Logik einer Webanwendung geändert werden, sind Änderungen nur an einer zentralen Stelle – nämlich auf dem Webserver – notwendig, was sich günstig auf die Wartungskosten auswirkt. Hierdurch ergeben sich auch spezielle Sicherheitsvorteile: Sicherheitslücken können sofort behoben werden, außerdem sind selbst bei vollständiger Kompromittierung der Webanwendung im Regelfall keine anderen Programme auf dem Anwender-System gefährdet.

=== Nachteile ===
Für die Nutzung einer Webanwendung wird eine Verbindung zum Webserver benötigt. Die [[Datenrate]] der Verbindung muss außerdem auf die Anforderungen der Webanwendung ausgelegt sein. Dieser Umstand schließt Webanwendungen für eine Reihe von Einsatzszenarien, wie z. B. die mobile Offline-Benutzung, per Definition 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, was nicht selbstverständlich ist, 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äufig [[Browserweiche]]n 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.

== Geschichte ==
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.<ref>[http://www.w3.org/MarkUp/htmlplus_paper/htmlplus.html A Review of the HTML+ Document Format]</ref> Aber schon die erste HTML-Version von [[Tim 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 der [[Stanford-Universität]].<ref>[http://www.slac.stanford.edu/history/earlyweb/index.shtml slac.stanford.edu]</ref> 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 wurde [[C (Programmiersprache)|C]] oder [[Perl (Programmiersprache)|Perl]] 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 Webverzeichnis [[Yahoo]]. Als Programmiersprache verwendeten sie Perl.

In den folgenden Jahren gab es Weiterentwicklungen der CGI-Schnittstelle, welche die Performance verbesserten. Im Frühjahr 1997 veröffentlichte Sun 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 Sprache [[PHP]], die um das Jahr 1997 aus einem Perl basierten Projekt entstand, [[JavaServer Pages]], die auf Servlets basieren, und [[Active Server Pages|Active 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 der [[New Economy]] bauten ihr Geschäftsmodell auf einer Webanwendung auf. Die übertriebenen Erwartungen führten 2001 zum Platzen der sogenannten [[Dotcom-Blase]]. In dieser Zeit wurden aber auch Webanwendungen wie z. B. [[eBay]], [[Yahoo]] und [[Google]] geboren, die heute zu einem selbstverständlichen Teil des Web-Lebens geworden sind.

Seit dem Einzug von [[Ajax (Programmierung)|AJAX]] werden bei Webanwendungen zunehmenden 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 mit [[JavaScript]] umgesetzt und im Webbrowser ausgeführt. Der klassische Seitenwechsel ist hierdurch nicht mehr zwingend erforderlich, um neue Seiteninhalte darzustellen. Das Paradigma von [[Single-page-Webanwendung|Single-page-Webanwendungen]] basiert auf einer ausschließlich clientseitigen Ausführung der Präsentationsschicht einer Webanwendung.

Als akademische Disziplin ist das [[Web Engineering]] entstanden, das Methoden des [[Software Engineering]] auf die Entwicklung von Webanwendungen überträgt.

== Frameworks und Werkzeuge ==
Es gibt unterschiedliche [[Framework]]s zur Erstellung von Web-Apps:

* [[Webframework]]s zur Datenhaltung, -datenverarbeitung und -darstellung (wie [[ASP.NET MVC]], [[Spring (Framework)|Spring]] oder [[Symfony]])
* [[CSS-Framework]]s für grafische Benutzeroberflächen besonders für [[Responsive Webdesign]] (wie [[Bootstrap (Framework)|Bootstrap]])
* JavaScript-Frameworks für grafische funktionale und [[Ereignis (Programmierung)|eventbasierte]] Benutzeroberflächen und [[Ajax (Programmierung)|asynchrone Datenübertragung]] (wie [[Ext JS|Sencha Touch]], [[jQuery UI]] oder [[AngularJS]].)

{{Siehe auch|Liste von Webframeworks}}

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 ==
{{Hauptartikel|Sicherheit von Webanwendungen}}
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 vorgeschalteten [[Web Application Firewall]]s erschwert oder abgewehrt werden.

* [[SQL-Injection]] – Anfrageparameter mit SQL-Steuerzeichen versehen
* [[Cross-Site-Scripting]] (XSS) – Einbinden von fremden Skripten zu Manipulation des Webauftritts
* [[Session Hijacking]] – Übernehmen einer Benutzersitzung
* [[Cross-Site Request Forgery]] – Webclient auf andere URLs lenken
* [[Directory Traversal]] – Manipulation von Pfadangaben, um auf beliebige serverseitige Ressource zuzugreifen
* [[E-Mail-Injection]] – Versenden von eigenen Emails über Kontaktformulare

Die folgenden Angriffe richten sich nicht gegen die Webanwendung selbst, sind aber in deren Umfeld häufig zu finden:

* [[Man-In-The-Middle-Angriff]] – Mithören während der Client-Server-Kommunikation
* [[Denial of Service]] – Überlastung des Webservers, sodass keine Anfragen mehr entgegen genommen werden können
* [[Phishing]] – Kundendaten über gefälschte E-Mails oder Webauftritte stehlen

== Beispiele ==
Einige Beispiele finden sich in der [[:Kategorie:Webanwendung]].

== Externe Links ==
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/WebSec/WebSec_pdf.pdf Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen] vom [[Bundesamt für Sicherheit in der Informationstechnik]] (BSI)
* [http://projects.webappsec.org/Threat-Classification-Previous-Versions Web Security Threat Classification]

== Einzelnachweise ==
<references />

[[Kategorie:Webanwendung| ]]
[[Kategorie:Benutzerschnittstelle]]

Webanwendung - Versionsgeschichte

Herr E-Mark: Die Seite wurde neu angelegt: „Eine '''Webanwendung''' (auch '''Online-Anwendung''', '''Webapplikation''' oder kurz '''Web-App''') ist ein Anwendungsprogramm nach dem Client-Server-Mod…“