Waarom IIS 6.0 veilig(er dan Apache) is

In Internet Information Server 6.0 zijn in de laatste ca. twee en een half jaar slechts 2 vulnerabilities gevonden, tegenover ruim 25 in Apache en 12 in Sun ONE/iPlanet 6.0. Ten opzichte van Apache is een veel gehoord argument dat dit komt omdat IIS 6.0 closed source is en Apache open source, zodat iedereen (in theorie) fouten zou kunnen vinden. Dat maakt echter heel weinig uit, omdat "vulnerability testing" niet op code niveau plaats vindt. Door de complexiteit van deze systemen heeft het weinig zin om op code niveau te kijken. Dat is goed te zien aan het aantal problemen met iPlanet 6.0, dat ook closed source is (en bovendien veel minder gebruikt wordt dan IIS).

Belangrijk voor de veiligheid is "threat modeling" en ontwerp, en na het implementeren TESTEN, TESTEN, TESTEN! En dat is iets dat Microsoft vandaag de dag heeeeel serieus neemt. IIS 6.0 is nadat het ontwikkelproces klaar was nog 18 maanden zeer rigoureus getest. In die 18 maanden is er dus alleen aan bug fixing gedaan op basis van de tests die gedaan werden, er zijn geen nieuwe features toegevoegd. Microsoft heeft een state-of-the-art lab, en de mensen om zich 18 maanden alleen met testen bezig te houden. Dat is wat IIS 6.0 dan ook zo veilig maakt, en is waarschijnlijk waar Apache een groot nadeel heeft. In vergelijking met de Apache Foundation is het budget van Microsoft haast ongelimiteerd. Microsoft kan daardoor een heel leger van mensen inzetten die zich dag in dag uit alleen met vulnerability testing bezig houden. Dat is misschien een beetje oneerlijk, maar wel de realiteit.

Terug van vakantie...

De laatste twee weken heb ik niets gepost. Logisch, ik zat op m'n achterste bij (en soms in) het zwembad in Fuerteventura met vrouw en kinderen. Bovendien was de harddisk van m'n laptop gecrasht, dus ik kon echt NIETS! Eigenlijk wel goed voor zo'n workaholic als ik, want nu heb ik echt rust genomen.

Je leest het goed: ik was niet op de PDC! Het was kiezen tussen PDC of de MVP Summit volgende week, en het is de laatste geworden. Volgende week hopelijk wat nieuws van daar, zolang het niet NDA is uiteraard.

Het eerste nieuwtje van na m'n vakantie: de launch van de Atlas Community Preview Site. Zie voor een uitleg over Atlas m'n eerdere post over ASP.NET 3.0.

Ook guidelines zijn niet altijd goed

Vandaag kwam ik terecht op een pagina waarop staat hoe je volgens Microsoft classes moet implementeren die een event bieden. De pagina in kwestie How to: Create Events that Conform to .NET Framework Guidelines (C# Programmers Reference) komt uit de (pre-release) documentatie van .NET 2.0, en staat ook in de reference voor WinFx. De guideline zegt dat als je class een event aanbiedt deze er als volgt uit moet zien (het gaat hier om het Changed event):

// An event that clients can use to be notified whenever the
// elements of the list change:
public event EventHandler Changed;

// Invoke the Changed event; called whenever list changes:
protected virtual void OnChanged(EventArgs e)
{
if (Changed != null)
   Changed(this,e);
}

Pop Quiz: Wat is hier mis mee?
Hint: Stel je eens voor wat er gebeurt in een van de geregistreerde event handlers een fout optreedt die niet afgehandeld wordt.

Antwoord (tekst is wit, dus even selecteren):
Als in een van de event handlers een fout optreedt, zullen alle nog niet uitgevoerde event handlers nooit uitgevoerd worden, en krijg je een glasharde unhandled exception (=crash). Nu kun je natuurlijk een try-catch block gebruiken om die unhandled exception af te vangen, maar dan hou je dat de nog niet uitgevoerde event handlers niet uitgevoerd worden. In de meeste gevallen is er maar één event handler, dus maakt het nog niet uit, maar het gaat om het principe. Als je verwacht dat meerdere event handlers geregistreerd worden, dan moet je de geregistreerde delegates zelf af gaan, als volgt:

protected virtual void OnChanged(EventArgs e)
{
   if (Changed != null)
   {
      foreach (EventHandler handler in Changed.GetInvocationList())
      {
         try
         {
            handler(this, e);
         }
         catch
         {
            continue;
         }
      }
   }
}


In dit geval ben ik even lui geweest en ga ik bij een fout gewoon door naar de volgende event handler, maar je kunt daar uiteraard ook foutafhandeling toevoegen.