In een reeks van artikelen probeer ik uit te leggen hoe je, je website kunt beschermen tegen aanvallen van buitenaf. Vandaag gaan we het hebben over Cross-site scripting (XSS).

Cross-site scripting is een aanval waarbij een stuk kwaadwillende code op een website word geïnjecteerd Waneer iemand de pagina bezoekt, word de code uitgevoerd.

Case 1

Stel dat je een website hebt ontworpen waarop bezoekers reacties kunnen achterlaten:

Code blok

<?php
  echo "$gebruiker zei $bericht";
?>

De code voor invoer van het bericht kan er als volgt uitzien:

Code blok

<?php
  $gebruiker = $_COOKIE['gebruiker'];
  $bericht = $_REQUEST['bericht'];
  if($bericht) {
     opslaan_bericht($gebruiker, $bericht);
  }
?>
<input type="text" name="bericht" value="<?php echo $bericht ?>">

Zolang een gebruiker alleen maar  simpele tekst invoert is er geen enkel probleem. Doordat er niet gecontroleerd wordt wat een gebruiker schrijft, kan iemand er willekeurige HTML code tussen plaatsten. Door bijvoorbeeld </div> in een bericht te plaatsen kan een aanvaller er bijvoorbeeld voor zorgen dat de HTML van je pagina niet meer klopt. Hoewel dit behoorlijk irritant is, is het nog behoorlijk onschuldig.

Een aanvaller kan ook bijvoorbeeld  de volgende code in zijn bericht stoppen:

Code blok

<script src="h++p://abc.com/abcscript.js"></script>

Wanneer iemand deze pagina dan bezoekt, word ook gelijk het script  abcscript.js van de website h++p://abc.com uitgevoerd. Deze script kan dan bijvoorbeeld gebruikt worden om een virus te plaatsen op de computer van de bezoeker.

Case 2

Een tweede voorbeeld van een XSS aanval is een aanval via de URL van een website.  Veel websites gebaseerd op WordPress hebben een zoekmachine ingebouwd.

Op deze site kan je zoeken door de volgende url in te typen:

http://zifp.nl/?s=zoekterm

In plaats van een zoekterm kan een aanvaller een stuk  code invoeren:

http://zifp.nl/?s=<script type="text/javascript"> alert('XSS!') </script>


Gevaarlijk aan deze aanval is dat de url er zelf onschuldig uitziet:
http://zifp.nl/?s=%3Cscript%20type=%22text/javascript%22%3E%20alert('XSS!')%20%3C/script%3E
Je kan niet duidelijk zien of er sprake is van een script.

Doordat veel wordpress templates niet goed in elkaar zitten werkt bovenstaande code op een heleboel websites. Probeer maar eens.

Oplossing

Om te voorkomen dat een bezoeker kwaadwillende code op je website plaatst moet alle invoer op je website gecontroleerd worden op vijandige code en moet alle vijandige code verwijderd worden.

Een belangrijk hulpmiddel in het ontdekken van malafide code en het schoonmaken daarvan is  PHP’s input_filter extensie.

We kunnen bovenstaande code dan in het volgende veranderen:

Code blok

<?php
  $gebruiker = filter_input(INPUT_COOKIE, 'gebruiker',
                         FILTER_SANITIZE_SPECIAL_CHARS);
  $bericht = filter_input(INPUT_POST | INPUT_GET, 'bericht',
                         FILTER_SANITIZE_SPECIAL_CHARS);
  if($bericht) {
     save_message($gebruiker, $bericht);
  }
?>
<input type="text" name="bericht" value="<?php echo $bericht ?>">

Belangrijk is om de code zo snel mogelijk na de invoer te valideren en schoon te maken zodat malafide code bijvoorbeeld niet in je database kan opduiken. Hoe eerder de code schoon is, hoe minder fouten er gemaakt kunnen worden.

Er zijn een heleboel verschillende filters voor PHP beschikbaar. Gebruik de filters die toepasbaar zijn op jouw situatie en probeer altijd zo streng mogelijk te controleren.

Je kan er ook aan denken om bijvoorbeeld de functies

Code blok

html_entity_decode()
htmlentities()

te gerbuiken. Deze functies worden gebruikt om speciale tekens naar de juiste HTML code en weer terug om te zetten.

Het controleren van bijvoorbeeld een E-mail adres zou dan toch goed ingeburgerd moeten zijn bij de gemiddelde website ontwerper. Toch blijkt dit vaak fout te gaan.

Heel vaak een functie zoals de volgende gebruikt:

Code blok

