Tous les produits
Search
Centre de documentation

Security Center:What is application protection

Dernière mise à jour :Sep 02, 2026

La protection des applications s'appuie sur la technologie RASP (Runtime Application Self-Protection) pour détecter et bloquer les attaques directement au sein de l'environnement d'exécution de l'application. Aucune modification du code applicatif n'est requise. Déployez la sonde RASP sur vos hôtes ou dans vos environnements conteneurisés afin de vous prémunir contre les vulnérabilités applicatives, les vulnérabilités zero-day et les attaques par shell en mémoire.

Présentation du produit

La protection des applications utilise la technologie RASP pour surveiller le comportement de l'application de l'intérieur. En interceptant les fonctions critiques au niveau de la couche applicative, elle observe en temps réel les interactions entre l'application et les autres systèmes. Lorsqu'un comportement suspect est détecté, le système analyse le contexte d'exécution actuel afin d'identifier et de bloquer les attaques.

Cette solution protège les processus web hébergés sur vos serveurs contre les vulnérabilités applicatives, les vulnérabilités zero-day et les attaques par shell en mémoire.

image

Principaux avantages

  • Protection contre les vulnérabilités connues et inconnues : Le RASP surveille l'exécution des fonctions critiques depuis l'intérieur de l'environnement d'exécution de l'application. Il ne dépend pas de bases de données de signatures de vulnérabilités, ce qui lui permet de se défendre contre les vulnérabilités zero-day et les techniques d'attaque inconnues, offrant ainsi une protection immédiate sans attendre les correctifs de sécurité.

  • Gestion du trafic chiffré : Le RASP obtient les données de requête déchiffrées depuis l'intérieur de l'application, sans être affecté par le chiffrement au niveau réseau. Même lorsque les requêtes sont encodées ou chiffrées de manière complexe, le RASP détecte les anomalies dès lors que les actions finales de l'application ne correspondent pas à l'identité et au comportement attendus.

  • Faible taux de faux positifs et de faux négatifs : Le RASP analyse les données réelles issues des opérations des fonctions critiques et ignore les charges utiles d'attaque qui ne peuvent pas s'exécuter effectivement, réduisant ainsi les faux positifs et les faux négatifs. Quelle que soit l'évolution du point d'entrée de l'attaque, celle-ci ne peut pas contourner le chemin d'exécution des fonctions critiques.

  • Traçabilité des attaques et localisation des vulnérabilités : Le RASP fournit aux équipes de sécurité et aux développeurs des chaînes d'attaque détaillées, incluant la charge utile d'attaque originale, les piles d'appels de code, etc., facilitant ainsi la localisation, la reproduction et la correction des vulnérabilités.

  • Déploiement simplifié : Effectuez le déploiement via la console sans modifier le code. Aucune maintenance ni mise à jour de règles spécifiques n'est nécessaire. Le RASP démarre automatiquement avec l'application, ce qui permet de maintenir les coûts opérationnels à un niveau bas.

Limites

La protection des applications prend en charge les applications Java, PHP et Node.js dans les environnements suivants :

  • Serveurs Alibaba Cloud avec l'agent Security Center installé

  • Serveurs cloud tiers

  • Serveurs IDC sur site

  • Instances Serverless App Engine (SAE)

Les systèmes d'exploitation suivants sont pris en charge :

Système d'exploitation

Systèmes d'exploitation pris en charge

Windows (64 bits)

  • Windows Server 2025

  • Windows Server 2022

  • Windows Server 2019

  • Windows Server 2016

  • Windows Server 2012

  • Windows Server 2008

  • Windows 11

  • Windows 10

Linux (64 bits)

  • Alibaba Cloud Linux

  • AlmaLinux

  • Anolis OS

  • CentOS 6, 7, 8

  • CentOS Stream

  • Debian 8 et versions ultérieures

  • Gentoo

  • OpenSUSE

  • RHEL 6, 7, 8, 9

  • Rocky Linux

  • SUSE Linux Enterprise Server

  • Ubuntu 14.04 et versions ultérieures

  • NeoKylin V7, Kylin V10

  • TencentOS

  • Oracle Linux 7, 8, 9

  • openEuler 20.03, 22.03

  • EulerOS

  • Amazon Linux 2, 2023

Fonctionnalités prises en charge

Détection des attaques (applications Java)

Le tableau suivant répertorie les types d'attaques que la protection des applications peut détecter et intercepter, ainsi que les recommandations de protection associées.

Type d'attaque

Description

Recommandation

Injection JNI

L'injection JNI est une technique courante de contournement du RASP. Lorsqu'un attaquant obtient l'exécution de code, il peut utiliser les fonctions de l'interface native Java pour appeler des bibliothèques partagées malveillantes externes, contournant ainsi les protections de sécurité au niveau Java et dissimulant les comportements malveillants.

Une vulnérabilité d'exécution de code peut exister sur votre serveur. Vérifiez l'emplacement de la vulnérabilité et restreignez la fonctionnalité d'exécution de code.

Injection SQL

Les attaques par injection SQL consistent à insérer des commandes SQL dans les requêtes de page ou les chaînes de requête des formulaires web, incitant le serveur à exécuter des instructions SQL arbitraires. Les attaquants peuvent exploiter les formulaires web pour extraire des données de sites web vulnérables.

L'injection SQL est causée par la concaténation d'instructions SQL. Utilisez des instructions préparées pour gérer les paramètres d'entrée dans la mesure du possible, ou restreignez la concaténation des paramètres à l'aide de listes d'autorisation et de listes de blocage.

XXE

Les attaques par injection d'entité externe XML (XXE) se produisent lorsqu'un analyseur XML traite des références d'entités externes. Un attaquant peut créer du contenu XML malveillant pour réaliser des lectures de fichiers arbitraires, l'exécution de commandes et des attaques sur le réseau interne.

Vérifiez si votre application doit charger des entités externes lors de l'analyse XML. Si ce n'est pas le cas, désactivez les entités externes dans votre configuration d'analyse XML.

Requête DNS malveillante

Les requêtes DNS malveillantes peuvent être exploitées de plusieurs manières. Les attaquants peuvent utiliser les protocoles DNS pour contourner les restrictions du réseau interne et exfiltrer des données sensibles, ou pour sonder les systèmes internes afin de détecter des vulnérabilités telles que SSRF et l'injection JNDI.

Les requêtes DNS malveillantes sont déclenchées lorsque le serveur envoie des requêtes vers des paramètres contrôlés par l'utilisateur. Vérifiez les paramètres et restreignez-les à l'aide d'une liste d'autorisation.

Appel de réflexion malveillant

Il s'agit d'un module d'auto-protection RASP qui empêche les attaquants de modifier les données d'exécution RASP par réflexion.

Une vulnérabilité d'exécution de code peut exister sur votre serveur. Vérifiez l'emplacement de la vulnérabilité et restreignez la fonctionnalité d'exécution de code.

Connexion sortante malveillante

SSRF (Server-Side Request Forgery) est une vulnérabilité permettant à un attaquant de fabriquer des requêtes initiées par le serveur pour cibler les systèmes internes.

Pour corriger les vulnérabilités SSRF, restreignez la plage d'adresses cibles que les requêtes du serveur peuvent atteindre. Utilisez une liste d'autorisation pour permettre l'accès uniquement aux ressources internes sûres et désactivez l'accès réseau sortant inutile.

Lecture/écriture de fichier malveillante

La classe RandomAccessFile de Java est utilisée pour les opérations de lecture et d'écriture de fichiers. Si les chemins et le contenu des fichiers ne sont pas restreints lors de l'utilisation de cette classe, un attaquant peut lire des fichiers système sensibles ou télécharger des fichiers trojan malveillants.

Vérifiez si les opérations de lecture et de téléchargement de fichiers sont normales. En cas d'anomalie, vérifiez le code de la fonction et restreignez les opérations à l'aide d'une liste de blocage.

Téléchargement de fichier malveillant

Si la fonctionnalité de téléchargement de fichiers d'un site web ne restreint pas les types de fichiers, un attaquant peut télécharger des fichiers trojan malveillants pour obtenir un accès plus large au serveur, causant ainsi de graves dommages.

Restreignez les types de fichiers pouvant être téléchargés et interdisez les fichiers disposant de permissions d'exécution, tels que JSP.

Exécution de commande

Une vulnérabilité d'exécution de commande se produit lorsque le serveur ne filtre pas les commandes que les utilisateurs peuvent exécuter, permettant ainsi l'exécution arbitraire de commandes système.

L'exécution de commandes à distance est souvent causée par des web shells ou du code dangereux sur le serveur. Supprimez rapidement tous les web shells. S'il s'agit d'une fonctionnalité normale du serveur, restreignez les commandes exécutables à l'aide d'une liste d'autorisation.

Parcours de répertoire

Des faiblesses de configuration sur un site web peuvent permettre la navigation arbitraire dans les répertoires, entraînant des violations de la vie privée que les attaquants peuvent exploiter.

Vérifiez si les opérations de parcours de répertoire sont normales. En cas d'anomalie, vérifiez le code de la fonction et utilisez une liste de blocage pour restreindre les commandes connexes telles que "./" et "../".

Injection de shell mémoire

Le shell mémoire est une technique de malware émergente où les attaquants injectent des chevaux de Troie dans la mémoire du serveur à l'aide de méthodes spéciales, contournant efficacement le WAF et les défenses basées sur l'hôte.

Une vulnérabilité d'exécution de code peut exister sur votre serveur. Vérifiez l'emplacement de la vulnérabilité et restreignez la fonctionnalité d'exécution de code.

Lecture de fichier arbitraire

Si la fonctionnalité de téléchargement et de lecture de fichiers d'un site web utilise des chemins absolus ou des caractères de parcours de répertoire sans restriction sur les chemins de fichiers, les attaquants peuvent obtenir des informations sensibles et attaquer le serveur.

Vérifiez si les opérations de lecture de fichiers sont normales. En cas d'anomalie, vérifiez le code de la fonction et utilisez une liste de blocage pour restreindre les paramètres d'entrée tels que "./" et "../".

Injection de thread

L'injection de thread est une technique courante de contournement du RASP. Lorsque les attaquants obtiennent des privilèges d'exécution de code, ils peuvent créer de nouveaux threads pour amener le RASP à perdre le contexte de l'environnement d'exécution, affectant ainsi les capacités de défense du RASP.

Une vulnérabilité d'exécution de code peut exister sur votre serveur. Vérifiez l'emplacement de la vulnérabilité et restreignez la fonctionnalité d'exécution de code.

Attachement malveillant

L'API Attach est une technologie fournie par Java pour modifier dynamiquement le bytecode au moment de l'exécution. Les attaquants l'utilisent souvent pour injecter des shells mémoire de type agent avec un haut niveau de discrétion.

Une vulnérabilité d'exécution de code peut exister sur votre serveur. Vérifiez l'emplacement de la vulnérabilité et restreignez la fonctionnalité d'exécution de code.

Injection JNDI

Lorsqu'une application effectue une recherche JNDI, si l'URL de recherche peut être contrôlée par un attaquant, celui-ci peut amener le serveur à interroger des liens malveillants, ce qui pousse le serveur à charger des classes malveillantes et à réaliser une exécution de code arbitraire.

  • Si la vulnérabilité provient d'un composant tiers, mettez à jour la version du composant rapidement.

  • Si elle provient d'un code de recherche JNDI personnalisé, restreignez les URL interrogeables et interdisez les protocoles dangereux.

Utilisation de protocole dangereux

Si l'URL accessible au serveur est contrôlable par l'utilisateur et que l'application ne restreint pas les protocoles, un attaquant peut utiliser des protocoles dangereux tels que file et netdoc pour lire des fichiers sensibles sur le serveur.

Restreignez les protocoles auxquels l'URL peut accéder.

Attaque par désérialisation

La désérialisation Java est le processus de restauration d'une séquence de caractères en un objet Java. Si l'objet généré contient du code à haut risque, un attaquant peut exploiter le contrôle des variables membres lors de la désérialisation pour effectuer des attaques malveillantes.

  • Mettez à jour rapidement les versions des composants vulnérables.

  • Si le fournisseur n'a pas publié de version corrigée, désactivez temporairement la fonctionnalité.

Suppression de fichier arbitraire

Si la fonctionnalité de suppression de fichiers d'un site web ne restreint pas les chemins de fichiers, les attaquants peuvent supprimer des fichiers arbitraires à l'aide de chemins absolus ou de caractères de parcours de répertoire, compromettant ainsi le serveur.

Vérifiez si les opérations de suppression de fichiers sont normales. En cas d'anomalie, vérifiez le code de la fonction et utilisez une liste de blocage pour restreindre les paramètres d'entrée tels que "./" et "../".

Injection d'expression

Les composants d'expression offrent des fonctionnalités riches, notamment l'interrogation et le traitement des données d'exécution. Cependant, de nombreux composants d'expression prennent également en charge des opérations à privilèges élevés telles que les appels de fonction. S'ils ne sont pas restreints et sont contrôlables par un attaquant, celui-ci peut exécuter du code arbitraire via l'évaluation d'expressions.

Restreignez strictement ce qui peut entrer dans l'évaluation d'expressions, en bloquant la plupart des appels de fonction Java. Si cela est causé par une vulnérabilité d'un composant tiers, mettez à jour la version du composant rapidement.

Injection de moteur

Java prend en charge de nombreux composants de moteur tiers (tels que les moteurs JS Rhino, Nashorn et les moteurs de template Velocity, FreeMarker). Ces moteurs fournissent généralement des opérations à privilèges élevés telles que les appels de fonction. S'ils ne sont pas restreints et sont contrôlables par un attaquant, celui-ci peut exécuter du code arbitraire via le moteur.

Restreignez strictement ce qui entre dans les fichiers du moteur, en bloquant la plupart des appels de fonction Java. Si cela est causé par une vulnérabilité d'un composant tiers, mettez à jour la version du composant rapidement.

Liaison de Beans malveillante

Certains frameworks Java prennent en charge la liaison de paramètres Beans au moment de l'exécution. Si les types de Beans liables ne sont pas restreints, un attaquant peut perturber le fonctionnement de l'application ou même réaliser une exécution de code arbitraire en modifiant les valeurs de Beans sensibles.

Restreignez les types de Beans pouvant être liés et interdisez la modification des valeurs de Beans similaires aux types Class et ClassLoader. Si cela est causé par une vulnérabilité d'un composant tiers, mettez à jour la version du composant rapidement.

Chargement de classe malveillant

De nombreuses exploitations zero-day et web shells reposent sur le chargement de classes malveillantes. Une fois qu'une classe malveillante est chargée, l'attaquant peut obtenir des privilèges d'exécution de code via l'initialisation de la classe, permettant ainsi d'autres opérations malveillantes.

  • Si le chargement de classe malveillant est contrôlé par un web shell, supprimez le web shell rapidement.

  • Si le chargement de classe malveillant est causé par le framework, mettez à jour la version du framework rapidement.

