SQL-Injection

Bei einer SQL-Injection sendet der Angreifer Verbindungsanfragen an den Webserver, wobei die Anfrage-Parameter mit SQL-Steuerzeichen versehen sind. Fängt die Webanwendung diese Steuerzeichen nicht ab, sondern sendet sie als Teil einer SQL-Abfrage an die Datenbank, kann der Angreifer für ihn auf herkömmlichem Weg nicht zugängliche Daten entweder auslesen oder verändern.

Cross-Site-Scripting

Hinter der Bezeichnung Cross-Site-Scripting (XSS) verbergen sich zwei (manchmal wird noch ein dritter Typ unterschieden) grundsätzlich verschiedene Angriffe. Beim clientseitigen XSS schleust der Angreifer HTML-Steuerzeichen und Code einer clientseitigen Skriptsprache, wie z. B. JavaScript, in eine Webseite ein, die in dem Webbrowser des Opfers ausgeführt wird. Dieser Angriff nutzt dabei Sicherheitslücken bei der lokalen Ausführung der Skripte aus oder leitet eine Cross-Site-Request-Forgery ein. Unter serverseitigem XSS versteht man das Einschleusen von manipulierten Informationen in eine auf dem Webserver ausgeführte Scriptsprache, so dass diese beispielsweise bei einem dynamisch generierten include() eine vom Programmierer nicht vorgesehene Datei (ggf. sogar von einem anderen Server) ausführt.

Session Hijacking

Da HTTP ein verbindungsloses Protokoll ist, muss die Webanwendung selbst die Identifikation eines Benutzers feststellen. Dies geschieht anhand einer Session-ID, die als Basic/Digest Authentication, Cookie, URL-Rewriting oder HTTP-Form-Parameter (GET oder POST) jedem Request mitgegeben wird. Beim Session Hijacking versucht der Angreifer Kenntnis von der Session-ID des Benutzers zu erlangen, um dann die Identität des Opfers vorzutäuschen und mit dessen Rechten auf die Webanwendung zuzugreifen.

Cross-Site-Request-Forgery

Cross-Site-Request-Forgery setzen eine bestehende Session zwischen dem Benutzer und der Webanwendung voraus. Dabei versucht der Angreifer über verschiedene Techniken (ggf. XSS) den Benutzer oder über ein clientseitiges Script auch direkt den Browser zum Aufruf einer manipulierten URL zu bewegen. Anders als beim Session-Hijacking erlangt der Angreifer selbst aber keine Kenntnis von der Session-ID, da der Angriff ausschließlich im Browser des Benutzers stattfindet.

Directory Traversal

Bei einem Directory-Traversal-Angriff nutzt der Angreifer die fehlende Prüfung der Webanwendung auf manipulierte Pfadangaben aus. Erwartet die Webanwendung beispielsweise einen Parameter wie item=datei1.html, kann dieser ggf. mit item=../../../Config.sys missbraucht werden.

E-Mail-Injection

Bei einer E-Mail-Injection fügt der Angreifer in ein Kontaktformular manipulierte Daten ein, so dass anstelle der Nachricht an den vom Betreiber der Webanwendung beabsichtigten Empfänger nun beliebige E-Mails an beliebige Empfänger gesendet werden. Diese Möglichkeit wird meist für den Versand von Spam missbraucht.

Man-in-the-Middle-Angriff

Bei einem Man-in-the-Middle-Angriff (MitM) zielt der Angreifer darauf ab, dass der Benutzer anstatt mit dem Webserver vielmehr direkt mit dem Rechner des Angreifers eine Verbindung aufbaut, ohne dies zu bemerken. Der „In-the-middle“-Rechner startet bei jeder Anfrage des Benutzers seinerseits eine Anfrage an den echten Webserver und gibt dessen Antwort an den Benutzer weiter. Der Nutzwert besteht für den Angreifer darin, Anfragen an oder Rückgaben der Webanwendung beliebig manipulieren zu können. Gegen diese Art von Angriff bietet nur die Verschlüsselung der Datenübertragung, beispielsweise mittels SSL, Schutz. Dieser Schutz wird aber unwirksam, wenn sich der Angreifer ein SSL-Zertifikat der betroffenen Webseite verschaffen kann, zu dem ein Root-Zertifikat im Browser des Opfers installiert ist.

Man-in-the-Browser

Man-in-the-Browser ist eine Sonderform des Man-in-the-middle-Angriffs, bei der die Darstellung von Webseiten direkt im Browser verändert wird. Das Programm kann eigenständig Transaktionen durchführen, die vom Nutzer im Normalfall nicht bemerkt werden, da der Nutzer sich auf den echten Seiten der Anbieter bewegt, korrekt angemeldet ist und die unerwünschten Transaktionen für den Nutzer wie normale Vorgänge angezeigt werden.

Denial of Service

Bei einem Denial of Service (DoS) Angriff versucht der Angreifer dem Webserver durch eine Vielzahl von Verbindungsanfragen den jeweiligen Server lahm zu legen. Wird der Angriff gleichzeitig von mehreren (ggf. mehrere tausend) Computern gleichzeitig durchgeführt, spricht man auch von einem Distributed-Denial-of-Service-Angriff (DDoS). Ein DoS ist nicht auf Webanwendungen beschränkt, sondern kann sich gegen jede Art von Server richten.

Phishing / Identitätsdiebstahl

Beim Phishing handelt es sich nicht um eine Sicherheitslücke einer Webanwendung, es gehört vielmehr in den Bereich des Social Hacking. Hierbei fordert der Angreifer seine potentiellen Opfer meist massenweise per E-Mail auf, Zugangsdaten, wie z. B. PIN und TAN zum Online Banking, auf einer Webseite einzugeben. Diese sieht in der Regel äußerlich so aus wie die des Betreibers der Webanwendung, unterliegt aber der Kontrolle des Angreifers. Nimmt das Opfer diese Fälschung nicht wahr und gibt seine Zugangsdaten preis, kann der Angreifer diese zu seinen Gunsten verwenden.

Data Validation

Die Validierung vor allem von Eingangsdaten ("input"), aber auch Ausgabedaten ("output") ist der wichtigste Bestandteil einer sicheren Webanwendung. Der Datenfluss ist nicht nur vom Benutzer zur Anwendung und umgekehrt, sondern auch zu den verschiedenen Subsystemen und von dort aus in die Ausgabe zu untersuchen. Im Idealfall werden alle Input- bzw. Output-Daten von einem zentralen "Data-Validation-Modul" (d. h. einem Programmteil zur Prüfung der Zulässigkeit von Daten) geprüft. In PHP lässt sich so etwas mit Funktionen lösen. Neben den offensichtlichen Eingabedaten in Formular-Variablen (engl. "form variable" wegen "form" = Formular) gibt es eine Reihe weiterer Quellen. Alternativ lässt sich Filterung einsetzen. Dies ist immer dann angebracht, wenn keine Nebenwirkungen zu befürchten sind oder wenn die Art der Datenverwendung gefährliche Zeichen oder Zeichenketten auf­grund ihrer Natur erlauben muss. Beispiel: Ein Forum, in dem über JavaScript diskutiert wird, kann nicht die Eingabe von <script> verbieten, muss dieses aber als HTML-Tag validieren. Bei der Filterung ist mit großer Umsicht vorzugehen, denn man läuft permanent Gefahr, eine Variante zu übersehen.

if (strlen($parameter) > 42) { return; };

Request.Form()
Request.QueryString()
Request.Cookies()
RangeValidator()
RegularExpressionValidator()
Server.HTMLEncode()
Server.URLEncode()

class java.sql.PreparedStatement
java.net.URLEncoder.encode()

CGI::autoEscape()
CGI::escapeHTML()

