Les 10 plus grands risques d’OWASP

Le projet Open Web Application Security Project (OWASP) tient à jour une liste de ce qu’il considère comme les 10 plus grands risques de sécurité liés aux applications web.

Ces risques sont répertoriés ci-dessous, avec une explication sur la manière dont ils sont gérés par CRX.

1. Injection

  • SQL -Empêché par défaut : La configuration de référentiel par défaut ne comprend ni ne requiert de base de données traditionnelle et toutes les données sont stockées dans le référentiel de contenu. Tous les accès sont limités aux utilisateurs authentifiés et ne peuvent avoir lieu que via l’API JCR. SQL est pris en charge pour les requêtes de recherche uniquement (SELECT). SQL offre en outre une prise en charge de la liaison des valeurs.
  • LDAP : L’injection LDAP est impossible, car le module d’authentification filtre l’entrée et exécute l’importation des utilisateurs à l’aide de la méthode de liaison.
  • OS : Aucune exécution shell n’est effectuée dans l’application.

2. Cross-Site Scripting (XSS)

La solution générale consiste à coder toutes les sorties du contenu créé par l’utilisateur avec une bibliothèque de protection XSS côté serveur basée sur OWASP Encoder et AntiSamy.

Le XSS est une priorité majeure pendant le test et le développement et les problèmes détectés sont (généralement) résolus immédiatement.

3. Authentification interrompue et gestion des sessions

AEM utilise des techniques d’authentification performantes et éprouvées, qui font appel à Apache Jackrabbit et Apache Sling. Les sessions de navigateur ou HTTP ne sont pas utilisées dans AEM.

4. Références d’objets directes non sécurisées

Tous les accès aux objets de données sont arbitrés par le référentiel et donc restreints par le contrôle d’accès basé sur les rôles.

5. Cross-Site Request Forgery (CSRF)

Une attaque Cross-Site Request Forgery (CSRF) est arbitrée en injectant automatiquement un jeton cryptographique dans l’ensemble des formulaires et des requêtes AJAX et en vérifiant ce jeton sur le serveur pour chaque requête POST.

En outre, AEM est fourni avec un filtre référent-en-tête, qui peut être configuré pour autoriser uniquement les requêtes POST d’hôtes spécifiques (inscrits dans une liste autorisée).

6. Configuration incorrecte de la sécurité

Il est impossible de garantir que tous les logiciels sont toujours correctement configurés. Toutefois, nous nous efforçons de fournir autant d’assistance que possible et de rendre la configuration aussi simple possible. En outre, AEM est fourni avec des contrôles d’intégrité intégrés de la sécurité qui vous aident à surveiller la configuration de la sécurité en un clin d’œil.

Veuillez examiner la Liste de contrôle de sécurité pour plus d’informations et obtenir des instructions étape par étape.

7. Stockage cryptographique non sécurisé

Les mots de passe sont stockés en tant que hachages cryptographiques dans le nœud d’utilisateur ; par défaut, ces nœuds sont lisibles uniquement par l’administrateur et par l’utilisateur lui-même.

Les données sensibles telles que les identifiants tiers sont stockées dans un formulaire chiffré à l’aide d’une bibliothèque cryptographique certifiée FIPS 140-2.

8. Échec de la restriction de l’accès à l’URL

Le référentiel permet de définir des autorisations précises (comme spécifié par JCR) pour n’importe quel utilisateur ou groupe dans n’importe quel chemin d’accès, via des entrées de contrôle d’accès. Les restrictions d’accès sont appliquées par le référentiel.

9. Protection insuffisante de la couche de transfert

Atténué par la configuration du serveur (par exemple, utilisez HTTPS uniquement).

10. Redirections et transferts non validés

Risque atténué en restreignant toutes les redirections à des destinations fournies par l’utilisateur vers des emplacements internes.

Sur cette page