Inclusion de fichier arbitraire JSTL

JSTL (JSP Standard Tag Library) est une collection de balises JSP qui encapsule les fonctionnalités de base courantes pour les applications JSP. Lorsque des paramètres contrôlables par l'utilisateur sont directement concaténés dans les balises JSTL sans restriction, les attaquants peuvent créer des scripts d'attaque spéciaux pour réaliser des lectures de fichiers arbitraires et des attaques SSRF.

Évitez de concaténer directement des paramètres contrôlables par l'utilisateur dans les balises JSTL. Si nécessaire, appliquez un contrôle strict par liste d'autorisation au contenu des paramètres.

Détection des attaques (applications PHP)

Type d'attaque

Description

Recommandation

Inclusion de fichier malveillante

Les vulnérabilités d'inclusion de fichiers en PHP sont des problèmes de sécurité courants qui permettent aux attaquants d'inclure et d'exécuter des fichiers arbitraires en manipulant les entrées. Ces vulnérabilités se produisent généralement lors de l'utilisation des fonctions include(), require(), include_once() ou require_once().

Validez et restreignez les chemins de fichiers saisis par l'utilisateur, en n'autorisant que les fichiers prédéfinis dans le répertoire de l'application pour empêcher les attaquants d'injecter des chemins malveillants.

Connexion sortante malveillante

SSRF (Server-Side Request Forgery) est une vulnérabilité permettant à un attaquant de fabriquer des requêtes initiées par le serveur pour cibler les systèmes internes.

Pour corriger les vulnérabilités SSRF, restreignez la plage d'adresses cibles que les requêtes du serveur peuvent atteindre. Utilisez une liste d'autorisation pour permettre l'accès uniquement aux ressources internes sûres et désactivez l'accès réseau sortant inutile.

Désérialisation

Les vulnérabilités de désérialisation PHP sont des problèmes de sécurité graves qui permettent aux attaquants d'exécuter des fonctions arbitraires en manipulant des données sérialisées. Cela se produit généralement lors de l'utilisation de la fonction unserialize().

Évitez de désérialiser directement des données non fiables. Utilisez json_decode() ou d'autres alternatives sûres, ou validez et filtrez strictement les sources de données désérialisées si nécessaire.

Exécution de fonction de rappel

Les fonctions de rappel en PHP, telles que array_map() et array_filter(), peuvent devenir dangereuses lorsque leurs paramètres sont contrôlables de l'extérieur, donnant potentiellement aux attaquants la capacité d'exécuter des fonctions arbitraires et de contrôler l'ensemble du système.

Pour prévenir l'abus des fonctions de rappel PHP, assurez-vous que les noms des fonctions de rappel passés à array_map(), array_filter() et autres fonctions similaires ne sont pas contrôlés par l'entrée utilisateur, et vérifiez chaque fonction de rappel autorisée par rapport à une liste d'autorisation.

Lecture/écriture de fichier malveillante

Lorsque les fonctions de lecture/écriture de fichiers sont appelées sans restriction sur les chemins et le contenu des fichiers, un attaquant peut lire des fichiers système sensibles ou télécharger des fichiers trojan malveillants.

Pour prévenir les vulnérabilités de sécurité liées aux fichiers, validez et restreignez strictement les chemins de fichiers afin de n'autoriser l'accès qu'aux répertoires prédéfinis, et effectuez des vérifications de sécurité sur le contenu des fichiers pour empêcher le téléchargement de code malveillant.

Exécution de code arbitraire

Les vulnérabilités d'exécution de code arbitraire permettent aux attaquants d'exécuter des extraits de code arbitraires sur le serveur, obtenant potentiellement le contrôle ou lisant et modifiant des données sensibles. Cela se produit généralement lorsque le programme ne valide pas adéquatement les entrées utilisateur, permettant l'injection de code malveillant. Une exploitation réussie peut entraîner des fuites de données, la défiguration de sites web ou l'installation de logiciels malveillants.

Utilisez une validation stricte des entrées et un encodage des sorties. Évitez d'utiliser eval(), include() et des fonctions similaires pour traiter directement les entrées utilisateur, et maintenez toutes les bibliothèques et frameworks à jour.

Lecture de fichier arbitraire

Sans filtrage et restrictions appropriés sur les interfaces de lecture de fichiers, les attaquants peuvent utiliser des chemins absolus ou des caractères de parcours de répertoire pour lire et télécharger des fichiers, obtenant ainsi des informations sensibles et attaquant le serveur.

Mettez en œuvre une validation stricte des entrées et des restrictions de chemin sur les interfaces de lecture de fichiers pour garantir que seuls les fichiers figurant sur la liste d'autorisation peuvent être consultés, et utilisez une liste de blocage pour restreindre les paramètres d'entrée tels que "./" et "../".

Suppression de fichier arbitraire

Sans restrictions appropriées sur les chemins de fichiers pour les interfaces de suppression de fichiers, les attaquants peuvent utiliser des chemins absolus ou des caractères de parcours de répertoire pour supprimer arbitrairement des fichiers et attaquer le serveur.

