RFZ: URL Kontext - Gefahren in href, src, etc?

Nabend,
nehmen wir an ich habe einen beliebigen String (Benutzereingabe) und möchte diesen als URL z.B. in den HTML Attributen href oder src einbinden.
Mit htmlentities() bringe ich den String in den richtigen Kontext für HTML.
Der String wird nun als URL interpretiert, ein Ausbrechen aus dem Kontext HTML sollte nicht mehr möglich sein (Ausnahme: HTML Attribute wurden in einfache Anführungszeichen gesetzt, diese maskiert htmlentities nicht! Sowas tue ich aber nicht...), allerdings kann es ja innerhalb des Kontexts URL Strings geben, die ich nicht haben möchte.
Ein Beispiel dafür wäre der String beginnend mit "javascript:".

Daher meine Frage: Welche Strings können auf einer Website gefährlich werden, wenn sie als URL interpretiert werden? (XSS Angriffe)

Interessant wären hier noch Steuer- oder Sonderzeichen. Dadurch erhalte ich zwar eine ungültige URL, aber können sie mir gefährlich werden? Zeilenumbrüche sicher nicht, aber wie sieht es mit einem Rückschritt oder Null-Byte aus?

Würd mich mal interessieren, für den Fall dass man eine URL eben nicht auf gültige Syntax prüft, sondern ungültige Syntax ausschließen möchte.

Gruß,
Andreas

  1. Hello,

    es würde wohl reichen, den String mit

    $linkapendix = htmlspecialchars(raw_url_encode($paramstring),ENT_QUOTES);

    zu behandeln.

    Ein harzliches Glückauf

    Tom vom Berg

    http://bergpost.annerschbarrich.de

    --
    Nur selber lernen macht schlau
    1. Hi Tom,

      es würde wohl reichen, den String mit
         $linkapendix = htmlspecialchars(raw_url_encode($paramstring),ENT_QUOTES);
      zu behandeln.

      es geht nicht um einen Parameter den ich einer URL anfügen möchte, es geht um den kompletten String innnerhalb des Attributs href. Da darin nicht zwangsweise eine URL steht, kann ich auch nicht nur deren Query-Teil behandeln. Ebensowenig kann ich den ganzen String behandeln, das würde eine URL ungültig machen.

      Die Frage war aber auch nicht, wie ich das Problem lösen kann, sondern welche Strings innerhalb eines href Attributs gefährlich werden können.
      Mir fällt als solches nur "javascript:" ein, wüsste aber gern, ob es da mehr gibt.

      Gruß,
      Andreas

      1. Moin!

        Die Frage war aber auch nicht, wie ich das Problem lösen kann, sondern welche Strings innerhalb eines href Attributs gefährlich werden können.
        Mir fällt als solches nur "javascript:" ein, wüsste aber gern, ob es da mehr gibt.

        Also mit NULL-Bytes taten sich eine zeitlang einige Browser schwer, ich glaube auch, dass man mit überlangen URLs einen Pufferüberlauf hervorrufen konnte.

        Was die Protokollangabe betrifft, würde ich eher auf eine Whitelist setzen. Also statt zu überlegen, welche Protokolle sich suboptimal auswirken können und dann doch welche zu übersehen, empfehle ich zu überlegen, welche Protokolle in deiner Anwendung sinnvoll sind. Vor einigen Jahren konntest du z.B. mit "telnet:" oder so deinen Browser dazu überreden, auf dem lokalen Rechner eine Datei zu schreiben. Die Whitelist liefe dann wahrscheinlich auf http, https, ftp und vielleicht noch ein paar andere hinaus.

        Schönes Wochenende,
        Robert

        1. Also mit NULL-Bytes taten sich eine zeitlang einige Browser schwer, ich glaube auch, dass man mit überlangen URLs einen Pufferüberlauf hervorrufen konnte.
          Was die Protokollangabe betrifft, würde ich eher auf eine Whitelist setzen. Also statt zu überlegen, welche Protokolle sich suboptimal auswirken können und dann doch welche zu übersehen, empfehle ich zu überlegen, welche Protokolle in deiner Anwendung sinnvoll sind. Vor einigen Jahren konntest du z.B. mit "telnet:" oder so deinen Browser dazu überreden, auf dem lokalen Rechner eine Datei zu schreiben. Die Whitelist liefe dann wahrscheinlich auf http, https, ftp und vielleicht noch ein paar andere hinaus.

          Danke, das sind schonmal gute Hinweise.
          Dass eine Whitelist besser ist, steht ausser Frage und in der Praxis werde ich auch immer eine solche einsetzen.
          Die Frage ist rein interessehalber :)

          Gruß,
          Andreas