Kleine Lücke in der RECMS

    Zurzeit wurde wieder eine Lücke bzw sehr viele Lücken von der Gattung : crsf gefunden.

    Naja wie ihr wisst ist in der Housekeeping Sachen wie z.b News löschen , Editieren , Hinzufügen etc.

    All diese Scripts werden so ausgefürt news.php?add=blublub?desc=s
    Weil in der isset bzw in der $_POST noch keine genauere definition bzw mehrere If abfragen gibt kann ein ganz normaler Habbo mit einem Rank =1 den script ausführen .

    Wie kann ich mich schützen ?

    Praktisch gesehen muss man alle POSTs und GETs mit einem Token versehen.
    Man kann aber auch bei jeder isset eine rankabfrage reinhauen damit er den script nicht entern kann weil er den rank 1 besitzt.


    Thanks on Steve ;)

    Einige haben die POSTS isset beim HK mit SESSIONs reingelegt zb

    Ein TIPP:
    Man ist im Housekeeping eingeloggt sobald man die $_SESSION['acp'] offen hat ;)

    Wie kriegt man sie offen meistens mit ein Cookie Editor :)

    Zitat

    Man kann aber auch bei jeder isset eine rankabfrage reinhauen damit er den script nicht entern kann weil er den rank 1 besitzt.

    Es gibt normalerweise immer eine Rankabfrage im Housekeeping.
    Der Sinn von CSRF ist, dass nicht der Hacker das Formular um z.B. den Rank eines Users zu ändern absendet, sondern der Admin selber.

    Man würde als Hacker also auf einer externen Seite ein Formular bauen, welches die POST-Daten an beispielsweise
    http://0815retro.de/hk/rankändern.php
    sendet, um einem User einen Rank zu geben. Dieses Formular muss der Admin des Retros dann selber ausführen.

    Zitat von Johnix

    Es gibt normalerweise immer eine Rankabfrage im Housekeeping.
    Der Sinn von CSRF ist, dass nicht der Hacker das Formular um z.B. den Rank eines Users zu ändern absendet, sondern der Admin selber.

    Angenommen machen wir mal so


    if(isset($_GET['alarm] && $user->rank > 3))
    echo "it works"

    Er würde die isset nur ausführen wenn der user den rank 4 oder höher hat .

    Amsonsten würde nichts passieren.

    Und das mein ich.


    Ich verweise auf meine nachträglich eingefüge Stelle im oberen Post.

    Zitat

    Man würde als Hacker also auf einer externen Seite ein Formular bauen, welches die POST-Daten an beispielsweise

    http://0815retro.de/hk/rankändern.php

    sendet, um einem User einen Rank zu geben. Dieses Formular muss der Admin des Retros dann selber ausführen.

    Der Hacker selber führt kein POST aus, sondern der Admin!
    Und dabei bringt eine Rankabfrage rein garnichts. Hier muss man dann mit Tokens arbeiten oder bei einer "Passwort ändern"-Seite mit einem Feld, bei dem das alte Passwort verlangt wird.
    Und hierbei ist fast jedes Retro angreifbar, da ich noch kein Retro gesehen habe das Tokens benutzt.

    Das ist CSRF!

    Einmal editiert, zuletzt von Johnix (19. Oktober 2013 um 18:04)

    Zitat von Johnix

    Und hierbei ist fast jedes Retro angreifbar, da ich noch kein Retro gesehen habe das Tokens benutzt.

    Das Kubbo Hotel nutzt Tokens im Housekeeping.

    Ganz einfach: Generiere einen Token beim Aufruf der was weiß ich.. Hotelalert Seite und speichere diesen
    in der Session ab. In dem Hotelalert Form fügst du dann so etwas hinzu wie etwa <input type="hidden" value="%token% name="token" />.
    Danach, wenn das Formular abgesendet wird, checkst du einfach ob das Feld "token" mitgesendet wurde und ob es den gleichen Token
    beinhaltet wie der, der vorher beim Aufruf der Seite generiert wird. Somit bist du wirksam gegen CSRF geschützt, da die externe Seite, auf der das Formular gefakt abgesendet wird, deinen Token nicht abrufen kann, und deshalb auch keine Aktion folgt.

    Cheers
    Steve Winfield

    Zitat von Steve Dleifniw

    Das Kubbo Hotel nutzt Tokens im Housekeeping.

    Ganz einfach: Generiere einen Token beim Aufruf der was weiß ich.. Hotelalert Seite und speichere diesen
    in der Session ab. In dem Hotelalert Form fügst du dann so etwas hinzu wie etwa .
    Danach, wenn das Formular abgesendet wird, checkst du einfach ob das Feld "token" mitgesendet wurde und ob es den gleichen Token
    beinhaltet wie der, der vorher beim Aufruf der Seite generiert wird. Somit bist du wirksam gegen CSRF geschützt, da die externe Seite, auf der das Formular gefakt abgesendet wird, deinen Token nicht abrufen kann, und deshalb auch keine Aktion folgt.

    Cheers
    Steve Winfield


    Dann muss ich ja bei jeder input den token hineintragen bzw die variable zu den token...

    Pwah das wird eine Arbeit sein

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden