Blidaoui Abdelhak, profile picture
Téléchargé parBlidaoui Abdelhak
PDF, PPTX212 vues

Securite web is_ima

Le document aborde la sécurité des applications en se concentrant sur les défis posés par la guerre numérique, illustrés par des exemples tels que Stuxnet et les Panama Papers. Il présente également le modèle OWASP Top 10 pour guider les pratiques de sécurisation, détaillant des vulnérabilités comme l'injection SQL, le cross-site scripting, et la mauvaise gestion des sessions, tout en fournissant des recommandations pour atténuer ces risques. L'importance d'une configuration sécurisée et d'une gestion des accès appropriée est soulignée pour prévenir les attaques sur les systèmes.

Intégrer la présentation

Télécharger en tant que PDF, PPTX
SÉCURITÉ DES APPLICATIONS Nabil HOSNI MCSA, ITIL , ISO 27001 Lead Implementer / Lead Auditor / Expert auditeur ANSI Nabil.hosni@ansi.tn (00216)94 675 101
Remerciement 2
Remerciement 3
PLAN Rappel  Introduction: Guerre classique vs la guerre numérique  Impacts de la guerre numérique OWASP TOP 10 Modèle proposé de la sécurité 4
De1970 à 2017
20/01/2009 RAPPEL 20/01/2012
7 Hier Km N jours
IMPACTS DE LA GUERRE CLASSIQUE: CAS DE L’IRAK  Coût des opérations militaires et de la reconstruction estimé au début : entre 100 et 200 milliards de $. Coûts totaux entre 2003 et 2005: 429 milliards Coûts prévisibles pour la période 2005-2015: 577 milliards  révision de la choix stratégiques du guerre sources : Scott Wallsten et Katrina Kosec de l'AEI-Brookings Joint Center for Regulary Studies 8
9 Aujourd’hui Impacts: Vol des informations confidentielles, Prise de contrôle du système, Déni de service, … 0 Km
IMPACTS DE LA GUERRE NUMÉRIQUE : CAS DU VIRUS STUXNET : IRAN 2010  Attaque du virus stuxnet: exploit des failles zero day: propagation du virus via USB  Limité d’une explosion du réacteur nucléaire  Retard du production de 4 mois 10
11 IMPACTS DE LA GUERRE NUMÉRIQUE : 2016 0 Km
12 ? #IMPACTS DES ATTAQUES WEB
CONSTAT SUR LE HACHING
INTRODUCTION 14 11,4 millions de documents, confidentiels 2,6 téraoctets de données plus de 214 000 sociétés offshore Conséquences Fuite d’information LA FUITE D’INFORMATION DU PANAMA PAPERS  Or, "Panama Papers" c’est la violation du serveur de messagerie du cabinet exploitée par des (les hackers)
CONSÉQUENCES..2016 (1) 15 03 Avril 2016
2017… FRAUDE FISCALE 16
LA DIRECTION … SÉCURISATIONHACKING
QUELLE EST LA DIRECTION? 18
19 LE CYCLE DE VIE D’UNE ATTAQUE CYBERNÉTIQUE Les sept étapes suivies par un seul et/ou un groupe d’attaquants pour réaliser une attaque cybernétique.
MODÈLE PROPOSÉ 20
21 MATRICE DE DÉFENSE
OWASP TOP 10 22
L’OWASP Top10 http://www.owasp.org/index.php/Top_10
A1 – Injection • Envoyer à une application des données générant un comportement non attendu. L’injection • Utilisent les chaines et les interpretent comme des commandes • SQL, OS Shell, LDAP, XPath, Hibernate, etc… Les Interpréteurs • Enormément d’applications y sont sensibles • Même s’il est très simple de s’en affranchir…. L’injection SQL est toujours commune • Souvent très sévère. Le plupart du temps l’ensemble des données de la base sont lisibles ou modifiables. • Cela peut même aller jusqu’au schéma de la base, les comptes ou un accès OS…. Impact
Exemple sur l’injection SQL Firewall Hardened OS Web Server App Server Firewall Databases LegacySystems WebServices Directories HumanResrcs Billing Custom Code APPLICATION ATTACK NetworkLayerApplicationLayer Accounts Finance Administration Transactions Communication KnowledgeMgmt E-Commerce Bus.Functions HTTP request  SQL query  DB Table   HTTP response   "SELECT * FROM accounts WHERE acct=‘’ OR 1=1-- ’" 1. L’application fourni un formulaire 2. L’attaquant envoi son attaque dans les données du formulaire 3.L’application transfère les données à la requête SQL Account Summary Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293 4. Le SGBD lance la requête contenant l’attaque et renvoie les résultats à l’application. 5. L’application renvoie ce résultat à l’utilisateur Account: SKU: Account: SKU:
A1 – Comment se protéger • Recommandations 1. Se passer des interpréteurs, 2. Utiliser une interface permettant de préparer les requêtes (ex, prepared statements, or les procédures stockées), 3. Encoder toutes les données fournies par l’utilisateur avant de les passer à l’interpréteur • Toujours effectuer une validation de type “white liste” sur les données utilisateurs. • Minimiser les privilèges dans les bases pour limiter l’impact de la faille. • References • Plus de détails sur http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
A2 – Cross-Site Scripting (XSS) • Des données venant d’un attaquant sont envoyées à l’innocent navigateur d’un utilisateur Se retrouve à chaque audit/pentest • Stockées en base, • Réfléchies depuis une entrée d’une page Web (champ de formulaire, champ caché, URL, …) • Envoyées directement à un client Riche (Javascript, Flash, …) Ces données peuvent être • Essayez cela dans votre navigateur – javascript:alert(document.cookie) Virtuellement toute application Web est vulnérable • Vol des sessions utilisateur, de données sensibles, réécriture de la page Web, redirection vers un site d’hameconnage ou autre code malveillant • De manière plus grave : installation d’un proxy XSS permettant à un attaquant d’observer le poste client voire de forcer l’utilisateur vers un site particulier Impact
Cross-Site Scripting Illustré Application disposant de faille XSS 3 2 L’attaquant découvre le script vulnérable L’attaquant entre un script malicieux sur la page web(stocké) ou bien utilise un lien(réfléchi) permettant d’envoyer vers la page 1 La victime se rend sur la page L’attaquant recoit le cookie ou autre élément directement Le Script s’execute sur le navigateur de la victime sans qu’il ne le sache Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus.Functions
(AntiSamy A2 – Contre mesures • Recommandations • Supprimer la faille  • Ne pas inclure de contenu fourni par l’utilisateur dans la page de sortie !!! • Défenses possibles 1. Encoder toutes les entrées et sorties utilisateurs (utilisez l’OWASP ESAPI pour l’encodage de sortie) http://www.owasp.org/index.php/ESAPI 2. Effectuer de la validation de type « white liste » pour les données utilisateurs entrantes qui sont inclues dans une page. 3. Pour des grosses portions de code HTML fourni par un utilisateur, utiliser le filtre OWASP Anti-Sammy de manière à nettoyer l’HTML Voir: http://www.owasp.org/index.php/AntiSamy • Référence • Pour effectuer un encodage propre, se référer à http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet
A3 – Mauvaise gestion des sessions et de l’authentification • Les identifiants doivent donc être passés à chaque requête. • Il faut utiliser SSL pour toute authentification HTTP est un protocole sans état • Des ID de sessions sont utilisés pour maintenir la session dans HTTP car il ne le peut lui. • Cela suffit à un attaquant, c’est aussi interessant qu’un identifiant • Les ID de sessions sont souvent exposés dans les sessions réseau, dans les browsers (cookies), dans les logs, …. Failles dans la gestion de l’authentification • Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secretes, logout, email, … Attention aux portes dérobées… • Vol de session ou compromission de comptes utilisateur Impact
Illustration d’une mauvaise authentification Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus.Functions 1 Utilisateur envoie ses identifiants 2 Le site récrit l’URL (i.e., mise dans l’URL de l’ID de session) 3 L’utilisateur clique sur un lien vers http://www.hacker.com dans un forum www.boi.com?JSESSIONID=9FA1DB9EA... 4 L’attaquant regarde les logs “Referer” sur www.hacker.com Et découvre le JSESSIONID 5 L’attaquant peut utiliser le JSESSIONID sur le site boi.com pour son méfait
A3 – Contre Mesure • Vérifier l’architecture ! • L’authentification doit être simple, centralisée et standardisée • Utiliser le mécanisme standard de gestion des cookies du framework (ils sont globalement fiables) • Utiliser constamment SSL pour protéger les identifiants de connexion et de sessions • Vérifier l’implémentation • Oublier l’analyse automatique • Vérifier le certificat SSL (SSLv2, renégociation, chiffrement faible, …) • Examiner toutes les fonctions relatives a l’authentification • Vérifier que la déconnexion supprime bien la session ! • Utiliser l’OWASP WebScarab pour tester l’implémentation (sessionID analysis)
A4 – Référence directe non sécurisée à un objet • C’est une manière de renforcer les habilitations en lien avec A7 – Mauvaise restriction d’accès à une URL Comment accéder aux données privées • Attendre uniquement de l’utilisateur des accès à des objets autorisés ou • Cacher des références à des objets dans des champs cachés • … et ne pas renforcer les restrictions coté serveur. • Ceci n’est qu’une tentative de contrôle d’accès sur la présentation et ne fonctionne pas ! • Un attaquant n’a qu’a modifier les valeurs des paramètres… Des erreurs classiques • Un utilisateur a accès à des données ou des fichiers normalement interdits Impact
Référence directe non sécurisée à un objet illustrée • L’attaquant note le paramètre acct = 6065 ?acct=6065 • Il modifie celui-ci de la manière suivante ?acct=6066 • L’attaquant visualise un autre compte. https://www.onlinebank.com/user?acct= 6065
A4 – Contre Mesure • Eliminer la référence directe. • La remplacer par une valeur temporaire aléatoire (e.g. 1, 2, 3) • L’ESAPI fournit des fonctions pour cela • IntegerAccessReferenceMap & RandomAccessReferenceMap • Valider la référence directe à l’objet • Vérifier que le contenu est correctement formaté. • Vérifier que l’utilisateur a le droit d’effctuer l’accès à l’objet. • Vérifier que le mode d’accès à l’objet est autorisé (e.g., read, write, delete) http://app?file=1 Report123.xls http://app?id=7d3J93 Acct:9182374http://app?id=9182374 http://app?file=Report123.xls Access Reference Map
A5 – Cross Site Request Forgery (CSRF) • C’est une attaque ou le navigateur de la victime génère une requête vers une application Web vulnérable • Cette vulnérabilité est causée par la capacité que les navigateurs ont d’ envoyer automatiquement des données d’authentification (session ID, IP adresse, comptes de domaine windows, ..) dans chaque requête. Cross Site Request Forgery • Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne a votre place. • Que pourrait-il faire ? Imaginez • Initiation de transactions (transfert de fonds, logoff, modification de données, …) • Accès à des données sensibles • Changement des mots de passes/identifiants Impact
CSRF démystifié • Le problème • Les navigateurs Web incluent automatiquement la plupart des identifiants dans chaque requête. • Que cela soit des requêtes venant d’un formulaire, d’une image ou d’un autre site. • Tous les sites basés uniquement sur les identifiants automatiques sont vulnérables • Approximativement 100% des sites le sont… • C’est quoi un identifiant automatique? • Cookie de session • Une entête d’authentification HTTP • Une adresse IP • Les certificats SSL client • L’authentification de domaine Windows.
CSRF illustré 3 2 L’attaquant pose son piège sur un site internet (ou via un e- mail)1 Tout en étant logguer sur le site vulnérable, la victime parcourt le site de l’attaquant. Le site vulnérable ne voit que des requêtes légitimes et effectue l’action demandée Le tag <img> tag chargé par le navigateur envoie une requête GET (contenant des identifiants sur le site vulnérable) Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus.Functions Un tag chaché <img> contient une attaque vers un site vulnérable Application vulnérable au CSRF
A5 – Contre Mesure • Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes sensibles. • Cela rend impossible pour l’attaquant de soumettre une requête valide. • (sauf si en plus il y a une faille XSS) • Ces jetons doivent être surs cryptographiquement. • Options • Stocker un seul jeton dans la session et l’ajouter a tous les formulaire et liens • Champ caché: <input name="token" value="687965fdfaew87agrde" type="hidden"/> • Utiliser un URL : /accounts/687965fdfaew87agrde • Utiliser un jeton de formulaire: /accounts?auth=687965fdfaew87agrde … • Attention a ne pas exposer le jeton dans l’entete “referer” • Utiliser de préférence un champ caché. • Utiliser un jeton unique par fonction. • Il est recommandé d’ajouter un second niveau d’authentification pour une transaction sensible • Ne pas laisser un attaquant stocker des attaques sur le site • Encoder proprement les données d’entrées • Cela permet de limiter la majorité des interpréteurs de liens Voir www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet pour plus de détails
A6 – Mauvaise configuration • On pense aux réseaux, aux systèmes et aux plateformes • Il ne faut pas oublier les environnements de développement Les applications Web doivent faire confiance à une fondation sécurisée • Pensez a tous les endroits ou l’on trouve votre code source. • La Sécurité ne doit pas se baser sur l’obscurité du code source. Est-ce que votre code source est secret? • Tous les identifiants doivent être changés sur les environnements de production Il faut étendre la gestion de la configuration a toutes les parties de l’application • Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…) • Failles XSS exploitées du à l’oubli de patch dans les frameworks • Accès non autorisé à des comptes , des données, ou des fonctionnalités applicatives par défaut non utilisées mais accessibles a cause d’une mauvaise configuration utilisateur Impact
Hardened OS Web Server App Server Framework Mauvaise configuration illustrée App Configuration Custom Code Accounts Finance Administration Transactions Communication KnowledgeMgmt E-Commerce Bus.Functions Test Servers QA Servers Source Control Development Database Insider
A6 – Contre Mesure • Vérifier la gestion de la configuration sécurité de vos systèmes. • Ayez des guidelines de renforcement de la sécurité. • L’automatisation est réellement utile dans ce cas • Couvrir toute la plateforme et l’application • Garder a l’esprit d’avoir des patchs pour TOUS les composants • Cela inclut les librairies, et pas seulement l’OS, les serveurs et applications. • Analyser l’impact sécurité des changements • Pouvez vous effectuer des “masters” de votre configuration applicative ? • Mettre en place un reporting des builds dans le processus sécurité • Si vous ne pouvez vérifier le configuration applicative, l’applicatif n’est pas sécurisé • Vérifier l’implémentation • Les scans découvrent généralement les configurations par défaut et les problèmes dus à des patchs de retard
A7 – Mauvaise restriction d’URL • Cela concerne aussi le renforcement des habilitations tout comme le paragraphe A4 Comment protégez vous l’accès à une URL ? • N’afficher que les liens et menus autorisés dans les listes de choix. • Une fois de plus, c’est du controle d’accès visuel, et cela ne fonctionne pas. • Il suffit de modifier les requêtes en allant diretement sur les pages “non autorisées” Une erreur commune… • Invocation de fonctions et de services non autorisées • Accès a des données ou des comptes n’appartenant pas à l’utilisateur • Élévation de privilèges et d’actions Impact
Mauvaise restriction d’URL illustrée • L’attaquant note dans l’URL que le rôle est affiché /user/getAccounts • Il modifie directement l’URL (le rôle) /admin/getAccounts, ou /manager/getAccounts • L’attaquant dispose de privilèges supplémentaires https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts
A7 – Contre Mesure • Pour toute URL il faut 3 éléments : • Restreindre l’accès aux seuls utilisateurs authentifiés (sauf si l’URL est publique). • Renforcer les permissions basées sur les rôles ou l’utilisateue (si l’URL est privée) • Bloquer toute requête à des pages non autorisées ( (e.g., fichiers de config, de log, code source, etc.) • Vérifier l’architecture • Utiliser un modèle positif simple a tous les niveaux • S’assurer d’avoir un modèle d’accès à tous les niveaux. • Vérifier l’implémentation • Oublier l’approche automatisée • Vérifier que chaque URL de l’application est protégée par : • Un filtre externe, comme en J2EE (web.xml) • Ou par un morceau de VOTRE code – Voir la méthode ESAPI’ isAuthorizedForURL() • Vérifier que la configuration du serveur n’autorise pas les requêtes vers les types de fichiers ou extensions non autorisés. • Utiliser un proxy type WebScarab pour forger des requêtes non autorisées.
A8 – Redirections et transferts non contrôlés • Et fréquemment elles incluent des paramètres fournis par l’utilisateur dans l’URL de destination. • Si ces paramètres ne sont pas validés, un attaquant peut envoyer la victime vers le site de son choix. Les redirections sont communes dans une application WEB. • Ils renvoient la requête vers une nouvelle page en interne de l’application. • Parfois les paramètres déterminent la page cible. • Si cela n’est pas validé, cela permet de parfois passer outre les mécanismes d’autorisation et d’authentification. Les transferts(aka Transfer en .NET) sont eux aussi communs • Rediriger la victime vers un site malveillant de type hameconnage. • Il devient possible de passer outre les contrôles de sécurité et accéder à des fonctions ou données non autorisées. Impact
Redirection illustrée 3 2 L’attaquant envoi à la victime via un email ou une page Web de son choix le lien. From: Internal Revenue Service Subject: Your Unclaimed Tax Refund Our records show you have an unclaimed federal tax refund. Please click here to initiate your claim. 1 L’application redirige la victime vers le site de l’attaquant Request sent to vulnerable site, including attacker’s destination site as parameter. Redirect sends victim to attacker site Custom Code Accounts Finance Administration Transactions Communication KnowledgeMgmt E-Commerce Bus.Functions 4 Le site malveillant installe des éléments sur le navigateur ou récupére des données La vicitime clique sur le lien contenant une donnée non validée. Evil Site http://www.irs.gov/taxrefund/claim.jsp?year=2 006& … &dest=www.evilsite.com
Unvalidated Forward Illustrated 2 L’attaquant envoie sa charge sur une page vulnérable ou il a accès1 L’application autorise la requête et continue vers la page vulnérable Request sent to vulnerable page which user does have access to. Redirect sends user directly to private page, bypassing access control. 3 La page de transfert ne contrôle pas le paramètre et renvoie l’attaquant vers la page non autorisée, passant outre le contrôle d’accès. public void doPost( HttpServletRequest request, HttpServletResponse response) { try { String target = request.getParameter( "dest" ) ); ... request.getRequestDispatcher( target ).forward(request, response); } catch ( ... Filtre public void sensitiveMethod( HttpServletRequest request, HttpServletResponse response) { try { // Do sensitive stuff here. ... } catch ( ...
A8 – Contre Mesure • Il y a des tonnes de solutions 1. Eviter au maximum les redirections et les transferts 2. S’il faut absolument les intégrer, ne pas utiliser les paramètres parvenant d’un utilisateur pour définir l’URL/fonction cible. 3. Si vous “devez” utiliser les paramètres utilisateurs, a) Validez chaque paramètre pour vérifier qu’il est autorisé et valide par rapport à l’utilisateur, ou alors b) Utilisez une table de correspondance serveur entre les paramètres utilisateurs et les pages à appeler. • Pour les redirection, valider l’URL cible après la construction pour vérifier qu’elle redirige bien vers un site autorisé ! • L’ESAPI peut vous aider : • Voir : SecurityWrapperResponse.sendRedirect( URL ) • http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/ SecurityWrapperResponse.html#sendRedirect(java.lang.String) • Quelques réflexions sur les Transferts • Idéallement, il faudrait appeler le contrôle d’accès pour être sur que l’utilisateur est bien autorisé aà effecgtuer le transfert(très simple avec l’ESAPI…) • Si vous utilisez des filtres externes (comme SiteMinder), cela ne sera pas simple • La meilleure solution est de s’assurer que les utilisateurs qui ont accès à la page initiale ont TOUS le droit d’accéder à la page cible….
A9 – Stockage Cryptographique non sécurisé • Oubli d’identification des données sensibles • Oubli d’identification de tous les entrepôts de stockage des données sensibles. • Bases de données, fichiers, répertoires, fichiers de logs, backup, … • Oubli de mettre en place une protection correcte des données dans tous les entrepots de stockages des données sensibles. Le stockage de données non sécurisées • Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …) • Extrait de données secretes via d’autres failles (injection SQL, LDAP, …) • Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la normale (forensics, lettres et dédommagements client, assurance, …) Impact
Stockage non sécurisé illustré Custom Code Accounts Finance Administration Transactions Communicatio nKnowledge Mgmt E-Commerce Bus.Functions 1 La victime stocke son numéro de carte de crédit dans le système via un formulaire 2Le gestionnaire des erreurs loggue le numéro de carte car la passerelle de commerce est indisponible. 4 Une personne malveillante interne vole 4 millions de carte de crédit Fichier de log 3Les logs sont rendus disponibles pour tous les membres internes dans le but du debug
A9 – Contre Mesure • Vérifier l’architecture • Identifier toutes les données sensibles • Identifier tous les entrepots de stockage des données • S’assurer des attaques possibles sur comptes • Utiliser un mécanisme de chiffrement approprié • Chiffrement de fichier, de base, d’élément de la base. • Utiliser correctement le mécanisme… • Utiliser des algorithmes connus standard et surs. • Générer, distribuer et protéger les clefs • S’assurer de la capacité de changement régulier des clefs • Vérifier l’implémentation • Un algorithme sur est utilisé et c’est le bon algorithme pour la situation ! • Toutes les clefs, certificats, et mots de passe sont stockés et protégés correctement. • Il existe une distribution propre des clefs et il est possible d’en changer facilement
A10 – Protection insuffisante lors du transport des données • Oubli de l’identification de TOUTES les données sensibles • Oubli de l’identification de TOUTES les URLs/Pages ou les données sensibles transitent. • Sur le Web, vers les SGBD, vers les partenaires métiers, vers les réseaux internes… • Oubli de protéger les données à chacun de ces endroits… La transmission de données non sécurisées… • Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …) • Extrait de données secretes via d’autres failles (injection SQL, LDAP, …) • Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la normale (forensics, lettres et dédommagements client, assurance) Impact
Protection insuffisante lors du transport des données illustrée Custom Code Employées Partenaire métier Victime externe Backend Systems Attaquant externe 1 Vols de données via le réseau externe 2 Vol de données via le réseau interne Attaquant interne
A10 – Contre Mesure • Utiliser les mécanismes de protection appropriés • Utiliser TLS pour tout transport de données sensibles. • Chiffrer les messages avant transmission. • E.g., XML-Encryption • Signer les messages avant transmission • E.g., XML-Signature • Utiliser les mécanismes correctement ! • Utiliser des algorithmes surs ! (désactiver les vieilles versions de SSL et les chiffrements faibles…) • Gérer correctement les clefs/certificats. • Vérifier les certificats SSL avant l’utilisation. • Voir http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet pour plus de details
En résumé : comment adresser ces risques • Développer du code sécurisé ! • Suivre les bonnes pratiques du Guide OWASP sur la construction sécurisée d’une application Web. • http://www.owasp.org/index.php/Guide • Utiliser l’OWASP Application Security Verification Standard comme un guide permettant de définir les mécanismes de sécurité • http://www.owasp.org/index.php/ASVS • Utiliser les composants de sécurité standard et s’adaptant le mieux a votre entreprise • Par exemple utiliser l’OWASP ESAPI comme une fondation a VOS composants standards • http://www.owasp.org/index.php/ESAPI • Auditer les applications • Faire appel a une équipe expérimentée pour analyser et auditer l’application. • Auditer les applications vous-meme graçe aux guide de l’OWASP • OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide • OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide
SÉCURITÉ DES APPLICATIONS 57
Minimisation des risques potentiels Fonctions de programmation Audit applicatif Equipements de sécurité Sécurisation des applications
Exemple : fonctions PHP utiles addslashes() : addslashes($ch) échappe les caractères " et ' en les faisant précéder d'un antislash . (évitez le SQL injection et XSS) mysql_real_escape_string: Protège les caractères spéciaux d'une commande SQL (évitez le SQL injection). ereg : La fonction ereg applique une expression régulière sur une chaîne par exemple pour valider une numéro de carte d’identité : ereg("^[0- 9]{8}$", @$num). (évitez le SQL injection et XSS)
safe_mode=On Option de php qui permet de sécuriser le système , afin d'éviter les interactions entre php et le système. En cas d'activation , php n'autorisera pas les exécutions de programmes externe , ou l'acces à des fichiers d'autres utilisateurs. display_errors = Off Cette directive détermine si les erreurs doivent être affichées à l'écran ou non. log_errors = On: activer le log des erreurs. register_globals = Off-> désactiver les variables globales. magic_quotes_gpc = Off Paramètre qui filtre les paramètres HTTP GET et POST et ajoute des / devant les apostrophes guillemets et caractère null. disable_functions= exec, system, popen, proc_open, passthru,fsockopen, ftp_connect, ftp_ssl_connect,dl_open : désactiver les fonctions dangereux. allow_url_fopen = Off -> éviter le file include file_uploads = Off ->désactiver l'upload de fichiers via HTTP Remarque: si la configuration est établie plusieurs applications génèrent des erreurs comme Joomla,PHPBB,PHPNUKE,phpbb etc…essayer de faire modifier les Configuration de php.ini
vulture, modsecurity FirewallRéseau Externe Application Hébergée HTTP Mail FTP DNS P2P HTTPS Autres Serveur Web DB Application Web Web Firewall Green SQL Sécurisation web
Hardening  Hardning du système d’exploitation.(voir le guide dans la site officielle)  Hardning du serveur web(exemple voir guide hardening apache).  Hardning du serveur base des données(exemple voir guide hardening mysql).
Installation des outils qui renforce la sécurité  Un web firewall applicatif (exemple voir guide de mod security).  Database firewall (exemple green sql).  urlScan:est un outil de sécurité Microsoft qui limite les types de requêtes HTTP traitées par Internet Information Services (IIS). IIS lockdown :est un outil qui permet d’assurer un plus haut niveau de sécurité en désactivant les options inutilisées d’IIS (Internet Information Services). Et contient l’outi urlscan lien : http://www.laboratoire-microsoft.org/d/?id=11151
Côté « application » 1) Sécurisation de la plateforme d’hébergement:  Mise à jour et hardening du serveur.  Détection d’intrusion réseau.  Détection d’intrusion au niveau de l’hôte (HIDS).  Détection antivirale  Filtrage applicatif
Côté « application » 2) Suivi et audit des logs enregistrés au niveau de la plateforme de connexion :  log d’administration,  log d’accès public,
Côté « application » 3. Sauvegarde des données sensible :  Applicatif,  base de données,
Côté « application » 4) Validation de l’application:  Aprés insertion ou ajout de nouveaux services, …par une tierce entité .  Audit de l’application avant sa mise en ligne :  au niveau de cette phase toute la documentation relative à l’application doit être demandé (Conception, Structure, architecture)
Côté « application » 5) Audit régulier de la sécurité :  de l’application,  du serveur web,
Côté « application » 6) Notification immédiate de tout type d’incident touchant l’application web:  Pour déclarer des incidents, vous pouvez utiliser l'un des moyens suivants : - Via Email: envoyer nous un e-mail (sécurisé) à l'adresse suivante: incident@ansi.tn - Par Téléphone : (+216) 71 843 200 ou bien (+216) 71 846 020 et demandez le poste 119 (pour le recueil des déclarations) - Par Fax: (+216) 71 846 363
Côté « application » 7) Mettre en place un plan de continuité de service:  via la virtualisation.  Ou autre solution.
MERCI POUR VOTRE ATTENTION Nabil HOSNI Nabil.hosni@ansi.tn (00216)94 675 101

