Business Geek

Quand on utilise les MasterPages, il devient impossible d’ajouter un lien vers une feuille de style directement dans une page. En effet, on ne peut mettre la référence à la CSS que dans la section <head/> et les <asp:Content> des pages enfants doivent se trouver obligatoirement dans le <body/> (la <form/> plus exactement).

On a tout de même accès à la section <head/> depuis le code pour ajouter manuellement un lien vers une CSS avec un contrôle de type HtmlLink.

HtmlLink cssLink = new HtmlLink();
cssLink.Href = "../mapage.css";
cssLink.Attributes.Add("rel", "stylesheet");
cssLink.Attributes.Add("type", "text/css");
Page.Header.Controls.Add(cssLink);

Afin de rendre cette utilisation plus souple, on peut encapsuler ce code dans un contrôle afin de l’ajouter graphiquement dans le designer de page :

La problématique

Elle est très simple, IE6 ne gère pas le channel alpha sur une image au format PNG. Je ne parle pas de simple transparence (ça c’est géré) mais d’une transparence en dégradé. (définition wikipedia)

La base de travail

Nous allons faire fonctionner le channel alpha pour une image classique et pour image en background. Le code HTML est le suivant :

Le code CSS est le suivant :

#headings h1 {
  height:241px;
  width:512px;
  background: url( '../images/logoalpha.png' ) no-repeat;
}
#headings h1 span {
  display: none;
}

La solution

Internet Explorer dispose d’un système de filtres pour effectuer des opérations de rendu sur des éléments de l’arbre DOM. Notamment, il existe un filtre appelé AlphaImageLoader qui permet de gérer le channel alpha. Pour appliquer un filtre, il suffit d’insérer une directive CSS filter. Pour l’image background, c’est assez simple, on applique directement la directive à la place de background :

filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='images/logoalpha.png', sizingMethod='scale');

Cependant, pour rester compatible avec IE7 et Firefox, on doit mettre la directive dans un hack pour IE et on garde un background classique pour les autres navigateurs. Le hack qui est interprété uniquement par IE (inférieur à la version 7) est “* html” :

* html #headings h1 {
  /* on annule le background et on le red‚finit avec le filtre */
  background:none;
  filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='images/logoalpha.png', sizingMethod='scale');
}

Pour l’image classique, on ne peut appliquer directement la directive filter en CSS. On doit recourir à du Javascript pour appliquer le filtre. Il existe un moyen d’appliquer un script sur un élément avec IE6, c’est l’utilisation des behaviours. Un behaviour est un bout de Javascript encapsulé dans un fichier .HTC formaté d’une certaine façon :

<public:component>
  <public:attach event="onpropertychange" onevent="propertyChanged()" />
  <script>
[MON SCRIPT ICI]
  /script>
</public:component>