Mettez en œuvre une validation stricte des entrées et des restrictions de chemin sur les interfaces de suppression de fichiers pour garantir que seuls les fichiers vérifiés peuvent être supprimés, et utilisez une liste de blocage pour restreindre les paramètres d'entrée tels que "./" et "../".

Exécution de commande

Les vulnérabilités d'exécution de commande permettent aux attaquants d'injecter à distance des commandes du système d'exploitation ou du code dans les serveurs backend, prenant ainsi le contrôle des systèmes backend.

Validez et filtrez toutes les entrées utilisateur. Évitez d'utiliser des entrées non traitées pour construire des commandes du système d'exploitation et utilisez des API sécurisées pour remplacer l'exécution de commandes système dans la mesure du possible.

Parcours de répertoire

Des faiblesses de configuration sur un site web peuvent permettre la navigation arbitraire dans les répertoires, entraînant des violations de la vie privée que les attaquants peuvent exploiter.

Utilisez des paramètres d'autorisation de serveur appropriés et des fichiers tels que .htaccess pour restreindre l'accès aux répertoires, en veillant à ce que les répertoires sensibles ne soient pas consultables par des utilisateurs non autorisés.

Téléchargement de fichier malveillant

Si une fonctionnalité de téléchargement de fichiers ne restreint pas les types de fichiers, un attaquant peut télécharger des fichiers trojan malveillants pour obtenir un accès plus large au serveur, causant ainsi de graves dommages.

Restreignez et validez strictement les types de fichiers téléchargés, en n'autorisant que les types de fichiers sûrs, en bloquant les extensions de fichiers exécutables telles que .php, et en revérifiant le contenu des fichiers côté serveur pour garantir leur sécurité.

Détection des attaques (applications Node.js)

Le tableau suivant répertorie les types d'attaques que Application Protection peut détecter et intercepter pour les applications Node.js, ainsi que les recommandations de protection associées.

Type d'attaque

Description

Recommandation

Exécution de commandes

Les vulnérabilités d'exécution de commandes permettent aux attaquants d'injecter à distance des commandes système d'exploitation ou du code dans les serveurs backend, prenant ainsi le contrôle des systèmes backend.

Évitez d'utiliser les fonctions exec, spawn et similaires pour exécuter des entrées contrôlables par l'utilisateur. Si nécessaire, restreignez les commandes exécutables à l'aide d'une liste d'autorisation.

Lecture/écriture de fichiers malveillants

Lorsque les fonctions de lecture/écriture de fichiers sont appelées sans restriction sur les chemins d'accès et le contenu des fichiers, un attaquant peut lire des fichiers système sensibles ou télécharger des fichiers trojan malveillants.

Validez et restreignez strictement les chemins d'accès aux fichiers afin de n'autoriser l'accès qu'aux répertoires prédéfinis, et effectuez des vérifications de sécurité sur le contenu des fichiers.

Lecture arbitraire de fichiers

Sans filtrage et restrictions appropriés sur les interfaces de lecture de fichiers, les attaquants peuvent utiliser des chemins absolus ou des caractères de traversée de répertoire pour lire et télécharger des fichiers, obtenant ainsi des informations sensibles et attaquant le serveur.

Mettez en œuvre une validation stricte des entrées et des restrictions de chemin sur les interfaces de lecture de fichiers pour garantir que seuls les fichiers figurant sur la liste d'autorisation sont accessibles, et utilisez une liste de blocage pour restreindre les paramètres d'entrée tels que « ./ » et « ../ ».

Écriture arbitraire de fichiers

Si une application ne valide et ne restreint pas correctement le type, la taille et le contenu des fichiers écrits, un attaquant peut exploiter cette faille pour écrire des fichiers malveillants à des emplacements désignés sur le système cible, y implantant des scripts malveillants ou des chevaux de Troie. Cela peut entraîner une compromission complète du serveur.

  • Normalisez et validez tous les chemins d'écriture de fichiers. Utilisez path.resolve ou realpath pour confirmer que la cible se trouve dans un répertoire autorisé par l'application.

  • Évitez d'utiliser directement l'entrée utilisateur comme chemin de fichier complet. Privilégiez les noms de fichiers générés par le serveur et les répertoires fixes.

  • Interdisez l'écriture dans les répertoires système, les scripts de démarrage utilisateur, les configurations SSH, les tâches cron, les unités systemd, les configurations du gestionnaire de packages et les fichiers clés de l'application.

  • Utilisez des systèmes de fichiers racine en lecture seule, des autorisations de fichiers minimales et des répertoires temporaires isolés dans les conteneurs et les environnements de production.

  • Pour les fonctionnalités de téléchargement, d'exportation et de mise en cache, définissez des listes d'autorisation pour les extensions, les tailles et les répertoires par type d'activité, et conservez les journaux d'audit.

Suppression arbitraire de fichiers

Sans restrictions appropriées sur les chemins d'accès aux fichiers pour les interfaces de suppression, les attaquants peuvent utiliser des chemins absolus ou des caractères de traversée de répertoire pour supprimer des fichiers de manière arbitraire.

