Certains prospects que nous rencontrons nous répondent qu'ils n'ont pas besoin de sécurité sur leur site internet pour différentes raisons.
Parmi les raisons, une est souvent répétée : "Nous n'avons jamais eu de problèmes de sécurité par le passé, il n'y a donc aucune évidence à ce que nous en ayons dans le futur."
C'est vrai que c'est déjà une bonne chose que rien de grave ne se soit passé, de connu en tout cas. Mais compter simplement sur la chance n'est pas une stratégie de sécurité fiable pour l'avenir. Il doit y avoir une visibilité sur le type et la fréquence des attaques web pour comprendre l'état de la sécurité actuelle. Car il est possible que le site internet soit déjà compromis mais cela ne peut être connu pour certains sans être proactif.
Le fait est que pratiquement tous les rapports de sécurité informatique affirment que la sécurité web est la première menace numérique des sociétés et qu'une grande majorité des sites internet ont des vulnérabilités graves. Le WHID recense les sociétés et organisations qui ont eu des incidents liés à leur application web. Beaucoup ont perdu des données clients, leur propriété intellectuelle, ont été infectés par des logiciels malveillants, etc.
Une vraie politique de sécurité des applications aide les sociétés à gérer leurs risques.
"L'étendue des activités des cybercriminels est telle qu'on découvre un site internet piraté toutes les 4,5 secondes."
Le 11/12/2009
Dotsafe soutient le projet ESAPI de l'OWASP en apportant ses compétences pour le développement de la version PHP. Le but d'ESAPI est de permettre aux développeurs de mettre en place des contrôles de sécurité sûrs dans leurs applications web.
OWASP ESAPI est une architecture basée sur le travail des plus grands experts internationaux en sécurité des applications web. Cette API se décline sur de nombreux langages : JAVA EE, .NET, ASP, PHP, ColdFusion, Python et Haskell.
ESAPI fournit aux développeurs web une API de sécurité complète :
Elle apporte une solution à chacune des vulnérabilités de l'OWASP Top Ten (Les 10 failles les plus critiques sur le web):
Authenticator
Authenticator apporte des méthodes pour authentifier un utilisateur, le déconnecter, gérer sa session, vérifier la force d'un mot de passe voire générer un mot de passe suffisamment fort.
User
User permet la gestion des comptes utilisateurs, la gestion des mots de passe, des niveaux de privilège,...
AccessController
AccessController gère les autorisations d'accès. Pour chaque utilisateur ou rôle, on peut définir finement la politique d'accès. On peut choisir de définir les autorisations pour :
AccessReferenceMap
AccessReferenceMap offre un moyen souple et sécurisé pour le téléchargement de fichier. Par exemple grâce à l'emploi de ce module, le lien:
Ainsi il est impossible de manipuler la requête HTTP pour télécharger un fichier arbitraire.
Validator
Validator permet de valider toutes les données en entrée. Grâce à la liste d'expressions régulières fournie par l'API, il est aisé de valider qu'une donnée se conforme à un format attendu ou qu'elle ne dépasse pas une certaine taille. Validator sera la première ligne de défense de votre application dans tous les échanges avec les utilisateurs et les systèmes distants.
Encoder
Encoder permet de résoudre le problème récurrent de l'injection de code. Que ce soit les injections SQL, LDAP, Javascript, ... les valeurs malveillantes sont désarmorcées grâce à un échappement des données qu'elles contiennent. De plus, ce module gère parfaitement la canonicalisation. Ce type d'attaque est couramment utilisé par les pirates pour contourner les filtres de sécurité grâce à un surencodage des données. Le caractère "<" est à surveiller de très près lors de la validation de données. Pour celui-ci, il n'y a pas moins de 150 encodages différents. La canonicalisation permet de régler ce problème.
HTTPUtilities
HTTPUtilities offre un moyen sécurisé de gérer les échanges HTTP : cookie sécurisé, redirection, protection CSRF, ...
Encryptor
Encryptor donne accès à des méthodes de cryptographie forte. On peut signer (de manière cryptographique) une donnée, la sceller pour une certaine durée ou utiliser les fonctions de hachage pour stocker des mots de passe "saltés".
EncryptedProperties
EncryptedProperties fournit un espace fortement crypté sur le serveur pour permettre le stockage de valeurs confidentielles comme des mots de passe et autres.
Randomizer
Bien souvent, les applications sont amenées à fournir des valeurs aléatoires pour par exemple générer un mot de passe, un code client, ... L'entropie du système de génération est déterminante. Si l'aléa est mauvais, un pirate pourra deviner la valeur générée et ainsi accéder à des ressources interdites.
SecurityException
La gestion des erreurs est très importante dans votre application. Une erreur dans une application peut permettre des fuites d'informations. Cela peut aider le pirate à comprendre comment fonctionne le système et ainsi faciliter une intrusion. Pire, une erreur mal gérée peut rendre votre application vulnérable.
Logger
Logger apporte une gestion des messages d'erreurs performante dans votre application. Le suivi du fonctionnement de votre application est indispensable pour détecter efficacement des problèmes. Toutes les exceptions générées par ESAPI sont automatiquement reportées dans ce système centralisé.
IntrusionDetector
IntrusionDetector permet de détecter un comportement suspect et de prendre les contremesures qui s'imposent comme la désactivation du compte, la déconnexion ou l'enregistrement dans les logs. Si par exemple un de vos utilisateurs essaye d'accéder de manière répétée au panneau d'administration, vous pouvez décider de désactiver son compte et de le déconnecter. Cela va permettre d'entraver l'intrusion, un obstacle de plus qui va décourager le pirate.
SecurityConfiguration
Toutes les informations sensibles concernant la configuration de ESAPI sont stockées à un même endroit (ESAPI.xml). Les algorithmes de cryptage à employer, les clefs secrètes, les espaces de stockage de fichier, les expressions régulières de validation, ... tout ceci se trouve regroupé dans le fichier de configuration central.
ESAPI est un projet très prometteur. Plusieurs organisations ont déjà commencé à adopter cette API dont American Express, Apache foundation, US Navy ou encore le SANS Institute. En outre, le framework STRUTS intègrera la version Java d'ESAPI.
OWASP ESAPI est une architecture basée sur le travail des plus grands experts internationaux en sécurité des applications web. Cette API se décline sur de nombreux langages : JAVA EE, .NET, ASP, PHP, ColdFusion, Python et Haskell.
ESAPI fournit aux développeurs web une API de sécurité complète :
Elle apporte une solution à chacune des vulnérabilités de l'OWASP Top Ten (Les 10 failles les plus critiques sur le web):
Authenticator
Authenticator apporte des méthodes pour authentifier un utilisateur, le déconnecter, gérer sa session, vérifier la force d'un mot de passe voire générer un mot de passe suffisamment fort.
User
User permet la gestion des comptes utilisateurs, la gestion des mots de passe, des niveaux de privilège,...
AccessController
AccessController gère les autorisations d'accès. Pour chaque utilisateur ou rôle, on peut définir finement la politique d'accès. On peut choisir de définir les autorisations pour :
- l'accès à une donnée
- l'accès à un fichier
- l'utilisation d'une fonction
- l'utilisation d'un service
- l'accès à une URL
AccessReferenceMap
AccessReferenceMap offre un moyen souple et sécurisé pour le téléchargement de fichier. Par exemple grâce à l'emploi de ce module, le lien:
http://www.dotsafe.fr/dl.php?file=rapports.xml
devienthttp://www.dotsafe.fr/dl.php?file=DS8TD3JS23
Ainsi il est impossible de manipuler la requête HTTP pour télécharger un fichier arbitraire.
Validator
Validator permet de valider toutes les données en entrée. Grâce à la liste d'expressions régulières fournie par l'API, il est aisé de valider qu'une donnée se conforme à un format attendu ou qu'elle ne dépasse pas une certaine taille. Validator sera la première ligne de défense de votre application dans tous les échanges avec les utilisateurs et les systèmes distants.
Encoder
Encoder permet de résoudre le problème récurrent de l'injection de code. Que ce soit les injections SQL, LDAP, Javascript, ... les valeurs malveillantes sont désarmorcées grâce à un échappement des données qu'elles contiennent. De plus, ce module gère parfaitement la canonicalisation. Ce type d'attaque est couramment utilisé par les pirates pour contourner les filtres de sécurité grâce à un surencodage des données. Le caractère "<" est à surveiller de très près lors de la validation de données. Pour celui-ci, il n'y a pas moins de 150 encodages différents. La canonicalisation permet de régler ce problème.
HTTPUtilities
HTTPUtilities offre un moyen sécurisé de gérer les échanges HTTP : cookie sécurisé, redirection, protection CSRF, ...
Encryptor
Encryptor donne accès à des méthodes de cryptographie forte. On peut signer (de manière cryptographique) une donnée, la sceller pour une certaine durée ou utiliser les fonctions de hachage pour stocker des mots de passe "saltés".
EncryptedProperties
EncryptedProperties fournit un espace fortement crypté sur le serveur pour permettre le stockage de valeurs confidentielles comme des mots de passe et autres.
Randomizer
Bien souvent, les applications sont amenées à fournir des valeurs aléatoires pour par exemple générer un mot de passe, un code client, ... L'entropie du système de génération est déterminante. Si l'aléa est mauvais, un pirate pourra deviner la valeur générée et ainsi accéder à des ressources interdites.
SecurityException
La gestion des erreurs est très importante dans votre application. Une erreur dans une application peut permettre des fuites d'informations. Cela peut aider le pirate à comprendre comment fonctionne le système et ainsi faciliter une intrusion. Pire, une erreur mal gérée peut rendre votre application vulnérable.
Logger
Logger apporte une gestion des messages d'erreurs performante dans votre application. Le suivi du fonctionnement de votre application est indispensable pour détecter efficacement des problèmes. Toutes les exceptions générées par ESAPI sont automatiquement reportées dans ce système centralisé.
IntrusionDetector
IntrusionDetector permet de détecter un comportement suspect et de prendre les contremesures qui s'imposent comme la désactivation du compte, la déconnexion ou l'enregistrement dans les logs. Si par exemple un de vos utilisateurs essaye d'accéder de manière répétée au panneau d'administration, vous pouvez décider de désactiver son compte et de le déconnecter. Cela va permettre d'entraver l'intrusion, un obstacle de plus qui va décourager le pirate.
SecurityConfiguration
Toutes les informations sensibles concernant la configuration de ESAPI sont stockées à un même endroit (ESAPI.xml). Les algorithmes de cryptage à employer, les clefs secrètes, les espaces de stockage de fichier, les expressions régulières de validation, ... tout ceci se trouve regroupé dans le fichier de configuration central.
ESAPI est un projet très prometteur. Plusieurs organisations ont déjà commencé à adopter cette API dont American Express, Apache foundation, US Navy ou encore le SANS Institute. En outre, le framework STRUTS intègrera la version Java d'ESAPI.
Le 28/09/2009
PCI-DSS (Paiment Card Industry Data Security Standard) est une norme aujourd'hui appliquée aux Etats-Unis, créée par Mastercard, Visa et autres grands groupes de transactions bancaires. Elle oblige la mise en place d'une politique de sécurité pour les paiements bancaires par exemple. Elle n'est pas pratiquée encore en France mais les chiffres statistiques sur son utilisation aux USA démontrent une avancée limitée dans la sécurité.
Seulement 30% des sociétés qui respectent la norme PCI engageraient une politique de sécurité sérieuse. Les autres sociétés adoptent la norme comme une validation quelconque sans mise en œuvre plus approfondie.
Une étude sur l'utilisation de la norme PCI expose que 80% de ces sociétés qui utilisent les transactions bancaires ont été victimes d'une faille de sécurité alors que plus de 70% n'ont pas de politique de sécurité pour ces opérations. Il est de même troublant que ces sociétés soient focalisées à 55% sur les données strictement bancaires et se désintéressent des données personnelles. La sécurisation globale d'un système est obligatoire pour assurer l'optimalité d'une politique de sécurité.
La norme PCI est adoptée parce que les entreprises américaines sont obligées de se mettre en conformité. Du coup, elle n'assure pas une plus grande sécurité quand elle est considérée comme une simple étape dans le processus de transactions bancaires.
D'autre part, le budget sécurité pour les PME ne permet d'envisager la mise en place d'une sécurisation des données bancaires suivant la norme PCI-DSS. La solution est chère pour le déploiement sur leurs propres serveurs : plus de 800 000 $ pour le premier niveau selon Gartner Group. On peut s'attendre alors à une augmentation de l'externalisation des transferts bancaires des PME.
Au final, la norme PCI n'est pas une avancée évidente, comme attendue, dans la sécurisation des données. On pourra penser que les sociétés, ayant une véritable politique de sécurité grâce à la norme PCI-DSS, avaient déjà en place avant la création de la norme des méthodes de sécurisation globale.
Seulement 30% des sociétés qui respectent la norme PCI engageraient une politique de sécurité sérieuse. Les autres sociétés adoptent la norme comme une validation quelconque sans mise en œuvre plus approfondie.
Une étude sur l'utilisation de la norme PCI expose que 80% de ces sociétés qui utilisent les transactions bancaires ont été victimes d'une faille de sécurité alors que plus de 70% n'ont pas de politique de sécurité pour ces opérations. Il est de même troublant que ces sociétés soient focalisées à 55% sur les données strictement bancaires et se désintéressent des données personnelles. La sécurisation globale d'un système est obligatoire pour assurer l'optimalité d'une politique de sécurité.
La norme PCI est adoptée parce que les entreprises américaines sont obligées de se mettre en conformité. Du coup, elle n'assure pas une plus grande sécurité quand elle est considérée comme une simple étape dans le processus de transactions bancaires.
D'autre part, le budget sécurité pour les PME ne permet d'envisager la mise en place d'une sécurisation des données bancaires suivant la norme PCI-DSS. La solution est chère pour le déploiement sur leurs propres serveurs : plus de 800 000 $ pour le premier niveau selon Gartner Group. On peut s'attendre alors à une augmentation de l'externalisation des transferts bancaires des PME.
Au final, la norme PCI n'est pas une avancée évidente, comme attendue, dans la sécurisation des données. On pourra penser que les sociétés, ayant une véritable politique de sécurité grâce à la norme PCI-DSS, avaient déjà en place avant la création de la norme des méthodes de sécurisation globale.
Le 24/06/2009
L'équipe de Firefox travaille actuellement sur une technologie qui permettra de mettre à l'abri les internautes des attaques Cross Site Scripting ou XSS.
Cette vulnérabilité se manifeste lorsque les entrées utilisateurs ne sont pas suffisamment filtrées, le pirate est alors en mesure d'injecter ce qu'il veut sur la page de réponse HTTP, y compris du HTML et du Javascript. Grâce à cette injection de code, il peut facilement modifier l'apparence du site internet, voler le cookie de l'utilisateur (dans le but de s'authentifier à sa place), réaliser du phishing voire même installer des malwares sur les ordinateurs des internautes.
L'origine du problème vient du fait que le client ne peut pas faire la différence entre un Javascript légitime développé par le créateur du site et un javascript injecté par un pirate. Aucun niveau de différenciation n'existe entre les différents scripts présents dans la réponse HTTP.
Le projet Content Security Policy est conçu pour empêcher ces attaques grâce à une police de sécurité précise et un renforcement des contraintes de sécurité.
Concernant la déclaration de la police, le développeur pourra choisir deux modes de communication au navigateur client :
Au cas où les deux déclarations seraient présentes, une nouvelle police sera appliquée issue de l'intersection des deux précédentes. Ainsi il est impossible d'agrandir la portée de la déclaration en ajoutant une balise meta ou un entête HTTP.
Pour ce qui est des restrictions, elles sont nombreuses et vont nécessiter des efforts d'adaptation conséquents :
- L'insertion de javascript entre les balises "<script>JAVASCRIPT</script>" sera interdite par défaut. Toutes les balises actuellement dans ce cas dans les pages HTML devront être supprimées et leur code déplacé dans des fichiers js séparés.
- Les attributs de gestion d'évenements comme par exemple "onclick" seront eux aussi désactivés et l'utilisation de javascript dans les URLs ne sera plus possible (problème pour toutes les applications ayant basé leur fonctionnement sur ce principe et plus basiquement toutes les applications ASP .NET).
- L'exécution à partir de code contenu dans des chaînes de caractères sera interdite. Ainsi les 'eval("alert(2)")' et l'utilisation de setTimeout, setInterval, ... seront maintenant fortement limités.
- Toutes les utilisations de ressources hébergées sur un autre domaine devront faire l'objet d'une déclaration précise. Ainsi l'inclusion d'une image d'un autre site internet aura un impact direct sur la déclaration de la police. On imagine mal comment cette restriction peut s'appliquer sur des sites permettant à leur utilisateur d'insérer du contenu, ...
Voici quelques exemples concrets :
Autorise seulement tous les contenus issus du domaine du site internet
Autorise les contenus issus du domaine du site internet, les contenus multimédia des domaines media1.com et media2.com, ainsi que les javascripts hébergés sur userscripts.example.com
Une fois le navigateur client informé, celui-ci pourra mettre en application la police envoyée par le serveur en refusant les contenus non autorisés. Il sera même en mesure d'envoyer des rapports d'erreurs au serveur pour l'informer que certains contenus HTML de son site ne respectent pas la police, par exemple dans le cas d'une tentative d'injection malicieuse.
70% des sites internet possèdent des failles de type XSS, il est clair que cette technologie permettra grandement leur diminution. Malheureusement la spécification actuelle ne permet pas d'éliminer complètement la menace. Plusieurs problèmes nous viennent à l'esprit :
- Si un entête HTTP est utilisé pour déclarer la police et qu'il est possible d'injecter avant celui-ci (typiquement dans le cookie) alors un pirate pourra définir sa propre police et écraser la légitime. "Only the first one received by the user agent will be considered; any additional X-Content-Security-Policy HTTP Response headers in the same request will be ignored" (HTTP Header Placement)
- Le fait que deux déclarations amènent à une nouvelle plus restrictive peut permettre en utilisant la technique précédente d'empêcher le fonctionnement normal du site.
- L'utilisation de E4X (ECMAScript pour XML) permet de contourner la restriction d'autorisation des scripts de même domaine.
La source du script est bien la page elle même avec src="#", le code alert(1) est exécuté (The Spanner).
A noter que cette spécification est en pleine étude et surement soumise à des changements significatifs. Enfin, Mozilla assure que cette technologie n'empêchera pas le bon fonctionnement des sites internet qui ne l'implémenteront pas.
Cette vulnérabilité se manifeste lorsque les entrées utilisateurs ne sont pas suffisamment filtrées, le pirate est alors en mesure d'injecter ce qu'il veut sur la page de réponse HTTP, y compris du HTML et du Javascript. Grâce à cette injection de code, il peut facilement modifier l'apparence du site internet, voler le cookie de l'utilisateur (dans le but de s'authentifier à sa place), réaliser du phishing voire même installer des malwares sur les ordinateurs des internautes.
L'origine du problème vient du fait que le client ne peut pas faire la différence entre un Javascript légitime développé par le créateur du site et un javascript injecté par un pirate. Aucun niveau de différenciation n'existe entre les différents scripts présents dans la réponse HTTP.
Le projet Content Security Policy est conçu pour empêcher ces attaques grâce à une police de sécurité précise et un renforcement des contraintes de sécurité.
Concernant la déclaration de la police, le développeur pourra choisir deux modes de communication au navigateur client :
| Entête HTTP | X-Content-Security-Policy: DECLARATION_POLICE |
| Une balise HTML | <meta http-equiv="X-Content-Security-Policy" content="DECLARATION_POLICE"/> |
Au cas où les deux déclarations seraient présentes, une nouvelle police sera appliquée issue de l'intersection des deux précédentes. Ainsi il est impossible d'agrandir la portée de la déclaration en ajoutant une balise meta ou un entête HTTP.
Pour ce qui est des restrictions, elles sont nombreuses et vont nécessiter des efforts d'adaptation conséquents :
- L'insertion de javascript entre les balises "<script>JAVASCRIPT</script>" sera interdite par défaut. Toutes les balises actuellement dans ce cas dans les pages HTML devront être supprimées et leur code déplacé dans des fichiers js séparés.
- Les attributs de gestion d'évenements comme par exemple "onclick" seront eux aussi désactivés et l'utilisation de javascript dans les URLs ne sera plus possible (problème pour toutes les applications ayant basé leur fonctionnement sur ce principe et plus basiquement toutes les applications ASP .NET).
- L'exécution à partir de code contenu dans des chaînes de caractères sera interdite. Ainsi les 'eval("alert(2)")' et l'utilisation de setTimeout, setInterval, ... seront maintenant fortement limités.
- Toutes les utilisations de ressources hébergées sur un autre domaine devront faire l'objet d'une déclaration précise. Ainsi l'inclusion d'une image d'un autre site internet aura un impact direct sur la déclaration de la police. On imagine mal comment cette restriction peut s'appliquer sur des sites permettant à leur utilisateur d'insérer du contenu, ...
Voici quelques exemples concrets :
| Entête HTTP | META tag |
| X-Content-Security-Policy: allow self | <meta http-equiv="X-Content-Security-Policy" content="allow self" /> |
Autorise seulement tous les contenus issus du domaine du site internet
| Entête HTTP | META tag |
| X-Content-Security-Policy: allow self; img-src *;
object-src media1.com media2.com; script-src userscripts.example.com |
<meta http-equiv="X-Content-Security-Policy"
content="allow self; img-src *; object-src media1.com media2.com; script-src userscripts.example.com" /> |
Autorise les contenus issus du domaine du site internet, les contenus multimédia des domaines media1.com et media2.com, ainsi que les javascripts hébergés sur userscripts.example.com
Une fois le navigateur client informé, celui-ci pourra mettre en application la police envoyée par le serveur en refusant les contenus non autorisés. Il sera même en mesure d'envoyer des rapports d'erreurs au serveur pour l'informer que certains contenus HTML de son site ne respectent pas la police, par exemple dans le cas d'une tentative d'injection malicieuse.
70% des sites internet possèdent des failles de type XSS, il est clair que cette technologie permettra grandement leur diminution. Malheureusement la spécification actuelle ne permet pas d'éliminer complètement la menace. Plusieurs problèmes nous viennent à l'esprit :
- Si un entête HTTP est utilisé pour déclarer la police et qu'il est possible d'injecter avant celui-ci (typiquement dans le cookie) alors un pirate pourra définir sa propre police et écraser la légitime. "Only the first one received by the user agent will be considered; any additional X-Content-Security-Policy HTTP Response headers in the same request will be ignored" (HTTP Header Placement)
- Le fait que deux déclarations amènent à une nouvelle plus restrictive peut permettre en utilisant la technique précédente d'empêcher le fonctionnement normal du site.
- L'utilisation de E4X (ECMAScript pour XML) permet de contourner la restriction d'autorisation des scripts de même domaine.
<html>
<script src="#"></script>
{alert(1)}
</html>
La source du script est bien la page elle même avec src="#", le code alert(1) est exécuté (The Spanner).
A noter que cette spécification est en pleine étude et surement soumise à des changements significatifs. Enfin, Mozilla assure que cette technologie n'empêchera pas le bon fonctionnement des sites internet qui ne l'implémenteront pas.
Le 11/06/2009
Publié le 24 mars 2009 sur phpMyAdmin, un bulletin de sécurité annonce une faille critique dans les versions :
Cette faille a été découverte par Greg Ose et Adrian "pagvac" pastor de GNUCITIZEN a mis en ligne ce mardi un outil d'exploitation. PhpMyAdmin est utilisé partout dans le monde et est très populaire. Autant dire que la publication de cet exploit est une menace sérieuse pour la communauté d'utilisateurs.
Techniquement, cette vulnérabilité permet d'exécuter du code à distance en utilisant des URLs du type :
Le problème vient d'abord du fait que les scripts d'installation sont toujours présents, on peut donc soumettre une nouvelle configuration. Enfin à cause d'une faible vérification du paramètre d'entrée "configuration", il est possible de passer du php qui sera sauvegardé dans le fichier de configuration /config/config.inc.php.
Le manque de filtrage sur les paramètres d'entrées est le problème numéro 1 des web applications, tous les problèmes les plus connus y trouvent leurs origines :
- 2.11.x inférieure à 2.11.9.5
- 3.x inférieure à 3.1.3.1
Cette faille a été découverte par Greg Ose et Adrian "pagvac" pastor de GNUCITIZEN a mis en ligne ce mardi un outil d'exploitation. PhpMyAdmin est utilisé partout dans le monde et est très populaire. Autant dire que la publication de cet exploit est une menace sérieuse pour la communauté d'utilisateurs.
Techniquement, cette vulnérabilité permet d'exécuter du code à distance en utilisant des URLs du type :
- http://www.victime.com/pma/config/config.inc.php?c=ls+-l+/
# Liste des répertoires présents à la racine - http://www.victime.com/pma/config/config.inc.php?c=cat+/etc/passwd+/
# Affichage du contenu de /etc/passwd
Le problème vient d'abord du fait que les scripts d'installation sont toujours présents, on peut donc soumettre une nouvelle configuration. Enfin à cause d'une faible vérification du paramètre d'entrée "configuration", il est possible de passer du php qui sera sauvegardé dans le fichier de configuration /config/config.inc.php.
Le manque de filtrage sur les paramètres d'entrées est le problème numéro 1 des web applications, tous les problèmes les plus connus y trouvent leurs origines :
- SQL injection
- Cross site scripting
- Inclusion de fichier
- Exécution de commande
- ...
Soumettez votre site internet à une évaluation !
DotSafe vous propose de vous inscrire à un test de l'évaluation de la sécurité de votre site internet.
Découvrez notre offre
Contactez-nous
Vous souhaitez avoir plus d'informations sur les services offerts par DotSafe ?