Ankündigung

Einklappen
Keine Ankündigung bisher.

htmlspecialchars/htmlentities/XSS

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • htmlspecialchars/htmlentities/XSS

    Hi,
    die Suchfunktion ergab schon so einiges nur nicht mein folgendes Anliegen bzgl. des Postings hier...

    besteht das Problem auch wenn ich htmlspecialchars verwende?
    PHP-Code:
    function hsc($param) {
        return 
    htmlspecialchars($paramENT_QUOTES'UTF-8');

    oder muss ich alle ausgaben vorher auf den zeichensatz prüfen und erst dann escapen?
    also:
    PHP-Code:
    $bad_utf8 "An invalid UTF-8 string";

    // make sure it's really UTF-8
    $bad_utf8 mb_convert_encoding($bad_utf8'UTF-8'mb_detect_encoding($bad_utf8));

    $goodone htmlspecialchars($bad_utf8ENT_NOQUOTES'UTF-8')); 
    ich ging eigentlich davon aus das diese zeile reicht um xss angriffe zu verhindern.. und jetzt lese ich hier dass htmlentities alleine gegen css angriffe nicht ausreicht..

    (und htmlspecialchars ist doch nichts anderes als htmlentities nur das es weniger zeichen escaped? )

    danke eurer hilfe!

  • #2
    Hi,

    für Such-Anfragen habe ich bisher immer einen White-Filter implementiert, in dem nur die Zeichen /0-9A-Za-z -./ zugelassen wurden. Sofern deine Formulare alle einen Zeichensatz definieren, solltest du auch nicht mit mb_convert_encoding() - was ohnehin sehr Resourcen-intensiv ist - hantieren müssen.
    Viele Grüße,
    Dr.E.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1. Think about software design [B]before[/B] you start to write code!
    2. Discuss and review it together with [B]experts[/B]!
    3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
    4. Write [I][B]clean and reusable[/B][/I] software only!
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Kommentar


    • #3
      eine whitelist wäre natürlich eine alternative.. nur frage ich mich.. ist htmlspecialchars wirklich sicher gegen xss angriffe?
      so wie ich es bei einigen blogs gelesen hab ist es ja nicht der fall...

      damit keine falschen zeichensätze im formular verwendet werden, so wie es ja einige angreifer machen würde also folgendes reichen oder?

      HTML-Code:
      <form accept-charset="utf8">
      <!-- hier folgen die Formularelemente -->
      </form>

      Kommentar


      • #4
        Nein. Clientseitige Angaben sagen überhaupt nichts aus.
        [COLOR="#F5F5FF"]--[/COLOR]
        [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
        [COLOR="#F5F5FF"]
        --[/COLOR]

        Kommentar


        • #5
          Bedingt. Die üblichen Browser halten sich dran, für Attacken, die über Tools initiiert werden, ist das untauglich. Letztere kannst du vielleicht an der nicht vorhandenen Session-ID erkennen, ...
          Viele Grüße,
          Dr.E.

          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          1. Think about software design [B]before[/B] you start to write code!
          2. Discuss and review it together with [B]experts[/B]!
          3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
          4. Write [I][B]clean and reusable[/B][/I] software only!
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          Kommentar


          • #6
            für Attacken, die über Tools initiiert werden, ist das untauglich.
            Das meinte ich. Allein schon mit einem Proxy (e.g. Webscarab) kann ich die Header manipulieren und damit auch die angeforderten Zeichensätze.
            [COLOR="#F5F5FF"]--[/COLOR]
            [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
            [COLOR="#F5F5FF"]
            --[/COLOR]

            Kommentar


            • #7
              ok soweit ist mir die sache mit der codierung klar...

              und ich nehme weiterhin an dass htmlspecialchars($post, ENT_QUotes, utf
              nur dann sicher ist wenn auch wirklich utf8 ankommt, richtig? so würde ich den blog siehe oben verstehen.

              also einzige möglichkeit mich gut vor xss angriffen zu schützen:
              -jegliche html ausgabe (und warum nicht auch jegliche formulareingabe) durch eine whitelist zu drücken damit am ende nur das rauskommt was es auch soll!

              odeR?

              Kommentar


              • #8
                Zitat von taurus Beitrag anzeigen
                und ich nehme weiterhin an dass htmlspecialchars($post, ENT_QUotes, utf
                nur dann sicher ist wenn auch wirklich utf8 ankommt, richtig?
                Wieso das? So lange htmlspecialchars keinen Bug hat, sehe ich da kein Problem. Interpretiert eine Funktion einen String als UTF-8 und escapet ihn dementsprechend und erfolgt die Ausgabe dann auch als UTF-8 (!), sollte das Escaping ungeachtet des Eingabe-Encodings wie vorgesehen greifen. (Davon würde ich zumindest ausgehen. Einer von 10.000 Hackern könnte anderer Ansicht sein.) Das ist schließlich der Sinn solcher Funktionen.

                (Edit: Da die von htmlspecialchars behandelten Zeichen alle in ASCII liegen, ist es hier afaik nicht so wichtig, sicherzustellen, dass auch im richtigen Charset ausgegeben wird. Bei anderen Funktionen sieht das aber anders aus.)

                Zitat von taurus
                also einzige möglichkeit mich gut vor xss angriffen zu schützen:
                -jegliche html ausgabe (und warum nicht auch jegliche formulareingabe) durch eine whitelist zu drücken damit am ende nur das rauskommt was es auch soll!

                odeR?
                Die XSS-Szenarien haben in der Regel bestimmte Voraussetzungen, die gegeben sein müssen. Die im verlinkten Blogeintrag vorgestellten Angriffe sind nur beim Einfügen von Benutzereingaben in Attribute von Tags problematisch oder sogar nur bei denjenigen Attributen, die unter Umständen JavaScript ausführen können (href). Ein htmlspecialchars steht standardmäßig auf ENT_COMPAT, das heißt, doppelte Anführungszeichen werden kodiert. Bei "normal" geschriebenem HTML-Code würde da schon das "Attribut schließen und neues Attribut definieren"-Problem wegfallen. Bliebe allerdings noch die Sache mit href="javascript:eval(String.fromCharCode(...))". Die dürfte jedoch schon durch einen einfachen Eingabevalidator behoben werden, denn vermutlich wird man irgendwo prüfen, ob der Benutzer für eine URL auch tatsächlich sowas wie eine URL angegeben hat.

                Ich denke, diese Angriffsszenarien werden auf den meisten Seiten indirekt verhindert, ohne dass der Entwickler sich bewusst ist, dass sie überhaupt existieren. Das mag nicht wie ein wünschenswerter Zustand klingen, aber -- na ja -- vollständige Sicherheit wird in den meisten Fällen ewig eine Illusion bleiben[1] und Software ist so komplex, dass man unmöglich jede Fremdbibliothek überprüfen kann (ungeachtet der Frage, ob das etwas bringen würde).

                Damit will ich nicht sagen, dass man die möglichen Standardangriffe nicht kennen sollte oder kennen müsste, sondern eher, dass man darüber nachdenken sollte, was passiert, wenn doch noch eine Lücke gefunden wird.



                [1] Im Zweifel sind's Layer 8-Fehler. Ich habe zum Beispiel mal meine externe Festplatte aus Versehen vom Tisch geworfen. Zum Glück hatte ich meinen Sourcecode aus irgendeinem Grund auf der internen Platte abgelegt, aber alle Fotos und das Musikarchiv waren weg. Ich hätte jedenfalls im Leben nicht gedacht, dass mir das mal passieren würde. Es ist nur eine Frage der Zeit, bis ungesicherte Daten unwiederbringlich verloren gehen. Lektion gelernt? Nicht wirklich...

                Kommentar


                • #9
                  Kannst dir auch mal den html purifier ansehen.

                  grüße
                  I like cooking my family and my pets.
                  Use commas. Don't be a psycho.
                  [URL="http://jscouch.de"]Blog[/URL] - [URL="http://coverflowjs.github.io/coverflow/"]CoverflowJS[/URL]

                  Kommentar

                  Lädt...
                  X