Anzeige
Anzeige
UX & Design
Artikel merken

Teil 2: Tipps zur Sicherheit von Webanwendungen: PHP 5 & MySQL 5

Sicherheit von Webanwendungen ist ein recht weites Feld. Daher beschränkt sich dieser Artikel auf die Beschreibung und Prävention der populärsten Angriffsmöglichkeiten, die im Zusammenhang mit Webanwendungen stehen. Angriffe gegen eine Webanwendung können durch die Vermeidung von Sicherheitslücken während der Implementierung oder durch den Einsatz von vorgeschalteten Web-Application-Firewalls (WAF) in den meisten Fällen abgewehrt werden. Einige hilfreiche Tipps, wie Sie bei der Prävention vorgehen sollten, gibt der vorliegende Artikel.

9 Min. Lesezeit
Anzeige
Anzeige

Bei der Realisierung von Webanwendungen sollte das Thema Sicherheit bereits in der Entwicklungsphase ins Auge gefasst werden. Dies gilt auch beim Einsatz von vorgefertigten Webanwendungen wie Blogs, Foren oder Shopsystemen. Sich darauf zu verlassen, dass der beim Provider vorkonfigurierte Server bereits sämtliche Sicherheitslücken schließt, könnte sich als ein fataler Irrtum herausstellen. Um Ihnen einen Überblick über die populärsten Angriffsmöglichkeiten und deren Prävention zu geben, gehe ich detailliert auf das Cross-Site Scripting (XSS) und die SQL-Injection ein.

Schwachstellen und Gefahren

Anzeige
Anzeige

Bevor ich Sie mit diesen beiden Angriffsmöglichkeiten vertraut mache, erhalten Sie noch eine kompakte Übersicht weiterer Schwachstellen und Angriffsmöglichkeiten. Unter anderem sind die folgenden Sicherheitsrisiken aufzuführen:

  • Denial of Service
  • E-Mail-Injection
  • Pufferüberlauf
  • Session-Hijacking
  • HTTP Response Splitting
  • Remote Command Execution
  • Man-In-The-Middle-Angriff
  • Cross-Site Request Forgery (CSRF oder XSRF)

Denial of Service

Mit einem Denial-of-Service-Angriff (DoS) versucht der Angreifer durch eine Vielzahl von Verbindungsanfragen dem
Webserver die Ressourcen
für reguläre Anfragen zu entziehen. Wird der Angriff von
mehreren Rechnern 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.

Anzeige
Anzeige

Man-In-The-Middle-Angriff

Beim Man-In-The-Middle-Angriff (MitM) verbindet sich der Nutzer statt mit dem Webserver unbemerkt mit dem Rechner des Angreifers. Dieser „in the middle“-Rechner
startet bei jeder Anfrage des Nutzers seinerseits eine Anfrage an den
echten Webserver und gibt dessen Antwort an den Nutzer weiter.

Anzeige
Anzeige

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 SSL-Verschlüsselung der Datenübertragung Schutz – dieser wird allerdings unwirksam, wenn sich der Angreifer
ein SSL-Zertifikat der betroffenen Website verschaffen kann, zu dem
ein Root-Zertifikat im Browser des Opfers installiert ist.

E-Mail-Injection

Bei einer E-Mail-Injection fügt der Angreifer
manipulierte Daten in ein Formular ein, so dass anstelle des beabsichtigten Empfängers
nun beliebige E-Mails an beliebige Empfänger gesendet werden. Diese Methode wird häufig für den Versand von SPAM missbraucht.

Anzeige
Anzeige

Pufferüberlauf

Bei einem Pufferüberlauf werden durch Fehler im Programm zu große
Datenmengen in einen dafür zu kleinen Speicherbereich geschrieben,
bis der Speicher überfüllt ist. Die überschüssigen Datenmengen überschreiben nun dem Ziel-Speicherbereich nachfolgende Informationen im Speicher. Der Angriff besteht darin, die überschreibenden
Daten so zu wählen, dass sie vom Programm als Befehle in
Maschinensprache interpretiert werden können.

Session-Hijacking

Da HTTP ein verbindungsloses Protokoll ist, muss die Webanwendung die Identifikation eines Nutzers feststellen. Dies geschieht
anhand einer Session-ID, die jedem Request als Basic/Digest Authentication, Cookie,
URL-Rewriting oder HTTP-Form-Parameter (GET oder POST)
mitgegeben wird.

Beim Session-Hijacking versucht der Angreifer, Kenntnis
von der Session-ID des Nutzers zu erlangen, um dann mit dessen Identität und den dazugehörenden Rechten auf die Webanwendung
zuzugreifen.

