jsf url-mapping sicherheitsrisiko

Question

Wenn Sie JSF verwenden, haben Sie das Controller-Servlet javax.faces.webapp.FacesServlet, das auf Folgendes abgebildet wird:

<servlet-mapping>
   ...
    <url-pattern>/somefacesurl/*</url-pattern>
</servlet-mapping>

Wenn wir eine mypage.xhtml in / ablegen, haben wir ein Sicherheitsrisiko, da auf sie auf zwei Arten zugegriffen wird (ausgehend vom Anwendungskontext): 1) /somefacesurl/mypage.xhtml 2) /mypages.xhtml

Die erste wird von jsf verarbeitet und ist korrekt. Die zweite wird nicht von jsf verarbeitet und wird daher dem Client mit jsf-Tags präsentiert, was ein Sicherheitsrisiko darstellt.

Ich habe nur zwei Lösungen gefunden
1) immer auf die Root-Url abbilden:

<servlet-mapping>
   ...
    <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

Gute Lösung, erlaubt aber nur Zuordnungen nach Dateierweiterung.

2) Verknüpfen Sie mit einer beliebigen URL und verwenden Sie die Sicherheitseinschränkung, um den Zugriff auf diese Dateien zu verbieten, wie in vorgeschlagen: Wie verhindert man den Benutzerzugriff auf die .xhtml-Seite in JSF?

Beide Lösungen werden in der JSF 2.0-Spezifikation als praktikable Alternativen vorgestellt, ABER es wird kein Wort über den unterschiedlichen Sicherheitsansatz der beiden Lösungen verloren.

Da die Sicherheit NICHT berücksichtigt wird, frage ich mich, ob die erste "sicher" ist, was den Zugriff auf die xhtml-Dateien angeht, oder ob es vielleicht einen Hack gibt, um die .xhtml-Quellen zu erhalten.

Answer 1

Es stimmt nicht, dass die JSF-Spezifikation das erste Mapping vorschreibt. In Kapitel 11.1.2 der JSF 2.0-Spezifikation (die Sie lesen sollten) und in Kapitel 10.1.2 der JSF 1.2-Spezifikation werden lediglich Beispiele für beide Mappings genannt. Hier ist ein relevanter Auszug aus der JSF 2.0 Spezifikation (Hervorhebung von mir):

11.1.2 Servlet-Zuordnung

Alle Anfragen an eine Webanwendung werden einem bestimmten Servlet zugeordnet, wenn sie einem URL-Muster entsprechen Java-Servlet-Spezifikation ) gegen den Teil der Anfrage-URL nach dem Kontextpfad, der dieses Web ausgewählt hat Anwendung ausgewählt hat. JSF-Implementierungen müssen Webanwendungen unterstützen, die eine <servlet-mapping> die jede gültige url-pattern zum FacesServlet . Die Zuordnung von Präfixen oder Erweiterungen kann verwendet werden. W Präfix-Zuordnung wird die folgende Zuordnung empfohlen, ist aber nicht erforderlich:

<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>/faces/*</url-pattern>
</servlet-mapping>

Bei der Verwendung der Erweiterungszuordnung wird die folgende Zuordnung empfohlen, ist aber nicht erforderlich:

<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>*.faces</url-pattern>
</servlet-mapping>

Zusätzlich zu FacesServlet JSF-Implementierungen können andere Möglichkeiten zum Aufrufen der J Verarbeitungslebenszyklus aufzurufen, aber Anwendungen, die sich auf diese Mechanismen verlassen, sind nicht portabel.

Ich verstehe wirklich nicht, warum eine Zuordnung von Endungen (Suffixen) "heikel" sein soll. Mehr noch, dies ist mein Lieblings-JSF-Mapping. Ich empfehle die Verwendung von *.xhtml als JSF-Zuordnung. Dies hat auch den Vorteil, dass Sie sich nicht mit Sicherheitsbeschränkungen herumschlagen müssen, um den direkten Zugriff auf Quelldateien zu verhindern.

---

Update : Bitte beachten Sie, dass das Quellcodeleck per se kein Sicherheitsproblem darstellt, solange die Ansicht deklarativ ist und keine einzige Zeile Java-Quellcode enthält, in der Variablen wie Datenbank-Benutzername/Passwort gespeichert und offengelegt werden. Da Facelets eingebetteten Java-Rohcode (wie JSP-Skriptlets) nicht zulassen, sehe ich nicht, wie das ein Sicherheitsleck sein soll. Was kann ein Hacker mit dem Quellcode der Ansicht machen? Sie bearbeiten, rendern und irgendwie zurücksenden? (Ich würde mich wirklich fragen wie ). Das ist schlichtweg unmöglich, da JSF standardmäßig auch auf den View-Status auf der Serverseite angewiesen ist.

Ich stimme jedoch dem Punkt zu, dass die JSF-Spezifikation den Leser mehr darüber informieren sollte. Ich habe erstellt JSF-Spezifikation Ausgabe 1015 für diese.