addslashes()
quote_meta()
mysql_real_escape_string()
pg_escape_string()
strip_tags()
htmlentities()
utf8_decode()

Minimalitätsprinzip

Beim Minimalitätsprinzip werden so wenige Informationen angegeben wie nötig, so dass sie für einen potenziellen Angreifer oder „Hacker“ nur schwer oder gar nicht zugänglich sind, um die Verwundbarkeit von Sicherheitslücken einzuschränken. Darüber hinausgehende Informationen könnten unnötige Ansatzpunkte für eine Kompromittierung der Webanwendung liefern.

URL-Weiterleitungen kontrollieren und einschränken

Weiterleitungen sind generell durch geeignete Maßnahmen vor Missbrauch zu schützen.

Sie werden auf die folgende externe Webseite weitergeleitet:
http://www.example.tld/angriff.foo
Aus Sicherheitsgründen führen wir die Weiterleitung nicht automatisch durch. Bitte
kontrollieren Sie den Link, und setzen Sie die Weiterleitung gegebenenfalls durch
einen Klick fort!

Anforderung an eine SessionID

Wird die Erzeugung der SessionID nicht einer ausgereiften API überlassen, sondern selbst implementiert, sind bestimmte Anforderungen zu beachten. Für diese Fälle sollten folgende Anforderungen berücksichtigt werden:

• Keine Verknüpfung mit extern bekannten oder erratbaren Daten. Dazu gehören: IP-Adresse des Clients, Uhrzeit, Prozess-ID, Attribute des Benutzers wie Geburtsdatum oder externe Schlüssel wie die E-Mail-Adresse.
• Hohe Zufälligkeit (Randomness): Das Erzeugungsmuster darf nicht aus einer Menge von Proben ableitbar sein.
• Die SessionID muss eine ausreichende Länge haben, um gegenüber Brute-Force-Angriffen – dem Durchprobieren aller Möglichkeiten – zu bestehen.
• Sie sollte ausschließlich über sichere Kanäle übertragen werden, wenn der Schutzbedarf der Anwendung dies erfordert.
• Die SessionID einer Anwendung, deren Schutzbedarf SSL erfordert, darf niemals versehentlich über eine unverschlüsselte Verbindung mit übertragen werden.
• Die Session selbst muss das kürzestmögliche Ablaufdatum haben, das für den jeweiligen Anwendungszweck gerade noch angemessen ist.

Bindung von zusätzlichen Parametern an die Session

Eine Session kann durch Einbeziehung von zusätzlichen Parametern (z. B. der IP-Adresse des Clients) als kennzeichnendes Merkmal zusätzlich geschützt werden, sofern die daraus resultierenden Probleme in Kauf genommen werden können. Als Beispiel hinterlegt die Anwendung bei der Instanziierung der Session die IP-Adresse des Clients und überprüft bei jedem Zugriff, ob diese mit der hinterlegten IP-Adresse weiterhin übereinstimmt. Ist das nicht der Fall, wird die Session invalidiert.

Nachteilig an diesem Lösungsansatz sind deutliche Beschränkungen in Bezug auf mögliche Einsatzumgebungen: Die Bindung der IP-Adresse an die Session funktioniert nicht oder nur eingeschränkt für all jene Benutzer, die sich hinter einem Proxy befinden. Das trifft z. B. auf größere Organisationen oder auch auf Kunden eines Internet-Access-Providers zu, der eine Proxy-Architektur einsetzt. In einer solchen Umgebung kann es vorkommen, dass im Verlaufe einer Applikations-Session der ausgehende Proxy oder Router bzw. die IP dessen wechselt und damit bei der Webanwendung eine andere IP-Adresse registriert wird. Als weitere Hindernisse sind software- und netzwerktechnische Gegebenheiten zu nennen, die dazu führen können, dass bei der Webanwendung die IP-Adresse des zugreifenden Benutzers gar nicht ankommt, sondern nur diejenige eines vorgeschalteten Reverse-Proxy oder einer anderen Komponente im eigenen Netz. Eingesetzt werden kann der vorgeschlagene Lösungsansatz jedoch in jenen Anwendungssituationen, in denen die oben genannten Nachteile nicht eintreten oder toleriert werden können. So z. B. sind die beschriebenen Hindernisse in der Regel in Intranet-Bereichen nicht vorhanden, so dass hier die Bindung der Session an die IP-Adresse bei Anwendungen mit erhöhtem Schutzbedarf als eine zusätzliche Sicherheitsmaßnahme erfolgen kann.

Session Riding

Session Riding ist durch Einführung eines SessionCodes oder durch eine andere Schutzmaßnahme zu verhindern. Die im Folgenden angeführten Maßnahmen sind geeignet, um Session Riding zu verhindern.

Privilege Escalation

Privilege Escalation bezeichnet die unautorisierte Erhöhung der Privilegien, die einem angemeldeten Benutzer zugeordnet sind, der einer bestimmten Rechtegruppe (Benutzergruppe) angehört.

Beispielhaft habe eine Anwendung zur Bestellabwicklung für jede neue Bestellung eine eindeutige ID vergeben. Diese IDs werden in der Reihenfolge der Bestellaufgabe und über alle Benutzer hinweg sequentiell erzeugt. Ein Benutzer kann sich die eigenen Bestellungen über eine Web-Schnittstelle anzeigen lassen. Ausgegeben wird eine Liste von Bestellungen, die durch eine Folge nun nicht mehr zusammenhängender IDs identifiziert werden. Nur auf diese Bestellungen soll der Benutzer zugreifen dürfen. Beim anschließenden weiteren Zugriff auf eine konkrete Bestellung wird die ID als Parameter mit übergeben. Privilege Escalation kann nun dann vorliegen, wenn die Anwendung beim Zugriff auf einen Datensatz nicht mehr prüft, ob der Benutzer rechtmäßiger Eigentümer dieses Datensatzes ist, sondern einfach die als Parameter übermittelte ID zum Zugriff auf die Datenbank heranzieht.

Zur Verhinderung von Privilege Escalation muss beim Bearbeiten oder Einsehen eine Bestellung kontrolliert werden, ob die über die ID identifizierte Bestellung entweder dem anfragenden Benutzer gehört oder ob der Benutzer eventuell der Administrator ist. In einer modernen Anwendung mit einer Model-View-Controller (MVC)-Struktur ist dies relativ einfach zu bewerkstelligen, indem die Kontrollfunktion im Modell (der Business-Logik) verankert wird. Die Praxis zeigt jedoch, dass diese Kontrolle häufig ganz oder teilweise in der Controller-Schicht vorgenommen wird. Nachteile sind duplizierter Code und dass ein Entwickler vergessen könnte, die Kontrolle überhaupt einzubauen. Ein Grund dafür ist, dass an Sicherheit meist zu einem sehr späten Zeitpunkt gedacht wird und Änderungen am Business-Modell dann zu aufwändig sind. Ein anderer Grund sind funktionale Erweiterungen wie z. B. die nachträgliche Einführung des oben genannten Administrators, die eine grundsätzliche Überarbeitung des Sicherheitskonzepts notwendig machen würde.

Hashes

Wenn die Anwendung Werte an den Browser sendet, die dieser nicht verändern darf (was bei einer SessionID der Fall ist), die aber mit einem Form-Request wieder zur Anwendung zurückkommen, dann muss die Anwendung die erhaltenen Werte mit einer Data Validation auf gültige Werte prüfen. Sollen die eigentlichen Werte zusätzlich vor Ausspähen geschützt werden, so empfiehlt sich die Verwendung von signierten Hashes anstatt der „Klartext“-Werte.

URL-Rewriting

Erfordert die Anwendung URL-Rewriting, so sollte ein Benutzer auf die Gefahren des Ausspähens hingewiesen und dazu aufgefordert werden, sich beim Verlassen des PCs aus der Webanwendung auszuloggen oder den Rechner zu sperren. Durch Verwendung sehr langer SessionIDs, die ein Abschreiben erschweren oder die Verwendung langer URLs mit der SessionID am Ende (so dass sie aus dem sichtbaren Bereich am Bildschirm herausgeschoben ist) kann zudem etwas gegen das Über-die-Schulter-schauen (z. B. in öffentlichen Orten) getan werden. Insbesondere ist ein Benutzer darauf hinzuweisen, niemals eine gespeicherte Seite oder einen kopierten Ausschnitt aus einer solchen Seite zu versenden. Es ist außerdem sicherzustellen, dass beim URL-Rewriting nicht versehentlich auch externe Links mit der SessionID versehen werden. Der Referrer, der beim Einsatz des URL-Rewritings auch die SessionID enthält, darf zudem nicht zu fremden Hosts gelangen. Dies ist dadurch sicherzustellen, dass Links auf externe Seiten niemals direkt gesetzt werden, sondern immer über einen Redirect (Weiterleitung) geführt werden.

Logout erzwingen

Jede Anwendung, die eine Login-Funktion hat, sollte auch eine Logout-Funktion besitzen. Das Logout hat das korrekte Invalidieren der Session sicherzustellen. Bei zahlreichen Webanwendungen ist zu beobachten, dass eine Logout-Funktion zwar vorhanden ist und der Benutzer nach Ausführung auch die Bestätigung erhält, nun abgemeldet zu sein, dass die Session aber nicht invalidiert wird. Zu erkennen ist das meist daran, dass die Betätigung des Zurück-Buttons des Browsers bis zu einer Seite innerhalb der Anwendung ein Weiterarbeiten darin nach wie vor ermöglicht. Mit einer gestohlenen SessionID könnte in einem solchen Fall weitergearbeitet werden (zum Beispiel in einem Internet-Café).

Der Benutzer ist darin zu animieren, das Logout auch wirklich auszuführen. Dies kann wie folgt durchgeführt werden:

• einfache und klare Darstellung des Logout-Buttons
• Hinweis nach dem Login
• Hinweis nur dann nach dem Login, falls dies beim letzten Mal nicht geschehen ist.

Schließt der Benutzer das Browser-Fenster in der Annahme, sich dadurch auch automatisch auszuloggen (was aber nicht der Fall ist), so sollte die Anwendung den Benutzer beim nächsten Login darüber informieren, dass ein automatisches Ausloggen erfolgte, und in Zukunft ein explizites Ausloggen stattfinden sollte.

Umgang mit Benutzerkennungen

Um die Sicherheit erheblich zu steigern, sollte die Benutzerkennung als nicht-öffentliche Information behandelt werden. Insbesondere sind E-Mail-Adressen sowie Schemata wie vorname.nachname zu vermeiden. Es wird empfohlen, stattdessen nicht ableitbare Zeichenketten zu verwenden oder eine Kombination aus externen Merkmalen mit einer nicht-erratbaren Komponente zu gestalten. Zudem ist darauf zu achten, dass die Anwendung keine Hinweise über das Vorhandensein von Benutzerkennungen gibt. Häufig anzutreffen ist diese Art der Implementierung einer „Passwort vergessen“-Funktion: Der Benutzer wird aufgefordert, seine eindeutige Identifikationsnummer (UserID) einzugeben. Ist diese korrekt, d. h., existiert die Nummer in der Datenbank, so lautet die Antwort: „Das Passwort wurde an die hinterlegte E-Mail-Adresse verschickt“. Wurde jedoch eine nicht existierende Identifikationsnummer eingegeben, so lautet die Antwort: „Dieser Benutzer existiert nicht, bitte korrigieren Sie Ihre Eingabe“. Auf diese Weise lassen sich Benutzerkennungen durch Aufzählen (Enumeration) ermitteln. Richtig wäre folgende Antwort, die keine Information über das Vorhandensein einer UserID gibt: „Das Passwort wurde an die hinterlegte E-Mail-Adresse verschickt, falls die eingegebene UserID korrekt gewesen ist. Sollten Sie nicht in Kürze eine E-Mail von uns erhalten, so ist dies darauf zurückzuführen, dass Sie eine fehlerhafte UserID eingegeben haben“.