Contenu connexe

PDF
Sécurité des Applications Web avec Json Web Token (JWT)
parENSET, Université Hassan II Casablanca
 
PDF
Sécurité des applications web: attaque et défense
parAntonio Fontes
 
PPTX
Durcissement de code - Sécurité Applicative Web
parCyrille Grandval
 
PPT
Les attaques par injection sql
parMohamed Yassin
 
PPTX
Introduction vulnérabilité web
pardavystoffel
 
PPTX
Sécurité des applications Web
parSylvain Maret
 
PDF
Cours Secu Web
parCedric Foll
 
PPTX
Securité web
parEmmanuel Gautier
 
Sécurité des Applications Web avec Json Web Token (JWT)
parENSET, Université Hassan II Casablanca
 
Sécurité des applications web: attaque et défense
parAntonio Fontes
 
Durcissement de code - Sécurité Applicative Web
parCyrille Grandval
 
Les attaques par injection sql
parMohamed Yassin
 
Introduction vulnérabilité web
pardavystoffel
 
Sécurité des applications Web
parSylvain Maret
 
Cours Secu Web
parCedric Foll
 
Securité web
parEmmanuel Gautier
 

Tendances

PDF
Les principales failles de sécurité des applications web actuelles
parBee_Ware
 
PPTX
Webinaire : sécurité informatique sur le web - Jérôme Thémée
parMarie Tapia
 
