[PHP] Formvalidatie

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • risr
  • Registratie: Juli 2002
  • Laatst online: 17-08 11:38
Op phpsec.org kwam ik een beveiligingsmethode tegen welke controleert of de namen van de verzonden $_POST variabelen wel geldig zijn:

http://phpsec.org/projects/guide/1.html#1.4.2

Ik dacht laat ik dit uitbreiden door ook op type en bereik te controleren, inmiddels ben ik al een heel eind en ben ik benieuwd wat jullie ervan vinden, het is uiteraard nog wel een testversie. Je kan het script (testcase) hier downloaden als je wilt.

Om deze methode te implementeren in je eigen PHP applicaties moet je voor elk formulier waar je deze methode wilt toepassen een controle-array inbouwen waarin staat welke POST variabelen geldig zijn, alsmede in welke volgorde, van welk type, minimale lengte/waarde, maximale lengte/waarde, mogelijke waarden, mod flags en een eventuele foutmelding.

Voorbeeld:

HTML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!-- html formulier -->
<form action="test.php" method="post">

  Your name: <input type="text" name="test1"><br>

  <input type="checkbox" name="test2[]" value=0>X 
  <input type="checkbox" name="test2[]" value=1>Y<br>

  <textarea name="test3" cols=40 rows=10></textarea><br>

  <input type="submit" name="btnSubmit" value="ok"> 
  <input type="submit" name="btnSubmit" value="cancel">

</form>


PHP:
1
2
3
4
5
// Het controle-array:
$allowed = array( 'test1' => array('string', true, 0, 30, 0, _UCWORDS, 'Please enter your name.'),
                  'test2' => array('array', true, 0, 3, array(0,1), _NONE, 'Select one or two valid options.'),
                  'test3' => array('string', false, 0, 400, 0, _NL2BR | _UCWORDS | _HTMLENT, 'Your story was too long.'),
                  'btnSubmit' => array('submit', true, 0, 0, array('ok', 'cancel'), _NONE, 'Wrong button') );


Bij een postback moet je voor elke POST variabele de functie check_key_type_range() aanroepen, als deze true returned kan je de invoer redelijk vertrouwen, maar het verdient wel om nog verder te gaan waar check_key_type_range() stopt:

PHP:
1
2
3
4
5
6
7
$sent = $_POST;
$clean = array();
  
foreach ($allowed as $key => $value) {
  if (check_key_type_range($key, $sent[$key]))
    $clean[$key] = $sent[$key];
}


Vertrouw dus alleen op de waarden in $clean

Na deze controle kan je specifiek gaan verifiëren, bijvoorbeeld of een opgegeven e-mail adres wel daadwerkelijk een geldig e-mail adres is (gebruik hiervoor reguliere expressies).

De functie in kwestie:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
function check_key_type_range($key, &$value)
{
  global $allowed;

  // Ignore anything that is both empty and not required:
  if ( (is_null($value)) && (!$allowed[$key][_REQ]))
    return true;

  // Check type and range
  switch ($allowed[$key][_TYPE])
  {
    case 'string':
      if (is_string($value))
        if (strlen($value) > $allowed[$key][_MIN])
          if (strlen($value) < $allowed[$key][_MAX]) {
            apply_mod($key, $value);
            return true;
          }
      break;

    case 'int':
      if (is_numeric($value))
        if ($value > $allowed[$key][_MIN])
          if ($value < $allowed[$key][_MAX])
            if (is_array($allowed[$key][_ALLOWED])) {
              if (in_array($value, $allowed[$key][_ALLOWED]))
                return true;
            }
            else return true;
      break;

    case 'array':
      if (is_array($value)) {
        if (sizeof($value) > $allowed[$key][_MIN])
          if (sizeof($value) < $allowed[$key][_MAX]) {
            if (is_array($allowed[$key][_ALLOWED]))
              for ($i=0; $i<sizeof($value); $i++)
                if (!in_array($value[$i], $allowed[$key][_ALLOWED]))
                  return false;
            return true;
          } else return false;
      }
      else return false;
      break;

    case 'checkbox':
      if (is_array($value)) {
        for ($i=0; $i<sizeof($value); $i++)
          if (!in_array($value[$i], $allowed[$key][_ALLOWED]))
            return false;
        return true;
      }
      break;

    case 'submit':
      if (is_string($value))
        if (in_array($value, $allowed[$key][_ALLOWED]))
          return true;
      break;
  }
  
  return false;
}


Met de mod flags in het controle-array kan je aangeven welke bewerkingen uitgevoerd moeten worden, dit is alleen van toepassing op het type string:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
function apply_mod($key, &$value)
{
  global $allowed;

  if ($allowed[$key][_MOD] & _TRIM)
    $value = trim($value);
  
  if ($allowed[$key][_MOD] & _UCWORDS)
    $value = ucwords(strtolower($value));
  
  if ($allowed[$key][_MOD] & _HTMLENT)
    $value = htmlentities($value);

  if ($allowed[$key][_MOD] & _NL2BR)
    $value = nl2br($value);
  
  if ($allowed[$key][_MOD] & _ADDSLASH)
    $value = addslashes($value);
}


PS.: Type 'checkbox' is overbodig vanwege type 'array'
PS2.: Met het tweede veld kan je aangeven of een veld verplicht is of niet.

[ Voor 25% gewijzigd door risr op 09-02-2005 22:41 ]


Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Het is gewoon een formvalidator dus :?
Waarom dan zo'n hoop code?

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

  • RwD
  • Registratie: Oktober 2000
  • Niet online

RwD

kloonikoon

Hoe maakt dit de site veiliger?

Als ik POST variabelen stuur om een systeem te gaan lopen hacken zou ik het per ongeluk al in de goede volgorde doen, simpelweg omdat het niet in mn gedachte op zou komen om ze te herordenen. Namen en maximale waardes zou ik ook altijd volgen, tenslotte werkt het systeem daar mee (eventueel andere lengtes zou ik wel gebruiken als ik wist dat het systeem daar gevoelig voor is).

Dus ik zie even de beveiliging niet. Misschien kun je een voorbeeld geven van een situatie waarin dit van pas komt?

[edit]
En de form validatie kan met minder code.

Trouwens met emailadressen moet je oppassen, laatst kreeg ik een klacht omdat een emailadres niet geaccepteerd werd. Volgens de regels die ik gevonden had was dat emailadres ook eigenlijk niet geldig. Maar blijkbaar werkte het wel |:(

[ Voor 24% gewijzigd door RwD op 07-02-2005 10:03 ]


Acties:
  • 0 Henk 'm!

  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 18:02
Emailadressen enzo kun je toch alleen maar controleren op @ en een . of : daarna. En dan nog heb je er nog niets aan als iemand spam@woei.spef invoert.

Form validatie met een bepaalde VOLGORDE lijkt me erg loos. Je eigen systeem wordt er ook niet handiger op; als je de layout wilt veranderen moet je ook nog eens je code aanpassen... Gewoon kijken of alle waardes in een bepaalde range zitten lijkt mij voldoende.

Verder sluit ik me aan bij SchizoDuckie.

[ Voor 5% gewijzigd door Mithrandir op 07-02-2005 11:40 ]

Verbouwing


Acties:
  • 0 Henk 'm!

  • RwD
  • Registratie: Oktober 2000
  • Niet online

RwD

kloonikoon

Mithrandir schreef op maandag 07 februari 2005 @ 11:40:
Form validatie met een bepaalde VOLGORDE lijkt me erg loos. Je eigen systeem wordt er ook niet handiger op; als je de layout wilt veranderen moet je ook nog eens je code aanpassen...
En daarmee is bijna het hele voorbeeldsysteem nutteloos waarop dit gebaseerd is trouwens, niet?

Acties:
  • 0 Henk 'm!

  • TRON
  • Registratie: September 2001
  • Laatst online: 16-09 13:13
Mithrandir schreef op maandag 07 februari 2005 @ 11:40:
Emailadressen enzo kun je toch alleen maar controleren op @ en een . of : daarna. En dan nog heb je er nog niets aan als iemand spam@woei.spef invoert.

Form validatie met een bepaalde VOLGORDE lijkt me erg loos. Je eigen systeem wordt er ook niet handiger op; als je de layout wilt veranderen moet je ook nog eens je code aanpassen... Gewoon kijken of alle waardes in een bepaalde range zitten lijkt mij voldoende.

Verder sluit ik me aan bij SchizoDuckie.
Je kan natuurlijk kijken of het domein bestaat :)

Maar om ontopic te gaan: zo'n formvalidator is leuk en aardig maar ook ik zie niet in wat hier veiliger is. Volgens mij hou je hierdoor geen SQL-injection tegen en geen XSS-exploits, of ben ik nu een beetje nog niet wakker?

Leren door te strijden? Dat doe je op CTFSpel.nl. Vraag een gratis proefpakket aan t.w.v. EUR 50 (excl. BTW)


Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 02:21

Janoz

Moderator Devschuur®

!litemod

De term beveiligingsmethode voor forms is eigenlijk slecht gekozen. Formvalidatie is een stuk beter. Ik mis echter nog wel een heleboel controles. Daarnaast zou het ook mooi zijn wanneer de validatie ook clientside gedaan kon worden dor gegenereerd javascript.

Wat enkele mensen hierboven over het hoofd zien is dat enkel de controle array aangepast en opgenomen hoeft te worden in je script. De rest kun je vanuit 1 lib in elk form verwerkend script includen.

Ikzelf gebruik trouwens het validator framwork van apache's jakarta commons. Dit is wel in java, maar het javascript dat ze daar hebben en de controle mogenlijkheden zijn een mooi uitgebreide set die je ook zou kunnen implementeren.

Een mooie uitbreiding zou oa kunnen zijn:
* Configuratie via een xml bestandje dat je inleest ipv de iets onduidelijke array configuratie
* Toevoegen van een reguliere expressie waaraan een antwoord moet voldoen
* vergelijken van velden onderling (password en password2 gelijk aan elkaar)

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

  • RwD
  • Registratie: Oktober 2000
  • Niet online

RwD

kloonikoon

Janoz schreef op maandag 07 februari 2005 @ 12:50:
...
Wat enkele mensen hierboven over het hoofd zien is dat enkel de controle array aangepast en opgenomen hoeft te worden in je script. De rest kun je vanuit 1 lib in elk form verwerkend script includen.
...
Ik had er niks over gezegd, maar wat gezegd wordt klopt nog steeds. Wil je je html wijzigen dan moet je plotseling ook je php code wijzigen terwijl dit strikt genomen geen enkel doel dient. Volgorde van je input hoeft niet gegarandeerd te zijn om juiste informatie te bevatten??

Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 02:21

Janoz

Moderator Devschuur®

!litemod

Beetje jammer dat je het hele idee gelijk afkeurt alleen maar om dat op 1 punt ergens wordt gezegd dat de volgorde wordt gecontroleerd. Inderdaad is dat complete onzin. Er is zelfs nergens vermeld dat de volgorde waarin elementen op een pagina staan ook gelijk is aan de volgorde waarop ze worden verstuurd. Ik zie echter nergens in de code dat die volgorde ook daadwerkelijk afgedwongen wordt. En mocht dat wel zo zijn dan is het handiger om dit er inderdaad uit te halen.

Wat jij echter wel over het hoofd ziet is dat deze formvalidatie ongeveer aantal velden + 1 regels kost. een uitgebreide foreach die alles valideert is immers ook gewoon in die ge-include lib op te nemen. Veel korter en overzichtelijker krijg je het imho niet snel.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

  • RwD
  • Registratie: Oktober 2000
  • Niet online

RwD

kloonikoon

Ik keur het geheel niet af maar het voorbeeld waar dit op gebaseerd was stelt dat er meer veiligheid is door de volgorde en het aantal velden te checken dat ontvangen wordt. Als dit uit het gehele systeem wordt gehaald heeft hij iets dat niet echt gerelateerd is aan waar het vandaan komt. Maar over de rest van het systeem heb ik alleen gezegd dat emailvalidatie soms tricky is.

Bij emailvalidatie geef ik meestal de melding "Uw emailadres 'bla#hetnet.nl' is zo op het eerste oog zonder het echt goed gecontroleerd te hebben wellicht misschien niet helemaal correct. Weet u zeker dat u deze waarde in ons systeem wilt invoeren?" (soms met een andere bewoording) maar laat in principe iedere waarde toe omdat "fakeadres@hotmail.com" snel genoeg ingetypt is). Emailadressen kun je alleen maar valideren door een email te sturen en zien of alles goed gaat. Als je dan een email terug verwacht valideer je ook of de gebruiker bij het emailadres hoort...

Acties:
  • 0 Henk 'm!

  • RwD
  • Registratie: Oktober 2000
  • Niet online

RwD

kloonikoon

Stomme vraag van mij zeker omdat ik alleen deze 3 regels gelezen heb, maar waar precies check je of dit array vereist is??

PHP:
1
2
3
  // Ignore empty arrays that are not required: 
  if ( (is_array($value)) && (sizeof($value) < 1)) 
    return true;


Misschien interpreteer ik je commentaar wel verkeerd trouwens...

Acties:
  • 0 Henk 'm!

  • Bob Popcorn
  • Registratie: Juni 2002
  • Laatst online: 17:54

Bob Popcorn

Plop!

Mithrandir schreef op maandag 07 februari 2005 @ 11:40:
Emailadressen enzo kun je toch alleen maar controleren op @ en een . of : daarna. En dan nog heb je er nog niets aan als iemand spam@woei.spef invoert.

Form validatie met een bepaalde VOLGORDE lijkt me erg loos. Je eigen systeem wordt er ook niet handiger op; als je de layout wilt veranderen moet je ook nog eens je code aanpassen... Gewoon kijken of alle waardes in een bepaalde range zitten lijkt mij voldoende.

Verder sluit ik me aan bij SchizoDuckie.
Nee hoor, je kan ook nog kijken of het domein een MXrecord, en kijken of deze actief is door een socket naar poort 25 te openen met de volgende functie:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
list($Username, $Domain) = split("@",$email);
if(getmxrr($Domain, $MXHost)) 
{
   return TRUE;
}
else 
{
   if(fsockopen($Domain, 25, $errno, $errstr, 30)) 
   {
      return TRUE; 
   }
   else 
   {
      return FALSE; 
   }
}


Ik ben hier veel mee bezig op het moment, ik hou dit topic in de gaten! :)

Kan niet stoppen met ontploffen!


Acties:
  • 0 Henk 'm!

  • raps
  • Registratie: April 2003
  • Laatst online: 06-09 19:51
Zelf heb ik mij laten inspireren door het strategy pattern, uitgelegd op phppatterns.com. Deze heb ik vervolgens geintegreerd met mijn Form-class. Bij een addField()-methode van mijn Form-class, kan ik een validator meegeven. addField() maakt vervolgens een Field-object aan, welke dus een Validator-object aan zich gekoppeld heeft. De Form class loopt door zijn velden heen en wanneer er een Validator aan gekoppeld is, valideert hij de input van dit veld.
Wellicht kun je hier iets mee.

Een ander te overwegen alternatief is het gebruik van Filters, waarbij je dus meerdere filters aan een veld kunt koppelen.

[ Voor 11% gewijzigd door raps op 07-02-2005 14:36 ]


Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Ikzelf ben bezig (geweest) aan zoiets :X

http://www.schizofreend.nl/

Moet het nog een keer afbouwen zodra ik het weer nodig heb..
De bedoeling is dus dat je met een simpele sleep-en-pleur een formulier in elkaar kan sleuren die je met 1 simpele $form->display($formid) weer weer kan uitpoepen in een pagina :)


Het allermooiste hieraan is dus dat je je over de hele validatiekwestie *nooit* meer druk hoeft te maken aangezien dit aan de clientside én de serverside ingebakken zit.

[ Voor 23% gewijzigd door SchizoDuckie op 07-02-2005 15:36 ]

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

Verwijderd

:X
Is dit niet gewoon PEAR::QuickForm nabouwen?

http://pear.php.net/manua...ml-quickform.tutorial.php

Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Bob Popcorn schreef op maandag 07 februari 2005 @ 13:43:
Nee hoor, je kan ook nog kijken of het domein een MXrecord, en kijken of deze actief is door een socket naar poort 25 te openen met de volgende functie:
En als het domein geen MX record heeft?
Of als de SMTP server tijdelijk down is?

[ Voor 7% gewijzigd door Olaf van der Spek op 07-02-2005 23:20 ]


Acties:
  • 0 Henk 'm!

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

OlafvdSpek schreef op maandag 07 februari 2005 @ 23:17:
[...]

En als het domein geen MX record heeft?
dan is het vrij lastig om een mailtje te sturen naar dat domein ;)

Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Erkens schreef op maandag 07 februari 2005 @ 23:18:
dan is het vrij lastig om een mailtje te sturen naar dat domein ;)
Dat gaat dan toch gewoon naar het 'A' adres?

Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 02:21

Janoz

Moderator Devschuur®

!litemod

Eigenlijk is er maar 1 redelijk betrouwbare manier voor het valideren van een email adres, en dat is gewoon een validatie mailtje versturen naar het adres, en de bezoeker pas verder laten gaan waneer deze opgestuurde validatie code is ingevuld.

Validatie op het ingevulde email adres zou imho alleen moeten dienen om tikfouten te verbeteren (, ipv.) en om de achterliggende software niet onderuit te laten gaan vanwege illegale email adres vormen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

  • risr
  • Registratie: Juli 2002
  • Laatst online: 17-08 11:38
De titel van het topic heb ik nogal ongelukkig gekozen, "[PHP] Formvalidatie" zou beter geweest zijn, dus daar hebben jullie wel een punt, het is inderdaad een formvalidator maar niet zo gewoon als SchizoDuckie beweert anders was ik deze methode wel eens eerder tegengekomen. Topic change request is inmiddels ingediend.

Met het punt dat het teveel code zou zijn ben ik het niet eens, lees de opmerking van Janoz maar eens, had ik zelf niet beter kunnen verwoorden:
Janoz schreef op maandag 07 februari 2005 @ 12:50:
...enkel de controle array aangepast en opgenomen hoeft te worden in je script. De rest kun je vanuit 1 lib in elk form verwerkend script includen.

Janoz schreef op maandag 07 februari 2005 @ 13:14:
...deze formvalidatie ongeveer aantal velden + 1 regels kost.
Een paar replies:
Janoz schreef op maandag 07 februari 2005 @ 12:50:
Daarnaast zou het ook mooi zijn wanneer de validatie ook clientside gedaan kon worden dor gegenereerd javascript.
Ik ga eens kijken in hoevere dit haalbaar is, althans voor mij dan, het is wel een goed idee.
Janoz schreef op maandag 07 februari 2005 @ 12:50:
Een mooie uitbreiding zou oa kunnen zijn:
* Configuratie via een xml bestandje dat je inleest ipv de iets onduidelijke array configuratie
en
RwD schreef op maandag 07 februari 2005 @ 13:06:
Wil je je html wijzigen dan moet je plotseling ook je php code wijzigen terwijl dit strikt genomen geen enkel doel dient.
Ik zou het kunnen combineren, het formulier zelf ook in het XML bestand opnemen met de nodige meta data (type, lengtes, etc.), heeft wel wat weg van ASP.NET.
Janoz schreef op maandag 07 februari 2005 @ 12:50:
Toevoegen van een reguliere expressie waaraan een antwoord moet voldoen
Dat vind ik een hele goeie, die komt er zeker in.
Janoz schreef op maandag 07 februari 2005 @ 12:50:
vergelijken van velden onderling (password en password2 gelijk aan elkaar)
Dat vind ik zelf een onderdeel van je "business logic", mijn idee was eigenlijk het volgende:

1. Formvalidatie (waar ik dus mee bezig ben)
2. Beveiliging
3. Business logic
TRON schreef op maandag 07 februari 2005 @ 12:14:
... Volgens mij hou je hierdoor geen SQL-injection tegen en geen XSS-exploits...
Het helpt wel, vooral als je de modflags als volgt uitbreidt:

PHP:
1
define('_MYSQLESC', 32);


en in apply_mod() de volgede check toevoegd:

PHP:
1
2
if ($allowed[$key][_MOD] & _MYSQLESC)
  $value = mysql_escapce_string($value);


Maar dit is lang niet altijd voldoende en hoort meer bij punt 2. Beveiliging.

Hierna zul je nog verder moeten gaan, dat hoopte ik ook duidelijk te maken door:
risr schreef op zondag 06 februari 2005 @ 20:51:
maar het verdient wel om nog verder te gaan waar check_key_type_range() stopt...
Even iets over die volgorde...
Janoz schreef op maandag 07 februari 2005 @ 13:14:
Ik zie echter nergens in de code dat die volgorde ook daadwerkelijk afgedwongen wordt. En mocht dat wel zo zijn dan is het handiger om dit er inderdaad uit te halen.
Dat had ik er ook uitgehaald, moest wel want als een niet verplicht veld niet wordt ingevuld wordt de 'key' niet meeverzonden en kan je het met de volgende check wel vergeten:

PHP:
1
2
3
4
5
6
7
//   if (array_keys($allowed) == array_keys($_POST)) {
//     echo 'Keys match, continue processing...<br>';
//   }
//   else {
//     echo 'Keys do not match, stop processing NOW!<br>';
//     exit;
//   }


En ik ben er mee eens dat bovenstaande check zinloos is, ik was alleen vergeten om
dat ook uit mijn post te halen.
RwD schreef op maandag 07 februari 2005 @ 13:23:
... Als dit uit het gehele systeem wordt gehaald heeft hij iets dat niet echt gerelateerd is aan waar het vandaan komt.
Je hebt ergens wel gelijk, het is zonder die check niet meer gebaseerd op datgene wat ik in mijn openingspost als eerste aanhaalde, ik had beter kunnen zeggen dat ik me daardoor heb laten inspireren.
RwD schreef op maandag 07 februari 2005 @ 13:26:
"Stomme vraag van mij zeker omdat ik alleen deze 3 regels gelezen heb, maar waar
precies check je of dit array vereist is??" ...
Is een fout, moet zijn:

PHP:
1
if ( (is_array($value)) && (sizeof($value) < 1) && (!$allowed[$key][_REQ]))


Overigens, die hele regel kan weg want de check daarna met empty() werkt ook met arrays.
Verwijderd schreef op maandag 07 februari 2005 @ 23:09:
Is dit niet gewoon PEAR::QuickForm nabouwen?
Niet als je het nog niet kende, maar ik had wel eerst mogen zoeken naar bestaande oplossingen want als ik de reacties lees zijn er nogal wat bestaande oplossingen die beter zijn, zie bijvoorbeeld de reactie van raps. Overigens bedankt voor de URL.

En ik had niet over emailadres-validatie moeten beginnen merk ik. :D

Allen bedankt voor de reacties en mocht ik het uitbreiden dan horen jullie nog van mij. :)

[ Voor 21% gewijzigd door risr op 08-02-2005 22:22 ]

Pagina: 1