Sicherheit im Webbenutzerschnittstellen-Framework - Schutz vor CSRF-Attacken

Mit diesem Verfahren können Sie im Webbenutzerschnittstellen-Framework vor CSRF-Attacken schützen.

Vorgehensweise

  1. Öffnen Sie die Datei "web.xml".
  2. Um das Token zu validieren, das zum Schutz vor CSRF-Attacken verwendet wird, erstellen Sie einen Anforderungsvalidator, der in der Anwendung registriert wird (sofern der Validator nicht bereits in der Datei "web.xml" vorhanden ist).

    Beispiel:

    <context-param>
      <param-name>scui-request-validator-10</param-name>
      <param-value>
    com.sterlingcommerce.ui.web.platform.security.SCUICSRFTokenValidator
      </param-value>
    </context-param>
  3. Legen Sie die Modi fest, in denen der Validator ausgeführt werden kann:
    • ALL - Sowohl POST- als auch GET-Anforderungen werden hinsichtlich des CSRF-Tokens validiert.
    • POST (Standard) - Nur POST-Anforderungen werden auf das CSRF-Token überprüft.
    • NONE - Der Validator validiert keine Anforderung hinsichtlich des CSRF-Tokens.

    Sie können den Validatormodus im Kontextparameter der Datei "config.xml" oder der Datei "web.xml" angeben (sofern der Validator nicht bereits in der Datei "web.xml" vorhanden ist).

    Die Standardeinstellung des Modus lautet POST, wenn kein Modus oder wenn für den Validierungsmodus kein Kontextparameter angegeben ist. IBM® empfiehlt die Verwendung des POST-Modus für die Validierung von Anforderungen.

    Beispiel:

    <context-param>
       <param-name>scui-csrf-validator-request-method</param-name>
       <param-value>ALL</param-value>
    </context-param>
  4. Richten Sie, falls erforderlich, URI-Einschluss- und Ausschlusslisten (URI - Universal Resource Indicator) für den Validator ein. Gehen Sie dazu nach den folgenden Vorgaben vor:
    • Wenn ein URI sich in der Ausschlussliste befindet, wird er nicht hinsichtlich des CSRF-Tokens validiert.
    • Wenn ein URI sich in der Einschlussliste befindet und sich nicht gleichzeitig in der Ausschlussliste befindet, wird er hinsichtlich des CSRF-Token validiert.
    Erstellen Sie mithilfe der folgenden Kontextparameter in der Datei "web.xml" Einschluss- und Ausschlusslisten. Es können beliebig viele Parameter angegeben werden.
    • csrf-include-uri

      Jede Anforderung mit einem URI, der mit dem Wert identisch ist, wird hinsichtlich des CSRF-Tokens validiert.

      Beispiel (für web.xml):

      <context-param>
         <param-name>csrf.include.uri.endswith.stk.1</param-name>
         <param-value>.do</param-value>
      </context-param>
    • csrf-include-uri-endswith

      Jede Anforderung mit einem URI, der mit dem Wert endet, wird hinsichtlich des CSRF-Tokens validiert.

      Beispiel (für web.xml):

      <context-param>
        <param-name>csrf.include.uri.endswith.stk.2</param-name>
        <param-value>.xml</param-value>
      </context-param>
    • csrf-include-uri-regex

      Jede Anforderung mit einem URI, der mit dem regulären Ausdruck (wird als Wert für den Parameter angegeben) übereinstimmt, wird hinsichtlich des CSRF-Tokens validiert.

      Beispiel (für web.xml):

      <context-param>
        <param-name>csrf.include.uri.stk.1</param-name>
        <param-value>/stk/home.jsp</param-value>
      </context-param>
    • csrf-bypass-uri

      Jede Anforderung mit einem URI, der mit dem Wert übereinstimmt, wird übergangen und nicht auf das CSRF-Token überprüft.

      Beispiel (für web.xml):

      <context-param>
        <param-name>csrf.bypass.uri.stk.1</param-name>
        <param-value>/console/login.jsp</param-value>
      </context-param>
    • csrf-bypass-uri-endswith

      Jede Anforderung mit einem URI, der mit dem Wert endet, wird übergangen.

      Beispiel (für web.xml):

      <context-param>
         <param-name>csrf.bypass.uri.endswith.stk.1</param-name>
         <param-value>.js</param-value>
      </context-param>
    • csrf-bypass-uri-regex

      Jede Anforderung mit einem URI, der mit dem regulären Ausdruck (wird als Wert für den Parameter angegeben) übereinstimmt, wird nicht auf das CSRF-Token überprüft.

      Beispiel (für web.xml):

      <context-param>
         <param-name>csrf.bypass.uri.regex.stk.1</param-name>
         <param-value>[a-zA-Z0-0]*servlet/param-value> 
      </context-param>

    Standardmäßig befinden sich alle URIs in der Einschlussliste, auch wenn kein csrf-include-Parameter angegeben ist. Sie müssen explizit angeben, dass ein URI sich in der Ausschlussliste befindet. Wenn keine Einschlussliste angegeben wird, wird standardmäßig von allen URIs angenommen, dass sie sich in der Einschlussliste befinden. Spezielle URIs können von der Anwendung einer Einschlussliste hinzugefügt werden, um zu vermeiden, dass alle URIs hinsichtlich des CSRF-Tokens validiert werden.

    Standardmäßig gibt das Framework eine Ausschlussliste an, um die CSRF-Validierung für Anforderungen für Dateien des Typs GIF, PNG, CSS oder JS zu übergehen.

  5. Die meisten CSRF-Attacken funktionieren einfach durch Replizieren von POST-Anforderungen in das jeweilige GET-Äquivalent. Da die meisten Anwendungen nicht zwischen POST- und GET-Anforderungen unterscheiden, sind die Attacken üblicherweise erfolgreich. Um zwischen GET- und POST-Anforderungen zu unterscheiden, richten Sie mithilfe des Parameters "requestMethodSupported" der Aktion die Modi in den Definitionen Ihrer Struts-Aktionen ein, in denen der Validator ausgeführt werden kann:
    • POST - (Standardeinstellung) Nur POST-Anforderungen sind zulässig.

      Wenn der Parameter "requestMethodSupported" nicht festgelegt oder ein unbekannter Wert ist, wird er standardmäßig auf POST festgelegt.

    • ALL - Sowohl GET- als auch POST-Anforderungen sind zulässig.

    Beispiel:

    <action name="accountTransfer" class="com.AccountTransfer">
      <param name="requestMethodSupported">POST</param>
      <param name="resourceId">AccountTransfer_Action002</param>
    </action>