Prezi

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in the manual

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

OWASP - Développement d’une application 100% sécurisée

No description
by Eric Chartre on 19 February 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of OWASP - Développement d’une application 100% sécurisée

Orientations
Identification unique pour la durée de l'interaction de l'utilisateur
Élaborer une architecture la plus légère possible, peu coûteuse, flexible, extensible : efficiente
Arriver rapidement à une solution faisable, viable et fiable
Avoir une sécurité omnipotente et une journalisation omniprésente
Haute disponibilité
Respect des normes Web
Contraintes reliées aux aspects et à une pile HTTP pure (RESTful)
Architecture client-serveur
Sans état
Interface uniforme
Encapsulation sous la forme de ressources
Identification forte des ressources : URL normalisée
Manipulation des ressources par des représentations
L'utilisateur peut être humain ou machine
Actions sur une ressource limitées à L-CRUD (ou BREAD) selon la norme HTTP (GPPD)
Rappel des exigences élémentaires en sécurité
Identification/authentification
Confidentialité
Intégrité
Irrévocabilité/non-répudiation
Preuve de livraison/piste de vérification
Disponibilité
Administration et surveillance
GET /world/earth?hello HTTP/1.1
Host: www.example.com
Requête
HTTP/1.1 200 OK
Date: Wed, 20 Jun 2012 23:38:34 GMT
Server: Apache/2.4.0.1 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 20 Jun 2012 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Content-Length: 642
Connection: close
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Hello World!</title>
</head>
<body>
<p>Hello <a href="http://www.example.com/world/earth">World!</a></p>
</body>
</html>
Réponse
L : List / Browse
C : Create / Add
R : Read / Retrieve
U : Update / Edit / Modify
D : Delete / Destroy
Opérations de base de
persistance de donnée
Avoir une sécurité applicative la plus étanche possible qui peut prévenir la plupart des erreurs courantes de programmation
Développement d’une application 100% sécurisée : étanchéité par le pipeline Web et le cadre d’application
Eric Chartré
19 février 2014
La sécurité est une histoire de détails.
Le diable est dans les détails.
La sécurité est donc le mal.
Pourquoi est-il nécessaire [essentiel] de faire de la sécurité :
Parce que les gens sont malhonnêtes
Pour éviter la perte de données [critiques]
Parce que toute vérité n'est pas nécessairement bonne à dire
Objectif ultime : Sécuriser toutes les couches OSI pertinentes
7. Application : HTTP
6. Présentation : MIME
5. Session : SSL/TLS
4. Transport : TCP
3. Réseau : IP
2. Liaison : Virtualisation des réseaux
1. Physique : Locaux, fils, appareils
1- Sécuriser physiquement et virtuellement (logiciel) l'infrastructure technologique
Accès physique = accès complet
Ne jamais utiliser de plate-forme fermée même si elle est supposément sécuritaire
Ne jamais faire de sécurité par l'obscurité
2- Sécuriser le maître des clés
Recette :
Selon le principe de Kerckhoff (écrit en 1883) :
Seule la clé utilisée pour sécurisé le message doit être tenue secrète.
Un corollaire de ce principe est que moins un système possède de secrets, plus il est sécuritaire. Si la perte de n’importe quel secret (comme la divulgation d’un algorithme ou d'un type d'équipement) met le système en péril, alors un système avec peu de secrets est un système plus sécuritaire. Plus un système possède de secrets, plus il est susceptible d’être percé. Ainsi, une architecture, un algorithme ou un protocole qui doivent demeurer secret, font en sorte que cette architecture, algorithme ou protocole font maintenant partie de la clé et que celle-ci est d’autant plus difficile à protéger. La sécurité est donc plus « fragile ».

L'énoncé qui stipule que de publier des détails de systèmes faciliterait le travail de pirates potentiels n’est donc généralement pas valable puisqu’un système bien conçu a normalement peu de secrets. Il y a toujours une façon de limiter le nombre de secrets dans un système donné.

Néanmoins, la relation entre la sécurité et la protection du secret peut être plus compli-quée que ce que le principe de Kerckhoff peut sous-entendre. En effet, jamais l'auteur du principe ne dit qu’il faut tout publier sauf la clé. Il ne fait qu’énoncer qu’il faut garder la protection du secret indépendante de la sécurité.

Ainsi, ce n’est pas parce que la sécurité ne demande pas qu’une information soit tenue secrète qu’il faut nécessairement la publier. Deux questions déterminent la publication ou non d’une information : y a-t-il une valeur ajoutée à publier des détails de systèmes, par exemple dans un but de validation par des pairs ? Le fait de publier un détail occasionne-t-il des « effets de bord » qui ont à voir avec la sécurité mais pas avec celle du système ?

Un bon exemple pour illustrer la première caractéristique est un algorithme de cryptographie. En le soumettant à des analyses par des pairs, l’algorithme aura beaucoup plus de crédibilité. Si l’algorithme est solide, aucun système ne sera mis en péril en publiant cet algorithme.

