Publié par

Il y a 9 ans -

Temps de lecture 16 minutes

Introduction à la sécurisation des applications web

La sécurisation des sites web est un sujet important dès lors que l’application que vous développez contient des données un tant soit peu sensibles, ayant trait à la vie privée, à des données bancaires ou encore à des données stratégiques (d’entreprise, gouvernementales, militaires …).

Le but de cet article est de sensibiliser les développeurs aux notions de sécurité des applications web. L’idée n’est pas de faire de vous des experts de la sécurité (le sujet est, comme vous vous en doutez probablement, plutôt vaste) mais de vous donner les bases qui vous permettront d’appréhender les principales problématiques de la sécurité informatique, et plus particulièrement de la sécurité des applications Web. Cet article n’a donc pas vocation à être un état de l’art des techniques de cryptographie et de sécurité informatique, mais d’en introduire les concepts.

Lorsque nous travaillons sur la sécurisation d’une application, nous nous attachons principalement aux aspects suivant :

  • l’authentification,
  • les autorisations,
  • l’intégrité,
  • la confidentialité,
  • l’identité,
  • la non répudiation.

Nous allons traiter dans la suite de cet article ces différents principes, en essayant de rester simple et pragmatique.

Principes de la cryptographie

Avant d’entrer dans le vif du sujet, je vous propose un petit rappel des principaux principes de la cryptographie.

Les fonctions de hachage

Ces fonctions permettent de calculer une empreinte (appelée aussi hash) d’une donnée informatique. Les fonctions de hachage implémentent quelques propriétés que nous allons définir maintenant :

  • le grand nombre d’empreintes possibles (entre 2^128 à 2^256 bits) implique une probabilité extrêmement faible de collisions,
  • la taille de l’empreinte est fixe, quelle que soit la taille de la donnée hachée. L’empreinte d’un mot de passe de huit caractères aura donc la même taille que l’empreinte d’un fichier de plusieurs centaines de Mo,
  • un changement infime dans la donnée hachée entraîne un changement important dans l’empreinte correspondante (ce qui rend une recherche inverse par dichotomie impossible),
  • le calcul d’une empreinte est très rapide (pratique pour le calcul de sommes de contrôle de fichiers de plusieurs centaines de Mo),
  • il n’est pas possible, en connaissant l’empreinte et la fonction de hachage utilisée, de calculer la donnée d’origine.

Ces fonctions sont généralement utilisées pour les besoins suivant :

  • vérification de l’intégrité d’une donnée : dans ce cas, le hash (généralement appelée somme de contrôle ou checksum) est utilisé pour s’assurer qu’une donnée informatique n’a pas été corrompue,
  • stockage des mots de passes : le hachage du mot de passe permet d’éviter que ce dernier soit stocké en clair. Nous reviendrons sur ce cas d’utilisation dans la suite de cet article,
  • la construction de jetons : comme les jetons remember me.

Il existe différents algorithmes de hachage :

  • MD5 (Message Digest 5) : probablement le plus connu, il est souvent utilisé pour les sommes de contrôle ou le stockage de mot de passes (notamment dans sa version salée dans diverses distributions Linux). Son empreinte est représentée sur 128 bits. Actuellement, le MD5 est mis de côté au profit des algorithmes SHA1 et SHA256 réputés plus sûrs.
  • SHA1 (Secure Hash Algorithm) : cette fonction de hachage crée des empreintes sur 160 bits. Cet algorithme est lui aussi progressivement remplacé par le SHA256, beaucoup moins facile a casser grâce à son empreinte sur 256 bits.

Le cassage d’un mot de passe haché ne peut se faire que par brute force (si l’on a beaucoup de puissance de calcul et de temps), par dictionnaire (on parcourt successivement les mots de passe les plus courants), en utilisant des dictionnaires inversés qui permettent de retrouver le mot de passe à partir du hash ou encore plus efficacement par l’utilisation de Rainbow Tables.
Cette dernière technique reste la plus efficace pour retrouver un mot de passe faible, à condition d’avoir accès au hash d’origine. On peut l’imaginer comme une grosse HashMap dont la clé serait l’empreinte et la valeur la donnée d’origine. Les mots de passe les plus simples ont donc de grandes chances de s’y retrouver.

