Ankündigung

Einklappen
Keine Ankündigung bisher.

Template-View: Globaler XSS-Filter sinnvoll?

Einklappen

Neue Werbung 2019

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

  • Template-View: Globaler XSS-Filter sinnvoll?

    Um Cross Site Scripting weitestgehend zu verhindern, kann man ja htmlspecialchars() verwenden. In meiner View-Klasse registriere ich daher einen globalen XSS-Filter, der diese Funktion auf alle Variablen ausführt:

    PHP-Code:
    $view->addGlobalFilter(new XSSFilter()); 
    Die Templates verzichten vollständig auf echo, es sollten nur die Methoden $this->show($var) oder $this->showVar($name) verwendet werden, damit alle registrierten Filter auch greifen.

    Meine Frage lautet: Ist das Vorgehen sinnvoll? Der Vorteil ist, dass sich eine vergessene escape-Anweisung nicht später rächt. Andererseits wird dadurch htmlspecialchars() auf wirklich jede Template-Variable angewendet, also auch auf Integers und Strings, die keine Benutzereingaben sind.

    Wirkt sich das vielleicht zu sehr auf die Performance aus?

  • #2
    Der Nachteil ist die fehlende Flexibilität. Angenommen, Du willst noch einen Filter benutzen (z. B. alles groß schreiben oder was auch immer). Nun soll z. T. aber HTML-Code ausgegeben werden. Bei den zwei Filtern hast Du aber nur noch die Möglichkeit, beide oder keinen zu benutzen. Was nun?

    Kommentar


    • #3
      Für den Fall hatte ich mir überlegt, das Ignorieren von Filtern zuzulassen (je nach Belieben beim Zuweisen oder im Template):

      PHP-Code:
      $options = new VariableDisplayOptions();

      $options->setIgnoreGlobalFilters();
      // oder:
      $options->addIgnoredFilter('XSSFilter');

      $view->assign('html_code''<b>Hello World</b>'$options); 

      Kommentar


      • #4
        Das ist jedoch ebenso unflexibel, weil du dann in deiner Filter-Chain konkrete Filter kennen musst. Das sollte IMHO nicht passieren, sondern es sollte vielmehr die Möglichkeit geben, das View-Abhängig zu steuern. Wenn du - wie xm22 schon anführt - an manchen Stellen einen Filter nicht anwenden möchtest, sollte es möglich sein, das in einem eigenen View auch zu berücksichtigen. Alternative: man hat Standard-Filter in einem View und kann bei
        PHP-Code:
        $this->show('foo'
        noch einen extra Filter angeben:
        PHP-Code:
        $this->show('foo',new Sting2UpperFilter(...)) 
        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


        • #5
          Ok, jetzt komme ich nicht mehr mit

          Wie steuere ich das konkret "View-Abhängig"? Vom abstract abgeleitete View-Klassen schreiben? Oder die Filter erst kurz vor der Ausgabe registrieren (dann dürfte ich sie ja als bekannt voraussetzen)?

          Das mit den extra Filtern ist implementiert, die gelten dann als lokal und nur für die entsprechende Variable.

          Kommentar

          Lädt...
          X