La deuxième caractéristique peut être illustrée de la façon suivante : le fait de publier les algorithmes de calculs des contrats d’assurance vie ne met pas en péril les systèmes informatiques mais peut favoriser la création de contrats avec des données frauduleuses.
Avoir un portable Linux avec OpenSSL qui n'a jamais été et ne sera jamais branché à un réseau
Utiliser une clé USB ou un papier/crayon pour transférer des clés (!)
Mettre ce portable dans un coffre-fort
TEMPEST? Keyloggers?
Ne pas utiliser d'autorité de certification?
Exiger et forcer l'utilisation de TLS 1.1 ou plus : SSL est
mort
Configurer les serveurs Web et OpenSSL correctement
3- Utiliser une pile applicative ouverte GRAM
Linux ou, encore mieux, OpenBSD
Apache ou Nginx
Toujours à jour


Le reste n'est pas important...
En autant qu'il n'y ait aucune porte d'entrée autre que celle prévue et
que le périmètre soit étroitement et constamment surveillé.
4- Développer avec le GBS
a) Appliquer des règles fonctionnelles de base
Ne jamais enfarger l'utilisateur avec des règles de sécurité stupides qui manquent d'imagination
b) Faire systématiquement du whitelisting
c) Throttling? Traffic shaping?
Le blacklisting, c'est mauvais et ça n'apporte qu'un faux sentiment de sécurité.
Comment ?
Programmation et infrastructure orientée aspect
Programmation par contraintes architecturales
GET/HEAD (sans id) : List
POST (toujours sans id) : Create
GET/HEAD (avec id) : Retrieve
PUT (avec id) : Update
DELETE (avec id) : Delete
Méthodes HTTP
Pare-feu plein état + IPS/IDS + throttling TCP (OSI 3, 4)
Encapsulation SSL/TLS (OSI 5) + accélérateur (?)
Filtre MIME et HTTP (WAF) (OSI 6, 7)

Autorisation (et identification)
Vérification d'un jeton (SWT?, JWT?, Kerberos?) ou d'un certificat client ($$$)
Sécurité sur le type de ressource et l'action
HTTP-RBAC, privilèges-RBAC
Autorisation sur les occurrences qui peut aller jusqu'aux actions sur des occurrences précises (ABAC, éviter XACML)
Routage/mappage HTTP -> implique un contrôleur/routeur dans un contexte MVC
Filtre antiviral/anti logiciels malveillants
Journalisation W3C évoluée
Filtres de sécurité
Antémémoire (cache)
Compression HTTP, HTML, JavaScript, CSS
Compression et conversion d'images
Gestion des exceptions
Autres filtres technologiques
Périmètre de sécurité physique (OSI 1)
Périmètre de sécurité virtuel (OSI 2)
IPS/IDS (OSI 3 et 4)

Conservation (copie de sauvegarde et archivage)
Audits de sécurité (technologique et applicatif)
EMR
Surveillance passive et active
Autres mesures de protection
Canal :
Id ressource :
Action :
Représentation (format) :
Passage du contexte de sécurité :
TLS v1.1+
URL
Méthode HTTP
Entête HTTP (Accept*)

Entête HTTP (jeton SWT, JWT, Kerberos) ou TLS v1.1+ (certificat client)
Écueils à éviter
Optimiser trop tôt
Faire de la sécurité par l'obscurité
Ne pas se soucier de l'utilisateur
Ne pas être sensible aux règles d'accessibilité et d'utilisabilité
Développer et déployer n'importe comment, sans contrôle
Présumer que les utilisateurs internes sont :
responsables,
non imputables,
bienveillants,
bien intentionnés.
Ne pas suivre les bonnes pratiques
Ne pas tenir compte des vulnérabilités OWASP
Expiration de session inopinée qui brise le scénario transactionnel
Expiration de mots de passe
Bloquage du compte après un certain nombre d'accès réussi ou non
Exemples :
Cadre, norme et règles de développement?
Whitelisting?
Environnement de développement flexible?
Outils de développement performants
Cadre d'application adapté
Modules communs, en particulier les filtres de sécurité
Intégration continue
Dénominalisation, dépersonnalisation, anonymisation
Niveaux de virtualisation variables
Débogage distant
Journaux d'erreurs techniques accessibles
Journal applicatif Web accessible
Environnement d'essais multinavigateur
Méthodologie Lean et Agile?
TDD?
Revue de code?
Équilibrage de charge
Redondance
Relève
HTTP
Multinavigateur Web
HTML, CSS, JavaScript, etc.
Merci!
Références
OWASP
https://www.owasp.org/index.php/Main_Page

Architectural Styles and the Design of Network-based Software Architectures
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

HTTP 1.1
http://www.w3.org/Protocols/rfc2616/rfc2616.html

Simple Web Token et JSON Web Token
http://msdn.microsoft.com/en-us/library/windowsazure/hh781551.aspx
http://openid.net/specs/draft-jones-json-web-token-07.html
Un peu d'autopromotion...
Eric Chartré
Spécialiste technique en architecture Web
TELUS Communications inc.
1000° inc.
eric.chartre@telus.com
eric.chartre@1000deg.com
id est
: en autant que la sécurité soit sortie des applications.
(non illustré)
Résultat
Application étanche
Avez-vous une GCVA mature?
See the full transcript