RE: [sdx-developers] Paramétrage par défaut

[Frédéric Glorieux]

 > 1) Fred m'a dit hier que la validation du processeur XSL était
assez
 > lâche. J'avoue ne pas avoir trouvé où ni comment la durcir
(dans les
 > sitemap ? dans  cocoon.xconf ?). Je pense que, comme dans
SDX1, on
 > devrait avoir un paramétrage par défaut le moins permissif
 > possible :
 > ainsi, les bugs de XSL seraient rapidement identifiés (y
 > compris ceux de
 > sdxtest ;-)... ce qui soulagerait le trafic de [sdx-users] ;-)

cocoon.xconf
    <xml-parser
class="org.apache.avalon.excalibur.xml.JaxpParser"
logger="core.xml-parser">
        <parameter name="validate" value="false"/>
        <parameter name="namespace-prefixes" value="false"/>
        <!-- SDX modif: don't stop  -->
        <parameter name="stop-on-warning" value="false"/>
        <parameter name="stop-on-recoverable-error"
value="false"/>
        <parameter name="reuse-parsers" value="false"/>
        <!--
        <parameter name="sax-parser-factory" value="???"/>
        <parameter name="document-builder-factory" value="???"/>
        -->
    </xml-parser>

On met tout à true et on voit

Ne pas s'arrêter sur des erreurs recouvrables a par exemple ce
mauvais effet de laisser passer des expressions xpath fautives
pour des valeurs d'attribut.

Je crois que c'est reuse-parser qui a pu posé pb dans cocoon à
une époque.

 > 2) J'ai fait un essai de hack sur une appli du Ministère :-)
Voici
 > comment je m'y suis pris :
 >
 > - les xsp2sdx sont exposées : je peux ainsi récupérer
l'adresse de
 > l'api-url (qui est de toutes façons déterministe : je n'ai
 > absolument
 > pas besoin de xsp2sdx popur la trouver).
 > - dans la plupart des cas, je pourrai aussi récupérer
 > l'indentifiant de
 > l'appli, soit en xsp2xsp, soit en allant voir dans les xsl,
soit en
 > étatnt attentif aux url générées en HTTP GET.
 > - comme les xsp de l'api-url me sont également connues, je
 > peux utiliser
 > une fieldsearch. Ici, on pourrait prévenir les développeurs
 > d'appli de
 > ne mettre que certaines xsp, de les renommer... On peut
 > aussi concevoir
 > d'interdir l'accès à ces xsp à d'autres utilisateurs que le
 > processus
 > serveur...
 > - comme sdxuserdb est interrogeable, je peux donc faire une
 > requête sur
 > les sdxdocid de sdxuserdb de l'appli. J'obtiens ainsi la
listes des
 > utilisateurs :-)
 > - à partir de là, je peux utiliser une tactique de force brute
pour
 > essayer de trouver un user/password...
 >
 > La question est donc : doit-on rendre sdxusersdb
 > interrogeable par défaut ?

Qui est fautif ? Les développeurs SDX de fournir des commodité
sitemap, ou les développeurs d'appli de ne pas les supprimer ?
Peut-être faudrait-il une action sitemap pour contrôler l'accès
aux URL d'admin ?

 > Autre point :
 >
 > J'ai eu un truc bizarre en testant une appli. Alors qu'elle
 > n'était pas
 > ouverte, j'ai pu y accéder. Même après redémmarage du
 > serveur, nettoyage
 > de work et des fichiers WEB-INF/sdx/applications, j'ai encore
pu y
 > accéder. Certes, je n'ai pas fait ce test avec la version
 > CVS, mais ça
 > m'intrigue. Des idées ?

était-elle cherchable ?