On voit ici que le script sera exécuté au changement d’une propriété du tag sur lequel il est appliqué. Je ne vais pas décrire le script ici et je vous propose plutôt de le télécharger ici. Retenez juste qu’il a besoin d’un gif transparent pour appliquer le filtre (je n’ai pas cherché à comprendre .

Mais alors, comment appliqué le behaviour ? En CSS, il suffit d’ajouter :

.alphaPNG {
  /* compris uniquement par IE --> javascript executé sur l'élément */
  behavior:url('png.htc');
}

Vous aurez compris que j’ai juste à appliquer la classe CSS sur mon image PNG :

<img src="logoalpha.png" width="512" height="241" class="alphaPNG" />

Vous noterez que je fixe la taille sinon, le rendu ne se fait pas.

Pour voir ce que cela donne, rendez-vous sur cette page : http://blog.djeepy1.net/public/labs/png-fix/SampleLogo.htm
Pour télécharger tout le projet :  http://blog.djeepy1.net/public/labs/png-fix/sample.zip

_{Merci à Mitch pour le logo.}

Je me suis retrouvé récemment face à un doute technique. Après avoir longuement expliqué l’intérêt de mettre des traces dans les différents événements d’une page ou d’un contrôle ASP.NET et l’importance de conditionner ces traces pour ne pas les retrouver dans l’environnement de production, je me suis retrouvé coincé car la technique a changé entre ASP.NET 1.x et ASP.NET 2.0. Explication…

Dans ma page, je mets les traces souhaitées :

#if TRACE
    Context.Trace.Write("MaPage", "Début de l'événement OnLoad");
#endif

Les pages et les contrôles ASCX étant compilés dynamiquement à l’exécution, il est inutile de mettre une directive de compilation dans votre projet (sauf si vous utilisez la fonctionnalité de publication avec les pages précompilées et non updateable).

En 1.x, j’avais l’habitude de configurer la directive dans la section <compilation/> du web.config :

<compilation debug="true" compilerOptions="/d:TRACE">

Là, l’intellisense ne me propose pas l’attribut CompilerOptions ce qui m’est confirmé par une erreur au runtime. Un petit tour sur la toile pour comprendre que la compilation est plus complexe (fine) en ASP.NET 2.0.
Heureusement, il existe toujours cette configuration dans la directive de page, ce qui n’est pas plus mal d’ailleurs pour restreindre le scope de la directive de compilation :

<%@Page Language="C#" CompilerOptions="/d:TRACE" %>

Pour ceux qui souhaitent utiliser la directive pour l’ensemble du site, il faut vous tourner vers la section de configuration <system.codeDom> où on doit déclarer des <compilers> avec leurs paramètres pour des jeux de fichiers du site. dans l’exemple ci-dessous, on définit que les fichier .cs seront compilés via un CSharpCodeProvider (csc.exe) avec la directive TRACE.

<system.codedom>
   <compilers>
      <compiler            
         language="c#;cs;csharp" extension=".cs"
         compilerOptions="/d:TRACE"
         type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />          
   </compilers>
</system.codedom>

Attention toutefois avec cette méthode car le site doit être exécuté en FullTrust pour avoir accès aux options de compilation.

_{Merci à Scott Allen pour les explications.}

Le magazine 01informatique vient de sortir un dossier complet sur la sécurité dans les sites AJAX (http://www.01net.com/01informatique/). Ayant entendu le teaser à la radio (les développeurs ont négligé la sécurité !! oh mon dieu), je m’attendais à un article pour pinpins basé sur des vérités générales. Je dois avouer que j’ai été surpris de la qualité avec laquelle le dossier a été traité. Il ont même réussi à me faire peur et j’ai repassé dans ma tête tous les sites web que j’ai pu développer en me posant cette question : sont-ils sécurisés, y’a t-il des failles ?

Je me suis toutefois rassuré rapidement, ASP.NET est loin d’être un gruyère et j’ai toujours appliqué les grands principes de sécurité du Web :

• vérifier toutes les saisies utilisateurs (Cross-Site Scripting, SQL Injection, Overflow)
• faire attention à tout Cookie, les crypter si nécessaire
• limiter la surface d’exposition des API publiques (WS, Ajax, GET, etc.)
• utiliser des ID temporaires (token ou ticket), casser les séquences (IDENTITY)

Cependant, j’ai été interpellé dans l’article par une technique de piratage appelée : Cross-Site Request Forgery (CSRF ou XSRF pour les intimes). Ne connaissant pas cette technique, j’ai donc fait quelques recherches pour me documenter et je me suis monté un petit lab pour voir comment l’utiliser (et la contourner).

Je ne vais pas décrire dans le détail l’histoire et la description de cette faille donc je laisse la main a des spécialistes pour cette partie : http://www.cgisecurity.com/articles/csrf-faq.shtml

Le principe, c’est qu’une page, un site tiers, un mail, un document, etc. exécute une requête vers le site à pirater en utilisant l’identité “reconnue” de l’utilisateur. Cela paraît simple sur le papier mais bien évidemment il faut réunir de nombreuses circonstances pour réussir son coup. La principale étant que le site à pirater doit baser son authentification sur un cookie persistant.

Démonstration : Sur mon site, j’expose une fonctionnalité. On va prendre la plus simple à détourner, le GET : http://lab.djeepy1.net/CSRF/default.aspx?action=achat&article=123456. Supposons que dans le code behind, je vérifie uniquemement la présence d’un cookie pour sécuriser l’action.

if (Request.Cookies["UserId"] != null)
{
    //on considère que l'utilisateur est OK
    BusinessLayer.ShoppingMgr.Buy(Helper.Decrypt(Request.Cookies["UserId"].Value), Request["ArticleId"]);
}

Le site tiers a juste à faire une requête, mais comment peut-il récupèrer la bonne valeur de cookie ? Avec un Cross-Site Scripting (XSS) classique mais pour cela il doit pouvoir exécuter du Javascript sur votre site (cf. règle n° 1 plus haut). L’autre moyen est à la base du Cross-Site Request Forgery : on s’arrange pour que cette requête soit exécutée depuis le navigateur de l’utilisateur, ainsi, les cookies sont automatiquement envoyés au site à pirater avec la fausse requête. Par exemple, on vous envoie un message sur votre webmail avec une image pointant sur la fonctionnalité GET. Vous ne voyez qu’une image “cassée” et pourtant, l’action a eu lieu sur l’autre site.

<img src="http://site/?action=XX"/>

Pourquoi donc Ajax est-il pointé du doigt ? Cette faille est vieille comme le web (1998) mais très difficilement exploitable dans un monde fondé sur les Postback. Avec Ajax, de nombreuses API s’exposent sans pudeur sur le Web, bien souvent accessibles avec un simple GET.

Comment sécuriser son site ? Vérifiez toute l’API exposée et vérifiez que vous n’utilisez pas de cookie persistant pour authentifier une requête ou tout du moins que TOUTE votre sécurité ne soit pas basée sur cet unique moyen. Les Sessions ASP.NET sont protégées de cette faille car elles se basent sur un cookie dit “de session” (temporaire et lié à la navigation).

Cette faille fait la une car on assiste depuis quelques temps à un nouveau type de site Web : le site composite (ou mashup). Un site composite est un assemblage de modules provenant de différents autres sites. Exemple : mes dernières enchères depuis ebay, mes news depuis MSN, ma météo depuis meteoconsult et mon site de chat depuis googletalk. Tout étant exécuté avec le même contexte, un module peut potentiellement exploiter les fonctionnalités d’un autre (via son API Javascript). 

En conclusion, ne cédez pas à la panique et suivez les conseils suivants (qui s’appliquent même au dela de l’informatique) :

• quels sont les risques (mobile du crime, conséquences) ?
• quelles sont les failles (ouvertures, exposition) ?
• comment je souhaite me protéger de ces risques ?

Pour cela, prévoyez toujours une phase d’audit de votre site web avant la mise en production.