[PHP] SQL-injection?

[Verwijderd]

Ik ben vandaag voor het eerst eens begonnen met php, na al jaren bezig te zijn geweest met C/C++. Dus ging redelijk makkelijk, qua programmeertechnisch gebeuren snap ik het wel. Nu, mijn vraag, die gaat meer over beveiliging. Ik hoor namelijk wel eens over die mysql-injections en andere rotzooi. Ik heb het volgende:

code:

$module = $_GET['module']; 
$page = $_GET['page'];

Wat dit doet hoef ik jullie niet uit te leggen, wat wel zo is, dat ze een int waarde horen te zijn. Ik doe met deze waarden een query op de database. Dus als ze geen getal zijn ben ik niet blij, want dan zou in principe iemand een sql-injection kunnen doen? Nu, is het een slim idee om het volgende te doen:

code:

$module = intval($_GET['module']); 
$page = intval($_GET['page']);

Zo forceer ik dat ze int zijn, en het lijkt mij dat ik hier een mysql-injection voorkom, of mis ik iets? Ik ben niet zo'n hacker of heb nog nooit een sql-injection meegemaakt, maar volgens mij ben ik nu veilig , toch?

[AW_Bos]

Eh, ik zie geen voorbeeld van je query. Maar zolang je maar single quotes gebruikt om je client-side-aanpasbare input... (denk aan $_GET, $_POST en $_COOKIES ben je al erg veilig.

Mijn extra dvies:
gebruik ook mysql_real_escape_string() op je input voor je MySQL..

PHP:

<?php
mysql_query("SELECT id, naam FROM leden WHERE naam = '".mysql_real_escape_string($_GET['id'])."'");
?>

[ Voor 3% gewijzigd door AW_Bos op 19-02-2007 00:12 ]

[Verwijderd]

code:

$result = mysql_query("select page_name, page_content from page where page_id=".$page." and module_id=".$module.";")

Ik gebruik alleen numerieke parameters, dus ik forceer ze naar int, wat dus veilig zou moeten zijn.

[XWB]

Ja, dat is veilig. Als een string een niet numerieke waarde bevat wordt dat gewoon 0. Je kan ook casten:

PHP:

$module = (int) $_GET['module'];

Maar dat is niet betrouwbaar, want php maakt er dit van:

PHP:

$module = '5 een string';
$module = (int) $module;

var_dump ( $module ); // result: int 5

Opletten dus met casten, intval is iig goed genoeg

PHP:

$module = intval ( $_GET['module'] );

if ( $module > 0 )
    mysql_query ( 'INSERT INTO table' );

[disjfa]

Als je je waardes al naar int`s cast dan ben je wel veilig ja. Dus bij jouw is er op dit moment geen probleem.

Hacku schreef op maandag 19 februari 2007 @ 00:16:
Maar dat is niet veilig, want php maakt er dit van:

En dat is niet veilig omdat? Het weerhoud sql injection iig. Dat het waardes overschrijft met integers is waar, maar niet veilig is een heel ander feit.

[ Voor 59% gewijzigd door disjfa op 19-02-2007 00:19 ]

[XWB]

Ariën Clay schreef op maandag 19 februari 2007 @ 00:12:
Mijn extra dvies:
gebruik ook mysql_real_escape_string() op je input voor je MySQL..

PHP:

<?php
mysql_query("SELECT id, naam FROM leden WHERE naam = '".mysql_real_escape_string($_GET['id'])."'");
?>

Niet nodig want intval() geeft gewoon 0 terug bij een niet numerieke waarde in een string.

[ID-College]

Bij zowel strings, als integers gebruik ik altijd addslashes($naam) en mysq_real_escape_string e.d.
Bij deze twee ben je meestal wel vrij van sql injections

[Verwijderd]

Ok, bedankt Nu maar met xml-parsertje spelen

[XWB]

disjfa schreef op maandag 19 februari 2007 @ 00:17:
En dat is niet veilig omdat? Het weerhoud sql injection iig. Dat het waardes overschrijft met integers is waar, maar niet veilig is een heel ander feit.

Laat ik het dan anders zeggen, het is niet betrouwbaar

[GlowMouse]

Hacku schreef op maandag 19 februari 2007 @ 00:16:
Ja, dat is veilig. Als een string een niet numerieke waarde bevat wordt dat gewoon 0. Je kan ook casten:

PHP:

$module = (int) $_GET['module'];

Maar dat is niet betrouwbaar, want php maakt er dit van:

PHP:

$module = '5 een string';
$module = (int) $module;

var_dump ( $module ); // result: int 5

Opletten dus met casten, intval is iig goed genoeg

PHP:

$module = intval ( $_GET['module'] );

if ( $module > 0 )
    mysql_query ( 'INSERT INTO table' );

intval($var) en (int)$var geeft voor zover mij bekend altijd precies hetzelfde resultaat, dus ik snap je post niet echt. Welke je gebruikt is een kwestie van conventie.

Bij zowel strings, als integers gebruik ik altijd addslashes($naam) en mysq_real_escape_string e.d.
Bij deze twee ben je meestal wel vrij van sql injections

Addslashes is een nutteloze functie die je nooit nodig hebt. Aan mysql_real_escape_string heb je, zolang je MySQL gebruikt, genoeg.

Eh, ik zie geen voorbeeld van je query. Maar zolang je maar single quotes gebruikt om je client-side-aanpasbare input... (denk aan $_GET, $_POST en $_COOKIES ben je al erg veilig.

Dan vertrouw je op magic_quotes_gpc. Beter is om eerst te checken of magic_quotes_gpc aanstaat, en zoja je hele G/P/C variabelen te ontdoen van alle slashes. Heb je vervolgens iets nodig voor in de database, kun je er altijd weer mysql_real_escape_string overheen halen. Staat magic_quotes_gpc uit, dan heb je niks meer aan je single quotes omdat er in de input net zo goed een single quote kan staan.

[ Voor 22% gewijzigd door GlowMouse op 19-02-2007 00:27 ]

[XWB]

intval($var) en (int)$var geeft voor zover mij bekend altijd precies hetzelfde resultaat, dus ik snap je post niet echt. Welke je gebruikt is een kwestie van conventie.

Fuck zeg, je hebt nog gelijk ook Ik ging er vanuit dat intval() altijd 0 terug gaf

[eamelink]

ID-College schreef op maandag 19 februari 2007 @ 00:19:
Bij zowel strings, als integers gebruik ik altijd addslashes($naam) en mysq_real_escape_string e.d.
Bij deze twee ben je meestal wel vrij van sql injections

Als je een integer veld hebt in je database hoef je daar niet persé quotes omheen te zetten in je query. Dan is het wel fijn om te zorgen dat er inderdaad een integer komt te staan op die plek en niet een al dan niet ge-mysql-real-escape-de string, want die kan nog steeds je query stuq maken

[ID-College]

eamelink schreef op maandag 19 februari 2007 @ 00:30:
[...]

Als je een integer veld hebt in je database hoef je daar niet persé quotes omheen te zetten in je query. Dan is het wel fijn om te zorgen dat er inderdaad een integer komt te staan op die plek en niet een al dan niet ge-mysql-real-escape-de string, want die kan nog steeds je query stuq maken

Klopt, maar ik selecteer eigenlijk nooit op een INT in een database. Het gene wat ik tot nu toe altijd gebruikt heb is een username, welke altijd (bij mij dan) uit een string bestaat

[Peedy]

Tevens staat op mysql.com een interessant PDFje over SQL Injection. Verplichte kost, me dunkt.

[XWB]

Dan vertrouw je op magic_quotes_gpc. Beter is om eerst te checken of magic_quotes_gpc aanstaat, en zoja je hele G/P/C variabelen te ontdoen van alle slashes. Heb je vervolgens iets nodig voor in de database, kun je er altijd weer mysql_real_escape_string overheen halen. Staat magic_quotes_gpc uit, dan heb je niks meer aan je single quotes omdat er in de input net zo goed een single quote kan staan.

Nooit op magic quotes vertrouwen. In php 6 gaan ze ook verdwijnen. Als je een script maakt dat op verschillende servers moet kunnen werken kan je die invoer maar beter omgedaan maken.

PHP:

function strip_deep ( $data ) 
{
    foreach ( $data as & $item ) 
    {
        $item = is_array ( $item ) ? strip_deep ( $item ) : stripslashes ( $item );
    }

    return $data;
}

if ( get_magic_quotes_gpc() == 1 )
{
    $_GET = strip_deep ( $_GET );
    $_POST = strip_deep ( $_POST );
    $_COOKIE = strip_deep ( $_COOKIE ); 
}

[André]

Move naar Programming

[gvanh]

Tevens staat op mysql.com een interessant PDFje over SQL Injection. Verplichte kost, me dunkt.

Zeker erg nuttig artikel, net gelezen. Iedereen aan te raden!

[Verwijderd]

Maak er een gewoonte van aan binding en parametrisatie via prepared statements te doen in plaats van stringconcatenatie van user input met uw sql-query. Dan kan SQL-Injection nooit voorkomen.

[DexterDee]

Verwijderd schreef op maandag 19 februari 2007 @ 12:05:
Maak er een gewoonte van aan binding en parametrisatie via prepared statements te doen in plaats van stringconcatenatie van user input met uw sql-query. Dan kan SQL-Injection nooit voorkomen.

Een goed database framework zoals Database Objects of Object Relational Mapping maken het leven een stuk aangenamer en voorkomen dat je zelf aan de slag moet met een database abstractie laag. Goede voorbeelden hiervan zijn Propel, Pear:db:dataobjects en de recent in PHP 5.1 toegevoegde PDO classes.

[PrisonerOfPain]

Hacku schreef op maandag 19 februari 2007 @ 00:16:
Maar dat is niet betrouwbaar, want php maakt er dit van:

intval doet anders precies hetzelfde.

code:

Dexter:~ Home$ php -r 'echo (int)"5 bananen","\n";'
5
Dexter:~ Home$ php -r 'echo intval("5 bananen"),"\n";'
5

_{Wat een hoop onzin word er weer gepost...}

[ Voor 22% gewijzigd door PrisonerOfPain op 19-02-2007 13:45 ]

[Verwijderd]

Ik ben blij dat jullie nog een beetje los zijn gegaan, ik ben nu met text-velden bezig, dus ik kan die tips hiervoor weer gebruiken TY!

[flowerp]

Verwijderd schreef op maandag 19 februari 2007 @ 12:05:
Maak er een gewoonte van aan binding en parametrisatie via prepared statements te doen in plaats van stringconcatenatie van user input met uw sql-query. Dan kan SQL-Injection nooit voorkomen.

Dit is gewoon 1 van de meest voor de hand liggende oplossingen. Al dat geneuzel met handmatige escaping en telkens weer andere methodes hiervoor schieten IMHO niet erg op. De andere goede methode is natuurlijk gewoon een framework gebruiken die dit alles al allemaal voor je doet. Deze gebruiken dan overigens onder water ook weer gewoon prepared statements (bv Hibernate doet dat).

[Verwijderd]

Ariën Clay schreef op maandag 19 februari 2007 @ 00:12:
Eh, ik zie geen voorbeeld van je query. Maar zolang je maar single quotes gebruikt om je client-side-aanpasbare input... (denk aan $_GET, $_POST en $_COOKIES ben je al erg veilig.

Sorry voor de kick, maar ik vond het zonde om een nieuw topic er voor te openen.

Misschien een noob-php (ben ik ook ) vraag, waar ik op php.net in de tutorial geen antwoord op kon vinden. Een gast die ik ken zei laatst, dat single quotues sneller geparsed worden dan double-quotes, dat heeft mij aan het denken gezet, en toen ik net weer mijn eigen topic doorlas, zag ik Arien's post weer, en dus mijn vraag, wat is nou het wezenlijke verschil tussen " en ' ??

[GlowMouse]

Verwijderd schreef op zaterdag 03 maart 2007 @ 21:28:
[...]


Sorry voor de kick, maar ik vond het zonde om een nieuw topic er voor te openen.

Misschien een noob-php (ben ik ook ) vraag, waar ik op php.net in de tutorial geen antwoord op kon vinden. Een gast die ik ken zei laatst, dat single quotues sneller geparsed worden dan double-quotes, dat heeft mij aan het denken gezet, en toen ik net weer mijn eigen topic doorlas, zag ik Arien's post weer, en dus mijn vraag, wat is nou het wezenlijke verschil tussen " en ' ??

Doe dit eens:

PHP:

$var = 'woot';
echo "Met dubbele quotes: $var\r\n";
echo 'Met single quotes: $var\r\n';

Je ziet dan de reden waarom single quotes in theorie iets sneller gaan. Het verschil is echter verwaarloosbaar, en je kunt beter andere dingen optimaliseren.

[sky-]

Om het voorbeeld van hierboven maar even te corrigeren :

PHP:

<?php 
$var = 'woot'; 
echo "Met dubbele quotes: ".$var." \r\n"; 
echo 'Met single quotes: '.$var.' \r\n'; 
?>

Want wanneer je bijv :

PHP:

<?php
echo 'Dit is een $var ';
?>

Doet, krijg je ook als output : Dit is een $var..

En ja , single quotes parsen sneller, gewoon "altijd" gebruiken dus.

[ Voor 12% gewijzigd door sky- op 03-03-2007 21:36 ]

[GlowMouse]

k8skaaay schreef op zaterdag 03 maart 2007 @ 21:35:
Om het voorbeeld van hierboven maar even te corrigeren :

PHP:

<?php 
$var = 'woot'; 
echo "Met dubbele quotes: ".$var." \r\n"; 
echo 'Met single quotes: '.$var.' \r\n'; 
?>

Want wanneer je bijv :

PHP:

<?php
echo 'Dit is een $var ';
?>

Doet, krijg je ook als output : Dit is een $var..

Dat is het voorbeeld om zeep helpen, niet corrigeren

[sky-]

Variabelen altijd buiten quotes halen.

Zweef je nog in PHP3 rond ?

[GlowMouse]

k8skaaay schreef op zaterdag 03 maart 2007 @ 21:36:
Variabelen altijd buiten quotes halen.

Ik geef het verschil aan tussen enkele en dubbele quotes. Bij dubbele quotes zie ik trouwens geen voordeel om variabelen buiten quotes te halen; bij enkele quotes echter blijkt het nut uit het voorbeeld.

[CyBeR]

k8skaaay schreef op zaterdag 03 maart 2007 @ 21:36:
Variabelen altijd buiten quotes halen.

Zweef je nog in PHP3 rond ?

Dat wat niet het punt van het voorbeeld Dat was het demonstreren van string-expansion binnen quoted strings. En dat heb je dus grondig om zeep geholpen

[sky-]

Voorbeeld @ GlowMouse :

PHP:

<?php
$var = "witte";
echo "$varkaas";

// zo "moet" het dus :
echo $var."kaas";
// of single quoted :
echo $var.'kaas';
?>

Wat krijg je nu als output ? Juist, helemaal niets. Wel dus variabelen buiten quotes halen. en ja , het is een crap voorbeeld. Maar dit komt vaak genoeg voor.

[ Voor 15% gewijzigd door sky- op 03-03-2007 21:56 ]

[GlowMouse]

k8skaaay schreef op zaterdag 03 maart 2007 @ 21:54:
Voorbeeld @ GlowMouse :

PHP:

<?php
$var = "witte";
echo "$varkaas";

Wat krijg je nu als output ? Juist, helemaal niets. Wel dus variabelen buiten quotes halen. en ja , het is een crap voorbeeld. Maar dit komt vaak genoeg voor.

Weet je dat je accolades kunt gebruiken om de stringnaam duidelijk aan te geven? Het intypen van de accolades is minder typwerk dan het intypen van quotes en puntjes, dus ik vind het zeker verdedigbaar wanneer je dubbele quotes gebruikt.

[Verwijderd]

Maar waarom zijn ze sneller? Er moet een reden voor zijn lijkt me, want in principe bij het parsen, verschillen ' en " niet zo veel van elkaar. Misschien dat er eerst op ' wordt gescanned, maar dan zou het verwaarloosbaar moeten zijn. En het geeft nog steeds geen antwoord waarom Arien schreef:

Maar zolang je maar single quotes gebruikt om je client-side-aanpasbare input... (denk aan $_GET, $_POST en $_COOKIES ben je al erg veilig.

imho moet er dan technisch verschil zijn als hij het zo stelt, toch?

[CyBeR]

Verwijderd schreef op zaterdag 03 maart 2007 @ 22:58:
Maar waarom zijn ze sneller? Er moet een reden voor zijn lijkt me, want in principe bij het parsen, verschillen ' en " niet zo veel van elkaar. Misschien dat er eerst op ' wordt gescanned, maar dan zou het verwaarloosbaar moeten zijn. En het geeft nog steeds geen antwoord waarom Arien schreef:


[...]


imho moet er dan technisch verschil zijn als hij het zo stelt, toch?

Is er ook. De strings met ' wordt niets speciaals gedaan, voor "-strings geldt dat er ook geparsed moet worden op variables enzo.

[Verwijderd]

Kijk een duidelijk antwoord ty

[Gomez12]

Verwijderd schreef op zaterdag 03 maart 2007 @ 22:58:
Maar waarom zijn ze sneller? Er moet een reden voor zijn lijkt me, want in principe bij het parsen, verschillen ' en " niet zo veel van elkaar. Misschien dat er eerst op ' wordt gescanned, maar dan zou het verwaarloosbaar moeten zijn. En het geeft nog steeds geen antwoord waarom Arien schreef:


[...]


imho moet er dan technisch verschil zijn als hij het zo stelt, toch?

Enige technische reden die ik kan bedenken is dat php bij " variabelen expand, hij moet dus eerst de string controleren op variabelen. Met ' doet hij geen expanding van je variabelen.

En daar zit volgens mij ook gelijk het probleem met " in. Het expanden kan onverwachte resultaten geven ( zie voorbeeld van k8skaay ).

En btw het snelheidsverschil is zo marginaal dat het voor snelheid niets uitmaakt in een gemiddeld php-script. Snelheidsverschil is imho dan ook geen reden om voor ' te kiezen. Alhoewel ik wel moet zeggen dat ik me gewoon heb aangeleerd om gewoon ' te gebruiken ipv " maar dat is om het expanden dan om een snelheidsverschil.

[MisterData]

Verwijderd schreef op zaterdag 03 maart 2007 @ 22:58:
Maar waarom zijn ze sneller? Er moet een reden voor zijn lijkt me, want in principe bij het parsen, verschillen ' en " niet zo veel van elkaar. Misschien dat er eerst op ' wordt gescanned, maar dan zou het verwaarloosbaar moeten zijn. En het geeft nog steeds geen antwoord waarom Arien schreef:


[...]


imho moet er dan technisch verschil zijn als hij het zo stelt, toch?

Ze zijn technisch niet zo gek veel sneller, geloof dat er ergens een topic is waar een aantal GoT'ers dat benchmarkten Je moet het zo zien (ik denk dat het zo gaat want dat is ongeveer wat een standaard scripting-engine implementatie doet, en ja, ik heb er zelf laatst nog een gemaakt): tijdens het 'uitvoeren' van je script wordt eerst het script omgebouwd ('geparsed') naar een 'parse tree'. Dat is een in-memory representatie van je script; op dat punt heeft de parser al uitgevogeld dat 'ie in plaats van letterlijk "AAAA $var BBB" als string interpreteren eigenlijk moet concateneren ("AAAA" . $var . "BBB"). De parser doet dus wat extra werk en zoekt alle dollartekens in string literals; daarna wordt je script uitgevoerd en is het daadwerkelijk concateneren even snel als de tweede manier

Zou je PHP laten compileren naar bytecode (voorzover ik weet al wel mogelijk maar redelijk experimenteel) dan zouden ze at-runtime waarschijnlijk even snel zijn

[_js_]

.

[ Voor 99% gewijzigd door _js_ op 03-03-2007 23:20 . Reden: overbodig ]

[mithras]

Als je een mega-grote dikke website hebt draaien die tig van dit soort outputs moet doen, _dan_ merk je verschil.

Toen ik begon met php was ik keurig alles met punten aan elkaar aan het plakken; nu door luiheid gewoon doortypen. Het werkt ook, de snelheid is verwaarloosbaar klein en met een goede php editor worden de variabelen binnen dubbele quotes ook netjes gehilighted. Geen probleem dus, en het typt stukken sneller.
Heb je elementen van arrays, dan doe ik voor de zekerheid wel accolades.

PHP:

echo "Test $variabele test";
echo "Test {$variabele["test"]} test";

Zo dus

[CyBeR]

MisterData schreef op zaterdag 03 maart 2007 @ 23:19:
[...]

Zou je PHP laten compileren naar bytecode (voorzover ik weet al wel mogelijk maar redelijk experimenteel) dan zouden ze at-runtime waarschijnlijk even snel zijn

Niks experimenteels aan. Da's precies wat Zend doet, evenals een aantal andere php caching extensies en d'r is geloof ik ook een php voor .NET die hetzelfde doet.

[Verwijderd]

Als ik numerieke GET variablen verwacht doe ik het altijd zo:

PHP:

<?php
if(is_numeric($_GET['id']))
{
   // Print pagina hier
}
else
{
  // Print iets van "Pagina is niet gevonden"
}
?>

Werkt vrij goed naar mijn mening.

[Cartman!]

mithras schreef op zondag 04 maart 2007 @ 00:07:
Als je een mega-grote dikke website hebt draaien die tig van dit soort outputs moet doen, _dan_ merk je verschil.

Toen ik begon met php was ik keurig alles met punten aan elkaar aan het plakken; nu door luiheid gewoon doortypen. Het werkt ook, de snelheid is verwaarloosbaar klein en met een goede php editor worden de variabelen binnen dubbele quotes ook netjes gehilighted. Geen probleem dus, en het typt stukken sneller.
Heb je elementen van arrays, dan doe ik voor de zekerheid wel accolades.

PHP:

echo "Test $variabele test";
echo "Test {$variabele["test"]} test";

Zo dus

Is natuurlijk persoonlijk maar wat een ranzige notatie... Als iemand jouw code moet editten is t echt n hel voor diegene. Gelukkig hebben we waar ik werk n interne code standaard die voorschrijft dat het

PHP:

echo 'Test' . $strVariabele . 'test';
echo 'Test' . $arrVariabele['test'] . 'test';

is. Generiek, sneller en veiliger

Als jij met een probleem zit en je post de code van je zo op GoT zal ik je minder snel helpen dan met een duidelijk ge-highlight stukje code. Moet ik eerst ontcijferen hoe en welke variabelen je precies aanroept, nee dankje.

[ Voor 11% gewijzigd door Cartman! op 04-03-2007 11:27 ]

[Toolskyn]

k8skaaay schreef op zaterdag 03 maart 2007 @ 21:35:

PHP:

<?php 
$var = 'woot'; 
echo "Met dubbele quotes: ".$var." \r\n"; 
echo 'Met single quotes: '.$var.' \r\n'; 
?>

Dat gaat niet goed met single quotes, \r\n wordt niet geparsed, dus newlines moet je wel met dubbele quotes doen...

[mithras]

Cartman! schreef op zondag 04 maart 2007 @ 11:24:
[...]

Generiek,

Is toch wel subjectief denk ik

sneller

Dat valt dus echt heel erg mee, als je die nanosecondes wil meetellen ben je echt aan het mierenneuqen. Zie bijvoorbeeld de post op scriptorama waar het wel bewezen wordt, maar met het juiste perspectief

en veiliger

Want? Waarom zou variabelen buiten je strings halen veiliger zijn dan erin laten? Ik zie het verschil niet zo...

Als jij met een probleem zit en je post de code van je zo op GoT zal ik je minder snel helpen dan met een duidelijk ge-highlight stukje code. Moet ik eerst ontcijferen hoe en welke variabelen je precies aanroept, nee dankje.

Toevallig werkt op GoT het niet zo dat $vars binnen quotes als variabelen worden geparsed, maar gewoon met de rest van de string mee. In testcases op GoT haal ik het dus ook even buiten de quotes

Maar de stelling dat je iemand minder snel zal helpen omdat die een andere syntax gebruikt vind ik toch wel heel vreemd hoor

En nogmaals, met een fijne editor zie je het dus zo:

PHP:

$this->display .= "<a name=\"newsitem\"></a>
                <h3>$caption</h3>
                <p class=\"blog-upper-notes\">Door <a href=\"user/profile/$user_id\">$user</a> op $date @ $time</p>
                $message
                <p class=\"blog-lower-notes\">$tags<br>
                $display_edit<a href=\"blog/$article/$caption_link.html\">Link</a> | $display_source $react_number</p>";

gPHPEdit

Toolskyn schreef op zondag 04 maart 2007 @ 12:43:
[...]

Dat gaat niet goed met single quotes, \r\n wordt niet geparsed, dus newlines moet je wel met dubbele quotes doen...

Dat was precies het punt van k8skaaay post: dubbele quotes parsed wel $vars en \r, \n, \t etc. Terwijl single quotes dat niet doen (en dus theoretisch iets sneller kan zijn).

[ Voor 14% gewijzigd door mithras op 04-03-2007 13:00 ]