Donnerstag, 12. Mai 2011
Benutzer werden darauf geschult, sich durch die Installation ausgefeilter Antivirensoftware vor schädlichen Programmen zu schützen, aber oft vertrauen sie ihre privaten Informationen auch Websites wie Ihrer an; in diesem Fall ist es wichtig, ihre Daten zu schützen. Es ist auch sehr wichtig, Ihre eigenen Daten zu schützen; wenn Sie einen Online-Shop betreiben, möchten Sie nicht ausgeraubt werden.
Im Laufe der Jahre haben Unternehmen und Webmaster gelernt — oft auf die harte Tour —, dass die Sicherheit von Webanwendungen kein Scherz ist; wir haben erlebt, wie Benutzerpasswörter durch
SQL-Injection
-Angriffe geleakt wurden, Cookies durch
XSSgestohlen wurden und Websites von Hackern aufgrund fahrlässiger Eingabevalidierung übernommen wurden.
Heute zeigen wir Ihnen einige Beispiele dafür, wie eine Webanwendung ausgenutzt werden kann, damit Sie daraus lernen können; dafür verwenden wir
Gruyere, eine absichtlich verwundbare Anwendung, die wir intern auch für Sicherheitsschulungen nutzen. Untersuchen Sie die Websites anderer nicht ohne Erlaubnis auf Schwachstellen , da dies als Hacking angesehen werden kann; aber Sie sind herzlich eingeladen — ja, sogar dazu ermutigt —, Tests an Gruyere durchzuführen.
Client-State-Manipulation – Was passiert, wenn ich die URL ändere?
Angenommen, Sie haben eine Bild-Hosting-Site und verwenden ein PHP-Skript, um die von Benutzern hochgeladenen Bilder anzuzeigen:
Was wird die Anwendung also tun, wenn ich die URL so ändere und userpasswords.txt eine tatsächliche Datei ist?
Erhalte ich den Inhalt von userpasswords.txt?
Ein weiteres Beispiel für Client-State-Manipulation liegt vor, wenn Formulardefinitionen nicht validiert werden. Angenommen, Sie haben dieses Formular:
Es scheint, dass der Benutzername des Absenders in einem versteckten Eingabefeld gespeichert wird. Nun, das ist großartig! Bedeutet das, dass ich das Formular als dieser Benutzer absenden kann, wenn ich den Wert dieses Feldes in einen anderen Benutzernamen ändere? Das kann durchaus passieren; die Benutzereingabe wird offenbar nicht mit beispielsweise einem Token authentifiziert, das auf dem Server verifiziert werden kann.
Stellen Sie sich die Situation vor, dass dieses Formular Teil Ihres Warenkorbs wäre und ich den Preis eines Artikels von 1000 $ auf 1 $ geändert und dann die Bestellung aufgegeben hätte.
Es ist nicht einfach, Ihre Anwendung gegen diese Art von Angriff zu schützen; werfen Sie einen Blick auf den dritten Teil von Gruyere , um ein paar Tipps zur Verteidigung Ihrer App zu erhalten.
Cross-Site Scripting (XSS) – Benutzereingaben können nicht vertraut werden
Eine einfache, harmlose URL:
Aber ist sie wirklich harmlos? Wenn ich die
prozentual kodierten
Zeichen decodiere, erhalte ich:
Gruyere ist, genau wie viele Websites mit
benutzerdefinierten Fehlerseiten, darauf ausgelegt, die Pfadkomponente in die HTML-Seite einzubeziehen. Dies kann Sicherheitsfehler wie XSS verursachen, da es Benutzereingaben direkt in die gerenderte HTML-Seite der Webanwendung einbaut. Sie könnten sagen: „Es ist nur ein Alarmfeld, na und?“ Die Sache ist die: Wenn ich ein Alarmfeld injizieren kann, kann ich höchstwahrscheinlich auch etwas anderes injizieren und vielleicht Ihre Cookies stehlen, die ich verwenden könnte, um mich als Sie auf Ihrer Site anzumelden.
Ein weiteres Beispiel ist, wenn die gespeicherte Benutzereingabe nicht bereinigt wird. Angenommen, ich schreibe einen Kommentar in Ihrem Blog; der Kommentar ist einfach:
Wenn andere Benutzer auf meinen unschuldigen Link klicken, habe ich ihre Cookies:
Sie können lernen, wie Sie XSS-Schwachstellen in Ihrer eigenen Web-App finden und beheben im zweiten Teil von
Gruyere; oder, wenn Sie ein fortgeschrittener Entwickler sind, werfen Sie einen Blick auf die automatischen Escape-Funktionen in Templatesystemen, über die wir in unserem
Online Security Blog.
gebloggt haben.
Cross-Site Request Forgery (XSRF) – Soll ich Anfragen von evil.com vertrauen? 404 Hoppla, ein kaputtes Bild. Es kann nicht gefährlich sein — es ist schließlich kaputt —, was bedeutet, dass die URL des Bildes ein
zurückgibt oder einfach fehlerhaft ist. Stimmt das in allen Fällen?
Nein, tut es nicht! Sie können jede URL als Bildquelle angeben, unabhängig von ihrem Inhaltstyp. Es kann eine HTML-Seite, eine JavaScript-Datei oder eine andere potenziell schädliche Ressource sein. In diesem Fall war die Bildquelle die URL einer einfachen Seite:
Diese Seite funktioniert nur, wenn ich angemeldet bin und einige Cookies gesetzt sind. Da ich tatsächlich in der Anwendung angemeldet war, als der Browser versuchte, das Bild durch Aufrufen der Bildquellen-URL abzurufen, hat er auch mein erstes Snippet gelöscht. Das klingt nicht besonders gefährlich, aber wenn ich mit der App etwas vertraut bin, könnte ich auch eine URL aufrufen, die das Profil eines Benutzers löscht oder Admins Berechtigungen für andere Benutzer erteilt.
Um Ihre App vor XSRF zu schützen, sollten Sie nicht zulassen, dass zustandsändernde Aktionen überGET aufgerufen werden; die POST -Methode wurde für diese Art von zustandsändernder Anfrage erfunden. Allegein diese Änderung hätte den obigen Angriff abmildern können, aber normalerweise reicht das nicht aus und Sie müssen in alle zustandsändernden Anfragen einen unvorhersehbaren Wert einbauen, um XSRF zu verhindern. Bitte besuchen Sie Gruyere
, wenn Sie mehr über XSRF erfahren möchten.
Cross-Site Script Inclusion (XSSI) – All your script are belong to us
Viele Websites können heute den Inhalt einer Seite dynamisch über asynchrone JavaScript-Anfragen aktualisieren, die JSON-Daten zurückgeben. Manchmal kann JSON sensible Daten enthalten, und wenn die richtigen Vorkehrungen nicht getroffen werden, ist es für einen Angreifer möglicherweise möglich, diese sensiblen Informationen zu stehlen.
Stellen wir uns folgendes Szenario vor: Ich habe eine Standard-HTML-Seite erstellt und Ihnen den Link geschickt; da Sie mir vertrauen, besuchen Sie den Link, den ich Ihnen geschickt habe. Die Seite enthält nur wenige Zeilen:
Da Sie bei Gruyere angemeldet sind und ein privates Snippet haben, sehen Sie auf meiner Seite ein Alarmfeld, das Sie über den Inhalt Ihres Snippets informiert. Wie immer, wenn es mir gelungen ist, ein Alarmfeld auszulösen, kann ich alles andere tun, was ich will; in diesem Fall war es ein einfaches Snippet, aber es hätte auch Ihr größtes Geheimnis sein können.
Es ist nicht allzu schwer, Ihre App gegen XSSI zu verteidigen, aber es erfordert dennoch sorgfältiges Nachdenken. Sie können Token verwenden, wie im XSRF-Abschnitt erklärt, Ihr Skript so einstellen, dass es nur auf POST-Anfragen antwortet, oder einfach die JSON-Antwort mit ‘n’ beginnen, um sicherzustellen, dass das Skript nicht ausführbar ist.
SQL Injection – Glauben Sie immer noch, dass Benutzereingaben sicher sind?
Was passiert, wenn ich versuche, mich mit einem Benutzernamen wie
JohnDoe’; DROP TABLE members;–
in Ihrer App anzumelden?
Obwohl dieses spezifische Beispiel keine Benutzerdaten preisgibt, kann es große Kopfschmerzen bereiten, da es das Potenzial hat, die SQL-Tabelle, in der Ihre App Informationen über Mitglieder speichert, vollständig zu löschen.Im Allgemeinen können Sie Ihre App durch vorausschauendes Denken und Eingabevalidierung vor SQL-Injection schützen. Erstens, sind Sie sicher, dass der SQL-Benutzer die Berechtigung haben muss, DROP TABLE members auszuführen? Wäre es nicht genug, nur
SELECT
-Rechte zu gewähren? Durch sorgfältiges Einstellen der Berechtigungen des SQL-Benutzers können Sie schmerzhafte Erfahrungen und viele Probleme vermeiden. Möglicherweise möchten Sie auch die Fehlerberichterstattung so konfigurieren, dass die Namen der Datenbank und ihrer Tabellen bei einer fehlgeschlagenen Abfrage nicht preisgegeben werden.
Zweitens, wie wir im XSS-Fall gelernt haben, vertrauen Sie niemals Benutzereingaben: Was für Sie wie ein Anmeldeformular aussieht, sieht für einen Angreifer wie eine potenzielle Eingangstür aus. Bereinigen Sie die Eingabe, die in einer Datenbank gespeichert wird, immer und schützen Sie sie mit Anführungszeichen, und nutzen Sie nach Möglichkeit sogenannte Prepared Statements oder parametrisierte Statements, die in den meisten Datenbank-Programmierschnittstellen verfügbar sind.Zu wissen, wie Webanwendungen ausgenutzt werden können, ist der erste Schritt, um zu verstehen, wie man sie verteidigt. Vor diesem Hintergrund ermutigen wir Sie, den
Gruyere-Kurs
zu besuchen, andere Websicherheitssurse von der
Google Code University
zu absolvieren und
skipfish.
So setzen wir das um
We archive Search Central announcements because client questions often trace back to a change that was announced years ago. Reading the original is faster than reconstructing it from second-hand summaries.
Verwandte Leistungen