XXS-Filter



  • Ich habe mich gerade mal ein bisschen zu dem Thema XSS belesen und bin dabei immer wieder auf die Technik gestoßen, in der man in der Web-Applikation Filter anhängt, die den User-Input nach kritischen Konstellationen durchsuchen.

    Soweit habe ich das verstanden.

    Man findet aber auf diversen Seiten solche [url="Cheat Sheets"]https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet[/url]. Im Endeffekt wohl besondere Konstellationen, die Filter möglicherweise austricksen.

    Sind denn Filter generell nicht zureichend sicher, oder gibt es einfach viele Filter, die unsauber geschrieben sind und nicht alle möglichen Konstellationen sicher betrachten?
    Das heißt wäre ein gut implementierter Filter ausreichend, um XSS-Attacken zu verhindern? Weil er jede mögliche Konstellation, JavaScript in die Seite zu bringen (betrachten wir nur mal reflected XSS), verhindern kann?
    Ohne, dass ich im Frontend sicher kontextbasiert escape?


  • Mod

    Filtern schrieb:

    Ich habe mich gerade mal ein bisschen zu dem Thema XSS belesen und bin dabei immer wieder auf die Technik gestoßen, in der man in der Web-Applikation Filter anhängt, die den User-Input nach kritischen Konstellationen durchsuchen.

    Blacklists sind hier der falsche ansatz.

    Einfach immer die Daten richtig sanitizen und fertig. Denn wie was wo und wann hängt immer vom Kontext ab. Ein "One size fits all" ist hier sehr fehleranfällig und vermittelt nur eine "false sense of security".



  • Shade Of Mine schrieb:

    Blacklists sind hier der falsche Ansatz.

    Einfach immer die Daten richtig sanitizen und fertig. Denn wie was wo und wann hängt immer vom Kontext ab. Ein "One size fits all" ist hier sehr fehleranfällig und vermittelt nur eine "false sense of security".

    Hast recht, hab tatsächlich selber noch etwas darüber nachgedacht - die Filter suchen ja meistens nur fertige Konstrukte.
    Dabei können sie natürlich nicht wirklich Konstrukte abfangen, die sich erst in Verbindung mit Spezifika der Website "ergänzen". Z.B bei einem HTML-Attribute, wennn das den Wert " onmouseover="java\1:..." annimmt, dann wird das ein Filter wohl nicht wirklich respektieren, obwohl das Konstrukt in einem <div someAttribut="${userInput}" /> natürlich schädlich wäre.

    Nun gut, für legacy Websites mit veralteten Rendering-Templateengines (JSP), die kein automatisches, kontextbasiertes escaping anbieten, ist ein Filter wohl immer noch die "effektivste" Methode, um wenigstens etwas Sicherheit gegenüber reflected XSS zu bieten.
    Sicherer ist natürlich das manuelle Nachholen des escapens, aber das ist natürlich enorm aufwendig.


  • Mod

    Filtern schrieb:

    Sicherer ist natürlich das manuelle Nachholen des escapens, aber das ist natürlich enorm aufwendig.

    modsecurity wäre hier der goto. Aber es ist ein Placebo. Man fühlt sich dadurch vielleicht besser, aber geschützt ist man dennoch nicht.

    Und wenn man es eh richtig macht, dann schadet modescurity nur (hatten wir schon öfters dass der dann zu aggressiv filtert und die Funktionalität der Seite beeinträchtigt).



  • Shade Of Mine schrieb:

    modsecurity wäre hier der goto. Aber es ist ein Placebo. Man fühlt sich dadurch vielleicht besser, aber geschützt ist man dennoch nicht.

    Und wenn man es eh richtig macht, dann schadet modescurity nur (hatten wir schon öfters dass der dann zu aggressiv filtert und die Funktionalität der Seite beeinträchtigt).

    Ja gut, ne WAF gibt's bei uns natürlich auch - aber die wird von einer ganz eigenen Abteilung (Infra) betrieben und verwaltet, da haben wir in der Entwicklung nicht viel Einfluss druaf.

    Mit modernen Rendering-Template-Engines sollte XSS ja eigentlich auch zunehmd weniger ein Thema sein?
    In dem Fall ist es halt eins, weil JSP kein automatisches escaping bietet.


  • Mod

    Filtern schrieb:

    Mit modernen Rendering-Template-Engines sollte XSS ja eigentlich auch zunehmd weniger ein Thema sein?
    In dem Fall ist es halt eins, weil JSP kein automatisches escaping bietet.

    Ja, aber Templates sind ja nur ein Teil. Die DB Komponente muss ja auch korrekt escapen, etc. Aber natürliche - moderne Libraries nehmen hier viel Arbeit ab.


Log in to reply