Mettez en œuvre une validation stricte des entrées et des restrictions de chemin sur les interfaces de suppression de fichiers pour garantir que seuls les fichiers vérifiés peuvent être supprimés, et utilisez une liste de blocage pour restreindre les paramètres d'entrée tels que « ./ » et « ../ ».

Lien de fichier malveillant

Si une application ne valide pas correctement le chemin cible et l'objet du lien lors de la création de liens de fichiers, un attaquant peut utiliser des liens symboliques ou des liens physiques pour mapper des fichiers protégés vers des emplacements accessibles, contournant ainsi les contrôles d'accès pour lire, modifier ou détruire des fichiers système sensibles.

N'autorisez pas les entrées externes à contrôler directement les cibles ou les chemins des liens. Effectuez une normalisation, une validation du chemin réel et des vérifications de liste d'autorisation de répertoire sur les sources et les cibles des liens. Utilisez lstat sur les répertoires de téléchargement, temporaires et d'extraction pour identifier les liens symboliques. Utilisez des utilisateurs distincts à privilèges minimaux pour les répertoires à haut risque afin d'éviter d'accorder au processus d'application un accès en lecture/écriture aux configurations système, aux répertoires d'identifiants et aux répertoires de montage hôte.

Connexion sortante malveillante

La falsification de requête côté serveur (SSRF) est une vulnérabilité permettant à un attaquant de concevoir des requêtes initiées par le serveur pour cibler des systèmes internes.

Pour corriger les vulnérabilités SSRF, restreignez la plage d'adresses cibles que les requêtes du serveur peuvent atteindre. Utilisez une liste d'autorisation pour n'autoriser l'accès qu'aux ressources internes sûres et désactivez l'accès réseau sortant inutile.

Création de processus malveillants

La fonction fork() de Node.js permet de créer de nouveaux processus Node exécutant des fichiers JS. Si une application ne restreint pas strictement les scénarios d'appel, la logique d'exécution ou les paramètres d'entrée, un attaquant peut utiliser cette capacité pour créer des sous-processus malveillants, effectuer des opérations non autorisées ou compromettre davantage le serveur via le chargement de scripts ou l'exécution de commandes.

Ne laissez pas l'entrée utilisateur déterminer directement le chemin du module et les paramètres de démarrage de fork(). Utilisez une énumération fixe ou une liste d'autorisation côté serveur des scripts pouvant faire l'objet d'un fork. Résolvez et confirmez que les scripts se trouvent dans des répertoires d'application approuvés à l'aide de chemins absolus avant le lancement. Transmettez uniquement des champs métier en tant que paramètres, et non des fragments de shell, des chemins de fichiers, des arguments d'interpréteur ou des remplacements de variables d'environnement. Utilisez des privilèges minimaux, des répertoires de travail isolés et des variables d'environnement restreintes pour les sous-processus. Pour les scénarios nécessitant l'exécution de tâches utilisateur, privilégiez les workers restreints, les files d'attente ou les sandbox plutôt que le chargement dynamique de scripts locaux arbitraires.

Liaison de processus malveillante

La fonction process.binding() de Node.js permet d'accéder aux modules internes de bas niveau. Si une application ne restreint pas ces appels, un attaquant peut utiliser cette capacité pour accéder aux interfaces de bas niveau, contourner les contrôles de sécurité de couche supérieure et effectuer des opérations inattendues, entraînant des fuites d'informations sensibles, un abus de privilèges ou une exploitation supplémentaire du système.

N'exposez pas process.binding ni process._linkedBinding dans le code métier, les plugins, les modèles ou les environnements d'exécution de scripts. Interdisez la transmission de paramètres externes à ces interfaces. Pour les applications prenant en charge les plugins, les règles, les modèles ou les compétences Agent, supprimez ou figez les capacités process à haut risque dans les sandbox. Activez les hooks et les alertes de liaison de processus RASP en production. Évaluez la nécessité des appels de liaison native directs dans les packages de dépendances et restreignez les sources d'appel. Utilisez l'isolation par conteneur, des utilisateurs à privilèges minimaux et des restrictions d'appels système/d'accès réseau pour les environnements d'exécution à haut risque.

Appel MCP malveillant

Dans les scénarios d'Agent IA, le protocole MCP (Model Context Protocol) permet d'accéder à des ressources, services ou capacités externes. Si une application ne valide pas strictement l'étendue de l'appel, les paramètres de requête et le contenu renvoyé des services MCP, un attaquant peut inciter l'Agent à effectuer des appels MCP malveillants, accédant ainsi à des données sensibles, réalisant des opérations à haut risque ou interagissant avec des services non approuvés.

Traitez le serveur MCP comme un composant externe non approuvé. N'autorisez les connexions qu'à des sources approuvées avec des versions fixes et des configurations contrôlées. Établissez des listes d'autorisation pour les noms d'outils MCP, les noms de serveur, les paramètres, les URL, les répertoires de travail et les commandes de démarrage. Activez la confirmation manuelle ou des politiques de niveau de risque plus élevé pour les outils qui modifient des fichiers, exécutent des commandes, accèdent au réseau ou lisent des identifiants. N'exposez pas directement les clés de production aux serveurs MCP. Exécutez les serveurs MCP dans des conteneurs isolés ou avec des comptes à faibles privilèges. Effectuez une validation de format, une validation de sécurité des URL et conservez des registres d'audit sur les métadonnées OAuth, les URL distantes et le contenu renvoyé par les outils. Les comportements sous-jacents child_process, fs, http et net générés par les appels d'outils doivent toujours être interceptés par RASP.

