Les 10 plus grands risques d’OWASP

Le Ouvrir le projet Web Application Security (OWASP) conserve une liste de ce qu’ils considèrent comme la variable Les dix premiers risques de sécurité des applications web.

Ils sont répertoriés ci-dessous, ainsi qu’une explication de la façon dont CRX les traite.

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). En outre, SQL offre une prise en charge de la liaison de valeurs.
• LDAP : l’injection LDAP n’est pas possible, car le module d’authentification filtre l’entrée et effectue l’importation de l’utilisateur à l’aide de la méthode bind.
• Système d’exploitation : aucune exécution de shell n’est effectuée dans l’application.

2. Script intersite (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 directs 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. Erreur de configuration de la sécurité

Il est impossible de garantir que tous les logiciels sont toujours correctement configurés. Cependant, Adobe s’efforce de fournir le plus d’instructions possible et de rendre la configuration aussi simple que possible. De plus, AEM navires avec Contrôle d’intégrité de la sécurité intégré qui vous aident à surveiller en un coup d’oeil la configuration de la sécurité.

Consultez la section Liste de contrôle de sécurité pour plus d’informations qui vous fournissent des instructions de renforcement étape par étape.

7. Stockage cryptographique non sécurisé

Les mots de passe sont stockés sous la forme de hachages cryptographiques dans le noeud utilisateur. Par défaut, ces noeuds ne sont lisibles que par l’administrateur et l’utilisateur lui-même.

Les données sensibles telles que les informations d’identification tierces sont stockées sous forme chiffrée à l’aide d’une bibliothèque cryptographique certifiée FIPS 140-2.

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

Le référentiel autorise le paramètre de privilèges affinés (comme spécifié par JCR) pour un utilisateur ou un groupe donné, quel que soit le chemin d’accès, par le biais d’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.