Anzeige
Anzeige

Cross-Site Request Forgery (CSRF oder XSRF)

Cross-Site Request Forgery setzt eine bestehende Session zwischen dem
Benutzer und der Webanwendung voraus. Der Angreifer
versucht dabei über verschiedene Techniken wie beispielsweise Cross-Site-Scripting
(XSS) den Nutzer oder über ein clientseitiges Skript auch direkt den
Browser zum Aufruf einer manipulierten URL zu bewegen. Anders als beim
Session-Hijacking erlangt der Angreifer selbst keine Kenntnis von
der Session-ID, da der Angriff ausschließlich im Browser des Nutzers
stattfindet.

HTTP Response Splitting

HTTP Response Splitting ermöglicht es, Websites mit Hilfe von
gefälschten Anfragen zu verunstalten. Dabei wird nicht direkt auf den
Webserver Einfluss genommen, sondern es werden Systeme beeinflusst, die
dem Webserver vorgeschaltet sind. Solche vorgeschalteten Systeme
könnten beispielsweise ein Proxy-Server oder ein Cache-Server sein.
Darüber hinaus sind Cross-Site-Scripting oder Phishing-Angriffe über
HTTP Response Splitting möglich.

Remote Command Execution

Beim Remote Command Execution versuchen Angreifer, Code auf einem
Server auszuführen. Dies geschieht in den meisten Fällen durch PHP
include()-Anweisungen. PHP erlaubt es, Dateien von
anderen Servern einzubinden – also auch vom Rechner eines
Angreifers. Darüber hinaus bietet PHP die Möglichkeit, lokale
Anwendungen über eine Shell aufzuführen. Werden diese mit
benutzermanipulierbaren Parametern aufgerufen und die Parameter nicht
entsprechend gefiltert, ist es möglich, weitere Programme aufzurufen.
So können etwa Dateien geändert oder sensible Daten ausgespäht werden.

Anzeige
Anzeige

Angriffsmöglichkeit SQL-Injection

Die wohl populärste Angriffsmöglichkeit stellt die SQL-Injection dar. Dabei 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 entweder für ihn auf herkömmlichem Weg nicht zugängliche Daten auslesen oder Daten verändern. Zum Maskieren dieser SQL-Steuerzeichen bietet PHP die Funktionen „mysql_real_escape_string()“ oder „mysqli_real_escape_string()/real_escape_string()“.

Folgendes Fallbeispiel soll Ihnen einen Einblick verschaffen: Auf einem Webserver befindet sich das Skript shop.php zum Anzeigen von Artikeln. Das Skript akzeptiert den Parameter produktid, der innerhalb der Webanwendung ein Bestandteil der SQL-Abfrage wird.

Status Erwarteter Aufruf
Aufruf http://www.domain.de/shop.php?produktid=42
Code SELECT * FROM produkte WHERE id=" . $_GET[‚produktid‘]
SQL-Abfrage SELECT * FROM produkte WHERE id=42

Dieser Code übernimmt ungeprüft die URL-Variable produktid in eine SQL-Abfrage. Die ungefährlichste Angriffsmöglichkeit ist das Ändern dieser ID in der URL. Bei Datenbanksystemen, die Multi-Querys, also mehrere durch ein Semikolon „;“ getrennte SQL-Abfragen zulassen, kann dies zur Manipulation oder sogar zur Löschung von Daten führen.

Anzeige
Anzeige
Status SQL-Injection
Aufruf http://www.domain.de/shop.php?produktid=42;DELETE+FROM+proukte
Code SELECT * FROM produkte WHERE id=" . $_GET[‚produktid‘]
SQL-Abfrage SELECT * FROM produkte WHERE id=42;DELETE FROM produkte

Wie man unschwer erkennen kann, wird der Anwendung ein zweiter SQL-Befehl untergeschoben.

Um sich vor solchen SQL-Injection-Angriffen zu schützen, stellt Ihnen PHP eine Reihe nützlicher Funktionen und Verarbeitungsprozesse als Abwehrmöglichkeiten zur Verfügung. Die populärsten davon sind:

Sonderzeichenbehandlung

Die Verarbeitung von Sonderzeichen mit Hilfe der Funktionen „mysql_real_escape_string()“, „mysqli_real_esscape_string()“, „adds-lashes()“ oder „stripslashes()“ sollte in keiner Webanwendung fehlen. Vorteil bei diesen Funktionen: Man hat absolute Kontrolle über die eingefügten Backslashs und kann somit auf einfache Weise Sonderzeichen maskieren. Sie sollten jedoch vor dem Einsatz von „addslashes()“ mit Hilfe der Funktion „get_magic_quotes_gpc()“ überprüfen, ob die Option „magic_quotes_gpc“ an- oder ausgeschaltet ist. Falls die Option auf on steht, ist eine Behandlung mit „addslashes()“ nicht notwendig.

