Cette année, je serais de plus ATE les 12 et 13 en matinée, sur ASP.NET (mais n’hésitez pas a passer pour faire un simple coucou )

PS: pour ceux qui ne se sont pas encore inscrit, pensez a y aller vite !

L?aspConf, c?est:

• des conférences de qualité (en tout cas, si je me base sur les années précédents)
• en ligne (pas de billet d?avion )
• gratuit

Si le nom a changé, c?est pour inclure, en dehors des contenus orientés MVC, des sujets Azure, Webpages, et autres, alors, n?hésitez pas, et bloquez vos agendas pour les 17 et 18 Juillet

Pour s?enregistrer, c?est ici : http://www.aspconf.net/

Bon, ceci dit, le mien n’est pas si sombre, ni si secret, vu que c’est une attirance certaine vers une musique qui fait beaucoup de bruit et dont les paroles sont souvent assez gutturales

Comme j’ai, de plus, un petit frère dont cela devient de plus en plus le métier de jouer de ladite musique, et que justement, ils commencent a avoir besoin d’un site web, c’est une bonne occasion pour:

• faire plaisir a un petit groupe de jeunes qui n’en veulent;
• faire mumuse avec des technos que je n’utilise pas tous les jours;
• et en faire profiter tout le monde (autrement dit, me planter en public )

Le premier choix est celui de la techno de développement.

Comme je en veux pas non plus aller trop loin du coté obscur, je vais partir sur du C#, en MVC (a priori 4), et avec du code client en Razor (dans un autre monde, j’ai commencé en nodeJs, mais j’ai une contrainte de temps forte, en la personne de mes enfants). Au passage, et compte bien alterner entre Webmatrix 2 et Visual Studio 11 (pour le fun).

Coté base de données, une petite base de données MongoDB me tente bien, très probablement avec NoRM pour y accéder. Pour ne pas payer trop cher, du moins au début, je vais créer une base chez MongoLab (gratuit jusqu’a 240 Mo)

En terme de gestion de configuration, je pars sur bitbucket et Git pour héberger le code

Pour l’hébergement, je vais partir sur AppHarbor, ce qui va me donner un bon serveur de test, avant de monter en gamme le jour ou le site est fini.

Au final, en faisant mes comptes:

• Webmatrix / VS11 beta : gratuit (le jour ou VS 11 est disponible, je passe a la version express)
• MongoDb: gratuit pour le moment
• Bitbucket/Git: gratuit
• AppHarbor: gratuit

Ah, oui, parce que *la* contrainte que je me mets, c’est de tout développer avec une dépense totale de 0? (pas pour des raisons financières, mais pour montrer qu’on peut le faire).

La suite au prochain épisode (heureusement qu’il y’a des ponts en mai )

.et la, justement, une des applis sur lesquelles on « travaille » vient d’entrer en preview, je parle de WASABI.

Qu’est-ce que Wasabi ?

Ce nouveau block fourni par le groupe Patterns&Practice (Enterprise Libraries, pour ceux a qui cela parle) permets de:

• monter de nouvelles instances de roles pour absorber la charge
• diminuer le nombre d’instances lorsque la charge redescends
• augmenter/réduire le nombre d’instances a date/jour définis (ventes de noël, ou jour férié, par exemple)

Pour ceux qui voudraient plus d’infos, le blog d’annonce « officiel » est ici:

http://blogs.msdn.com/b/agile/archive/2011/09/12/announcing-windows-azure-autoscaling-block-preview.aspx

Une petite vidéo a même été mise en ligne sur Channel9:

http://channel9.msdn.com/posts/Autoscaling-Windows-Azure-applications

Après s’être intéressé a debug=true et a customErrors=false, on va voir ce que notre bon vieux Web.Config a à dire sur les cookies

Non, pas ceux-la…

httpOnlyCookies

En me connectant sur un site, je me rends compte que, suite a la connexion, mon navigateur stocke des informations sous forme de cookies, que je peux ensuite accéder grâce a la ligne suivante en javascript:

En soi, pas de gros problème.

Ceci dit, si en plus, le site contient une quelconque faille XSS, ce code va me permettre de récupérer le contenu d’un cookie, et de le renvoyer sur un autre site. A partir de la, c’est la fin des haricots.

Un solution qui couvre 100% du problème est de ne pas utiliser de cookies (bon courage…oubliez session, et autres joyeusetés, mais c’est faisable).

Une solution qui ne couvre *que* 90% du problème est d’ajouter la ligne suivante au web.config:

Mettre cette option a true va flagger tous les cookies comme étant des cookies httpOnly, qui ne pourront pas être accédés en javascript. Le risque de vol d’identité est donc du coup limité aux utilisateurs qui accèderaient le site avec un navigateur ne gérant pas httpOnly (tant pis pour eux)

cookieLess

Ca y’est, nos cookies sont en httpOnly, maintenant, on est tranquille…ou pas

Deux mécanismes capitaux d’asp.net se basent sur les cookies pour fonctionner:

• la session
• l’authentification de type Forms

Malheureusement, certains utilisateurs pouvant, pour des raisons diverses, ne pas avoir une configuration leur permettant de gérer les cookies, un mécanisme de gestion « sans cookies » a été implémenté pour ces mécanismes.

LE « petit » problème de ce mode est qu’il va ajouter une clé directement dans l’url. Il suffit donc de sniffer le réseau pour voir passer toutes les URLs contenant cette clé, et de copier une de ces URLs pour voler l’identité de l’utilisateur.

Alors, effectivement, cela ne va cibler que les utilisateurs qui ne peuvent pas stocker de cookies, mais si une société mets en place une règle empèchant le stockage des cookies, *tous* les utilisateurs de l’entreprise en question vont potentiellement permettre le vol de leur identité.

A cela, trois options:

• mettre cookieLess = UseCookies. Dans ce cas, les utilisateurs n’acceptant pas les cookies seront incapables d’utiliser le site
• mettre cookieLess = AutoDetect. Dans ce cas, les utilisateurs n’acceptant les cookies pourront utiliser le site, mais seront vulnérables. Une façon de limiter ce risque est décrite dans cet article -> http://msdn.microsoft.com/en-us/magazine/dd458793.aspx
• mettre en place du SSL sur tout le site va aussi limiter les risques

requireSSL

Vous avez un joli site web tout sécurisé, en SSL, vous avez mis les cookies en httpOnly, tout va bien. Sauf que soudain, vous vous rendez compte que vous vous êtes connecté en admin a une heure du matin et que vous avez aspiré toutes les adresses clients de la base. Aïe…

En fait, il est possible (un peu compliqué, mais envisageable) en exploitant une faille XSS, de voler un cookie qui est censément transmis a un site alors que le site est supposé être accédé en SSL.

En effet, si l’attaquant redirige l’utilisateur sur une adresse locale au site, mais en utilisant HTTP au lieu de HTTPS, même si le site ne va pas transmettre d’information (une exception sera remontée), le cookie sera tout de même transmis en clair…

Pour cela, la solution est simple, il suffit d’ajouter requireSSL= »true » au niveau de la balise httpCookies du web.config

Références

La plupart de ces infos viennent des tréfonds du site d’OWASP, une vraie mine d’or du genre.

Pour la suite, je laisse la sécurité de coté, il y’a des petites astuces de performances a voir

• les livres qui ont une approche théorique
• les livres qui ont une approche technique

Ce livre est définitivement dans la seconde catégorie, avec une approche très détaillée de 60 « recettes » de développement, allant de la manipulation basique du DOM a des requêtes Ajax cross domain.

Chacune des recettes est détaillée point par point, avec des exemples de code complets et des captures d’écran de chaque étape, ce qui permets même aux plus débutants de rapidement comprendre le fonctionnement de JQuery.

Au niveau des bons cotés, les recettes sont très proche de cas d’utilisation réels (certaines sont vraiment des musts, surtout dans les deux premiers chapitres et dans les chapitres sur Ajax)

Le seul bémol, pour moi, est un petit manque sur le coté théorique (…bon, ceci dit, j’ai encore mon abelson & sussman sur la table de chevet, je ne suis donc pas une référence )