Appel d'outil malveillant

Dans les scénarios d'Agent IA, les outils permettent d'effectuer des opérations externes ou d'appeler des capacités tierces. Si une application ne restreint pas efficacement l'étendue disponible, les paramètres d'appel et les résultats d'exécution des outils, un attaquant peut utiliser l'injection de prompt ou des entrées malveillantes conçues pour inciter l'Agent à appeler des outils à haut risque, effectuant ainsi des opérations non autorisées, accédant à des ressources sensibles ou affectant même la sécurité de l'hôte ou du système métier.

Concevez les autorisations des outils selon le principe du moindre privilège. Refusez par défaut les outils à haut risque et accordez des autorisations explicites en fonction des scénarios métier. Classez les outils par niveaux de risque : lecture seule, écriture, réseau et exécution de commandes. Exigez une confirmation ou une approbation politique pour les outils d'écriture, d'exécution de commandes et sortants. Appliquez une validation stricte et des contraintes de liste d'autorisation sur chaque paramètre d'outil, telles que les modèles de commande, les répertoires accessibles, les domaines autorisés et les méthodes HTTP autorisées. Traitez les résultats des outils comme des entrées non approuvées et effectuez une détection d'injection de prompt et de données sensibles avant leur entrée dans le contexte LLM. Conservez des registres d'audit pour les noms d'outils, les paramètres, les chaînes d'appel, runId/toolCallId et les résumés des résultats. Bloquez ou escaladez les alertes lors de la détection de séquences dangereuses, telles que la lecture de fichiers sensibles suivie de connexions sortantes, ou l'exécution de commandes suivie de l'écriture d'éléments de démarrage.

Défense contre les vulnérabilités des applications

Application Protection peut défendre efficacement contre les vulnérabilités des applications, les vulnérabilités zero-day et les attaques par shell en mémoire. Le principe de la défense contre les vulnérabilités est illustré dans la figure suivante. Lors de la réponse aux incidents de vulnérabilité des applications, l'exploitation des capacités de protection contre les attaques de RASP permet de bloquer rapidement les attaques, gagnant ainsi du temps précieux pour corriger les vulnérabilités des applications. Application Protection peut également aider à localiser rapidement les sources de risque et à déterminer l'étendue de l'impact. Pour plus d'informations sur les vulnérabilités des applications, consultez Gérer les vulnérabilités.

image

Si vous ne pouvez pas corriger immédiatement une vulnérabilité d'application, vous pouvez d'abord connecter le processus d'application à RASP pour le protéger. Les étapes suivantes décrivent comment ajouter la protection RASP à une application où une vulnérabilité a été détectée.

  1. Connectez-vous à la console Security Center.

  2. Dans le volet de navigation de gauche, sélectionnez Risk Governance > Vulnerabilities. Dans le coin supérieur gauche de la console, sélectionnez la région où se trouve la ressource à protéger : Chinese Mainland ou Outside Chinese Mainland.

  3. Dans l'onglet Application Vulnerability, les vulnérabilités portant le tag RASP supports real-time protection. sont prises en charge par Application Protection. Cliquez sur Enable Protection Now dans la colonne Actions pour la vulnérabilité correspondante.

  4. Dans le panneau Access Management, sélectionnez le groupe d'applications à connecter dans la liste déroulante Application Group Name, sélectionnez les ressources correspondantes, puis cliquez sur Confirm.

    Si le groupe d'applications requis n'existe pas, vous pouvez cliquer sur Create Application Group dans la liste déroulante, saisir le nom du groupe d'applications et cliquer sur OK pour créer rapidement un groupe d'applications. Le Protection Mode du groupe d'applications créé ici est Block et le Protection Policy Group est Group Name.

    Une fois que l'application présentant la vulnérabilité détectée est connectée à Application Protection, la liste Unhandled Vulnerabilities de la page des détails de la vulnérabilité affichera la colonne Actions du serveur comme Protected uniquement après qu'une analyse de vulnérabilité a été effectuée pour la vulnérabilité de l'application.

Analyse du comportement des applications

La fonctionnalité d'analyse du comportement des applications surveille, collecte et analyse en temps réel les données de comportement des applications connectées, générant des rapports et des affichages visuels. Cela vous aide à comprendre les détails des attaques et de la défense de votre application et à renforcer la sécurité du système. Pour plus d'informations, consultez Analyse du comportement des applications.

Défense contre les shells en mémoire (applications Java uniquement)

La technologie RASP d'Application Protection peut détecter les shells en mémoire en temps réel en analysant les données mémoire, et prend en charge l'interception des processus d'injection et d'exécution de shells en mémoire. Pour plus d'informations, consultez Défense contre les logiciels malveillants résidents en mémoire.

