Publié par: Andrey Pinchuk | Développeur AEM senior certifié
Imaginez la situation: vous dormez paisiblement et voyez votre troisième rêve, quand soudain un téléphone sonne - un client insatisfait se plaint que tout le système n'est pas disponible. D'accord, de tels événements gênent la vie du développeur AEM, de toute l'équipe et du fournisseur de solutions. Il n'y a rien à faire, une levée précoce et une recherche de solution à venir.
Pour éviter que de tels moments de joie ne se produisent dans votre vie professionnelle, je vais vous parler des problèmes de sécurité typiques et comment mieux vous protéger contre eux.
J'adhérerai à un tel plan:
- Sécurité au niveau de l'auteur;
- Publier le niveau de sécurité;
- Sécurité du répartiteur
- Protection du cadre CSRF;
- Attaques DDoS.
Conseils de sécurité de base d'Adobe Experience Manager
Le monde des projets AEM deviendra encore meilleur si chaque développeur a une compréhension commune de la façon de protéger la plate-forme contre les fuites de données en général. Selon le schéma ci-dessous, nous avons un auteur, plusieurs éditeurs et deux ou plusieurs répartiteurs (les soi-disant équilibreurs). En fait, ces trois niveaux méritent une attention particulière en termes de protection des données. Ce sont les règles de travail classiques qui sont généralement acceptées dans la communauté AEM du monde entier.
1. Utilisez HTTPS . AEM évolue rapidement, offrant la flexibilité de créer un auteur sur un autre protocole plus sécurisé. Il suffit de générer la clé «SSL Wizard», de lui créer un chemin d'accès et donc d'utiliser un protocole plus sécurisé. Dans les recommandations d'Adobe, cette étape est précisément la première priorité en matière de sécurité.
2. Installez les packages avec les dernières mises à jour. Le processus standard du développeur se résume au fait que lorsque vous travaillez sur des composants et des services, vous devez rechercher des solutions dans Google. L'objectif de cette étape est de surveiller régulièrement le Service Pack et les correctifs. Ensuite, de nombreux problèmes disparaissent, y compris ceux liés à la sécurité des données. Bien que ce ne soit pas une panacée, l'important est de maintenir le système à jour.
3. Création de pages soignées avec des messages d'erreur. Si vous créez initialement une page avec une brève description de l'erreur, le client verra immédiatement qu'elle ne fonctionne pas, tandis que le développeur sera déjà en train de résoudre le problème. Il est logique que ces informations ne passent pas par vous, mais vous éviterez la panique du client et des testeurs, la confusion dans les tâches.
4. Refusez de définir un mot de passe et connectez-vous sur «admin-admin». Ce ne serait pas drôle, mais le problème avec un identifiant et un mot de passe de mauvaise qualité est assez fréquent même dans AEM. En conséquence, dans la poursuite de la vitesse ou d'autres considérations, nous obtenons le système le plus vulnérable. Une fois que vous avez constaté que les informations de connexion primitives sont configurées, essayez de convaincre l'équipe / les supérieurs et de les remplacer par des plus fiables dès que possible.
Sécurité au niveau de l'auteur
Tout d'abord, utilisez vpn . L'utilisation de Virtual Protected Network est le travail d'un réseau privé sécurisé pour établir une connexion sécurisée entre vous et le serveur. Il s'agit d'un outil simple et important: étant donné que votre trafic sera crypté, il est impossible de savoir d'où vous envoyez vos données. Il s'avère qu'avec vPn, personne ne pourra accéder à votre instance.
Cette approche convient aux développeurs distants et à tous ceux dont le travail est effectué à partir de différents emplacements avec une connexion Internet instable.
Deuxièmement, votre «auteur» doit toujours être fermé, y compris de Google . Vous pouvez donc récupérer un mot de passe et pirater le système: par négligence, l'auteur peut être indexé. Pour vérifier votre vulnérabilité dans un moteur de recherche, saisissez dans sa ligne votre domaine et auteur et le chemin vers crx. Oui, vous pouvez contacter Yandex ou Google avec une demande de suppression d'une telle ligne dans le SERP. Mais, pendant que le problème est résolu, le système sera déjà accessible au public.
Troisièmement, ne sous-estimez pas les privilèges de l'utilisateur «admin» , qui a le plus souvent la possibilité d'effectuer toutes les opérations disponibles.
Ceci est particulièrement critique au moment où un employé dit au revoir à l'entreprise. En effet, pour la plupart des entreprises, l'accès à l'instance n'est pas personnel, mais via un seul compte administrateur. Il est plus logique de faire le contraire et d'être conscient des changements spécifiques dans le système d'un auteur spécifique.
AEM 6.1 a introduit une nouvelle approche dans laquelle vous pouvez définir des droits spécifiques pour un bundle ou un service utilisateur. Mais il vaut mieux faire un profil personnalisé: c'est agréable pour l'employé, et il est plus facile pour l'entreprise de savoir qui a quels niveaux d'accès au système. Cette approche est pertinente pour les niveaux d'auteur et d'éditeur.
Publier la sécurité
En règle générale, ce n'est qu'après une longue période sur le projet qu'ils remarquent qu'ils n'ont pas vérifié l'utilisateur anonyme. Et tandis qu'un utilisateur ordinaire peut avoir des restrictions sur les opérations, un utilisateur anonyme - cela arrive souvent, a beaucoup plus de droits pour effectuer des opérations.
Le filtre de référence Apache Sling est un mécanisme pratique et efficace pour sécuriser votre application. Par exemple, pour envoyer des mesures à AEM, vous voyez des informations sur l'envoi de données dans la boîte de réception. Si vous dépassez la valeur par défaut, un système tiers peut envoyer cette demande. Cela signifie que personne ne pourra envoyer de demande. Vous entrez le domaine dans la configuration; au moment de la demande, il le compare avec les données initialement saisies et, si tout concorde, l'intégration a lieu.
Il s'avérera effectuer une configuration plus flexible avec le filtre: vous pouvez spécifier la requête, la méthode, l'hôte. Il existe également une valeur vide ou un astérisque pour des requêtes plus détaillées.
Sécurité au niveau du répartiteur
Les développeurs sont confrontés à des différends dans 10% des cas. Il s'agit donc du fichier de configuration principal, où nous définissons le type d'URL (interdire / autoriser).
Habituellement, les développeurs font une petite tâche, créent une règle et oublient que cela ajoutera de la vulnérabilité. Pour que personne n'essaie d'attaquer votre instance, vous devez vérifier l'URL avec les sélecteurs au moment de la disponibilité.
Grâce au fichier de configuration, vous pouvez spécifier le traitement des en-têtes. Parce que plus vous précisez le zag, la méthode, etc., un paramètre aussi détaillé ne cassera certainement rien. Ce sont des exemples élémentaires. Et s'il existe des centaines de règles de ce type et que leur navigation est plus difficile?
Le moyen le plus simple consiste à activer la journalisation. Selon la version d'Apache, le mécanisme de travail peut légèrement changer. Mais le système vous indiquera immédiatement quelle URL quelle règle particulière fonctionne pour vous et ce qui doit encore être corrigé.
Vous pouvez également spécifier des domaines dans les règles: il s'agit d'une référence à l'intégration.
Une fois que le répartiteur est utilisé pour la mise en cache, les demandes sont exécutées plusieurs fois plus rapidement: vous n'avez pas besoin d'aller nulle part et de vérifier, et vous pouvez immédiatement l'envoyer au client. De plus, cette méthode améliore considérablement la sécurité de votre application.
Cross Site Request Forgery - fausse demande.
Principe général du CSRF: supposons que vous utilisiez votre compte sur le site Internet de la banque. Après autorisation, vous disposez d'une session standard avec les cookies dans le navigateur, vous recevez un email et suivez le lien vers un site suspect. Sur celui-ci, un attaquant a intégré un formulaire, à l'issue duquel vos données sont envoyées sur le site Internet de la banque.
Le point est dans le protocole HTTP. Un attaquant n'a pas besoin de beaucoup de données: cette requête est suffisante. Le serveur bancaire verra: une demande est arrivée, il y a des cookies et une session, tout va bien. C'est ainsi que fonctionnent les attaques typiques.
Que peut apporter AEM pour empêcher la falsification des requêtes
Un exemple classique de protection est la génération d'un "secret" dans une chaîne. Lorsque le formulaire est généré, ce jeton secret est ajouté à partir du champ caché. Si vous vous rendez sur le site de l'attaquant, le système détectera l'absence d'un token ou son invalidité et refusera d'envoyer des données. Parfois, ils protègent les utilisateurs eux-mêmes.
Vous avez maintenant un ajack régulier, dans lequel vous ne pouvez pas ajouter de champ masqué. Au stade de l'autorisation, le serveur vous renvoie un cookie avec un nom avec SCRF, le transfère dans l'en-tête, l'envoie au serveur. Vous avez donc signé la demande.
AEM fera tout pour vous: il générera des clés, des jetons, il vérifiera la soumission du formulaire
Il y a des cas où une application est écrite dans React et il y a un moment difficile avec l'intégration. AEM a pris cette situation en compte: il suffit d'aller sur inpoint et de la signer pour vérification. Convient lors de l'utilisation de composants et de bibliothèques non standard.
Que peut-on faire d'autre pour protéger le système:
- Les bibliothèques qui en sont responsables. Cela n'a aucun sens d'ajouter jusqu'à ce que vous cassiez quoi que ce soit.
- Au bas niveau, vous pouvez voir tous les «secrets». Il s'agit d'une sorte de validation de vos données.
- C'est simple: il y a une API prête à l'emploi et vous êtes déjà protégé contre ce type d'attaque.
Attaque DDOS - la deuxième attaque la plus populaire
L'objectif est d'épuiser les capacités physiques du serveur. Des millions de demandes sont faites sur un hôte. Quand ils deviennent infiniment nombreux, le système commence physiquement à ne pas faire face. En règle générale, ils attaquent puissamment à partir de plusieurs sources et utilisent un VPN. 100% de ce montant n'est pas assuré; mais ne les aidons pas.
Dans quels cas le système est vulnérable:
- Configurez le système avec le mauvais suffixe;
- Il y a beaucoup de demandes d'avs, le répartiteur sur le public ne peut pas les transmettre;
- Lorsqu'il n'est pas interdit d'afficher un nombre illimité de nœuds de contenu. En particulier, le rendu JSON, qui peut traverser l'arborescence à plusieurs niveaux.
- localhost : 4502 / .json peut vider l'intégralité du référentiel au format JSON.
Pour rendre votre travail sur AEM plus sûr, concentrez-vous sur les capacités d'utilisateurs spécifiques.
N'oubliez pas de parcourir la liste de contrôle de sécurité Adobe et de laisser tout stable avec votre projet sur AEM.