.-- -- ---- ----. ___| MKD1001\007 |____ _ ___________ _ ___________________________________ | '---------------' | | | | .---- - ----------------- - ---------------------------------- - --. . '-----' '---' Le Controle des flux web AKA des flux pas du flu Le filtrage des flux WEB 1 - Principe général Il y a deux méthodes principalement employées pour le filtrage. Filtrage interne : on utilise une collection de fonctions/classes pour «nettoyer» les flux entrant de l'application. Filtrage externe : on utilise un équipement réseau ou une application tierce pour «nettoyer» les flux entrant et sortant de l'application. On parle de filtrage des requètes envoyées au serveur : elle sont rejetées si elles ne sont pas conformes à ce que l'on attend, ou bien leur contenu peut être réécrit ou nettoyé. 2 - Utilité Évaluation du risque : EXTREMEMENT CRITIQUE. Dans le top 10 OWASP des vulnérabilités 2003, 2004 : A1 : Paramêtre non validé A4 : Cross Site Scripting A5 : Débordement de tampon A6 : Failles d'injection Quatre items du top dix, dont la plus répandue des failles de sécurité, sont résolus par un filtrage efficace. Le facteur de risque est donc maximum, et la réponse apportée à ce problème sera une application critique du système. 3 - Le problème de validité des flux. Si l'on considère que la trame reçue est à priori valide, on s'expose aux attaques : Buffers overflows Forced browsing Cookie poisoning SQL injection Command Injection Format string Pour filtrer les données entrantes et sortantes nous avons besoin de règles. Ces règles sont définies par l'utilisation de l'application et du framework dans lequel elle se trouve ( ex : gestion des échappements de caractères en PHP). Cette collection de règles va définir soit les requêtes valides (filtrage positif), soit les requêtes à rejeter. Pour que cette validation ait un sens elle doit respecter elle-même des règles de bon sens : La validation est-elle centralisée ? La validation est-elle obligatoire ? Tout les flux sont-ils bien concernés (paramètres URL, cookies, en-têtes HTTP ...) ou juste les formulaires ? Des paramêtres sont-ils utilisés avant la validation ? Comment sont gérées les exceptions de la validation (handler) ? Pouvez-vous détecter une attaque basée sur l'echec en boucle de la validation ? Les échecs de validation sont-ils journalisés ? 4 “ Le filtrage interne à l'application Il s'agit de filtrer les variables que reçoit l'application. Pour une application Web ce sont les variables GET, POSTS, COOKIES et SESSION. C'est un filtrage positif, on spécifie dans le masque uniquement ce qui est explicitement autorisé, le reste est nettoyé. Cette technique met l'accent sur la nécessité de développer ces applications web dans un framework cohérent qui va centraliser le nettoyage des variables. Si cette couche applicative n'a pas été prévue dès le début du développement, il est extrêmement difficile de l'implémenter à posteriori. Ce filtrage valide les points suivants : Le type de données (surtout dans un langage de programmation non typé) Le jeu de caractères autorisé La longueur minimale et maximale Si le nul est permis Si le paramêtre est exigé ou non Si les duplicata sont permis L'étendu numérique Les valeurs légales spécifiques (ex : départements) Les modêles spécifiques (masque regexp) Exemple pour PHP : http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=106757 sanitize_paranoid_string($string) -- input string, returns string stripped of all non alphanumeric characters sanitize_system_string($string) -- input string, returns string stripped of special characters sanitize_sql_string($string) -- input string, returns string with slashed out quotes sanitize_html_string($string) -- input string, returns string with html replacements for special characters sanitize_int($integer) -- input integer, returns ONLY the integer (no extraneous characters sanitize_float($float) -- input float, returns ONLY the float (no extraneous characters) sanitize($input, $flags) -- input any variable, performs sanitization functions specified in flags. flags can be bitwise combination of PARANOID, SQL, SYSTEM, HTML, INT, FLOAT, LDAP, UTF8 Exemple pour Java : Stinger ( http://www.owasp.org/software/validation/stinger.html ) . 5 “ le filtrage externe à l'application Pourquoi filtrer avant l'application si on le fait correctement à l'intérieur de celle-ci ? Si vous ne maîtrisez pas le développement de vos applications (si, comme beaucoup de développeurs, vous passez par des prestataires, des produits commerciaux ...), c'est la seule méthode qu'il vous reste pour valider vos flux entrant et sortant. Comme il est presque impossible d'être sûr à 100% qu'une application qui doit vivre (évolution, patchs correctifs etc ...) ne comporte pas d'oubli ou de défaut de structure, c'est le principe ceinture et bretelles :) Il existe deux méthodes : a ) En utilisant un module sur une couche applicative au-dessus de votre application, comme le modSecurity d'Apache ou URLScan et Lockdown pour IIS. Ces modules permettent de traiter efficacement les problèmes de validation de flux pour les applications Web. Ils montrent cependant leurs limites lorsque l'application à protéger a beaucoup de variables et surtout si l'on connaît mal celle-ci. Dans ce cas, la gestion des exceptions de traitement ( variable recevant des données potentiellement rejetées et qui sont de cette façon sur-traitées par l'application ) peut vite devenir un casse-tête. De plus lorsque l'application évolue il ne faut pas oublier de vérifier qu'il n'y a rien à faire sur la configuration du module. Cette protection est particulièrement discrète car elle inclue la possibilité de rediriger, avec un code statut de page souhaitée ou vers une url. Pour cela il est conseillé d'adapter la redirection selon le masque qui l'a déclenché: une malformation d'en-tête http ne devrait pas donner le même message d'erreur qu'une tentative d'injection SQL. La chute de performance est dépendante de la complexité et du nombre de masques de validation utilisé, elle se situe entre 5% et 15% en moyenne. Exemple de configuration de mod_security : http://www.gotroot.com/downloads/ftp/mod_security/rules.conf Fonctionnalités de mod_security : Prévention des requêtes sur d'autres chemins du Système de fichier Suppression des multiples slash Traite les anti-slash et les slash de la même manière (Windows seulement) Supprime l'auto référence des répertoire (./) Détecte et supprime les null-bytes (%00) Décode les caractères encodés d'une URL Validations Validation de l'encodage de l'URL Validation de l'encodage unicode Détection et rejet des Shell Code (vérification du byte range) Règles Supporte autant de règles personnalisées que l'on souhaite. Les Règles sont des expressions régulières. Support des Règles négatives. Chaque container (VirtualHost, Location, ...) peut avoir sa configuration. Analyses des headers (en-têtes http) Analyses de chaque cookie Analyses des variables d'environnement Analyses variables de serveur. Analyses unitaires des variables de page. Analyses des POST payload . Analyses des flux de sortie de script . Actions Rejette une requète avec le code Statut de page désiré Redirige une requète rejeté Exécute un programme externe pour un masque de requète Journalise les requètes Peut laisser passer les requètes choisies Permet de chaîner des requètes Permet d'exclure des règles sur le test d'une règle Possibilité de définir des pauses en millisecondes Envoi de fichiers Intercepte les fichiers envoyés au serveur Peut stocker les fichiers envoyés Exécute un script externe pour approuver ou rejeter un fichier (ex: anti-virus ) Autres Change la signature du serveur Peut être facilement chroot Journal des requètes complètes pour l'audit Permet de gérer des journaux de débogage Fonction intelligente qui permet d'appliquer les filtres uniquement sur les contenus dynamiques b ) En utilisant un équipement réseau supplémentaire comme mandataire pour le réseau interne. Un équipement réseau responsable de la validation des flux décharge le processeur et la mémoire du serveur web, de plus cela crée un « single point of faillure » dans votre architecture Web. Les solutions existantes proposent généralement des fonctionnalités supplémentaires comme de l'accélération SSL, la réécriture d'URL ( url masking ), l'authentification centralisée ( SSO ) et de la répartition de charge ( load balancing ). Dans les offres les plus abouties, on trouve aussi une mise a jour automatique qui enrichit la base des masques avec les « signatures » des derniers vers ou des dernières attaques connues. Certaines solutions proposent un apprentissage automatique des variables du serveur et leur donnent des masques génériques ( en fonction du type de champ : text, textarea, etc ...). C'est une fonctionnalité essentielle lorsque l'on doit superviser des sites qui évoluent souvent, qui intègrent des développements externes, ou qui ont beaucoup de pages. Utiliser un équipement externe permet aussi de cloisonner les flux, c'est alors le proxy inverse qui distribue vers les différents serveurs les requètes. Cela masque aussi les serveurs d'applications derrière le site puisque seul le reverse proxy est connecté à Internet. Le coût en performance est environ de 20% à 30% d'allongement du temps de réponse. Exemple : Reverse Proxy SSO (open source ) Vulture est un firewall applicatif protégeant efficacement les applications Web. Basé sur une technologie de Proxy Inverse, Vulture fait barrière entre les applications et le monde extérieur. Il prend en charge toutes les fonctionnalités liées à la sécurité, et notamment : L'authentification des utilisateurs Le chiffrement des flux Le filtrage de contenu La réécriture des Url La haute disponibilité La répartition de charge Exemple : Avec Apache Serveur Web Apache Module mod_proxy et mod_proxy_http Module Mod_Security Module mod_ssl, si on veut faire du HTTPS La configuration basique d'Apache pour le firewall applicatif : ServerName www.serveur.com #pour que nous ce ne soit pas un proxy ouvert ProxyRequests Off ProxyPass / http://192.168.0.10/ ProxyPassReverse / http://192.168.0.10/ ServerName www.unautre.com ProxyRequests Off ProxyPass / http://192.168.0.11/ ProxyPassReverse / http://192.168.0.11/ 6 “ Points faibles L'analyse des masques utilisés pour filtrer permet de déterminer quelle syntaxe sera rejetée ou acceptée (ex : javascript et java script). Certaines variables doivent absolument laisser passer tous les caractères et traiter ceux-ci a posteriori; c'est un point délicat. L'analyse du flux sortant permet de limiter les risques tout en étant difficile à mettre en oeuvre (ex : webmails). Dans le cas d'un équipement réseau supplémentaire, c'est lui seul qui est exposé aux attaques (single point of faillure). Il devra être particulièrement robuste et surveillé. 7 “ Du point de vue du pirate La détection d'un reverse proxy est délicate. On peut essayer de déclencher des erreurs de scripts et de serveur pour voir si les réponses du serveur sont cohérentes. Ex : Quand votre requète est rejetée (ex : ?...&var=' OR 1=1;#) une page d'erreur apparaît, si c'est une erreur 500 ou 404 cela n'est pas logique. Le problème est qu'il contient maintenant ces attaques dans le journal ... Si l'on sait quelle application de filtrage est installÃée (dans les crédits du vendeur de solution de sécurité par exemple) , l'analyse des filtres par défaut peut révéler des faiblesses. écrit par Indalo __ __ __ _____ / / / /___ ______/ /_|__ / _____ _____ / /_/ / __ `/ ___/ //_//_ < | / / _ \/ ___/ / __ / /_/ / /__/ ,< ___/ / |/ / __/ / /_/ /_/\__,_/\___/_/|_/____/|___/\___/_/ - (c)Hack3ver - All rights reversed. .-----. .---. | '----- - ------ - ------- - ------------------------------------- -' | | | |______ _ ________________________________.--------------------.______ _ ____| | by Indalo | '--------------------'