Le salage du hash est une technique efficace permettant de se prémunir des attaques par dictionnaire inversé. Cette technique consiste à ajouter à la donnée à hacher un sel, qui peut être une valeur arbitraire, et qui rendra donc les attaques par dictionnaire inversé inefficaces :
empreinte = hachage(mot_de_passe + sel)
Il n’est pas nécessaire que le sel soit une information secrète, son utilité étant de rendre les dictionnaires inversés inefficaces.

Les commandes unix md5pass et sha1pass permettent de générer des mots de passes salés :

% sha1pass password dupont@example.com
$4$dupont@example.com$hJLyOpYbVayE1Iq/ZY03Rx/r5Sk$
% sha1pass password martin@example.com
$4$martin@example.com$+LoO8eRzXhH23ozwXIDDpNE7ag4$

On voit ici que le salage d’un même mot de passe donne une empreinte totalement différente.

Nous reviendrons dans un prochain article sur la manière d’utiliser les algorithmes de hachage pour le stockage des mots de passe.

Le chiffrement symétrique

Les algorithmes de chiffrement symétriques reposent sur un secret (clé de chiffrement) partagé qui est utilisé pour chiffrer une donnée. Ils sont généralement utilisés pour sécuriser des informations ou des communications. Ses caractéristiques sont :

  • un chiffrement rapide des données, nécessaire au chiffrement des communications ou d’un important volume de données,
  • la même clé est utilisée pour chiffrer et déchiffrer.

Les algorithmes les plus couramment utilisés sont l’AES et le Blowfish. Il existe un grand nombre d’algorithme disponibles en Java (cf la documentation du projet Bouncycastle et la page de Wikipedia)

Le chiffrement asymétrique

Ce chiffrement repose sur une bi-clé, l’une publique et l’autre privée, dont l’une permet de chiffrer ce que l’autre va déchiffrer. Si la clé publique est utilisée pour chiffrer, la clé privée permettra le déchiffrement et inversement.
La clé publique est librement diffusée et peut être utilisée pour chiffrer une donnée à l’intention du détenteur de la clé privée.
La clé privée peut aussi être utiliser pour chiffrer et dans ce cas, seule la clé publique pourra déchiffrer le contenu. Ce type d’utilisation permet au détenteur de la clé privée de prouver son identité en signant une donnée. Nous y reviendrons dans la suite de cet article.

Le chiffrement asymétrique est principalement utilisé pour chiffrer des clés de chiffrement symétriques ou des hash pour une raison toute simple : les algorithmes de chiffrement asymétriques sont excessivement lents et ne peuvent pas être utilisés pour chiffrer des données dépassant quelques centaines d’octets. Son usage est donc principalement réservé au chiffrement de clés ou d’une empreinte (hash).

Un cas typique d’utilisation du chiffrement asymétrique est l’échange de clés de session (clé secrète) permettant le chiffrement d’une communication entre deux systèmes.
Un autre cas d’utilisation du chiffrement asymétrique est la signature d’un document. Dans ce cas, l’empreinte du document à signer est chiffrée à l’aide de la clé privée et déchiffrée avec la clé publique. Nous reviendrons plus tard sur ces types d’utilisation.

Les algorithmes asymétriques les plus connus sont le RSA (Rivest Shamir Adleman), le DSA (Digital Signature Algorithm) et le protocole d’échange de clés Diffie-Hellman.

Enfin, le chiffrement asymétrique est utilisé dans les certificats numériques X509 dont nous reparlerons bientôt.

Nous en avons fini avec les principes de base de la cryptographie. Un petit tour sur Wikipedia vous donnera de plus amples informations sur le sujet.

L’authentification

L’authentification est probablement la notion la plus simple à comprendre, mais en tant que développeur, c’est une de celles qui vous demandera le plus de travail d’implémentation.
Comme vous pouvez vous en douter, l’authentification consiste à fournir un moyen d’accès à une application.

Authentification par identifiant et mot de passe