Si vous avez besoin de vite comprendre comment utiliser JQuery dans vos développements .NET, ce livre est fait pour vous.

Note globale : 4/5, Public concerné: Débutants/Intermédiaire

Plus d’informations ici: ASP.NET JQuery Cookbook

Chapter 1: Working with ASP.NET Controls Chapter 2: Validation of ASP.NET Controls Chapter 3: Working with GridView Control Chapter 4: Working with Image Control Chapter 5: Animations in ASP.NET (disponible en ligne) Chapter 6: AJAX and ASP.NET (Part I) Chapter 7: AJAX and ASP.NET (Part II) Chapter 8: Client Templating in jQuery Chapter 9: Creating Rich Content in ASP.NET(téléchargement gratuit)

Usually, development books can be split across two distinct families:

• books that take a theoretical approach
• books that take a practical approach

This book definitely falls in the second category, with a very detailed approach to 60 « recipes » of development, ranging from basic manipulation of the DOM of a cross domain Ajax requests.

Each recipe is detailed point by point, with complete code examples and screenshots of each step, allowing even the most novice to quickly understand how jQuery works.

The bright side is that those recipes are very close to actual use case (some are real life savers, especially in the first two chapters and the chapters on Ajax)

The only downside for me is that the books lacks a bit of explanaiton on the theoretical side (…that said, I still have my Abelson &Sussman on the bedside table, hence I am not a reference )

If you need to quicky get up to speed on JQuery, this book is definitely for you.

Note : 4/5, For: Beginner/Intermediate

More info here: ASP.NET JQuery Cookbook

Aujourd’hui, premier billet, on va parler des deux « erreurs » les plus classiques du genre, à savoir l’activation du debug en production, et l’affichage des erreurs.

Symptômes

Lors d’une erreur sur le site, l’utilisateur voit l’écran suivant s’afficher

Ouch.

Raisons

Lorsque l’on va lancer l’application depuis Visual Studio la toute première fois, on va avoir ce petit dialogue (si, tout le monde l’a vu…et cliqué sur OK direct).

Si on laisse l’option par défaut, Visual Studio va automatiquement ajouter, dans le Web.config, la ligne

<compilation debug="true"> 

L’affichage du message, lui, vient de la propriété CustomErrors, qui est, la plupart du temps, mise a Off dans les environnements de Validation ou de QA, de façon a pouvoir voir le détail des erreurs:

<customErrors mode="Off"> 

Risques et inconvénients

En fonction de l’endroit ou se produit l’erreur, ce scénario va d’afficher des données permettant de faciliter une attaque. Rien qu’avec l’écran ci-dessus, je sais quelle est la version du Framework, quelle est la version d’ASP.NET.

Je peux aussi déduire d’autres informations a partir du type de l’exception, et la pile des appels me donne une vue sur la logique de développement de l’application (signature des méthodes).

Dans le pire des cas, un éventuel attaquant pourra voir des portions de code (comme ci-dessus).

De plus, lorsque l’application est en mode debug, elle subit des surcouts en terme de performance, liés à:

1. La désactivation de certaines optimisations lors de la compilation des pages ASP.NET
2. Une augmentation de l’utilisation de la mémoire
3. La désactivation du cache pour les Scripts et les images récupérés depuis le handler WebResources.axd

(source : http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx)

Solution

Pour corriger ces deux problèmes, la solution est simplissime, il suffit de modifier le Web.Config de la façon suivante:

<configuration> 

  <system.web> 

    <customErrors mode="RemoteOnly"> 

    <compilation debug="false"> 

Pour la section customErrors, il est même conseillé de définir des pages d’erreur en fonction du code d’erreur retourné (l’exemple se trouve dans le web.config par défaut )

Encore mieux, pour la partie debug, il est possible de « forcer » debug à false sur toutes les applications de la machine en ajoutant, dans le machine.config, la ligne suivante:

<configuration>

    <system.web>

          <deployment retail="true"/>

Et oui, dans des audits, c’est malheureusement ce qui revient le plus souvent…