PDF
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
parENSET, Université Hassan II Casablanca
 
PDF
Sécurité des réseaux
parSehla Loussaief Zayen
 
PDF
Architecture jee principe de inversion de controle et injection des dependances
parENSET, Université Hassan II Casablanca
 
PPTX
La sécurité sur le web
parSofteam agency
 
KEY
Securitedesapplications 091011120426-phpapp02
parAsma Messaoudi
 
PDF
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
parNormandie Web Xperts
 
PDF
OpenSSO Aquarium Paris
parAlexis Moussine-Pouchkine
 
PDF
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
parMicrosoft Décideurs IT
 
PDF
White paper - La sécurisation des web services
parBee_Ware
 
PDF
Partie III – APM Application Policy Manager
pare-Xpert Solutions SA
 
PPTX
Sécurité des web services soap
parZakaria SMAHI
 
PPTX
Sécuriser mes applications avec ZF2
parCyrille Grandval
 
Les principales failles de sécurité des applications web actuelles
parBee_Ware
 
Webinaire : sécurité informatique sur le web - Jérôme Thémée
parMarie Tapia
 
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
parENSET, Université Hassan II Casablanca
 
Sécurité des réseaux
parSehla Loussaief Zayen
 
Architecture jee principe de inversion de controle et injection des dependances
parENSET, Université Hassan II Casablanca
 