Elle prend le plus souvent la forme d’un formulaire d’authentification où un identifiant unique ainsi qu’un secret (mot de passe secret que seul l’utilisateur rattaché à l’identifiant unique est sensé connaître) vous est demandé.
Dans ce cas de figure, le mot de passe est généralement stocké sous forme hachée le plus souvent dans un annuaire LDAP ou dans une base de donnée. La version salée de la fonction de hachage est chaudement recommandée afin d’éviter la découverte du mot de passe à l’aide d’un dictionnaire inversé.

Des techniques de durcissement de l’authentification par mot de passe, comme l’envoi de SMS, l’utilisation de Captchas ou encore l’utilisation de RSA SecurID, peuvent être employé avec des résultats plus ou moins satisfaisants.

Dans un prochain article, nous verrons qu’il est assez simple de mettre en œuvre ces bonnes pratiques d’authentification à l’aide du framework Spring Security.

Authentification par certificat

Les certificats numériques X509 sont généralement connus pour leur utilité dans le chiffrement des connexions SSL (utilisé avec le protocole HTTPS) et peuvent aussi être utilisés pour l’authentification à une application. Ils sont constitués d’une partie privée, généralement protégée par un mot de passe, qui est conservée par l’utilisateur et d’une partie publique qui est stockée sur le système hébergeant l’application à laquelle nous souhaitons accéder.

Là encore, un durcissement de cette technique d’authentification peut être réalisé à l’aide de tokens cryptographiques (clés USB, cartes à puce). Ces tokens cryptographiques ont la capacité de générer la bi-clé du certificat numérique et d’effectuer des opérations de chiffrement/déchiffrement asymétriques. L’intérêt majeur réside dans le fait que la clé privée ne sortira jamais du token et ne pourra donc pas être dupliquée (en cas de vol, le certificat sera simplement révoqué et deviendra inutilisable). La sécurité est donc assurée par une possession physique (le token) et par un secret (le mot de passe permettant l’utilisation du token).

Les certificats numériques sont un moyen de contrôle d’accès efficace mais potentiellement complexes à mettre en œuvre. Nous reviendrons sur le détail de leur fonctionnement et de leur utilisation dans un prochain article.

Authentification par Single Sign On (SSO)

Le Single Sign On permet la délégation de l’authentification à une application tierce qui va permettre aux utilisateurs d’accéder à toutes les applications du Système d’Information en ne s’authentifiant qu’une unique fois, pour la durée de la session d’authentification.

L’authentification par SSO peut être mise en place en interne, au sein du Système d’Information d’entreprise utilisant le Central Authenticate Service (CAS) par exemple, ainsi qu’en externe à l’aide de sites implémentant des protocoles tels qu’OpenID.

Là encore, un prochain article entrera dans les détails de l’utilisation du SSO dans vos applications web, ainsi que diverses bonnes pratiques et mises en garde sur leur utilisation (notamment en ce qui concerne OpenID).

Les autorisations

Une fois authentifié, l’utilisateur souhaite utiliser l’application et pour cela, il lui faut des droits ou autorisations. Chaque utilisateur aura donc un rôle lui accordant un ensemble de droits permettant d’effectuer des opérations ou d’accéder à certaines données.
Les rôles les plus communs sont « utilisateur » ou encore « administrateur » mais il est possible d’imaginer tous types de rôles en fonction des besoins de l’application.

L’intégrité

Les fonctions de hachage sont utilisées pour s’assurer de l’intégrité (la non altération) d’une donnée. Le calcul des sommes de contrôle est un élément important permettant de s’assurer qu’une donnée n’a pas été corrompue, frauduleusement ou non.

La confidentialité

L’un des enjeux de la sécurisation des sites web est de garantir la confidentialité des données. Cette confidentialité repose sur les mécanismes de chiffrement symétriques et asymétriques qui permettent de protéger des données locales (avec TrueCrypt par exemple) ou bien des communications.

L’un des mécanismes les plus connus est probablement le protocole Secured Socket Layer (SSL) (remplacé par Transport Layer Security normalisé par l’IETF) qui permet entre autre, le chiffrement des communications entre deux tiers. Le protocole utilise les algorithmes asymétrique pour chiffrer une clé de session (symétrique) qui est ensuite utilisée pour le chiffrement symétrique de la communication.

