web-dev-qa-db-fra.com

Contrainte de sécurité de liste blanche dans web.xml

J'utilise Tomcat pour mon application Struts2. Le web.xml a certaines entrées comme indiqué ci-dessous:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>PUT</http-method>
        <http-method>DELETE</http-method>
        <http-method>TRACE</http-method>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>
<security-constraint>
   <web-resource-collection>
       <web-resource-name>no_access</web-resource-name>
       <url-pattern>/jsp/*</url-pattern>
   </web-resource-collection>
   <auth-constraint/>
</security-constraint>
    <security-constraint>
   <web-resource-collection>
       <web-resource-name>no_access</web-resource-name>
       <url-pattern>/myrrunner/*</url-pattern>
   </web-resource-collection>
   <auth-constraint/>
</security-constraint>

Comment puis-je modifier les parties de la liste noire pour utiliser uniquement la partie de liste blanche ... Par exemple, au lieu de mettre sur liste noire les méthodes PUT, DELTE http, je dois mettre en liste blanche d'autres méthodes mais je ne suis pas sûr que le syntaxe de leur mise en liste blanche et quelles méthodes pour les mettre en liste blanche.

Pour mon ci-dessus web.xml extrait, j'apprécierai si quelqu'un peut me fournir une contre-partie whitelisitng pour ci-dessus xml.

EDIT: Aussi, comment pourrais-je vraiment vérifier si la solution fonctionne ou non?

Merci

javatomcatstruts2web.xmlsecurity-constraint
23
Mike

J'essaierais ce qui suit:

<security-constraint>
    <web-resource-collection>
        <url-pattern>/*</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <!-- no auth-constraint tag here -->
</security-constraint>

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
   <auth-constraint/>
</security-constraint>

La première security-constraint n'a pas de auth-constraint, donc les méthodes GET et POST sont disponibles pour tous sans connexion. La seconde restreint les autres méthodes http pour tout le monde. (Je ne l'ai pas essayé.)

21
palacsint

Nouvelle fonctionnalité de Java EE 6 qui simplifie la configuration de la sécurité des applications. Vous pouvez désormais ajouter à la liste blanche les méthodes HTTP autorisées dans votre web.xml:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Disable unneeded HTTP methods by 403 Forbidden them</web-resource-name>
        <url-pattern>*</url-pattern>
        <http-method-omission>GET</http-method-omission>
        <http-method-omission>HEAD</http-method-omission>
        <http-method-omission>POST</http-method-omission>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>

Référence: https://docs.Oracle.com/cd/E19798-01/821-1841/bncbk/index.html#6nmq2cpkb

11
aviundefined

Un léger ajustement à la réponse acceptée (définissez le url-pattern dans la seconde security-constraint pour mapper sur le servlet par défaut "/") fonctionne pour JBoss et Weblogic mais pas pour Websphere:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Allowed methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <!-- no auth-constraint tag here -->
</security-constraint>
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Restricted methods</web-resource-name>
        <url-pattern>/</url-pattern>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>

Avec la configuration des contraintes de sécurité ci-dessus, je ne sais pas pourquoi Websphere autorise toutes les méthodes HTTP, tandis que JBoss et Weblogic n'autorisent que GET et POST.

3
mendozal