SlideShare une entreprise Scribd logo
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

Tendances

Webinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme ThéméeWebinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme Thémée
Marie Tapia
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le webSofteam agency
 
Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Asma Messaoudi
 
Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2
Cyrille Grandval
 
Architecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependancesArchitecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependances
ENSET, Université Hassan II Casablanca
 
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeConférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeNormandie Web Xperts
 
Sécurité des web services soap
Sécurité des web services soapSécurité des web services soap
Sécurité des web services soap
Zakaria SMAHI
 
Sécurité des réseaux
Sécurité des réseauxSécurité des réseaux
Sécurité des réseaux
Sehla Loussaief Zayen
 
Les principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesLes principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuelles
Bee_Ware
 
White paper - La sécurisation des web services
White paper - La sécurisation des web servicesWhite paper - La sécurisation des web services
White paper - La sécurisation des web servicesBee_Ware
 
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
ENSET, Université Hassan II Casablanca
 
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
Microsoft Décideurs IT
 
OpenSSO Aquarium Paris
OpenSSO Aquarium ParisOpenSSO Aquarium Paris
OpenSSO Aquarium Paris
Alexis Moussine-Pouchkine
 
Partie III – APM Application Policy Manager
Partie III – APM Application Policy ManagerPartie III – APM Application Policy Manager
Partie III – APM Application Policy Manager
e-Xpert Solutions SA
 

Tendances (14)

Webinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme ThéméeWebinaire : sécurité informatique sur le web - Jérôme Thémée
Webinaire : sécurité informatique sur le web - Jérôme Thémée
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le web
 
Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02
 
Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2
 
Architecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependancesArchitecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependances
 
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeConférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
 
Sécurité des web services soap
Sécurité des web services soapSécurité des web services soap
Sécurité des web services soap
 
Sécurité des réseaux
Sécurité des réseauxSécurité des réseaux
Sécurité des réseaux
 
Les principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesLes principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuelles
 
White paper - La sécurisation des web services
White paper - La sécurisation des web servicesWhite paper - La sécurisation des web services
White paper - La sécurisation des web services
 
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
 
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
(Azure) Active Directory + BYOD = tranquillité d’esprit, chiche ! (2nde Partie)
 
OpenSSO Aquarium Paris
OpenSSO Aquarium ParisOpenSSO Aquarium Paris
OpenSSO Aquarium Paris
 
Partie III – APM Application Policy Manager
Partie III – APM Application Policy ManagerPartie III – APM Application Policy Manager
Partie III – APM Application Policy Manager
 

Similaire à Securite web is_ima

Owasp top 10 2010 Resist toulouse
Owasp top 10   2010  Resist toulouseOwasp top 10   2010  Resist toulouse
Owasp top 10 2010 Resist toulouseSébastien GIORIA
 
20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif
LeClubQualiteLogicielle
 
Lutter contre les attaques ciblées avec quelques mesures simples et efficaces
Lutter contre les attaques ciblées avec quelques mesures simples et efficacesLutter contre les attaques ciblées avec quelques mesures simples et efficaces
Lutter contre les attaques ciblées avec quelques mesures simples et efficaces
Microsoft
 
Securité des applications web
Securité des applications webSecurité des applications web
Securité des applications web
Marcel TCHOULEGHEU
 
Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !
Microsoft Décideurs IT
 
Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !
Microsoft Technet France
 
Vulnérabilité des sites web
Vulnérabilité des sites webVulnérabilité des sites web
Vulnérabilité des sites web
Said Sadik
 
Sécurité des Applications WEB -LEVEL1
 Sécurité des Applications WEB-LEVEL1 Sécurité des Applications WEB-LEVEL1
Sécurité des Applications WEB -LEVEL1Tarek MOHAMED
 
Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]
Wixiweb
 
On a volé les clefs de mon SI !
On a volé les clefs de mon SI !On a volé les clefs de mon SI !
On a volé les clefs de mon SI !
Microsoft Technet France
 
Le Darwinisme Digital
Le Darwinisme DigitalLe Darwinisme Digital
Le Darwinisme Digital
NBS System
 
Epitech securite-2012.key
Epitech securite-2012.keyEpitech securite-2012.key
Epitech securite-2012.key
Damien Seguy
 
Sécurisation d'un site internet
Sécurisation d'un site internetSécurisation d'un site internet
Sécurisation d'un site internetwaggaland
 
