XSS/SQL-Injection

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von N3X.

    Thread steht im Zusammenhang mit und wurde ausgelagert aus Login/Registrierung PHP PDO. ~Artentus


    @N3X Wo siehst du da XSS? Er gibt nirgends die übergebenen Daten wieder an den Benutzer aus.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Artentus“ ()

    slice schrieb:

    @N3X Wo siehst du da XSS? Er gibt nirgends die übergebenen Daten wieder an den Benutzer aus.


    und? Es ist trotzdem fatal, für eine in teilen basierende Webanwendung, direkt Superglobals in die Datenbank zu werfen. Spätestens, sobald dieses Beispiel um ein weiteres webbasiertes frontend erweitert werden würde, würde ich nicht derjenige sein wollen, der die Scherben davon wegfegen muss. Permanent injizierter Javascript-Code hat in der Datenbank nichts zu suchen. Wenn du lediglich danach argumentierst, dass wenn keine tatsächliche Ausgabe des Sourcecodes erfolgt, dieses Usecase praktikabel ist, stellt sich für mich die Gegenfrage (verhältnismäßig im ähnlichen context), wenn ich die Möglichkeit einer Blind-SQL-Injection oder einer Timebased-SQL-Injection auf meiner Webseite vorzufinden hätte, wäre dieser Usecase weniger kritisch zu betrachten als bei einer error-based-SQL-Injection?
    Ach so, das meintest du. Das ist aber m.M.n. kein XSS, sondern zählt noch zu SQL-Injection - daher meine Verwirrung.
    Klar, den User Input sollte man natürlich immer validieren, da stimme ich dir absolut zu.

    FYI: Die Aussage "Er gibt nirgends die übergebenen Daten wieder an den Benutzer aus." bezog sich aufs XSS, denn da ist mehr oder weniger die Definition.

    slice schrieb:

    Ach so, das meintest du. Das ist aber m.M.n. kein XSS, sondern zählt noch zu SQL-Injection - daher meine Verwirrung.
    Klar, den User Input sollte man natürlich immer validieren, da stimme ich dir absolut zu.

    FYI: Die Aussage "Er gibt nirgends die übergebenen Daten wieder an den Benutzer aus." bezog sich aufs XSS, denn da ist mehr oder weniger die Definition.



    Anbei noch ein Auszug:

    Persistentes (persistent) oder beständiges (stored) Cross-Site-Scripting unterscheidet sich vom reflektierten XSS prinzipiell nur dadurch, dass der Schadcode auf dem Webserver gespeichert wird, wodurch er bei jeder Anfrage ausgeliefert wird. Dies ist bei jeder Webanwendung möglich, die Benutzereingaben serverseitig speichert und diese später wieder ausliefert, solange keine Prüfung der Benutzereingaben bzw. eine geeignete Kodierung der Ausgabe stattfindet.



    Definiere SQL-Injection nach deinem Verständnis, bitte. Meines Verständnis nach, ist wie der Name SQL-Injection es ausdrücklich sagt, eine Injizierung von SQL. Ist Javasctipt SQL ? Denke nicht. Warum sollte es sich daher um eine SQL-Injection handeln?

    XSS ist XSS und SQL-Injections sind SQL-Injections. Das einschleusen von Javascript ist keine SQL-Injection. In Welcher Form ein XSS-Angriff erfolgt ist unabhängig davon, dass er ausgeführt wird. Sicher ist der standardgemäße Weg für einen XSS-Angriff oftmals der über die Superglobale GET zu gehen, aber nicht zwingend ein muss.....

    Des weiteren:
    http://de.wikipedia.org/wiki/Datenbanksicherheit#Risiken

    Evtl. sollte ich nochmal einen Blogartikel zur klaren Untertrennung der jeweiligen Angriffsarten insbesondere der letzten OWASP TOP 10 aufsetzen. :/

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „N3X“ ()

    Danke für die Info, das mit dem persistent/stored war mir neu und ich wäre nie auf die Idee gekommen das dort anzusiedeln, weil der User Input zuvor immer validiert werden sollte (wodurch das Problem eigentlich nicht entstehen kann). Und natürlich ist Javascript kein SQL, jedoch fällt doch das einschleusen von beliebigen Code, in der Situation, unter die Kategorie "SQL-Injection" und Javascript ist nun mal Code.

    Hab mein Beitrag mal gemeldet damit die Diskussion zum Thema XSS/SQL-Injection ausgelagert wird, das wird langsam ziemlich OT hier.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „slice“ ()

    Javascript ist code, deckt sich aber nicht mit der Definition einer SQL-Injection. Da wie du sagst, Javascript kein SQL ist, ist dementsprechend die Idiologie dahinter, dass bei der Injizierung von Javascript es eine SQL-Injection ist nicht gegeben.
    Siehe Definition: php.net/manual/de/security.database.sql-injection.php

    Oder als anderes Beispiel, die vielen bereits existenten CVEs zu SQL-Injections mit den darin sich befindlichen PoCs.

    Eine SQL-Injection ist nicht das Einschleusen von beliebigen Code, sondern das Einschleusen von beliebigen SQL-Statements, das ist schon ein ziemlich großer Unterschied. Wenn wir in diesem Falle eine Injektion von beispielsweise PHP Code hätten, wäre es auch keine SQL-Injection, sondern dann eine RCE, sofern weitere Faktoren gegeben wären.
    Habe mich bisher mit den Begriffen/der Kategorisierung nur sehr oberflächlich beschäftigt, daher sag ich recht herzlichen Dank für die sehr aufschlussreiche Diskussion.

    slice schrieb:

    Habe mich bisher mit den Begriffen/der Kategorisierung nur sehr oberflächlich beschäftigt, daher sag ich recht herzlichen Dank für die sehr aufschlussreiche Diskussion.


    Gern geschehen. Wenn dich das Thema rund um die Sicherheit interessiert, bist du immer herzlichst eingeladen auf meinem Blog vorbeizuschauen. Ich persönliche vertrete die Meinung, dass IT-Sicherheit jeden etwas angeht, und das durchaus über das Berufsschulwissen (Safety, Security und die drei Säulen der Sicherheit) hinweg. Es ist und war, meiner Ansicht nach, immer ein essentieller Schwerpunkt. Eben aus diesem Grund, schreibe ich desöfteren Beiträge aus genau diesem Umfeld.