La confidentialité est d’une importance capitale dans tout mécanisme d’échange de données un tant soit peu sensibles (mot de passes, données bancaires …).

L’identité

Prouver son identité est probablement la tâche la plus complexe, et en même temps un des aspects fondamentaux de la sécurité. Lors d’une communication entre deux tiers, au hasard un client et un serveur, nous avons vu que certains mécanismes permettent de s’authentifier ou encore d’assurer la confidentialité.

Nous avons aussi vu que les algorithmes de chiffrement asymétriques, reposant sur une bi-clé dont l’une est privée et l’autre est publique, permettent l’échange de données sécurisé ou encore de prouver son identité.

Dans le premier cas de figure, nous utilisons la clé publique de notre interlocuteur afin de chiffrer une clé de session qui elle même a permis le chiffrement du document que nous souhaitons faire parvenir, en toute confidentialité, au possesseur de la clé privée. Dans ce cas, la seule chose dont nous sommes certains est que seul le possesseur de la clé privée sera à même de déchiffrer le contenu du document.

Dans un second cas de figure, nous souhaitons prouver que nous sommes à l’origine d’une donnée (une demande de congés par exemple). Une fois encore, le mécanisme de chiffrement asymétrique va venir à notre rescousse en nous permettant de chiffrer une empreinte du document que nous souhaitons envoyer à l’aide de notre clé privée. Ainsi, en déchiffrant l’empreinte à l’aide de la clé publique, nous nous assurons que la donnée provient bien du possesseur de la clé privée, mais aussi que cette donnée n’a pas été altérée, en recalculant l’empreinte du document et en la comparant à celle que nous venons de déchiffrer.

C’est plutôt pas mal, nous avons un mécanisme nous permettant d’envoyer un document de manière confidentielle à un tiers, mais aussi de prouver notre identité, juste à l’aide d’un mécanisme de clé publique que l’on distribue à ceux avec qui l’on souhaite communiquer. C’est malheureusement sur ce dernier point, « la distribution de la clé publique », que les choses se compliquent. Est-il toujours possible de remettre en main propre sa clé publique ? Comment puis-je m’assurer que la clé publique dont je dispose correspond bien à l’émetteur dont je crois connaître l’identité ?

Les certificats numérique dont le standard X509 est le plus répandu, apporte des réponses à nos questions. Ces certificats contiennent un certain nombre d’informations sur son propriétaire, sa clé publique ainsi qu’une empreinte signée du contenu du certificat.

Concernant la signature de l’empreinte nous avons deux cas de figure. Dans le premier cas, l’empreinte est signée à l’aide de la clé privée correspondant à la clé publique du certificat, c’est ce que l’on appelle un certificat auto-signé. Dans le second cas, une demande de certification est envoyée à une Autorité de Certification (AC), qui va ajouter sa propre identité dans le certificat (clé publique + informations sur l’Autorité de Certification) et signer l’empreinte du certificat.

L’Autorité de Certification peut être une entreprise dont les certificats sont reconnus dans la plupart des Systèmes d’Exploitation, Navigateurs, JVM…, comme Verisign par exemple, mais peut aussi être une DSI qui crée son propre certificat racine et l’implante dans les différentes postes de son SI.

Lorsque le navigateur, par exemple, recevra un certificat X509, celui-ci vérifiera qu’il est bien signé par une Autorité de Certification reconnue et le reconnaîtra comme valide. Dans le cas d’un certificat auto-signé et non reconnu, le système pourra proposer de l’accepter à ses risques et périls.

Afin d’augmenter la sécurité des certificats, les clés privées (qui sont sensées ne jamais être exposées), sont généralement protégées par un mot de passe. Le principe est que notre identité soit protégée par quelque chose que l’on possède (une clé privée) et un secret. Des mécanismes plus « durs » de sécurisation reposent sur des tokens cryptographiques qui contiennent le générateur de la bi-clé et l’espace mémoire pour stocker la clé privée. Dans ce cas, la clé privée peut être volée mais pas dupliquée. En cas de vol, le certificat numérique peut être révoqué ce qui empêche une utilisation délictueuse.

