Quelle est la qualité de votre sécurité AEM ? – Résolution de l’élingue

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. Le sujet d’aujourd’hui est Sling Resolution.

Articles précédents dans la série :

Vulnérabilités de résolution Sling

Les ensembles de règles Dispatcher Allow sont l’un des plus grands vecteurs de risque dans AEM en raison du comportement de résolution Sling par défaut. Passez une grande partie de votre temps à tester la sécurité ici, car c’est le moyen le plus courant pour les acteurs malveillants de trouver d’autres vulnérabilités, de compromettre des données au sein du système et d’exécuter du code à distance.

L’exécution de code à distance (RCE) est la préoccupation la plus importante, car un attaquant peut bénéficier d’un large éventail d’options d’exploitation supplémentaires. Cela peut inclure la rupture du système, la compromission des données, le vol des informations d’identification des utilisateurs et la création de pages de phishing sur des domaines légitimes.

Lors de la création de mesures défensives, il est utile de savoir comment RCE peut se produire en premier lieu. RCE est possible si le pirate peut accéder à la console OSGI, en écrivant dans /apps ou (dans les systèmes non sécurisés) /content, Querybuilder, Groovy console, ACS AEM Tools ou WebDAV. Il est préférable d’interdire complètement l’accès à ces fonctionnalités sur les éditeurs de production pour tout utilisateur. À partir de là, utilisez les meilleures pratiques d’Adobe consistant à refuser tous les chemins, puis à autoriser les chemins nécessaires. La plupart de ces vulnérabilités potentielles devraient être atténuées par la dernière version des règles du répartiteur présentes dans Archétype du projet AEM d’Adobemais cela vaut également la peine de le confirmer dans votre propre répartiteur.

Ce qui suit n’est pas une liste exhaustive des vulnérabilités, mais cela vous donnera une idée de ce qu’il faut commencer à rechercher.

• Parfois, les développeurs écrivent des règles de refus trop rigides ou autorisent des règles qui ne le sont pas assez. Par exemple, une demande de /bin/querybuilder.json/test.css peut toujours renvoyer la page du générateur de requêtes AEM. À la place d’utiliser:

{ /type “deny” /path “/bin/querybuilder” }

Utiliser le caractère générique

{ /type “deny” /path “/bin/querybuilder*” }

• correspondance pour les chemins enfant et extension. Par exemple
• L’ajout de sélecteurs, de paramètres d’URL, de plusieurs barres obliques à l’URL peut modifier la façon dont Sling et le répartiteur interprètent la demande. De nombreuses vulnérabilités reposent sur l’exposition de la structure de contenu JCR via des requêtes de rendu .json.
• Si un utilisateur malveillant accède à la structure du contenu, il peut souvent extraire des noms d’utilisateur, des informations d’identification stockées en texte brut, des PII, des pages d’administration exposées ou des indices sur d’autres vulnérabilités du système. Tout ce qu’il peut falloir, c’est que l’attaquant trouve 1 nom d’utilisateur où il peut forcer brutalement le mot de passe, pour avoir une violation de données beaucoup plus importante.
• Par défaut, les sélecteurs numérotés (-1,1,2,3…), « enfants » et « infini » dans une requête sont interprétés par Sling pour afficher le chemin de contenu actuel et les ressources Sling sous celui-ci sous forme de réponse JSON. Cette fonctionnalité ne doit pas être disponible sur le répartiteur. Si vous avez activé Exportateurs de modèles d’élingues

pour vos objets Sling Model, assurez-vous qu’aucune donnée ou propriété sensible n’est exposée accidentellement dans la réponse.

Mise en pratique

Au fur et à mesure que la part de marché d’AEM augmente, l’incitation des pirates à trouver des exploits augmente également. Il est donc très important de tester et de se tenir au courant des dernières règles d’autorisation recommandées. Testez très soigneusement toutes les règles qui s’écartent de l’ensemble de règles standard.

• Besoin d’exemples pratiques ? Ci-dessous, j’ai fourni quelques URL de base à tester sur votre répartiteur. Sur l’Internet public, ceux-ci doivent renvoyer un 404 ou rediriger de manière appropriée. Sinon, cela représente une vulnérabilité au sein de votre application.
• /content.infinity.json
• /.1.json
• /content.5.json
• /content.ext.json
• /content.children.json/test.css
• /etc.-1.json
• /content.html/test.png/test.1.json
• /bin/querybuilder.json/test.css
• /bin/querybuilder.json?a.html
• /bin/querybuilder.json.css
• /bin/querybuilder.json.servlet.css
• //bin//querybuilder.json

/system/console/bundles?.css

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 contactpour commencer votre voyage