Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Bitte, bitte, bitte informiere dich zum Theme Websicherheit und SQL-Injection!
Das was du da baust, riecht nach einer Sicherheitslücke, so groß wie das Hangar-Tor für den A380!
Bevor du weiter machst, schau dir die Dokumention der PHP-Funktion mysql_real_escape_string an.
Informiere dich über Prepared Statements und auch über die Funktion htmlspecialchars.
Das ist ganz ehrlich gemeint! Mit dem, was du da gerade baust, setzt du deine User einer ernsten Gefahr aus (Stichwort Crossite-Scripting).
Wenn du Strings so wie oben, ohne Behandlung in die Datenbank schreibst, hacke ich dir deine Seite in 10 Sekunden.
man muss halt auch immer im hinterkopf haben das eine PHP ausgabe so erscheint wie sie ist und anschließend erst von einem HTML / JS Parser ausgewertet werden muss.
Schreib es einfach so wie du auch in HTML schreiben würdest und escape anschließend alle" die nicht den string begrenzen.
@DerHoschi
wieso sollte das erste smeikolon raus? Das sollte da schon drinne bleiben, ist zwar bei einem einzigen befehl im onclick handler nicht zwingend erforderlich, aber der kompatibilität halber sollte das schon drinne bleiben.
Bitte, bitte, bitte informiere dich zum Theme Websicherheit und SQL-Injection!
Das was du da baust, riecht nach einer Sicherheitslücke, so groß wie das Hangar-Tor für den A380!
Keine Sorge, dieser Beispielcode ist innerhalb meines CMS includiert, der nur von berechtigten Usern betreten werden kann.
Der String ist nur Teil einer ganzen String-Kette, die mit vielen if-Anweisungen und Session_Variablen verknüpft ist, die nur nach einem Userloggin zur Verfügung stehen.
Ihr seit ja alle echte Spezialisten. Ich hoffe ihr baut keine Webseiten, die wirklich im Internet live stehen.
Die beiden Hochkommas in dem String werden erst dann zum Problem, wenn Überkinger den String, so wie er da ist, in sein SQL-Statement einfügt ohne den String vorher zu behandeln.
MySQL parst das Statement, dass dann etwas so aussieht
UPDATE myTable SET col_1 = 'onclick="jsapi('#helper').toggle();"'
Jetzt sollte jedem klar sein, dass die ' da zum Problem werden. MySQL interpretiert das ganze dann nämlich so:
UPDATE myTable SET col_1 = 'onclick="jsapi(' mit dem Rest #helper').toggle();"' kann es nicht angangen und wirft einen Fehler. Das ist an dieser Stelle dann noch das kleines Übel. Ein Angreifer könnte so die ganze Datenbank manipulieren.
Hausaufgabe:
überlegt euch doch mal, was passiert, wenn Überkinger in seiner Variable $test das folgende schreibt:
$test = "nix '; DROP TABLE myTable; --' "
Lest euch bitte dringen in das Thema SQL-Injection ein.
Und für Überkinger:
Benutze mysql_real_escape_string
Ergänzung ()
Überkinger schrieb:
Keine Sorge, dieser Beispielcode ist innerhalb meines CMS includiert, der nur von berechtigten Usern betreten werden kann.
Der String ist nur Teil einer ganzen String-Kette, die mit vielen if-Anweisungen und Session_Variablen verknüpft ist, die nur nach einem Userloggin zur Verfügung stehen.
Keine Sorgen machen? Wenn die SQL-Statements bei dir alle so programmiert sind, dann reicht mir das für alle zugängliche Loginformular vollkommen aus, um die Datenbank beliebig zu manipulieren.
EDIT:
Hausaufgabe 2:
Ich nehme mal an, dass deine SQL zum prüfen des Logins etwa so ausieht: SELECT * FROM table_user WHERE login='".$login."' AND password='".$pw."';
Jetzt überlege dir mal, was passiert, wenn jemand folgenden Usernamen in dein Loginfeld eingibt:
$login = " '; -- "
Keine Sorgen machen? Wenn die SQL-Statements bei dir alle so programmiert sind, dann reicht mir das für alle zugängliche Loginformular vollkommen aus, um die Datenbank beliebig zu manipulieren.
Hmm hatte dasproblemnicht ganz verstanden das $test in die DB soll, dachte $test wird ausgegeben und dieaktion vononclick soll den inhalt speichern.
Da hat jared natürlich ganz recht.
Um dich vor Injektions zu schützen und sowieso weils generell ratsam ist Objekt orientiert zu arbeiten würde ich dir einfach empfehlen dir eine Klasse für sämtlichen DB Operationen zu schreiben die automatisch alle Statements SQL sicher macht, dann kommst auch nicht in die verlegenheit das mal zu vergessen
Gleiches gilt übrigens auch wenn du user eingaben wieder ausgeben willst, das niemals ungefiltert geschehen lassen, stichwort Cross-site scripting!
Danke für Eure Hilfe und den Tipp für das Buch. Werde ich mir besorgen.
Hmm, also das Script liegt außerhalb vom Webspace und wird von mir per Crontab aufgerufen. Es prüft geschützte Ordner auf eine neue Datei, liest diese aus, parst Inhalte die in die Datenbank sollen. Daher müsste man schon meinen Webspace hacken um da dranzukommen um zu manipulieren. Denk ich mir mal...?!?
kommt ganz drauf an!
liegt das script im ööfentlichem root ordner des webservers?
Dann muss man nur die Adresse kennen, die kann man durch geschicktes probieren oder aber per bruteforce rausbekommen. Beides recht aufwendig aer knackbar. Und das script muss ja nichteinmal schuld sein das man ran kommt. Aber wenn es nun z.b. jemanden gelingt nen eignes script auf die seite zu laden über irgendein andere sicherhitsleck....
ansonsten leg es halt irgendwo außerhalb der ordnunerstruktur des servers und rufe es mit dem php befehl auf.
sicherheit durch verschleierung hat nie und wird nie funktionieren.
Danke für Eure Hilfe und den Tipp für das Buch. Werde ich mir besorgen.
Hmm, also das Script liegt außerhalb vom Webspace und wird von mir per Crontab aufgerufen. Es prüft geschützte Ordner auf eine neue Datei, liest diese aus, parst Inhalte die in die Datenbank sollen. Daher müsste man schon meinen Webspace hacken um da dranzukommen um zu manipulieren. Denk ich mir mal...?!?
kommt ganz drauf an!
liegt das script im ööfentlichem root ordner des webservers?
Dann muss man nur die Adresse kennen, die kann man durch geschicktes probieren oder aber per bruteforce rausbekommen. Beides recht aufwendig aer knackbar. Und das script muss ja nichteinmal schuld sein das man ran kommt. Aber wenn es nun z.b. jemanden gelingt nen eignes script auf die seite zu laden über irgendein andere sicherhitsleck....
ansonsten leg es halt irgendwo außerhalb der ordnunerstruktur des servers und rufe es mit dem php befehl auf.
sicherheit durch verschleierung hat nie und wird nie funktionieren.
