IIS: App_Offline.htm – .NET Webapplikation offline nehmen

Will man eine .NET Webapplikation mit einer neueren Version ersetzen, sollte man diese offline nehmen. Ansonsten werden die HTTP-Anfragen munter weiter bedient und dies führt dann oft zu unschönen Fehlermeldungen.

Eine elegante Methode ist die Datei „App_Offline.htm“. Wird ins Root-Verzeichnis der .NET Webapplikation eine Datei mit dem Namen „App_Offline.htm“ kopiert, werden sämtliche neuen HTTP-Anfragen mit dem Inhalt dieser Datei beantwortet und zugleich wird die Webapplikation sowie deren „Application Domain“ beendet.

Nach den Wartungsarbeiten oder dem Updaten wird die Datei „App_Offline.htm“ einfach wieder gelöscht. Ist die Datei nicht mehr vorhanden, werden sämtliche Anfragen wieder wie gewohnt beantwortet.

Schritte um eine .NET Webapplikation zu aktualisieren:

  1. App_Offline.htm ins Root-Verzeichnis kopieren
  2. ein Backup der Dateien erstellen
  3. Webapplikation updaten
  4. App_Offline.htm aus dem Root-Verzeichnis löschen

Nützliche Links

Vipin Agarwal: App_Offline.htm, taking site down for maintenance
ScottGu’s Blog: App_Offline.htm
stackoverflow.com: explain the differences, in IIS, between application pools, worker processes and app domains

OWASP: Rangliste der zehn grössten Risiken für Webanwendungen

Zuletzt aktualisiert am: 17.09.2013

Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation mit dem Ziel, die Sicherheit von Anwendungen und Diensten im World Wide Web zu verbessern. [1]

Dazu veröffentlicht OWASP eine Rangliste mit den zehn schwerwiegendsten Sicherheitsschwachstellen von Webanwendungen. Auf Platz 1 ist „Injection“, das Einschleusen von fremdem Code.

Passend zum Thema Injection musste ich erst kürzlich feststellen, dass es immer noch Webanwendungen gibt bei denen SQL-Injection ohne grosse mühe funktioniert.

SQL-Injection

Das erste Mal aufmerksam auf das Thema SQL-Injection wurde ich im Jahr 2000. In dieser Zeit waren sehr viele Webanwendungen davon betroffen. Auch bekannte online Shops waren vor dieser Problematik nicht gefeit. Dies war auch die Zeit des „Quick-Login“, oft genügte die Eingabe des Prozentzeichens (%) bei Passwort und Benutzername und man wurde mit dem erst besten Login angemeldet.

Inzwischen sollte eigentlich jeder Programmierer, der mit Datenbanken arbeitet, wissen was SQL-Injection ist und was es für geeigneten Gegenmassnahmen gibt. Sei dies die Verwendung von Stored Procedures, Prepared Statements oder dem Maskieren von Metazeichen. Auch sollte die Webanwendung Benutzereingaben genau prüfen und nur korrekte Werte akzeptieren. Hat man keinen Einfluss auf die Webanwendung, kann auch ein WAF (Web Application Firewall) eingesetzt werden.

Aber leider musste ich schon des Öfteren feststellen, dass es auch im 2013 Programmierer gibt, die sich nicht mit diesem Thema beschäftigen. Im Glauben ein Projekt schneller fertigzustellen wird dies einfach ignoriert. Auch Begründungen wie: „Diese Anwendung ist nur für den internen Gebrauch…“ oder „Unsere Daten sind doch nicht interessant für einen Hacker…“.

Und was passiert bei einem „DROP TABLE;“ oder „WAITFOR DELAY ‚0:30:00‘–“ usw.?

Ich glaube diese Programmierer haben noch nicht bemerkt, das Programmieren viel mehr Spass macht, wenn man versucht „sicheren“ und „sauberen“ Code zu schreiben.

Nützliche Links:

Wikipedia: OWASP [1]
Wikipedia: WAF
Anfälligkeit von Webapplikationen durch SQL-Injection prüfen, mit Hilfe von sqlmap
Clean Code Developer
The OWASP Cheat Sheet Series – web application security

Anfälligkeit von Webapplikationen durch SQL-Injection prüfen, mit Hilfe von sqlmap

Zuletzt aktualisiert am: 02.06.2016

Heutige Webapplikationen müssen gegen eine grosse Anzahl von Angriffen aus dem Web gesichert werden. Bei Webapplikationen die eine Datenbank im hintergrund haben, sind Steuerparameter eine häufige Schwachstelle. Dabei nutzt der Angreifer die Möglichkeit Parameter, welche die Webapplikation in der URL oder in einem Formular mitführt, zu ändern. Mehr zum Thema SQL-Injection bei Wikipedia.

Sqlmap ist eine Open-Source Applikation zum automatisierten Testen von Webapplikationen, auf Anfälligkeit durch SQL-Injection. Dadurch das sqlmap in Python geschrieben wurde, ist die Applikation Plattformunabhängig und läuft unter Windows sowie Unix/Linux. Vorausgesetzt ist ein installierter Python Interpreter ab Version 2.6.

Anzeigen der vorhandenen Parameter


>sqlmap.py -h

Liefert eine Liste mit den vorhandenen Parameter.

Bestimmen der verwendeten Datenbank (Database Fingerprinting)


>sqlmap.py -u "http://meine.url.info/page.asp?artid=1" -f

Output eines erfolgreichen Tests:


........
[INFO] testing Microsoft SQL Server
[INFO] confirming Microsoft SQL Server
[INFO] the back-end DBMS is Microsoft SQL Server
web server operating system: Windows 2000
web application technology: ASP.NET, ASP, Microsoft IIS 5.0
back-end DBMS: active fingerprint: Microsoft SQL Server 2008
               html error message fingerprint: Microsoft SQL Server

Prüfen ob ein bestimmter Parameter anfällig auf SQL-Injection ist


>sqlmap.py -u "http://meine.url.info/page.asp?artid=1" -p "artid"

Output eines erfolgreichen Tests:


......
GET parameter 'artid' is vulnerable.

sqlmap identified the following injection points with a total of 41 HTTP(s) requests:
---
Place: GET
Parameter: artid
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: artid=1' AND 9454=9454 AND 'WAlX'='WAlX
---

Nützliche Links:
sqlmap Dokumentation
SQL Injection Cheat Sheet
SQL Injection Cheat Sheet für Oracle, MSSQL, MySQL, PostgreSQL, Ingres, DB2, Informix
Testseite für den Acunetix Web Vulnerability Scanner