La sécurité sur le web
parSofteam agency
 
Securitedesapplications 091011120426-phpapp02
parAsma Messaoudi
 
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
parNormandie Web Xperts
 
OpenSSO Aquarium Paris
parAlexis Moussine-Pouchkine
 
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
parMicrosoft Décideurs IT
 
White paper - La sécurisation des web services
parBee_Ware
 
Partie III – APM Application Policy Manager
pare-Xpert Solutions SA
 
Sécurité des web services soap
parZakaria SMAHI
 
Sécuriser mes applications avec ZF2
parCyrille Grandval
 

Similaire à Securite web is_ima

PDF
Introduction à la sécurité des applications web avec php [fr]
parWixiweb
 
PPTX
Securité des applications web
parMarcel TCHOULEGHEU
 
PDF
Les menaces applicatives
parBee_Ware
 
PDF
Sécurisation d'un site internet
parwaggaland
 
PDF
OWASP Top Ten 2007 - Sommaire executif - French version
parspl0it
 
PPTX
ASFWS 2011 - L’importance du protocole HTTP dans la menace APT
parCyber Security Alliance
 
PDF
White paper: SSTIC 2008: Advanced CSRF
parManfred Touron
 
PDF
La securite au coeur des projets web
parChristophe Villeneuve
 