Sichere Passwörter

Die Benutzung von sicheren Passwörtern ist dadurch zu erreichen, dass das System nicht jedes vom Anwender gewünschte Passwort akzeptiert und Regeln vorgibt sowie die Einhaltung dieser prüft. Bisher existieren für das Web keine allgemein anerkannten Verfahren und auch keine Standardbibliotheken zur Passwortprüfung. Auch wird häufig in der jeweiligen Anwendungssituation die Berücksichtigung anwendungsspezifischer Randbedingungen erforderlich sein. Generell sollten Passwörter aus einfachen Wörterbuchwörtern, persönlichen Angaben (Name, Geburtstag etc.) sowie einfachen Zahlenkombinationen vermieden werden. Es empfiehlt sich eine Kombination aus (auch absichtlich falsch geschriebenen) Wörtern, Sonderzeichen, Groß- und Kleinschreibung sowie Zahlen. Dabei ist auch die Länge des Passworts von entscheidender Bedeutung.

Einsatz eines SSL/TLS/HTTPS-Protokolls

Daten, bei denen Ausspähen verhindert werden muss (z. B. Passwörter, Bankdaten etc.) sind durch Einsatz des SSL-Protokolls zu schützen. Das SSL-Protokoll verschlüsselt die zwischen Browser und Server ausgetauschten Daten und sorgt dafür, dass vertrauliche Informationen vor dem Ausspähen auf dem Übertragungsweg geschützt sind. Diesen Schutz führen heutige Browser so weit, dass auch bei einem Wechsel von einer per SSL geschützten Seite (HTTPS) zu einer ungeschützten Seite (HTTP) – etwa dann, wenn der User auf der SSL-geschützten Seite auf einen HTTP-Link klickt – sensitive Protokollinformationen nicht weitergegeben werden. Das SSL-Server-Zertifikat stellt außerdem sicher, dass der Hostname authentisch ist. D. h., es garantiert, dass der im Zertifikat angezeigte Hostname unverfälscht ist. Schließen wir den Fall aus, dass der DNS manipuliert worden ist, so garantiert das Zertifikat auch die Echtheit des Hosts (sofern die Seite keine Frames benutzt).

Web Shields

WebShields (auch: Web Application Firewall) filtern den Datenstrom zwischen Browser und Webanwendung und können mit Firewalls verglichen werden. Tritt ein als unzulässig eingestuftes Eingabemuster auf, wird der Transfer unterbrochen oder auf eine andere, vorher festgelegte Weise reagiert. Ein WebShield arbeitet als Proxy im Datenstrom, kennt somit das Protokoll der Anwendung. Grundsätzlich filtern WebShields die vom Browser an den Webserver übertragenen Daten. Einige WebShield-Produkte können zusätzlich die vom Webserver an den Browser versandten Daten überwachen. Hierbei kann das WebShield „lernen“, wie die Daten beschaffen sind. Dadurch wird ein späterer Vergleich zwischen aktuellen und gelernten Daten ermöglicht. So können Filter in eingeschränktem Maße verhindern, dass der Browser schadhaften Code erhält. WebShields sind nicht fähig, alle Angriffsformen auf Webanwendungen zu erkennen. Generell gilt: Sicherheitsprobleme sollten in der Webanwendung selbst gelöst werden. WebShields sollten nur als zusätzliche Schutzmaßnahme in Betracht gezogen werden.

Web Scanner

Web Scanner (auch: Web Application Scanner) sind Programme für Penetrationstests. Sie untersuchen eine Anwendung auf bekannte Schwachstellen und unterstützen dabei den Webentwickler oder Penetrations-Tester beim Auffinden von Sicherheitslücken. Allerdings kann dies auch von einem Angreifer verwendet werden. Dabei wird auf einem Client-Computer der Web-Scanner installiert, um dann die (auf einem anderen entfernten Server liegende) Webanwendung zu analysieren. Allgemein gilt: Web-Scanner sind sinnvolle Hilfsmittel, um erfahrenen Benutzern bei der Analyse der Sicherheitseigenschaften einer Webanwendung zu unterstützen. Sie sind jedoch weder in der Lage, fehlendes Wissen zu kompensieren, noch können sie Experten ersetzen. Die einer Webanwendung innewohnende Komplexität und die Tatsache, dass manche Schwachstellen von einem Hilfsprogramm ("tool") grundsätzlich nicht erkennbar sind, haben zur Folge, dass weiterhin geübte Personen für den Großteil der Analyse benötigt werden. Eine Interpretation eines Web-Scan-Reports ist ohne Erfahrung im Testen von Webanwendungen nur schwer möglich. Im Zuge einer Analyse können folgende vier Phasen durchlaufen werden:

Crawl/Scan: Der Web-Scanner bewegt sich ähnlich wie eine Suchmaschine durch die gesamte Webanwendung. Dabei werden sämtliche Links besucht und gegebenenfalls Formfelder mit Testwerten ausgefüllt. Der Scanner erhält so ein umfassendes Wissen über den Aufbau der Webanwendung, die Funktionsweise von Dialogschritten und den Inhalt von Formularseiten. Die Webanwendung wird außerdem auf häufig vorhandene Installations-, Konfigurations- oder Testverzeichnisse sowie bekannte problematische oder informative Dateien durchsucht. Unterstützt werden kann die Scan-Phase durch Einbeziehen großer öffentlicher Suchmaschinen. Vorausgesetzt wird hierfür, dass die zu analysierende Website bereits durch diese Suchmaschinen indexiert worden ist. Die Ergebnisse dieses Schrittes wurden dann auf den Suchmaschinen gespeichert (Index oder Cache). Im Rahmen einer Scan-Phase können diese Suchmaschinen nun gezielt nach Informationen über die Website abgefragt werden. Für die Zusammenstellung von Suchmustern, sowie Automatisierung der Abfragen kann die Nutzung spezieller Hilfsprogramme zweckmäßig sein.

Analyse: In einem nächsten Schritt wird die Webanwendung einer eingehenden Sicherheitsanalyse unterzogen. Die gewonnenen Erkenntnisse können in einer Datenbank hinterlegt werden: Typ und Version des Webservers, verwendete Technologien und Tools (CGI, Servlets, JSP, JavaScript, PHP usw.), Verwendung von Cookies oder anderer Mechanismen zum Session-Tracking, Analyse der Formular-Parameter einer Seite, insbesondere auch die Verwendung von versteckten Parametern ("hidden parameter") sowie der Extraktion von Kommentaren.

Audit/Penetrationstest: Unter Einbeziehung des in der vorangegangenen Phase gewonnenen Wissens werden systematisch fehlerhafte oder unzulässige Eingabemuster erzeugt und an die Webanwendung versandt. Einige der existierenden Scanner unterteilen diese Phase in eine schadlose und eine potentiell schadhafte Prüfung.

Reporting: Die Ergebnisse der Scan- und Audit-Phase werden in Berichten ("report") zusammengefasst. Der Umfang reicht dabei von kurzen Zusammenfassungen mit Nennung nur der größten Schwachstellen bis hin zu detaillierten Beschreibungen, in denen auch erste Hinweise für die Behebung des jeweiligen Problems gegeben werden können.