Formation Sécurité du Développement web en Java sur Niort

AppSecFR vous propose une formation de 2J sur le sujet de la Sécurité du Développement Web en Java

Cette formation aura lieu sur NIORT (79) sur 2 dates :

  • 1 et 2 Octobre 2018
  • 19 et 20 Novembre 2018

Le contenu de la formation vous permettra de prendre en compte les problématiques de sécurité de Java et d’appliquer les bonnes pratiques dans le cadre d’exercices proche des technologies que vous pouvez utiliser.

Cette formation entre dans le cadre de l’obligation PCI-DSS 6.5 

A l’issu de la formation, le stagiaire recevra

  • Le certificat de formation AppSecFR(r) Secure DevWeb Java niveau 1
  • Une feuille des contrôles de sécurité à effectuer sur son application Web.
  • Goodies 🙂

Le nombre de place est limité à 12 personnes par session.

 

Pour s’inscrire deux solutions :

 

Nous pouvons aussi réaliser la formation sur 3J en intra-entreprise au besoin sur d’autres dates. Nous contacter pour plus d’informations

 

 

Victime d’une cyber-Malveillance ?

Hier, le GIP ACYMA a ouvert sur l’ensemble de la France l’accès au portail https://www.cybermalveillance.gouv.fr/.

Ce portail se veut un point de contact unique entre les victimes et les entreprises pouvant les aider. Différentes catégories de prestataires existent :

– Prestataire a destination des entreprises
– Prestataire a destination des administrations
– Prestataire à destination des particuliers

Aujourd’hui lorsque vous êtes une cybervictime, la procédure n’est pas claire, vous ne savez pas si vous devez aller à la gendarmerie, la police, voir un avocat, …. ACYMA se veut simplifier tout cela

Les buts sont :
– pouvoir donner des points de contacts validés par les autorités aux victimes
– simplifier éventuellement la démarche
– décharger les autorités de police et de gendarmerie qui ont d’autres taches plus prioritaires
– permettre la remontée des informations à destination des autorités (ANSSI, ….).

Le processus ne se veut pas un remplacement de la procédure judiciaire, mais les contacts avec les prestataires référencés permet de mieux s’y retrouver, voir de pouvoir résoudre votre probleme (dans le cadre d’une prestation de service du prestataire)

AppSecFR(r) est membre  dans la liste des partenaires à destination des entreprises et administrations.

Notre périmètre d’intervention est :
– Investigation judiciaire ou et privée
– Analyse des défaillances et plans de remédiation
– Assistance à la constitution des preuves légales
– Audit de sécurité organisationnel et technique
– Sécurisation des sites Web.

 

N’hésitez pas à nous contacter

La sécurité Web, vue via les entêtes du navigateur – Episode 2 – L’entete X-Content-Type-Options

Suite des épisodes sur les entêtes intéressantes à rajouter à vos applications, Web. Aujourd’hui nous allons parler de X-Content-Type-Options

Toute page envoyée depuis un serveur vers un client Web, doit convertir ses données dans le bon type MIME. Ce type MIME est normalement associé à une entête technique nommée content-type décrivant le type de données renvoyées (image, script, …).

Dans Internet Explorer et aussi dans Chrome , il existe une fonctionnalité permettant d’effectuer du « changement  de type MIME à la volée ». Cette fonctionnalité permet au navigateur d’effectuer un changement de type, en fonction du contenu, sans pour autant s’en tenir à ce que renvoie le serveur dans l’entête « content-type ».  Cette fonctionnalité semble avoir été ajoutée pour des raisons très obscures du a des « serveurs renvoyant des types de contenu text/plain contenant du HTML… ».

Cette fonctionnalité, bien que très pratique pour le rendu visuel, peut dans certains cas conduire à des problématiques de sécurité.

Si je dispose d’un élément HTML de ce type

http://«.

et si le contenu du fichiermonimage.js n’est pas du code JavaScript, alors dans le cas ou l’entête est positionnée à  la valeur suivante : X-Content-Type-Options: nosniff, le navigateur n’effectuera pas une tentative de changement d’interprétation du contenu et ne chargera pas le moteur d’interprétation JavaScript. Il passera à l’élément HTML suivant.

Contrôle de la mise en place de l’entête

  • Dans le cas ou vous  utilisez un outil tel que OWASP Zap vous aurez une remontée de l’oubli de cet entête lors de vos analyses

Implémentation de l’entête :

Plusieurs solutions sont possibles.

Vous disposez du module mod_headers d’apache, il suffit d’ajouter les lignes suivantes :

<IfModule mod_headers.c> 
Header set X-Content-Type-Options nosniff 
</IfModule>

Vous n’avez pas ce module, ou vous souhaitez le « coder » : En java :

response.addHeader("X-Content-Type-Options", "nosniff");

En PHP :

<?php header(‘X-Content-Type-Options : nosniff’); ?>

En C#

HttpResponse.AddHeader(« X-Content-Type-Options », « nosniff »);

 

 

La sécurité Web, vue via les entêtes du navigateur – Episode 1 – Le Content-Security Policy

Pour lutter contre l’insécurité du Web il est répété régulièrement de ne pas faire confiance au contenu venant des navigateurs. Mais il n’est jamais dit que le navigateur ne peut être d’une certaine utilité dans cette lutte.

Dans cette lutte implacable, Madame Michu dispose d’un navigateur qu’elle a téléchargée sur Internet, ou qui lui a été livré avec son ordinateur PC ou Mac (il est loin le temps des Kit FAI avec le navigateur moisi fourni).

Récemment(tout est relatif, car cela bouge pas mal)  un certain nombre de fonctionnalités sont apparues (sous forme de draft/RFC IETF ) permettant d’améliorer la sécurité globale dans un monde Web.

Voici donc quelques une de ces fonctionnalités que vous allez pouvoir utiliser pour « aider » le navigateur et la sécurité de votre application Web :

Ce billet parle du Content Security Policy. Pas que les autres ne sont pas intéressants, mais nous les traiterons par ailleurs chacun.

Donc le CSP, avant de l’utiliser il est bon de savoir si il est possible de l’utiliser dans son navigateur. Pour cela vous pouvez vous retourner vers le superbe site anglais CanIUse.com qui vous indiquera si votre navigateur est compatible ou pas avec la directive.

Content Security Policy 

Il existe plusieurs versions (en fait 2) du CSP, la v2.0 étant très peu supportée actuellement

Actuellement les navigateurs ont tous un niveau de support plutôt différent (IE est encore une fois a la traine), comme on peut le voir sur le graphique suivant pour la V1.0:

NewImage

Le principe du CSP est de donner  le contrôle sur le contenu dit « sur ». En effet aujourd’hui il existe peu de sites Web qui contiennent tout le code à exécuter et les exécutions de JavaScript ne sont la plupart du temps uniquement possible que via le site d’ou provient le .JS. Cela peut poser des problèmes via AJAX car il est possible d’avoir besoin de contenu se trouvant sur un autre site Web. Dans ce cas il est nécessaire de pouvoir limiter le téléchargement, voir l’exécution du code en fonction de ce que souhaite le développeur. Cela permettra de limiter les attaques de type XSS, et autres joyeusetés que nous pourrions avoir dans le site Web.

Le site http://content-security-policy.com résume bien tout ce qu’il est possible d’utiliser.

D’un point de vue très simple nous pourrions dire qu’il y en a 3 d’importants :

  • default-src : tous les contenus peuvent venir de cette zone
  • script-src : les Javascripts ne peuvent venir que de cette zone
  • img-src : Les images elles sont ici.

Il suffit alors de spécifier la ligne suivante pour donner une politique de contenu au navigateur

Content-Security-Policy: default-src 'self'; img-src img.example.com; script-src api.example.com

Dans ce cas, cela veut donc dire :

  • Les images ne sont possibles que depuis img.example.com
  • Les scripts depuis api.example.com