Nous n’entrerons pas plus dans les détails sur les certificats numériques dans cet article. Nous en reparlerons lorsque nous aborderons l’authentification X509 dans un prochain article. Sachez simplement que les certificats numériques sont mis en œuvre dans beaucoup de mécanismes tels que les connections HTTPS qui sécurisent nos communications sur le web, dans le protocole SSH ou encore dans les réseaux privés virtuels (VPN).

La non répudiation

La non répudiation consiste à s’assurer que l’émetteur d’une donnée ne puisse pas nier son implication en cas de litige. La non répudiation repose généralement sur des certificats numériques, qui restent le moyen le plus efficace pour s’assurer de l’identité d’une personne.

D’un point de vue légal, la non répudiation est particulièrement difficile à mettre en œuvre. Il est en effet difficile de remettre en cause la bonne foi d’une personne pouvant prétexter le vol de son identité numérique pour se défausser de sa responsabilité. Il peut par exemple être nécessaire de mettre en place des mécanismes de co ou de contre signature et de l’horodatage en fonction des besoins.

Ce sujet est particulièrement complexe, nous ne nous y attarderons pas plus. Vous pourrez trouver de plus amples informations sur internet, ici par exemple.

Conclusion

Cette introduction nous à permis de faire un tour des principes liés à la sécurisation des sites web. Les principes cryptographiques que sont le hachage et les algorithmes de chiffrement symétriques et asymétriques sont à la base de toute infrastructure web sécurisée.

Comme vous l’aurez compris, cet article est le prélude à une série d’articles sur la sécurisation des sites web, où nous utiliserons le très répandu framework Spring Security pour illustrer nos propos et quelques bonnes pratiques. Nous nous efforcerons par la même occasion d’aborder les failles les plus communes, référencées par l’OWASP Top Ten, et de montrer comment les traiter.

Publié par

Publié par David Galichet

David a commencé sa carrière en 2004 chez Fimasys, éditeur de progiciel dans la finance puis a rejoint Linagora, une SSLL dans laquelle il a passé un an et demi avant de rejoindre Xebia fin 2009. Il s'intéresse tout particulièrement au monde Java, aux technologies J2EE et aux langages qui gravitent autour comme Groovy et Scala. Il a aussi développé un fort intérêt pour les plateformes d'intégration ainsi que pour les problématiques de production. David a aussi un réel intérêt pour les méthodologies agiles, qu'il a pu appliquer en tant que Scrum Master dans ses différentes missions. Enfin, David participe activement à la revue de presse de Xebia sur des sujets relatifs aux technologies Java et aux méthodologies agiles.

Commentaire