Les menaces applicatives
Les menaces applicativesLes menaces applicatives
Les menaces applicatives
Bee_Ware
 
La Sécurité Sur Le Web
La Sécurité Sur Le WebLa Sécurité Sur Le Web
La Sécurité Sur Le Web
Groupe Revolution 9
 
Tuto atelier securisation_site_web
Tuto atelier securisation_site_webTuto atelier securisation_site_web
Tuto atelier securisation_site_web
sahar dridi
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdf
depinfo
 
ASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas Grégoire
ASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas GrégoireASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas Grégoire
ASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas Grégoire
Cyber Security Alliance
 
Starc by Exaprobe
Starc by ExaprobeStarc by Exaprobe
Starc by Exaprobe
Exaprobe
 

Similaire à Securite web is_ima (20)

Owasp top 10 2010 Resist toulouse
Owasp top 10   2010  Resist toulouseOwasp top 10   2010  Resist toulouse
Owasp top 10 2010 Resist toulouse
 
20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif20090929 04 - Securité applicative, hacking et risque applicatif
20090929 04 - Securité applicative, hacking et risque applicatif
 
Lutter contre les attaques ciblées avec quelques mesures simples et efficaces
Lutter contre les attaques ciblées avec quelques mesures simples et efficacesLutter contre les attaques ciblées avec quelques mesures simples et efficaces
Lutter contre les attaques ciblées avec quelques mesures simples et efficaces
 
Securité des applications web
Securité des applications webSecurité des applications web
Securité des applications web
 
Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !
 
Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !
 
Vulnérabilité des sites web
Vulnérabilité des sites webVulnérabilité des sites web
Vulnérabilité des sites web
 
Sécurité des Applications WEB -LEVEL1
 Sécurité des Applications WEB-LEVEL1 Sécurité des Applications WEB-LEVEL1
Sécurité des Applications WEB -LEVEL1
 
Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]Introduction à la sécurité des applications web avec php [fr]
Introduction à la sécurité des applications web avec php [fr]
 
On a volé les clefs de mon SI !
On a volé les clefs de mon SI !On a volé les clefs de mon SI !
On a volé les clefs de mon SI !
 
Le Darwinisme Digital
Le Darwinisme DigitalLe Darwinisme Digital
Le Darwinisme Digital
 
Epitech securite-2012.key
Epitech securite-2012.keyEpitech securite-2012.key
Epitech securite-2012.key
 
Sécurisation d'un site internet
Sécurisation d'un site internetSécurisation d'un site internet
Sécurisation d'un site internet
 
Les menaces applicatives
Les menaces applicativesLes menaces applicatives
Les menaces applicatives
 
La Sécurité Sur Le Web
La Sécurité Sur Le WebLa Sécurité Sur Le Web
La Sécurité Sur Le Web
 
Tuto atelier securisation_site_web
Tuto atelier securisation_site_webTuto atelier securisation_site_web
Tuto atelier securisation_site_web
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdf
 
ASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas Grégoire
ASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas GrégoireASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas Grégoire
ASFWS 2013 - Optimiser ses attaques Web avec Burp par Nicolas Grégoire
 
Starc by Exaprobe
Starc by ExaprobeStarc by Exaprobe
Starc by Exaprobe
 
1 introduction secu
1  introduction secu1  introduction secu
1 introduction secu
 

Securite web is_ima

  • 1. 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
  • 4. 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
  • 8. 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. 9 Aujourd’hui Impacts: Vol des informations confidentielles, Prise de contrôle du système, Déni de service, … 0 Km
  • 10. 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. 11 IMPACTS DE LA GUERRE NUMÉRIQUE : 2016 0 Km
  • 13. CONSTAT SUR LE HACHING
  • 14. 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)
  • 18. QUELLE EST LA DIRECTION? 18
  • 19. 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.
  • 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’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:
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. (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
  • 30. 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
  • 31. 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
  • 32. 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)
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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.
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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.
  • 46. 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
  • 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’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 ( ...
  • 49. 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….
  • 50. 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
  • 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 – 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
  • 53. 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
  • 54. 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
  • 55. 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
  • 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
  • 58. Minimisation des risques potentiels Fonctions de programmation Audit applicatif Equipements de sécurité Sécurisation des applications
  • 59. 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)
  • 60. 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
  • 62. 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).
  • 63. 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
  • 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 Nabil HOSNI Nabil.hosni@ansi.tn (00216)94 675 101