Détection des faiblesses (applications Java uniquement)

Le tableau suivant répertorie les types de faiblesses d'application qu'Application Protection peut détecter, ainsi que les recommandations de correction associées.

Type de faiblesse

Niveau de risque

Description

Recommandation

Configuration Fastjson non sécurisée

Élevé

Fastjson dans l'application a la désérialisation activée, ce qui peut être exploité par des attaquants pour réaliser une exécution de code à distance. Désactivez cette fonctionnalité si elle n'est pas requise.

Définissez safemode de Fastjson sur true, ou définissez autotype sur false.

Configuration log4j non sécurisée

Élevé

Le composant log4j a la fonctionnalité de recherche activée, que les attaquants peuvent exploiter pour une injection JNDI, entraînant une exécution de code à distance.

Mettez à jour log4j vers la dernière version, ou supprimez le fichier org/apache/logging/log4j/core/lookup/JndiLookup.class du package JAR.

Paramètres de démarrage non sécurisés

Élevé

Lorsqu'un attaquant peut accéder au port de débogage JDWP, il peut exécuter du code arbitraire via cette fonctionnalité, provoquant une exécution de code à distance.

Fermez le port JDWP ou évitez d'exposer le port JDWP au réseau public si aucun scénario de ce type n'est requis. Soyez prudent avec les applications de longue durée qui ont le port JDWP activé.

Clé faible Shiro

Élevé

Shiro utilise une clé de chiffrement faible, que les attaquants peuvent craquer pour effectuer d'autres attaques par désérialisation, entraînant une exécution de code à distance.

Mettez à jour la clé de chiffrement Shiro dans votre application dès que possible.

Configuration JMX non sécurisée

Moyen

L'accès distant JMX est activé sans authentification adéquate. Les attaquants peuvent se connecter à distance au service JMX de l'application et réaliser une exécution de commandes.

Désactivez les connexions JMX distantes, ou utilisez des identifiants d'authentification sécurisés.

Configuration Rhino non sécurisée

Moyen

Le framework Rhino contient des propriétés dangereuses que les attaquants peuvent exploiter pour une exécution de code à distance.

Mettez à jour Rhino vers la dernière version, puis utilisez SafeStandardObjects pour définir le contexte Rhino afin d'empêcher le moteur JavaScript d'appeler du code Java.

Voici un exemple d'utilisation de SafeStandardObjects pour définir le contexte Rhino :

 package com.aliyun.sample;

  import org.mozilla.javascript.Context;
  import org.mozilla.javascript.Scriptable;

  public class RhinoSecurityExample {
      public static void main(String[] args) {
          Context ctx = Context.enter();
          // Scriptable scope = ctx.initStandardObjects(); // Unsafe
          Scriptable scope = ctx.initSafeStandardObjects(); // Safe
          ctx.setOptimizationLevel(-1);
          String str = "var test={};";
          str += "test.call=function(){return 'Successful!';};";
          str += "test.call()";  // Returns only JavaScript result, no Java call
          try {
              // Pass in and execute JavaScript code
              Object result = ctx.evaluateString(scope, str, "", 1, null);
              System.out.println("JavaScript execution result: " + result);
          } catch (Exception e) {
              e.printStackTrace();
          } finally {
              Context.exit();
          }
      }
  }

Configuration Spring non sécurisée

Moyen

Spring Actuator a certains endpoints activés : heapDump, env, restart, refresh, trace, jolokia, h2-console, etc., ce qui peut entraîner une fuite d'informations sensibles ou une exécution de code à distance.

Désactivez ces fonctionnalités si aucun scénario spécial ne les requiert.

Identifiants de connexion faibles

Moyen

L'application possède un mot de passe de connexion faible, que les attaquants peuvent forcer par brute-force pour accéder au système et obtenir des informations sensibles, voire un accès au serveur.

Modifiez le mot de passe de l'application pour un mot de passe complexe dès que possible.

Configuration JNDI non sécurisée

Faible

L'application utilise de manière non sécurisée les paramètres useCodebaseOnly/rmi-trustURLCodebase/ldap-trustURLCodebase, ce qui peut la rendre vulnérable à l'injection JNDI.

Mettez à jour JDK vers la dernière version. Si vous ne pouvez pas mettre à jour, ajoutez les paramètres de démarrage suivants lors du démarrage de l'application :

-Djava.rmi.server.useCodebaseOnly=true -Dcom.sun.jndi.rmi.object.trustURLCodebase=false -Dcom.sun.jndi.ldap.object.trustURLCodebase=false

Configuration d'entité XML non sécurisée

Faible

L'analyse des entités externes XML est activée, ce qui peut exposer l'application aux attaques XXE.

Désactivez les entités externes si aucun scénario spécial ne les requiert.

Mot de passe faible de la base de données

Faible

L'application utilise un mot de passe faible pour se connecter à la base de données, ce que les attaquants peuvent exploiter pour se connecter à la base de données et provoquer des fuites d'informations sensibles ou une exécution de code à distance.

Modifiez le mot de passe de connexion à la base de données pour un mot de passe complexe dès que possible.