Anzeige
Anzeige

Schlüsselwort Filterung

Die Filterung bestimmter Schlüsselwörter gehört ebenfalls zu den bekannten Abwehrmöglichkeiten. Vor allem die SQL-Schlüsselwörter SELECT, UNION, AND, OR und ORDER sollten gefiltert werden. Die Schlüsselwort-Filterung kann aber auch Probleme mit sich bringen, zum Beispiel wenn Feldinhalte wie „Union Investment“ oder „Europäische Union“ einschlägige Schlüsselwörter enthalten.

Stored Procedures

Seit MySQL 5 können die sogenannte hinterlegten Prozesse (engl. stored procedures) verwendet werden. Eine Stored Procedure ist eine Folge von SQL-Abfragen, die auf dem Server gespeichert bzw. hinterlegt werden können. Clients können auf diese Stored Procedure zugreifen, ohne sich um die Beschaffenheit der einzelnen Abfragen kümmern zu müssen. Datenbankanwendungen, die bei Banken und Versicherungen verwendet werden, nutzen häufig Stored Procedures, um ein sicheres Anwendungsumfeld zu schaffen. In einem solchen Umfeld hat ein Nutzer keine Möglichkeit, direkt auf eine Datenbanktabelle zuzugreifen. Er ist lediglich in der Lage, die gespeicherten Stored Procedures zu verwenden. Auf Stored Procedures können Nutzer unterschiedliche Nutzerrechte besitzen. Somit sind SQL-Injection-Angriffe nahezu ausgeschlossen.

Prepared Statements/Parameter Binding

Vorbereitete Abfragen (engl. prepared statements) oder gebundene Parameter (engl. Parameter Binding) erzeugen mit Hilfe eines sogenannten Query-Templates eine SQL-Abfrage, die auf dem MySQL-Server gespeichert wird. In PHP können Prepared Statements durch die neue MySQLi-Extension oder PHP Data Objects (PDO) verwendet werden.

Anzeige
Anzeige

Angriffsmöglichkeit Cross-Site-Scripting (XSS)

Eine weitere äußerst populäre Angriffsmöglichkeit stellt das Cross-Site-Scripting (XSS) dar. Hinter dieser Bezeichnung verbergen sich zwei grundsätzlich verschiedene Angriffe. Beim clientseitigen XSS schleust der Angreifer HTML-Steuerzeichen und Code einer clientseitigen Skriptsprache, wie beispielsweise JavaScript, in eine Webseite ein, die im Webbrowser des Opfers ausgeführt wird. Der 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 Skriptsprache, so dass diese beispielsweise bei einem dynamisch generierten include() eine vom Programmierer nicht vorgesehene Datei ausführt.

Wie muss man sich einen solchen XSS-Angriff vorstellen? Auch hier bieten sich dem Angreifer mehrere Möglichkeiten. Besonders bequem ist es für potenzielle Angreifer, wenn die Daten des Angriffs permanent gespeichert werden, etwa in einem Blog, Gästebuch oder Forum. Dann nämlich wird der bösartige Code bei jedem Nutzer ausgeführt, der die Website besucht. Das Gefährliche daran ist, dass hier fremder Code im Kontext von eigentlich vertrauenswürdigen Webseiten ausgeführt wird.

Was kann man dagegen tun? Als Nutzer bzw. Besucher können Sie fast nichts tun, außer merkwürdige und vor allem recht lange Links nicht anzuklicken. Als Entwickler einer Webanwendung müssen Sie jedoch unbedingt Vorkehrungen gegen XSS treffen. Jede Ausgabe, die Nutzerdaten enthält, muss entwertet werden. Dabei gibt es spezielle Sonderzeichen, die je nach Kontext gefährlich werden können, wie beispielsweise <, >, ", ‚ und &. Diese Sonderzeichen müssen durch ihre HTML-Entitäten ersetzt werden, also &lt;, &gt;, &quot;, &apos; und &amp;. PHP bietet hierfür die Funktionen htmlspecialchars() und htmlentities() an.

Darüber hinaus sollten Sie auch aus Nutzereingaben HTML-Code entfernen – PHP liefert dafür mit der Funktion „strip_tags()“ genau das richtige Mittel.

Checkliste für Gegenmaßnahmen

Sollten Sie Maßnahmen gegen potentielle Gefahren und Schwachstellen ergreifen wollen, dürfte die folgende Tabelle eine brauchbare Checkliste darstellen:

Sicherheitslücke Beschreibung
Verschlüsselung per SSL Werden Autorisierungdaten unverschlüsselt und ohne SSL übertragen?
Passwort-Übertragung Wird das Passwort per E-Mail unverschlüsselt übertragen?
Passwort-Qualität Ist die Passwortwahl frei oder erzwingt die Anwendung sichere Passwörter (Länge, Zusammensetzung) über entsprechende Überprüfungen?
Standard-Zugänge Legt die Anwendung über Installationsroutinen Standard-Zugänge, wie
beispielsweise admin, root etc. an und vergibt hierbei
Standardpasswörter?
Sensible Inhalte in Cookies Werden Passwörter, Passwort-Hashes oder andere sensible Daten in Cookies gespeichert?
Remote-Code-Ausführung Kann über einen Parameter PHP-Code von einem fremden Server ausgeführt
werden, wie z. B. durch eine unsichere include()-Anweisung?
Session Fixation Können Angreifer Session-IDs vorgeben, die dann von der Anwendung weiter verwendet werden?
Session Hijacking Kann der Angreifer eine Session mit ihm bekannter Session-ID übernehmen? Gibt es Überprüfung auf User-Agent, IP etc.?
SQL-Injection (Formulare) Kann ein Angreifer über ein Formular eigene SQL-Abfragen in die Anwendung einschleusen?
SQL-Injection (Cookies) Werden IDs in Cookies gespeichert, anhand derer ein Angreifer SQL-Statements einfügen könnte?
SQL-Injection (URL-Parameter) Können über URL-Parameter SQL-Abfragen eingeschleust werden?
XSS via XML Können Angreifer über einen von der Anwendung verwendeten XML-Service,
wie beispielsweise bei RSS-Feeds, Skriptcode einschleusen?
XSS (Formulare) Kann an Eingabeformulare Skriptcode übergeben werden, der nicht gefiltert bzw. maskiert wird?
XSS (Cookies) Werden Werte aus Cookies, wie beispielsweise Benutzer-IDs, ungeprüft übernommen?
XSS (User-Agent, Referrer) Kann ein Angreifer über einen manipulierten User-Agent oder HTTP-Referrer Skriptcode einschleusen?

Einsatz von Web Application Firewalls (WAF)

Eine weitere Gegenmaßnahme stellt der Einsatz von Web Application Firewalls (WAF) dar. Eine WAF ist eine Technologie, die Webanwendungen vor Angriffen über HTTP schützen soll. Gegenüber klassischen Firewalls und Intrusion Detection Systemen (IDS) untersucht eine WAF die Kommunikation auf der Dienstebene. Dazu ist normalerweise keine Änderung an den zu schützenden Webanwendungen nötig. Die WAF untersucht hierbei sämtliche eingehenden Anfragen und die Antworten des Webservers. Bei verdächtigen Inhalten wird der Zugriff unterbunden.

Zur Klassifizierung von gefährlichen oder verbotenen Aktionen wird häufig in einer vorgeschalteten Lernphase ein Application-Security-Scanner eingesetzt. Dieser analysiert, häufig im Dialog mit einem Nutzer, die Anwendung und erzeugt daraus Profile für zulässige Aktionen.

Alternativ werden durch eine Art Crawler oder auch Application-Security-Scanner die Webseiten der Webapplikation angesteuert und enthaltene Formularfelder überprüft. Die Applikation läuft in diesem Fall in einer Art passivem Modus, das heißt erlaubte und nicht erlaubte Eingaben werden in einer Logdatei festgehalten. Der Administrator kann dann nachträglich sehen, welche Aktionen im Betrieb geblockt würden und diese selektiv freischalten, indem er Sonderregeln einrichtet.

Zu den bekanntesten WAF-Vertretern gehören der USP Secure Entry Server und die ModSecurity für Apache-Webserver. Sie sollten sich jedoch im klaren darüber sein, dass auch eine WAF keine absolute Sicherheit gewährleistet.

Fazit

Ein effizientes und optimiertes Sicherheitskonzept erfordert eine stetige Anpassung an neue Gegebenheiten und Sicherheitslücken. Während Sie die hier aufgeführten Schwachstellen schließen, erblicken sicher bereits neue Gefahrenquellen das Licht der Welt, welche Sie in die Planung und Realisierung eines Sicherheitskonzepts mit einbeziehen sollten.

Eines ist sicher: Eine absolut sichere Webanwendung gibt es nicht, aber durch eine vorausschauende Anwendungsentwicklung kann die Anpassung auf Gefahrenquellen deutlich erleichtert werden.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige