Les Pare-Feu et attaques Web D

1. Les Pare-Feu et attaques WebDéfinition, classification, fonctionnement

3. Un pare-feu est un composant ou un ensemble de composants restreignant l’accès entre un réseau externe (Internet) et un réseau interne. Un pare-feu fait donc office de point de contrôle entre plusieurs hôtes, réseaux ou segments de réseaux disposant au minimum de deux interfaces réseaux (cas du pare-feu d’entreprise).

4. Les pare-feu dans une topologie de réseau

5. Politiques de sécurité

6. Les mécanismes de filtrage

7. Typologie des pare-feu

8. Typologie des pare-feu

9. Typologie des pare-feu

10. Typologie des pare-feu

11. Typologie des pare-feu

12. Tester et administrer un pare-feu

13. Tester et administrer un pare-feu

14. Exemple de mise en œuvre de filtres

15. Exemple de mise en œuvre de filtres

16. Application Web Fonctionnement d’une attaque Web Attaques d’URL Attaques SQL Prévention

17. Définition L’OWASP (Open Web Application Security Project) définit une application Web comme « une application logicielle client-serveur qui interagit avec les utilisateurs ou d’autres systèmes en utilisant le protocole HTTP ».

18. Zones d’attaque application Web Zone 1 : client avec navigateur routeur pare-feu Zone 2 : serveur HTTP Zone 3 : serveur d’applications Zone 4 : SGBD

19. Recueillir le maximum d’informations avec son navigateur Version HTTP ? Serveur utilisé (Apache, IIS …) ? Serveur applicatif utilisé ? Base de données utilisée (Oracle, DB2, SQL Server, PostgreSQL ..) ? Langages utilisés côté client comme côté serveur ? En résumé : établir une liste de toutes les technologies utilisées mises en œuvre pour attaquer à la fois côté client et côté serveur. Outils disponibles : NetCat, Nmap, Nessus, Whisker, Brutus, Webcracker… Les attaques sur les langages et protocoles web HTML : éléments et attributs <form>, <form action>, <input>, <form method>, <object>, <applet>, <embed> … HTTP : problème avec les méthodes HTTP.1 « options », « trace »; possibilité de modification d’en-tête (ex : pour traversée de répertoires) HTTPS (HTTP over SSL) : problème si absence de certificat client

20. Paramètres non validés : requête Web non validée avant son utilisation Contrôle d’accès rompu : mauvaise gestion des droits d’accès Gestion de la session : crédits et jetons mal protégés Faille CSS : souvent pour un vol de session après rebond sur un client en ligne Buffer overflow : crash du serveur par débordement (ou autres effets) Injection de commandes : passages de paramètres par les serveur HTTP vers d’autres serveurs applicatifs Condition d’erreur : fournit des informations détaillées sur le système Utilisation non sécurisée de la crytpographie : protection faible Administration à distance : Fonctions administratives mal protégées Mauvaise configuration des serveurs : mauvaise sécurisation par défaut

21. RFC 1738 (1994) – RFC 1808 (url relatives) Structure URL : Protocole://serveur/numéro-de-port/chemin-d’accès-à-la ressource/ressource?paramètres Protocoles les plus connus : HTTP, FTP, MAILTO, HTTPS, NEWS … Points faibles : utilisation des métacaractères (%, @, $, *, # etc…) pour modifier le comportement d’une application en étant insérés dans les paramètres d’une URL, vérifier l’existence d’un utilisateur sur un site (avec ~), lister les fichiers d’un répertoire (avec *), lancer la commande « cmd.exe » sous Windows NT/2000, traverser des répertoires (avec /) etc… Formats d’encodage : possibilité d’exploiter un mauvaise application de la spécification UTF-8, UTF-16 ou UTF-32; de plus les serveurs HTTP fonctionnent souvent sans connaître l’encodage choisi, donc sans toujours reconnaître les métacaractères utilisés.

22. Rappels SQL 4 ensembles de commandes : DDL (Data Definition Language), DML (Data Manipulation Language), DQL (Database Query Langage), DCL (Data Control Language) 2 catégories supplémentaires : commandes de contrôle des transactions (COMMIT, ROLLBACK, SET TRANSACTION) et commandes de programmation SQL (EXPLAIN, FETCH, DECLARE …) Sybase et Microsoft SQL Server mettent à disposition des utilisateurs des procédures stockées (envoi d’un email, définition d’un nouvel utilisateur, adaptation à un trafic réseau réduit …).

23. Attaques SQL indirectes Exemples de référence : www.silksoft.co.za et www.sqlsecurity.com Injection de commandes via formulaire HTML : placer des commandes SQL dans un formulaire HTML (via PERL, ASP, CGI ou PHP); si les champs ne sont pas validées par le serveur, du code hostile peut être alors exécuté (login + password sur un SGBD) Utilisation de messages d’erreur de la base de données : utiliser des messages d’erreur pour identifier les noms de tables et colonnes d’un SGBD; si l’application prévoit la possibilité de créer un utilisateur, les ressources habituelles peuvent ensuite être utilisées pour tester des login+password.

24. Principales règles à suivre (liste non limitative) Valider systématiquement les entrées utilisateurs dans chaque script orienté serveur Limiter précisément les droits d’accès des utilisateurs, et éviter d’utiliser des comptes système par défaut (sa de SQL Server); definir des comptes précis pour des besoins précis Sécuriser les login+password (règles habituelles en sécurité) Limiter au niveau d’un pare-feu la taille des URL, pour éviter l’injection de requêtes SQL) Gérer les métacaractères interdits dans les scripts Gérer au plus précis les fonctions d’administration à distance (adresse IP, numéro de port …) au niveau du serveur HTTP comme au niveau des pare-feu et routeur.