18 réponses pour " Introduction à la sécurisation des applications web "

  1. Publié par , Il y a 9 ans

    Très pédagogique. J’attends la suite avec impatience.
    A noter que l’ANSSI (Agence nationale de la sécurité des systèmes d’information) recommande un algorithme de hash de la famille des SHA2 (à commencer par le SHA256) pour les applications mettant en oeuvre du hashage pour de l’authentification SSL par exemple ou pour de la signature de document).
    C’est important car les administrations sont censées suivre les recommandations de l’ANSSI.

  2. Publié par , Il y a 9 ans

    Je nuancerais la conclusion en disant que les principes exposés sont les bases de la sécurité *des systèmes d’information* et ne s’appliquent pas qu’aux applications web…

  3. Publié par , Il y a 9 ans

    Merci pour ce commentaire encourageant et pour les précisions sur le SHA2 :-)

    Le SHA256 est effectivement vivement conseillé à l’heure actuelle, et semble même être impératif dans certaines administrations.

  4. Publié par , Il y a 9 ans

    @Bastien, effectivement la plupart de ces principes sont applicables d’une manière plus générale à la sécurité des SI.

    Je souhaitais néanmoins cadrer cet article en insistant sur la sécurité des applications web, qui sera le sujet des articles à venir dans cette série.

  5. Publié par , Il y a 9 ans

    La gestion centralisée de l’autorisation peut être un aspect interessant à couvrir. Autant l’authentification peut se mettre en place assez rapidement avec des solutions comme CAS, abordable techniquement et financierement, autant la centralisation des autorisations ne dispose pas, à ma connaissance, d’équivalent.

  6. Publié par , Il y a 9 ans

    @David, la question est aussi de savoir s’il est vraiment intéressant de centraliser les autorisations, sachant qu’elles dépendent de l’application à laquelle on accède. En tant que développeur, il serait intéressant que j’aie les pleins accès à Hudson par exemple, mais juste des droits restreints à mon bugtracker, etc. Dans ce cas il faudrait que l’outil centralisant les autorisations ait connaissances des différentes applications, ce qui n’est pas forcément souhaitable.

  7. Publié par , Il y a 9 ans

    @Bastien : les RSSI tendent à privilégier une centralisation des autorisations

  8. Publié par , Il y a 9 ans

    @David Galichet: Merci David pour cet article très intéressant.
    A noter, puisque tu traites ici des applications Web, que le SSO peut également se faire en interne avec des outils comme LemonLdap::NG (Web SSO) http://lemonldap-ng.org/.
    @David et @Bastien Jansen, cet outil permet notamment de faire de la gestion centralisée des droits.
    Enfin, aspect intéressant également, il supporte l’authentification par certificats X509.

    @David Galichet: hâte de lire la suite !

  9. Publié par , Il y a 9 ans

    @David, il est possible de gérer les autorisations de manière centralisée à l’aide d’un annuaire LDAP, et même de le faire en passant par un CAS qui pourra utiliser l’annuaire LDAP pour gérer l’authentification ainsi que les autorisations. Dans ce cas, les droits seront passés dans le ticket de réponse du CAS. Nous reviendrons sur ces cas d’utilisation (LDAP et CAS) dans de futurs articles.

    @Bastien & Raf, techniquement, il est possible de gérer des autorisations par applications. Dans les faits, les RSSI auront effectivement la main sur les décisions prises par rapport aux annuaires de l’entreprise.

    @Stéphanie, merci pour tes encouragements :-) Des SSO tels que CAS ou LemonLdap::NG seront effectivement plutôt utilisés en interne dans l’entreprise. Si mes souvenirs sont bons, LemonLdap::NG fonctionne un mode proxy authentifiant, CAS lui est basé sur un système de ticketing.

  10. Publié par , Il y a 9 ans

    @David Galichet, c’est ça, et l’avantage de Lemon c’est qu’il est facile à intégrer à l’application Web (par exemple il suffit de mettre en place un filtre spring security qui va lire les en-têtes HTTP) tandis qu’avec CAS il faut que l’application vérifie auprès de CAS que le ticket est valable.

  11. Publié par , Il y a 9 ans

    @Stéphanie : le principe du filtre peut aussi être utilisé pour CAS ; c’est d’ailleurs ce que nous avons fait dans mon entreprise afin de déployer rapidement CAS sur l’ensemble de nos webapps.

  12. Publié par , Il y a 9 ans

    @Stéphanie et Raf, je confirme que l’utilisation de CAS est plutôt simple avec Spring Security. Je ne vais pas entrer dans les détails ici, ce sera le sujet d’un futur article. Je prends en tous cas bonne note de vos commentaire et je penses que j’aborderai les deux types de SSO dans l’article en question.
    Merci pour vos commentaires :-)

  13. Publié par , Il y a 9 ans

    Article qui va à l’essentiel, bravo David :)

    J’en profite pour compléter un peu. Il faut différencier les protocoles d’authentification de leurs implémentations. David, tu parles de CAS, mais il s’agit justement d’un protocole, qui possède une implémentation majeure: celle de la communauté JASIG.

    Lemonldap::NG est une solution qui implémente des protocoles d’authentification (LDAP, SQL, SSL, etc. et depuis peu SAML2, OpenID, CAS, etc.). Elle se positionne comme une brique SSO frontale à un environnement hétérogène, et injecte les « autorisations » dans les entêtes HTTP. Je pense que ça permet une plus grande cohérence et facilité d’intégration au niveau d’un SI avec un gros historique (Webapps J2EE, PHP, Dot.NET, Ruby, etc.).

  14. Publié par , Il y a 9 ans

    Merci Thomas pour ces précision :-)

    La solution type Lemonldap::NG semble en effet particulièrement séduisante pour mettre en place simplement un SSO sur un SI historique.

    Aurais-tu des informations sur la tenue en charge de ce type de solution (et notamment pour le traitement d’un grand nombre de requêtes) ?

    Si mes souvenirs sont bons, cette solution se présente sous la forme d’un mod apache. Génère-t-il un overhead significatif pour l’établissement de l’authentification (ce qui en soit semblerait « normal ») et ensuite pour le traitement des requêtes subséquentes ?

  15. Publié par , Il y a 9 ans

    Bravo, un article qui pose très bien les bases !

    Sur le « durcissement de l’authentification », il serait intéressant de différencier les usages: les captchas servent à montrer que l’utilisateur est humain, tandis que les SMS démontrent d’une possession physique (le téléphone).

    A propos de SpringSec, l’une des failles les plus courantes (à mon sens) est le mapping de beans hibernate sur des champs de formulaire, pour faciliter l’édition. C’est très pratique, à condition de fonctionner en liste blanche (j’autorise l’édition de tels et tels champs) plutôt qu’en liste noire. Car dans le cas contraire, il devient facile d’ajouter des champs POST à une requête HTTP lors d’une édition (si je suis pas clair, dites-le et je préciserai ;-p).

    CAS, par défaut, permet d’intégrer des applications sans intervenir sur CAS.

    Quel intérêt ? Permettre aux utilisateurs de créer des applications s’intégrant au SI de l’entreprise sans demander d’autorisation à personne. Décentraliser le développement du SI, sans introduire de perte en terme de sécurité.

    Par ailleurs, CAS fonctionne très bien sur AppEngine, même sans passer par OpenId (=> http://code.google.com/p/cas-client-appengine/).

    A noter aussi, les dernières versions de CAS incluent une CSS « mobile », pas de soucis pour les sites web mobiles donc ;-) .

  16. Publié par , Il y a 9 ans

    >Il n’est pas nécessaire que le sel soit une information secrète, son utilité
    >étant de rendre les dictionnaires inversés inefficaces.

    Le sel même public rend « impossible » les attaques par pré calcul (Rainbow Table), en rendant le pré calcul trop important.
    Par contre, un sel public n’empêche pas une attaque par dictionnaire sur un mot de passe faible.

    Donc, le sel privé offre plus de sécurité mais il n’est pas toujours possible de le mettre en oeuvre.

  17. Publié par , Il y a 9 ans

    @Piwaï, merci pour ces différents commentaires.
    Le mapping automatique des données de la requêtes avec les champs d’un bean est effectivement une faille d’injection à éviter. J’en reparlerai plus longuement dans un prochain article.
    Concernant le point sur CAS, je te rejoins sur ce que tu dis. Par contre une interaction sera probable si l’application requiert l’ajout de nouveaux rôles (gérés au niveau de l’annuaire LDAP par exemple).

    @Stéphane, merci pour cette précision. En effet, la connaissance du sel permettra d’attaquer par dictionnaire et de casser des mots de passe faibles.

    On revient souvent aux problématiques de mots de passe faibles et de sites peu fiables qui « égarent » des dumps de base, voir utilisent de manière subversives les mots de passe de leurs utilisateurs (qui la plupart du temps utilisent toujours le même). Je reparlerai de ce sujet lorsque j’aborderai OpenID, souvent décrié à cause des problèmes de fishing.

  18. Publié par , Il y a 8 ans

    Article très intéressant. Je pense néanmoins que la sécurisation des applications web est une problématique plus vaste qui doit non seulement traiter les aspects authentification, autorisation, intégrité, confidentialité mais aussi plus pragmatiquement se protéger des attaques applicatives les plus courantes SQL injections, Cross Site Scripting, injection de code …).

    C’est là que peut rentrer en jeu les nouvelles solutions WAF
    Qu’en pensez vous ?

    Pour ceux intéressé par WAF, quelques liens :
    http://johanne.ulloa.org/pourquoi-un-waf.html
    http://blog.gioria.org/?q=Web+Application+Firewall

    http://www.slideshare.net/Eagle42/2010-0311sdlcv02
    http://www.slideshare.net/starbuck3000/owasp-top10-2010-rc1
    http://www.slideshare.net/starbuck3000/web-application-security-how-to-start

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.