function checkEmail($email) {
if(preg_match("/^([a-zA-Z0-9])+([a-zA-Z0-9\._-])
↪*@([a-zA Z0-9_-])+([a-zA-Z0-9\._-]+)+$/", $email))
// Checkt door middel van een reguliere expressie of de email kan bestaan
   {list($username,$domain)=split('@',$email);
// splitst email adres in stuk voor en achter het @ symbool
 
   if(!checkdnsrr($domain,'MX')){
      return false;
   }
// kijk of het stuk achter @ een geldige domein is
   return true;
}
return false;

Deze code houd veel foute email adressen tegen maar blokkeert ook veel geldige adressen.

Wist je  dat de volgende adressen gewoon geldig zijn:

• Abc\@abc@voorbeeld.com
• voorbeeld=voorbeeld@voorbeeld.com
• !abc!def%abc@voorbeeld.com

Deze adressen werden door de voorbeeldfunctie geblokkeerd.

Als je op de juiste manier e-mail wil valideren is het belangrijk om de regels eens goed te bekijken.

Volgens het IETF gelden voor een e-mail adres de volgende regels:

1. An e-mail address consists of local part and domain separated by an at sign (@) character (RFC 2822 3.4.1).
2. The local part may consist of alphabetic and numeric characters, and the following characters: !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, |, } and ~, possibly with dot separators (.), inside, but not at the start, end or next to another dot separator (RFC 2822 3.2.4).
3. The local part may consist of a quoted string—that is, anything within quotes (“), including spaces (RFC 2822 3.2.5).
4. Quoted pairs (such as \@) are valid components of a local part, though an obsolete form from RFC 822 (RFC 2822 4.4).
5. The maximum length of a local part is 64 characters (RFC 2821 4.5.3.1).
6. A domain consists of labels separated by dot separators (RFC1035 2.3.1).
7. Domain labels start with an alphabetic character followed by zero or more alphabetic characters, numeric characters or the hyphen (-), ending with an alphabetic or numeric character (RFC 1035 2.3.1).
8. The maximum length of a label is 63 characters (RFC 1035 2.3.1).
9. The maximum length of a domain is 255 characters (RFC 2821 4.5.3.1).
10. The domain must be fully qualified and resolvable to a type A or type MX DNS address record (RFC 2821 3.6).

Aan de hand van deze regels kunnen we een goede email validator bouwen.

Code blok

function validEmail($email)
{
   $isValid = true;
   $atIndex = strrpos($email, "@"); //kijkt waar de @ zit
   if (is_bool($atIndex) && !$atIndex) //controleert of @ in de mail voorkomt
   {
      $isValid = false;
   }
   else
   {
      $domain = substr($email, $atIndex+1);
      $local = substr($email, 0, $atIndex); //splits de e-mail in een stuk voor en na het @ teken
      $localLen = strlen($local);
      $domainLen = strlen($domain); //bekijkt de lengte van stukjes
      if ($localLen < 1 || $localLen > 64)
      {
         // kijkt of het stuk voor de @ tussen  de 1 en 64 tekens bevat
         $isValid = false;
      }
      else if ($domainLen < 1 || $domainLen > 255)
      {
         // Bekijkt of het stuk na de @ tussen de 1 en 255 tekens bevat
         $isValid = false;
      }
      else if ($local[0] == '.' || $local[$localLen-1] == '.')
      {
         // kijkt of het locale deel begint of eindigt met een  '.'
         $isValid = false;
      }
      else if (preg_match('/\\.\\./', $local))
      {
         // kijkt of er 2 punten achter elkaar zitten
         $isValid = false;
      }
      else if (!preg_match('/^[A-Za-z0-9\\-\\.]+$/', $domain))
      {
         // Kijkt voor een ongeldig teken in het domein deel
         $isValid = false;
      }
      else if (preg_match('/\\.\\./', $domain))
      {
         // Kijkt of het domein 2 punten achter elkaar bevat
         $isValid = false;
      }
      else if
(!preg_match('/^(\\\\.|[A-Za-z0-9!#%&`_=\\/$\'*+?^{}|~.-])+$/',
                 str_replace("\\\\","",$local)))
      {
         // Kijkt naar een ongeldig teken in het domein
         // Als er quotes in staan is deze toch geldig
         if (!preg_match('/^"(\\\\"|[^"])+"$/',
             str_replace("\\\\","",$local)))
         {
            $isValid = false;
         }
      }
      if ($isValid && !(checkdnsrr($domain,"MX") ||
 ↪checkdnsrr($domain,"A")))
      {
         // Bekijkt of het domein in het DNS gevonden kan worden
         $isValid = false;
      }
   }
   return $isValid;
}

Ondanks dat deze vreemde email adressen niet vaak gebruikt worden is het toch een goed idee om deze niet bij voorbaat al te blokkeren. Deze vreemde adressen zijn voor veel mensen een manier om bijvoorbeeld spam tegen te houden.