PPTX
Traitement d’incidents de sécurité : cas pratiques, retours d’expérience et r...
parMicrosoft
 
PPTX
La sécurité informatique
parSaber Ferjani
 
PDF
Modul de lafradqbqvqjiaoaooakkskkskskzkkakzkzkzkkakakzkzkzlzlzlzlzllzaiiakaka...
paronyikondi
 
PPTX
Modéliser les menaces d'une application web
parAntonio Fontes
 
PPTX
Owasp top 10 2010 Resist toulouse
parSébastien GIORIA
 
PDF
2011 02-08-ms tech-days-sdl-sgi-v02
parSébastien GIORIA
 
PDF
Hackfest @ WAQ2011
parHackfest Communication
 
PDF
siris1.pdf
parssuserdd27481
 
PDF
Comprendre la securite web 2017
parChristophe Villeneuve
 
PDF
Première rencontre d'owasp québec
parPatrick Leclerc
 
PPTX
Un peu de sécurité dans ce monde de Kiwi
parLaurie-Anne Bourdain
 
PDF
OWASP Top10 2013 - Présentation aux RSSIA 2013
parSébastien GIORIA
 
Introduction à la sécurité des applications web avec php [fr]
parWixiweb
 
Securité des applications web
parMarcel TCHOULEGHEU
 
Les menaces applicatives
parBee_Ware
 
Sécurisation d'un site internet
parwaggaland
 
OWASP Top Ten 2007 - Sommaire executif - French version
parspl0it
 
ASFWS 2011 - L’importance du protocole HTTP dans la menace APT
parCyber Security Alliance
 
White paper: SSTIC 2008: Advanced CSRF
parManfred Touron
 
La securite au coeur des projets web
parChristophe Villeneuve
 
Traitement d’incidents de sécurité : cas pratiques, retours d’expérience et r...
parMicrosoft
 
La sécurité informatique
parSaber Ferjani
 
Modul de lafradqbqvqjiaoaooakkskkskskzkkakzkzkzkkakakzkzkzlzlzlzlzllzaiiakaka...
paronyikondi
 
Modéliser les menaces d'une application web
parAntonio Fontes
 
Owasp top 10 2010 Resist toulouse
parSébastien GIORIA
 
2011 02-08-ms tech-days-sdl-sgi-v02
parSébastien GIORIA
 
Hackfest @ WAQ2011
parHackfest Communication
 
siris1.pdf
parssuserdd27481
 
Comprendre la securite web 2017
parChristophe Villeneuve
 
Première rencontre d'owasp québec
parPatrick Leclerc
 
Un peu de sécurité dans ce monde de Kiwi
parLaurie-Anne Bourdain
 
OWASP Top10 2013 - Présentation aux RSSIA 2013
parSébastien GIORIA
 

Securite web is_ima

  • 1.
    SÉCURITÉ DES APPLICATIONS NabilHOSNI MCSA, ITIL , ISO 27001 Lead Implementer / Lead Auditor / Expert auditeur ANSI Nabil.hosni@ansi.tn (00216)94 675 101
  • 2.
  • 3.
  • 4.
    PLAN Rappel  Introduction: Guerreclassique vs la guerre numérique  Impacts de la guerre numérique OWASP TOP 10 Modèle proposé de la sécurité 4
  • 5.
  • 6.
  • 7.
  • 8.
    IMPACTS DE LAGUERRE CLASSIQUE: CAS DE L’IRAK  Coût des opérations militaires et de la reconstruction estimé au début : entre 100 et 200 milliards de $. Coûts totaux entre 2003 et 2005: 429 milliards Coûts prévisibles pour la période 2005-2015: 577 milliards  révision de la choix stratégiques du guerre sources : Scott Wallsten et Katrina Kosec de l'AEI-Brookings Joint Center for Regulary Studies 8
  • 9.
    9 Aujourd’hui Impacts: Vol desinformations confidentielles, Prise de contrôle du système, Déni de service, … 0 Km
  • 10.
    IMPACTS DE LAGUERRE NUMÉRIQUE : CAS DU VIRUS STUXNET : IRAN 2010  Attaque du virus stuxnet: exploit des failles zero day: propagation du virus via USB  Limité d’une explosion du réacteur nucléaire  Retard du production de 4 mois 10
  • 11.
    11 IMPACTS DE LAGUERRE NUMÉRIQUE : 2016 0 Km
  • 12.
  • 13.
  • 14.
    INTRODUCTION 14 11,4 millions dedocuments, confidentiels 2,6 téraoctets de données plus de 214 000 sociétés offshore Conséquences Fuite d’information LA FUITE D’INFORMATION DU PANAMA PAPERS  Or, "Panama Papers" c’est la violation du serveur de messagerie du cabinet exploitée par des (les hackers)
  • 15.
  • 16.
  • 17.
  • 18.
    QUELLE EST LADIRECTION? 18
  • 19.
    19 LE CYCLE DEVIE D’UNE ATTAQUE CYBERNÉTIQUE Les sept étapes suivies par un seul et/ou un groupe d’attaquants pour réaliser une attaque cybernétique.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
    A1 – Injection •Envoyer à une application des données générant un comportement non attendu. L’injection • Utilisent les chaines et les interpretent comme des commandes • SQL, OS Shell, LDAP, XPath, Hibernate, etc… Les Interpréteurs • Enormément d’applications y sont sensibles • Même s’il est très simple de s’en affranchir…. L’injection SQL est toujours commune • Souvent très sévère. Le plupart du temps l’ensemble des données de la base sont lisibles ou modifiables. • Cela peut même aller jusqu’au schéma de la base, les comptes ou un accès OS…. Impact
  • 25.
    Exemple sur l’injectionSQL Firewall Hardened OS Web Server App Server Firewall Databases LegacySystems WebServices Directories HumanResrcs Billing Custom Code APPLICATION ATTACK NetworkLayerApplicationLayer Accounts Finance Administration Transactions Communication KnowledgeMgmt E-Commerce Bus.Functions HTTP request  SQL query  DB Table   HTTP response   "SELECT * FROM accounts WHERE acct=‘’ OR 1=1-- ’" 1. L’application fourni un formulaire 2. L’attaquant envoi son attaque dans les données du formulaire 3.L’application transfère les données à la requête SQL Account Summary Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293 4. Le SGBD lance la requête contenant l’attaque et renvoie les résultats à l’application. 5. L’application renvoie ce résultat à l’utilisateur Account: SKU: Account: SKU:
  • 26.
    A1 – Commentse protéger • Recommandations 1. Se passer des interpréteurs, 2. Utiliser une interface permettant de préparer les requêtes (ex, prepared statements, or les procédures stockées), 3. Encoder toutes les données fournies par l’utilisateur avant de les passer à l’interpréteur • Toujours effectuer une validation de type “white liste” sur les données utilisateurs. • Minimiser les privilèges dans les bases pour limiter l’impact de la faille. • References • Plus de détails sur http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
  • 27.
    A2 – Cross-SiteScripting (XSS) • Des données venant d’un attaquant sont envoyées à l’innocent navigateur d’un utilisateur Se retrouve à chaque audit/pentest • Stockées en base, • Réfléchies depuis une entrée d’une page Web (champ de formulaire, champ caché, URL, …) • Envoyées directement à un client Riche (Javascript, Flash, …) Ces données peuvent être • Essayez cela dans votre navigateur – javascript:alert(document.cookie) Virtuellement toute application Web est vulnérable • Vol des sessions utilisateur, de données sensibles, réécriture de la page Web, redirection vers un site d’hameconnage ou autre code malveillant • De manière plus grave : installation d’un proxy XSS permettant à un attaquant d’observer le poste client voire de forcer l’utilisateur vers un site particulier Impact
  • 28.
    Cross-Site Scripting Illustré Application disposantde faille XSS 3 2 L’attaquant découvre le script vulnérable L’attaquant entre un script malicieux sur la page web(stocké) ou bien utilise un lien(réfléchi) permettant d’envoyer vers la page 1 La victime se rend sur la page L’attaquant recoit le cookie ou autre élément directement Le Script s’execute sur le navigateur de la victime sans qu’il ne le sache Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus.Functions
  • 29.
    (AntiSamy A2 – Contremesures • Recommandations • Supprimer la faille  • Ne pas inclure de contenu fourni par l’utilisateur dans la page de sortie !!! • Défenses possibles 1. Encoder toutes les entrées et sorties utilisateurs (utilisez l’OWASP ESAPI pour l’encodage de sortie) http://www.owasp.org/index.php/ESAPI 2. Effectuer de la validation de type « white liste » pour les données utilisateurs entrantes qui sont inclues dans une page. 3. Pour des grosses portions de code HTML fourni par un utilisateur, utiliser le filtre OWASP Anti-Sammy de manière à nettoyer l’HTML Voir: http://www.owasp.org/index.php/AntiSamy • Référence • Pour effectuer un encodage propre, se référer à http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet
  • 30.
    A3 – Mauvaisegestion des sessions et de l’authentification • Les identifiants doivent donc être passés à chaque requête. • Il faut utiliser SSL pour toute authentification HTTP est un protocole sans état • Des ID de sessions sont utilisés pour maintenir la session dans HTTP car il ne le peut lui. • Cela suffit à un attaquant, c’est aussi interessant qu’un identifiant • Les ID de sessions sont souvent exposés dans les sessions réseau, dans les browsers (cookies), dans les logs, …. Failles dans la gestion de l’authentification • Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secretes, logout, email, … Attention aux portes dérobées… • Vol de session ou compromission de comptes utilisateur Impact
  • 31.
    Illustration d’une mauvaiseauthentification Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus.Functions 1 Utilisateur envoie ses identifiants 2 Le site récrit l’URL (i.e., mise dans l’URL de l’ID de session) 3 L’utilisateur clique sur un lien vers http://www.hacker.com dans un forum www.boi.com?JSESSIONID=9FA1DB9EA... 4 L’attaquant regarde les logs “Referer” sur www.hacker.com Et découvre le JSESSIONID 5 L’attaquant peut utiliser le JSESSIONID sur le site boi.com pour son méfait
  • 32.
    A3 – ContreMesure • Vérifier l’architecture ! • L’authentification doit être simple, centralisée et standardisée • Utiliser le mécanisme standard de gestion des cookies du framework (ils sont globalement fiables) • Utiliser constamment SSL pour protéger les identifiants de connexion et de sessions • Vérifier l’implémentation • Oublier l’analyse automatique • Vérifier le certificat SSL (SSLv2, renégociation, chiffrement faible, …) • Examiner toutes les fonctions relatives a l’authentification • Vérifier que la déconnexion supprime bien la session ! • Utiliser l’OWASP WebScarab pour tester l’implémentation (sessionID analysis)
  • 33.
    A4 – Référencedirecte non sécurisée à un objet • C’est une manière de renforcer les habilitations en lien avec A7 – Mauvaise restriction d’accès à une URL Comment accéder aux données privées • Attendre uniquement de l’utilisateur des accès à des objets autorisés ou • Cacher des références à des objets dans des champs cachés • … et ne pas renforcer les restrictions coté serveur. • Ceci n’est qu’une tentative de contrôle d’accès sur la présentation et ne fonctionne pas ! • Un attaquant n’a qu’a modifier les valeurs des paramètres… Des erreurs classiques • Un utilisateur a accès à des données ou des fichiers normalement interdits Impact
  • 34.
    Référence directe nonsécurisée à un objet illustrée • L’attaquant note le paramètre acct = 6065 ?acct=6065 • Il modifie celui-ci de la manière suivante ?acct=6066 • L’attaquant visualise un autre compte. https://www.onlinebank.com/user?acct= 6065
  • 35.
    A4 – ContreMesure • Eliminer la référence directe. • La remplacer par une valeur temporaire aléatoire (e.g. 1, 2, 3) • L’ESAPI fournit des fonctions pour cela • IntegerAccessReferenceMap & RandomAccessReferenceMap • Valider la référence directe à l’objet • Vérifier que le contenu est correctement formaté. • Vérifier que l’utilisateur a le droit d’effctuer l’accès à l’objet. • Vérifier que le mode d’accès à l’objet est autorisé (e.g., read, write, delete) http://app?file=1 Report123.xls http://app?id=7d3J93 Acct:9182374http://app?id=9182374 http://app?file=Report123.xls Access Reference Map
  • 36.
    A5 – CrossSite Request Forgery (CSRF) • C’est une attaque ou le navigateur de la victime génère une requête vers une application Web vulnérable • Cette vulnérabilité est causée par la capacité que les navigateurs ont d’ envoyer automatiquement des données d’authentification (session ID, IP adresse, comptes de domaine windows, ..) dans chaque requête. Cross Site Request Forgery • Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne a votre place. • Que pourrait-il faire ? Imaginez • Initiation de transactions (transfert de fonds, logoff, modification de données, …) • Accès à des données sensibles • Changement des mots de passes/identifiants Impact
  • 37.
    CSRF démystifié • Leproblème • Les navigateurs Web incluent automatiquement la plupart des identifiants dans chaque requête. • Que cela soit des requêtes venant d’un formulaire, d’une image ou d’un autre site. • Tous les sites basés uniquement sur les identifiants automatiques sont vulnérables • Approximativement 100% des sites le sont… • C’est quoi un identifiant automatique? • Cookie de session • Une entête d’authentification HTTP • Une adresse IP • Les certificats SSL client • L’authentification de domaine Windows.
  • 38.
    CSRF illustré 3 2 L’attaquant poseson piège sur un site internet (ou via un e- mail)1 Tout en étant logguer sur le site vulnérable, la victime parcourt le site de l’attaquant. Le site vulnérable ne voit que des requêtes légitimes et effectue l’action demandée Le tag <img> tag chargé par le navigateur envoie une requête GET (contenant des identifiants sur le site vulnérable) Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus.Functions Un tag chaché <img> contient une attaque vers un site vulnérable Application vulnérable au CSRF
  • 39.
    A5 – ContreMesure • Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes sensibles. • Cela rend impossible pour l’attaquant de soumettre une requête valide. • (sauf si en plus il y a une faille XSS) • Ces jetons doivent être surs cryptographiquement. • Options • Stocker un seul jeton dans la session et l’ajouter a tous les formulaire et liens • Champ caché: <input name="token" value="687965fdfaew87agrde" type="hidden"/> • Utiliser un URL : /accounts/687965fdfaew87agrde • Utiliser un jeton de formulaire: /accounts?auth=687965fdfaew87agrde … • Attention a ne pas exposer le jeton dans l’entete “referer” • Utiliser de préférence un champ caché. • Utiliser un jeton unique par fonction. • Il est recommandé d’ajouter un second niveau d’authentification pour une transaction sensible • Ne pas laisser un attaquant stocker des attaques sur le site • Encoder proprement les données d’entrées • Cela permet de limiter la majorité des interpréteurs de liens Voir www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet pour plus de détails
  • 40.
    A6 – Mauvaiseconfiguration • On pense aux réseaux, aux systèmes et aux plateformes • Il ne faut pas oublier les environnements de développement Les applications Web doivent faire confiance à une fondation sécurisée • Pensez a tous les endroits ou l’on trouve votre code source. • La Sécurité ne doit pas se baser sur l’obscurité du code source. Est-ce que votre code source est secret? • Tous les identifiants doivent être changés sur les environnements de production Il faut étendre la gestion de la configuration a toutes les parties de l’application • Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…) • Failles XSS exploitées du à l’oubli de patch dans les frameworks • Accès non autorisé à des comptes , des données, ou des fonctionnalités applicatives par défaut non utilisées mais accessibles a cause d’une mauvaise configuration utilisateur Impact
  • 41.
    Hardened OS Web Server AppServer Framework Mauvaise configuration illustrée App Configuration Custom Code Accounts Finance Administration Transactions Communication KnowledgeMgmt E-Commerce Bus.Functions Test Servers QA Servers Source Control Development Database Insider
  • 42.
    A6 – ContreMesure • Vérifier la gestion de la configuration sécurité de vos systèmes. • Ayez des guidelines de renforcement de la sécurité. • L’automatisation est réellement utile dans ce cas • Couvrir toute la plateforme et l’application • Garder a l’esprit d’avoir des patchs pour TOUS les composants • Cela inclut les librairies, et pas seulement l’OS, les serveurs et applications. • Analyser l’impact sécurité des changements • Pouvez vous effectuer des “masters” de votre configuration applicative ? • Mettre en place un reporting des builds dans le processus sécurité • Si vous ne pouvez vérifier le configuration applicative, l’applicatif n’est pas sécurisé • Vérifier l’implémentation • Les scans découvrent généralement les configurations par défaut et les problèmes dus à des patchs de retard
  • 43.
    A7 – Mauvaiserestriction d’URL • Cela concerne aussi le renforcement des habilitations tout comme le paragraphe A4 Comment protégez vous l’accès à une URL ? • N’afficher que les liens et menus autorisés dans les listes de choix. • Une fois de plus, c’est du controle d’accès visuel, et cela ne fonctionne pas. • Il suffit de modifier les requêtes en allant diretement sur les pages “non autorisées” Une erreur commune… • Invocation de fonctions et de services non autorisées • Accès a des données ou des comptes n’appartenant pas à l’utilisateur • Élévation de privilèges et d’actions Impact
  • 44.
    Mauvaise restriction d’URLillustrée • L’attaquant note dans l’URL que le rôle est affiché /user/getAccounts • Il modifie directement l’URL (le rôle) /admin/getAccounts, ou /manager/getAccounts • L’attaquant dispose de privilèges supplémentaires https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts
  • 45.
    A7 – ContreMesure • Pour toute URL il faut 3 éléments : • Restreindre l’accès aux seuls utilisateurs authentifiés (sauf si l’URL est publique). • Renforcer les permissions basées sur les rôles ou l’utilisateue (si l’URL est privée) • Bloquer toute requête à des pages non autorisées ( (e.g., fichiers de config, de log, code source, etc.) • Vérifier l’architecture • Utiliser un modèle positif simple a tous les niveaux • S’assurer d’avoir un modèle d’accès à tous les niveaux. • Vérifier l’implémentation • Oublier l’approche automatisée • Vérifier que chaque URL de l’application est protégée par : • Un filtre externe, comme en J2EE (web.xml) • Ou par un morceau de VOTRE code – Voir la méthode ESAPI’ isAuthorizedForURL() • Vérifier que la configuration du serveur n’autorise pas les requêtes vers les types de fichiers ou extensions non autorisés. • Utiliser un proxy type WebScarab pour forger des requêtes non autorisées.
  • 46.
    A8 – Redirectionset transferts non contrôlés • Et fréquemment elles incluent des paramètres fournis par l’utilisateur dans l’URL de destination. • Si ces paramètres ne sont pas validés, un attaquant peut envoyer la victime vers le site de son choix. Les redirections sont communes dans une application WEB. • Ils renvoient la requête vers une nouvelle page en interne de l’application. • Parfois les paramètres déterminent la page cible. • Si cela n’est pas validé, cela permet de parfois passer outre les mécanismes d’autorisation et d’authentification. Les transferts(aka Transfer en .NET) sont eux aussi communs • Rediriger la victime vers un site malveillant de type hameconnage. • Il devient possible de passer outre les contrôles de sécurité et accéder à des fonctions ou données non autorisées. Impact
  • 47.
    Redirection illustrée 3 2 L’attaquant envoià la victime via un email ou une page Web de son choix le lien. From: Internal Revenue Service Subject: Your Unclaimed Tax Refund Our records show you have an unclaimed federal tax refund. Please click here to initiate your claim. 1 L’application redirige la victime vers le site de l’attaquant Request sent to vulnerable site, including attacker’s destination site as parameter. Redirect sends victim to attacker site Custom Code Accounts Finance Administration Transactions Communication KnowledgeMgmt E-Commerce Bus.Functions 4 Le site malveillant installe des éléments sur le navigateur ou récupére des données La vicitime clique sur le lien contenant une donnée non validée. Evil Site http://www.irs.gov/taxrefund/claim.jsp?year=2 006& … &dest=www.evilsite.com
  • 48.
    Unvalidated Forward Illustrated 2 L’attaquantenvoie sa charge sur une page vulnérable ou il a accès1 L’application autorise la requête et continue vers la page vulnérable Request sent to vulnerable page which user does have access to. Redirect sends user directly to private page, bypassing access control. 3 La page de transfert ne contrôle pas le paramètre et renvoie l’attaquant vers la page non autorisée, passant outre le contrôle d’accès. public void doPost( HttpServletRequest request, HttpServletResponse response) { try { String target = request.getParameter( "dest" ) ); ... request.getRequestDispatcher( target ).forward(request, response); } catch ( ... Filtre public void sensitiveMethod( HttpServletRequest request, HttpServletResponse response) { try { // Do sensitive stuff here. ... } catch ( ...
  • 49.
    A8 – ContreMesure • Il y a des tonnes de solutions 1. Eviter au maximum les redirections et les transferts 2. S’il faut absolument les intégrer, ne pas utiliser les paramètres parvenant d’un utilisateur pour définir l’URL/fonction cible. 3. Si vous “devez” utiliser les paramètres utilisateurs, a) Validez chaque paramètre pour vérifier qu’il est autorisé et valide par rapport à l’utilisateur, ou alors b) Utilisez une table de correspondance serveur entre les paramètres utilisateurs et les pages à appeler. • Pour les redirection, valider l’URL cible après la construction pour vérifier qu’elle redirige bien vers un site autorisé ! • L’ESAPI peut vous aider : • Voir : SecurityWrapperResponse.sendRedirect( URL ) • http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/ SecurityWrapperResponse.html#sendRedirect(java.lang.String) • Quelques réflexions sur les Transferts • Idéallement, il faudrait appeler le contrôle d’accès pour être sur que l’utilisateur est bien autorisé aà effecgtuer le transfert(très simple avec l’ESAPI…) • Si vous utilisez des filtres externes (comme SiteMinder), cela ne sera pas simple • La meilleure solution est de s’assurer que les utilisateurs qui ont accès à la page initiale ont TOUS le droit d’accéder à la page cible….
  • 50.
    A9 – StockageCryptographique non sécurisé • Oubli d’identification des données sensibles • Oubli d’identification de tous les entrepôts de stockage des données sensibles. • Bases de données, fichiers, répertoires, fichiers de logs, backup, … • Oubli de mettre en place une protection correcte des données dans tous les entrepots de stockages des données sensibles. Le stockage de données non sécurisées • Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …) • Extrait de données secretes via d’autres failles (injection SQL, LDAP, …) • Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la normale (forensics, lettres et dédommagements client, assurance, …) Impact
  • 51.
    Stockage non sécuriséillustré Custom Code Accounts Finance Administration Transactions Communicatio nKnowledge Mgmt E-Commerce Bus.Functions 1 La victime stocke son numéro de carte de crédit dans le système via un formulaire 2Le gestionnaire des erreurs loggue le numéro de carte car la passerelle de commerce est indisponible. 4 Une personne malveillante interne vole 4 millions de carte de crédit Fichier de log 3Les logs sont rendus disponibles pour tous les membres internes dans le but du debug
  • 52.
    A9 – ContreMesure • Vérifier l’architecture • Identifier toutes les données sensibles • Identifier tous les entrepots de stockage des données • S’assurer des attaques possibles sur comptes • Utiliser un mécanisme de chiffrement approprié • Chiffrement de fichier, de base, d’élément de la base. • Utiliser correctement le mécanisme… • Utiliser des algorithmes connus standard et surs. • Générer, distribuer et protéger les clefs • S’assurer de la capacité de changement régulier des clefs • Vérifier l’implémentation • Un algorithme sur est utilisé et c’est le bon algorithme pour la situation ! • Toutes les clefs, certificats, et mots de passe sont stockés et protégés correctement. • Il existe une distribution propre des clefs et il est possible d’en changer facilement
  • 53.
    A10 – Protectioninsuffisante lors du transport des données • Oubli de l’identification de TOUTES les données sensibles • Oubli de l’identification de TOUTES les URLs/Pages ou les données sensibles transitent. • Sur le Web, vers les SGBD, vers les partenaires métiers, vers les réseaux internes… • Oubli de protéger les données à chacun de ces endroits… La transmission de données non sécurisées… • Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …) • Extrait de données secretes via d’autres failles (injection SQL, LDAP, …) • Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la normale (forensics, lettres et dédommagements client, assurance) Impact
  • 54.
    Protection insuffisante lorsdu transport des données illustrée Custom Code Employées Partenaire métier Victime externe Backend Systems Attaquant externe 1 Vols de données via le réseau externe 2 Vol de données via le réseau interne Attaquant interne
  • 55.
    A10 – ContreMesure • Utiliser les mécanismes de protection appropriés • Utiliser TLS pour tout transport de données sensibles. • Chiffrer les messages avant transmission. • E.g., XML-Encryption • Signer les messages avant transmission • E.g., XML-Signature • Utiliser les mécanismes correctement ! • Utiliser des algorithmes surs ! (désactiver les vieilles versions de SSL et les chiffrements faibles…) • Gérer correctement les clefs/certificats. • Vérifier les certificats SSL avant l’utilisation. • Voir http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet pour plus de details
  • 56.
    En résumé :comment adresser ces risques • Développer du code sécurisé ! • Suivre les bonnes pratiques du Guide OWASP sur la construction sécurisée d’une application Web. • http://www.owasp.org/index.php/Guide • Utiliser l’OWASP Application Security Verification Standard comme un guide permettant de définir les mécanismes de sécurité • http://www.owasp.org/index.php/ASVS • Utiliser les composants de sécurité standard et s’adaptant le mieux a votre entreprise • Par exemple utiliser l’OWASP ESAPI comme une fondation a VOS composants standards • http://www.owasp.org/index.php/ESAPI • Auditer les applications • Faire appel a une équipe expérimentée pour analyser et auditer l’application. • Auditer les applications vous-meme graçe aux guide de l’OWASP • OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide • OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide
  • 57.
  • 58.
    Minimisation des risques potentiels Fonctions de programmation Auditapplicatif Equipements de sécurité Sécurisation des applications
  • 59.
    Exemple : fonctionsPHP utiles addslashes() : addslashes($ch) échappe les caractères " et ' en les faisant précéder d'un antislash . (évitez le SQL injection et XSS) mysql_real_escape_string: Protège les caractères spéciaux d'une commande SQL (évitez le SQL injection). ereg : La fonction ereg applique une expression régulière sur une chaîne par exemple pour valider une numéro de carte d’identité : ereg("^[0- 9]{8}$", @$num). (évitez le SQL injection et XSS)
  • 60.
    safe_mode=On Option de phpqui permet de sécuriser le système , afin d'éviter les interactions entre php et le système. En cas d'activation , php n'autorisera pas les exécutions de programmes externe , ou l'acces à des fichiers d'autres utilisateurs. display_errors = Off Cette directive détermine si les erreurs doivent être affichées à l'écran ou non. log_errors = On: activer le log des erreurs. register_globals = Off-> désactiver les variables globales. magic_quotes_gpc = Off Paramètre qui filtre les paramètres HTTP GET et POST et ajoute des / devant les apostrophes guillemets et caractère null. disable_functions= exec, system, popen, proc_open, passthru,fsockopen, ftp_connect, ftp_ssl_connect,dl_open : désactiver les fonctions dangereux. allow_url_fopen = Off -> éviter le file include file_uploads = Off ->désactiver l'upload de fichiers via HTTP Remarque: si la configuration est établie plusieurs applications génèrent des erreurs comme Joomla,PHPBB,PHPNUKE,phpbb etc…essayer de faire modifier les Configuration de php.ini
  • 61.
  • 62.
    Hardening  Hardning dusystème d’exploitation.(voir le guide dans la site officielle)  Hardning du serveur web(exemple voir guide hardening apache).  Hardning du serveur base des données(exemple voir guide hardening mysql).
  • 63.
    Installation des outilsqui renforce la sécurité  Un web firewall applicatif (exemple voir guide de mod security).  Database firewall (exemple green sql).  urlScan:est un outil de sécurité Microsoft qui limite les types de requêtes HTTP traitées par Internet Information Services (IIS). IIS lockdown :est un outil qui permet d’assurer un plus haut niveau de sécurité en désactivant les options inutilisées d’IIS (Internet Information Services). Et contient l’outi urlscan lien : http://www.laboratoire-microsoft.org/d/?id=11151
  • 64.
    Côté « application» 1) Sécurisation de la plateforme d’hébergement:  Mise à jour et hardening du serveur.  Détection d’intrusion réseau.  Détection d’intrusion au niveau de l’hôte (HIDS).  Détection antivirale  Filtrage applicatif
  • 65.
    Côté « application» 2) Suivi et audit des logs enregistrés au niveau de la plateforme de connexion :  log d’administration,  log d’accès public,
  • 66.
    Côté « application» 3. Sauvegarde des données sensible :  Applicatif,  base de données,
  • 67.
    Côté « application» 4) Validation de l’application:  Aprés insertion ou ajout de nouveaux services, …par une tierce entité .  Audit de l’application avant sa mise en ligne :  au niveau de cette phase toute la documentation relative à l’application doit être demandé (Conception, Structure, architecture)
  • 68.
    Côté « application» 5) Audit régulier de la sécurité :  de l’application,  du serveur web,
  • 69.
    Côté « application» 6) Notification immédiate de tout type d’incident touchant l’application web:  Pour déclarer des incidents, vous pouvez utiliser l'un des moyens suivants : - Via Email: envoyer nous un e-mail (sécurisé) à l'adresse suivante: incident@ansi.tn - Par Téléphone : (+216) 71 843 200 ou bien (+216) 71 846 020 et demandez le poste 119 (pour le recueil des déclarations) - Par Fax: (+216) 71 846 363
  • 70.
    Côté « application» 7) Mettre en place un plan de continuité de service:  via la virtualisation.  Ou autre solution.
  • 71.
    MERCI POUR VOTRE ATTENTION NabilHOSNI Nabil.hosni@ansi.tn (00216)94 675 101