Et-ce que ces informations vous sont utiles (je m’adresse a mon unique visiteur, mais je le vouvoies par politesse ), ou est-ce qu’il vaut mieux que je parle d’autre chose ?

Sur un site grand public, ca fait mauvais genre.

Passons.

Ce soir (j’ai ré-essayé quelques fois dans la journée, sans succès), toujours décidé a utiliser ma dernière tablette de chocolat, je retourne (oui, j’insiste) sur le site, pour récupérer une recette.

A un moment donné, je notes, sur ce site une URL qui reçoit un paramètre (la plupart des autres sont des URLs « en dur »). Je vais donc jusqu’au bout de ma bêtise, et je bidouilles l’ID.

Et la, c’est le drame:

Donc, de ces deux infos, on peut en déduire (ou du moins supposer) que:

• le site web n’a pas de mécanisme de monitoring (le site est resté H.S. une bonne partie de la journée, pour ce qui était probablement une typo dans le web.config)
• le développeur a utilisé Cast, au lieu d’un TryCast (pas gravissime en soi, mais permets d’induire une erreur)
• le web.config a CustomErrors=false

Ce qui nous donne un bon exemple pour une quatrième faute inexcusable si vous avez un site web externe, a savoir ne pas vérifier son web.config avant la mise en prod (en étant trés feignant, un tour sur http://www.wcanalyzer.com/ suffit )

Une des choses que j’adore avec l’équipe MVC, c’est que, contrairement a d’autres (suivez mon regard…Azure, peut-être ???), les roadmaps sont annoncées un petit bail a l’avance, et que, même si cela bouge entre temps, cela permets d’alimenter le dialogue avec l’équipe de Dev (qui a le grand mérite d’être ouverte aux remarques).

Dans cette nouvelle roadmap, on apprends donc que le but, pour MVC 4, est (tout simplement…) d’en faire la meilleure plate-forme pour écrire des applications riches pour le web (oui, le gras est d’origine ).

Au programme, entre autres:

• Une amélioration du développement et déploiement, que ce soit ciblé vers une machine ‘classique’ ou vers Azure
• Un meilleur support des projets orientés vers les Mobiles (téléphones et tablettes)
• L’ajout de recettes (recipes), ou comment apporter une touche de développement orienté composants
• …et pas mal de petites choses sympathiques qui viennent améliorer l’expérience de développement (meilleur support des helpers Razor, css bundling, meilleur support de HTML5 et autres)

L’intégralité de la roadmap est situé ici: http://aspnet.codeplex.com/wikipage’title=ASP.NET%20MVC%204%20RoadMap

Personnellement, depuis la sortie de la v1 de MVC, je reste scotché par ce Framework, et ce n’est pas son évolution récente qui va diminuer mon enthousiasme (Hmmmmm, Razor)

Après pas mal d’itérations, voici la liste de ce qui, de mon avis, ne devrait pas se trouver dans le code d’un développeur Web en 2011 (pas que cela aurait du s’y trouver en 2010):

Les entrées utilisateur non encodées

Les dernières versions du framework ont rendu beaucoup plus simple (comprendre un seul caractère: http://philippe.developpez.com/articles/nouveautes-asp-net-4/#LVIII-H)  l’encodage du text, et la bibliothèque anti-xss peut maintenant être facilement utilisée dans un projet

Des paramètres de requête non parsés/non contraints

Utiliser TryParse sur tous les composants de la query string ne coute rien, mais permets d’éviter pas mal de mauvaises surprises en prod.

De la même façon, vérifier la longueur de ces valeurs, dans le cas d’une chaine, ne mange pas de pain

Du SQL construit a la main sans paramètres

Vu le cout de l’utilisation des paramètres, laisser la porte ouverte a une injection SQL, ca mérite un coup de pied quelque part. A noter, l’article suivant date de 2008: http://johannblais.developpez.com/tutoriel/dotnet/bonnes-pratiques-acces-donnees/

A noter, c’est évidemment non exhaustif, mais c’est juste le petit quelque chose qui va faire sonner les oreilles de quelqu’un si je tombe dessus dans une revue

Et vous, y a t’il une erreur grossière qui vous fait bondir ?