Quelle est la qualité de votre sécurité AEM ? – XSS

Les violations de données à grande échelle et les failles de sécurité critiques poussent plus que jamais les entreprises à se préoccuper de la sécurité. De nombreux développeurs connaissent le top 10 OWASP (https://owasp.org/www-project-top-ten/) et il existe déjà de nombreuses ressources sur l’atténuation générique de ces vulnérabilités. Au lieu de cela, dans cette série, je couvre les problèmes de sécurité et les atténuations spécifiques à AEM.

XSS et AntiSamy

En guise d’examen rapide, Cross Site Scripting (XSS) peut se produire si les entrées saisies par l’utilisateur ne sont pas filtrées avant d’être renvoyées à l’utilisateur. N’oubliez pas que le contenu saisi par l’utilisateur peut inclure des sources que les utilisateurs ne modifient généralement pas, telles que les paramètres d’URL, le stockage local et les cookies. De nombreuses applications devront également filtrer le contenu utilisateur des e-mails HTML et JS avant de les envoyer.

Lors de l’utilisation de balises HTL dans AEM, le contexte de rendu par défaut et tous les autres contextes autres que « non sécurisé » utiliseront un ensemble de règles OWASP appelé AntiSamy. Parfois, cet ensemble de règles peut filtrer plus que prévu, et certains développeurs ont recours à l’attribut context=’unsafe’ qui restitue le texte brut à partir de la propriété Sling Model.

Un cas d’utilisation courant avec lequel la bibliothèque AntiSamy par défaut interfère est le téléphone (tel:) hrefs dans les liens. Par exemple:

<a href=”${model.url @ context="html"”>
  ${model.urlText @ context=’html’}
</a>

N’autorisera pas model.url = tél://555-555-555 pour être sorti correctement sur la page. Un développeur pourrait simplement recourir à :

<a href=”${model.url @ context="unsafe"”>
  ${model.urlText @ context="html"}
</a>

ou pire:

${model.rteText @ context="unsafe"}

Conception de solutions

Heureusement, nous avons quelques options autres que l’utilisation de context=’unsafe’.

1. Concevez vos composants pour utiliser des indicateurs de fonctionnalité pour les attributs codés en dur ou les caractères spéciaux sortis séparément de l’entrée de l’utilisateur ou de l’auteur.
2. Vous pouvez superposer l’ensemble de règles par défaut situé à /libs/cq/xssprotection/config.xml. Veillez à ne pas autoriser plus d’attributs ou de caractères spéciaux que ce dont vous avez besoin, ou ceux couramment utilisés par les exploits pour exécuter JavaScript.
3. Utilisez un service backend personnalisé ou un utilitaire statique qui réécrit les caractères saisis dans le substitut souhaité autre que vide.

Ma préférence est #1 donc je vais donner un exemple. Avec ces considérations, votre mise en œuvre peut ressembler davantage à ce qui suit :

<a data-sly-test=”${!model.isPhoneLink}” href=”${model.url @ context="html"”>
  ${model.urlText @ context=’html’}
</a>
<a data-sly-test=”${model.isPhoneLink && model.isValidPhone}”
    href=”tel:// ${model.url @ context=’html’}${ model.phoneExt ? ',' : ''}${properties.phoneExt @ context="html"}
    x-cq-linkchecker="skip">
  ${model.url @ context="html"}${model.extentionText || ‘’ @ context="html"}${properties.phoneExt @ context="html"}
</a>
<a data-sly-test=”${model.isPhoneLink && !model.isValidPhone}”>
  ${model.invalidPhoneMsg}
</a>

Avez-vous des utilisations context = ‘unsafe’ dans votre base de code ? Cela vaut la peine de vérifier si c’est exploitable. Mais ce n’est que le début du processus d’examen des vulnérabilités XSS.

Pour plus d’informations sur la façon dont Perficient peut vous aider à atteindre vos objectifs de sécurité AEM et à mettre en œuvre vos expériences numériques de rêve, nous aimerions avoir de vos nouvelles.

Ils compléteront le contact pour commencer votre voyage.