php email form werkt half

[Ambianz]

Ben me al een tijdje aan het verdiepen in websites, en heb zojuist weer een site bijna af. Nu wil ik hier eigenlijk een php form in krijgen, maar ik krijg deze niet werkend.

Nu heb ik een form in html + php script gemaakt, deze allemaal op 1 pagina.

PHP: filename

        <?php
                $action=$_REQUEST['action'];
                    if ($action=="")    /* display the contact form */
                        {
                        ?>
                <form  action="" method="POST" enctype="multipart/form-data">
                    <input type="hidden" name="action" value="submit" />
                    <label for="naam">Naam:</label> <input type="text" id="naam" name="naam" value="" class="input_field" />
                    <div class="cleaner h10"></div>
                    
                    <label for="adres">Adres:</label> <input type="text" id="adres" name="adres" class="input_field" />
                    <div class="cleaner h10"></div>
                    
                    <label for="postcode">Postcode:</label> <input type="text" id="postcode" name="postcode" class="input_field" />
                    <div class="cleaner h10"></div>
                    
                    <label for="woonplaats">Woonplaats:</label> <input type="text" id="woonplaats" name="woonplaats" class="input_field" />
                    <div class="cleaner h10"></div>
                    
                     <label for="telefoonnummer">Telefoonnummer:</label> <input type="text" id="telefoonnummer" name="telefoonnummer" class="input_field" />
                    <div class="cleaner h10"></div>
                    
                     <label for="geboortedatum">Geboortedatum:</label> <input type="text" id="geboortedatum" name="geboortedatum" class="input_field" />
                    <div class="cleaner h10"></div>
                    
                     <label for="datum">Datum inschrijving:</label> <input type="text" id="datum" name="datum" class="input_field" />
                    <div class="cleaner h10"></div>
                    
                     <label for="email">Email adres:</label> <input type="text" id="email" name="email" class="validate-email input_field" />
                    <div class="cleaner h10"></div>
                   
                    
                    <input type="submit" class="submit_btn float_l" name="submit" id="submit" value="Versturen" />
                    <input type="reset" class="submit_btn float_r" name="reset" id="reset" value="Reset" />
                
                </form>

PHP: filename

<?php
                        } 
                    else                /* send the submitted data */
                        {
                        $naam=$_REQUEST['naam'];
                        $adres=$_REQUEST['adres'];
                        $postcode=$_REQUEST['postcode'];
                        $woonplaats=$_REQUEST['woonplaats'];
                        $telefoonnummer=$_REQUEST['telefoonnummer'];
                        $geboortedatum=$_REQUEST['geboortedatum'];
                        $datum=$_REQUEST['datum'];
                        $email=$_REQUEST['email'];
                        if (($naam=="")||($adres=="")||($postcode=="")||($woonplaats=="")||($telefoonnummer=="")||($geboortedatum=="")||($datum=="")||($email==""))
                            {
                            echo "Alle velden dienen ingevuld te worden, vul het <a href=\"\">formulier</a> opnieuw in alstublieft.";
                            }
                        else{        
                            $from="From: $name<$email>\r\nReturn-path: $email";
                            $subject="Aanmelding Movere";
                            mail("[e-mail]", $subject, $email, $from);
                            echo "Email verzonden, we nemen zo spoedig mogelijk contact met u op!";
                            }
                        }  
                ?> 

Nu wil ik eigenlijk alle 8 de invoervelden weergeven in het mailtje dat ik opgestuurd krijg. Echter krijg ik dit alleen werkend als ik in deze regel, maar 1 waarde invoer:

PHP: filename

mail("[e-mail]", $subject, $email, $from);

Waar ik het eigenlijk zo wil hebben: (althans, dat dacht ik, maar wellicht is er een andere, betere oplossing)

PHP: filename

mail("[e-mail]", $subject, $naam, $adres, $postcode, $woonplaats, $telefoonnummer, $geboortedatum, $datum, $email, $from);

Vul ik deze laatste lijn in, dan krijg gewoon geen mail opgestuurd. Iemand die hier een oplossing voor weet?

[Hydra]

Hoe kom je er bij dat je uberhaupt die parameters mee kunt geven aan die mail functie?

$email is de volledige body van de email. Als je daar al die informatie in wil hebben zul je dus zelf een string samen moeten stellen met alle info (naam, adres, etc.) erin. Hoe dat ding werkt staat hier gewoon: http://php.net/manual/en/function.mail.php

[Slurpgeit]

Let ook op dat je nu kwetsbaar bent voor SMTP injection (https://www.owasp.org/ind..._Injection_(OWASP-DV-011)). Denk dat je ook zoiets moet gaan doen:

http://php.net/manual/en/function.filter-var.php
http://www.php.net/manual/en/filter.filters.validate.php

Anders loop je het risico dat iedereen via jouw website mail kan versturen naar willekeurige adressen.

[Ambianz]

Juist, eerste keer dat ik er pas mee bezig ben, maar kan zo al op de hall of shame zo te horen hehe..

Dank voor de feedback, ik ga er even mee aan de gang

[Ambianz]

Het is inmiddels gelukt, dank voor het kleine stapje in de goede richting!

[Damic]

als je je action andersom doet kun je je gegevens terug meegeven en kan de gebruiker zien wat hij gemsit heeft.

[NMe]

Nooit zelf met de functie mail gaan lopen klooien. Neem dan liever iets als PHPMailer, want anders loop je binnen de korste keren spam te versturen of komt jouw legitieme mail bij iedereen in de spamfolder.

[drm]

Op deze manier kan jan en alleman mail gaan versturen in je formpje, simpelweg door \nCC: [e-mail] in het $name veld te posten. Voor de duidelijkheid, met \n bedoel ik een newline character, niet letterlijk \n. Kan dat? Ja dat kan, want ik hoef allereerst niet eens een post te gebruiken, in dit geval is een querystring parameter al voldoende (aangezien je $_REQUEST gebruikt, en niet checkt op HTTP request method). Verder is de post niet beperkt tot de mogelijkheden die je formulier biedt, ook niet onbelangrijk.

Wees strict, vertrouw niemand, filter je input, escape je output. Altijd en overal.

Als je geen idee hebt wat ik allemaal zeg, zorg dan eerst dat je het wel weet en wat de gevaren zijn voordat je je de achterdeur openzet voor de hele wereld. Spam versturen is nog maar een relatief onschuldig voorbeeld van wat er mis kan gaan.

En wat NMe zegt, dus.

[NMe]

drm schreef op donderdag 03 april 2014 @ 00:30:
Spam versturen is nog maar een relatief onschuldig voorbeeld van wat er mis kan gaan.

Ik weet niet of zijn hostingprovider er ook zo over denkt wanneer hun IP ineens op een blacklist staat.

[Ambianz]

Oké bedankt voor de opheldering, aangezien dit eigenlijk een klein onderdeel op de website is waar ik me verder niet vaak meer mee bezig zal zijn, zijn deze dingen op een relatief eenvoudige manier te omzeilen?

Zou een Captcha toevoegen voldoende zijn?
Of evt een hidden field?

Al zit ik dan volgensmij nog met het probleem met die querystring waar drm het over heeft

[ Voor 18% gewijzigd door Ambianz op 03-04-2014 02:07 ]

[PsychoMantis_NL]

Wat je wilt doen v.w.b. de querystring, is kijken of het formulier wel via de juiste manier is verzonden, en dat zou dus via POST moeten zijn, getuige je opzet van het formulier:

HTML:

<form  action="" method="POST" enctype="multipart/form-data">

$_REQUEST omvat standaard $_GET, $_POST en $_COOKIE variabelen, en afhankelijk van de serverinstellingen wordt de een door de ander bij gelijke naamgeving overschreven, waardoor je variabelen dus te manipuleren zijn.

Ter verduidelijking even onderstaand voorbeeld:

PHP:

// URL = http://www.mijnsite.nl/index.php?foo=bar

print_r($_REQUEST);

// geeft:
// Array(
//     foo=> bar
// )

Logisch, $_REQUEST bevat een $_GET variabele en geeft dus ?foo=bar terug. Ga je e.e.a. nu combineren met een formulier, dan krijg je dit:

PHP:

// URL = http://www.mijnsite.nl/index.php?foo=bar
// Na submitten van het formulier

echo '<form action="index.php" method="post">';
echo '<input type="text" name="foo" value="een andere waarde">';
echo '<input type="submit" name="submit" value="go!">';
echo '</form>';
print_r($_REQUEST);

// geeft:
// Array(
//     foo => een andere waarde
//     submit => go!
// )

In het 2e voorbeeld zie je dat de $_POST variabele (foo=een andere waarde) voorrang krijgt over de $_GET variabele, maar ten eerste is dit in te stellen in je php.ini, ten tweede kan ik door rechtstreeks te navigeren naar de url http://www.mijnsite.nl/index.php?foo=bar mogelijk al jouw actie triggeren doordat je controleert op $_REQUEST, en ten derde wil je überhaupt niet dat je data extern beïnvloedbaar is, want ik kan via de $_GET methode wel extra variabelen meegeven die jij helemaal niet wilt hebben:

PHP:

// URL = http://www.mijnsite.nl/index.php?foo=bar&var2=fooFoo&var3=barbarbar
// Na submitten van het formulier

echo '<form action="index.php" method="post">';
echo '<input type="text" name="foo" value="een andere waarde">';
echo '<input type="submit" name="submit" value="go!">';
echo '</form>';
print_r($_REQUEST);

// geeft:
// Array(
//     foo => een andere waarde
//     var2 => fooFoo
//     var3 => barbarbar
//     submit => go!
// )

Zoals je kunt zien kun je dus via $_REQUEST variabelen setten die jij eigenlijk niet verwacht. Zou je dit zonder te controleren door een loopje gooien, bijvoorbeeld een for() of foreach() dan hoef je geen Einstein te zijn om te kunnen bedenken dat iets als delete=unlink('index.php') of delete=DROP TABLE users; wel eens vervelend kan uitpakken.

Daarom zou je dus alleen de variabelen willen hebben die je verwacht. Dit kun je doen door ze expliciet te benoemen. Dit werkt wanneer je slechts een paar variabelen hebt (ook dan is e.e.a. natuurlijk nog steeds te beïnvloeden), maar het wordt vervelender wanneer je een formulier hebt wat uit 30+ velden en meerdere pagina's bestaat:

PHP:

if(isset($_REQUEST['a'],$_REQUEST['b'],$_REQUEST['c'], .... , $_REQUEST['x'], $_REQUEST['z'], $_REQUEST['y']))

Concreet wil je dus uitsluitend variabelen terugkrijgen die gePOST zijn, en die haal je dus op via $_POST['foo'] en niet via $_REQUEST['foo'].

Ook dan geldt uiteraard dat je de variabelen nog moet checken voordat je ze uitvoert, dit omdat ook in een textbox gewoon het unlink() of DROP TABLE commando gegeven kan worden. Zou je hier vervolgens niet op checken dan gaat het alsnog mis, maar je voorkomt in ieder geval dat er variabelen binnenkomen die jij helemaal niet verwacht.


Edit:
Even een toelichting op het "triggeren via rechtstreeks navigeren":

Als jij controleert op:

PHP:

if(isset($_REQUEST['submit']))
{
  // Doe iets leuks
}

Dan verwacht je dat er gecontroleerd wordt op $_POST. Maar omdat $_REQUEST dus ook kijkt naar $_GET kan ik dus zonder het formulier te verzenden, maar door simpelweg te navigeren naar http://www.mijnsite.nl/in...Niet&woonplaats=ZegIkNiet meteen voldoen aan je if() claussule ($_REQUEST['submit'] bestaat immers), en daarnaast vul ik meteen al even 3 variabelen voor je in, die ik uit de broncode van je website kan halen.

[ Voor 12% gewijzigd door PsychoMantis_NL op 03-04-2014 09:00 ]

[andydewit]

Belangrijk is dat je checkt of alle velden daadwerkelijk verstuurd zijn, anders krijg je foutmeldingen:

PHP:

// Controleren of veld verstuurd is en niet leeg is
if (!isset ($_POST['veld']) || empty($_POST['veld'])) {
// Veld niet verstuurd of leeg
}

Daarna controleer je de velden of er wel in staat wat je graag wilt hebben. Voorbeeld hiervan is een functie om het e-mailadres te controleren.

PHP:

// Email controleren
if (!filter_var ($email, FILTER_VALIDATE_EMAIL) {
  // e-mail klopt niet
}

Verder zou ik even op het internet kijken voor een Captcha script, aangezien je anders veel spam gaat krijgen.

[ Voor 109% gewijzigd door andydewit op 03-04-2014 08:58 ]

[HuHu]

Ambianz schreef op donderdag 03 april 2014 @ 01:55:
Oké bedankt voor de opheldering, aangezien dit eigenlijk een klein onderdeel op de website is waar ik me verder niet vaak meer mee bezig zal zijn, zijn deze dingen op een relatief eenvoudige manier te omzeilen?

Nee.

Zou een Captcha toevoegen voldoende zijn?

Nee.

Of evt een hidden field?

Nee.

Al zit ik dan volgensmij nog met het probleem met die querystring waar drm het over heeft

Zoals NMe al zegt: schrijf niet zelf je mail-functie. Gebruik een standaard pakket als PHPMailer, Zend\Mail, etc... Maar ga het niet zelf doen!

Je gaat gegarandeerd wat over het hoofd zien, wat alleen maar problemen geeft. Er zijn mensen, veel slimmer dan jij en ik, die daar veel beter over nagedacht hebben en goede implementaties hebben gemaakt die in bijvoorbeeld PHPMailer of Zend\Mail zitten.

andydewit schreef op donderdag 03 april 2014 @ 08:46:

Verder zou ik even op het internet kijken voor een Captcha script, aangezien je anders veel spam gaat krijgen.

Persoonlijk vind ik een captcha in een contactformulier maar stom. Ik ben van mening dat het gebruikersvriendelijker is om een simpel contactformulier aan te bieden en dan server-side een goed spamfilter te draaien. Dat moet sowieso, want ook spammers kunnen een captcha correct invullen. Maar het weglaten van een captcha en een goed spamfilter is veel vriendelijker voor de normale gebruiker.

[ Voor 24% gewijzigd door HuHu op 03-04-2014 09:03 ]

[Barryvdh]

Ik gebruik altijd http://swiftmailer.org/, werkt ideaal.

Een hidden field (honeypot field) werkt meestal best aardig tegen spam, als het niet een drukke/populaire website is.

[NMe]

Barryvdh schreef op donderdag 03 april 2014 @ 09:30:
Een hidden field (honeypot field) werkt meestal best aardig tegen spam, als het niet een drukke/populaire website is.

Even voor de duidelijkheid voor de topicstarter (ik weet dat je het zelf begrijpt ): dat werkt tegen het ontvangen van spam via het contactformulier, niet tegen het misbruiken van jouw formulier om spam te versturen. Dat laatste is echt kinderlijk eenvoudig door zoals drm al zei in het veld waarin je het e-mailadres invult achter dat adres een enter te zetten, waarna een spammer zijn eigen To-, CC- of BCC-header kan zetten.

Resumerend, de dingen die hier spelen:

1. Een dergelijk formulier doe je doorgaans door te kijken naar $_POST, niet naar $_REQUEST.
2. De mail-functie zelf gebruiken is vragen om problemen, gebruik een van de vele bekende standaardoplossingen.
3. Beveiliging die je alleen in HTML inbouwt is geen beveiliging, hooguit een extra horde.
4. Hidden fields, flash gordons, captcha's en andere manieren om te checken of iemand wel een echte gebruiker is en geen spammer helpen tegen het ontvangen van spam, niet tegen het versturen ervan.

In short: neem even die 15 minuten om te leren hoe je een van de vele mailerclasses gebruikt en bouw dat in. Doe je dat niet, dan is het een kwestie van tijd tot je hoster je site gaat suspenden omdat er spam mee verstuurd wordt.

HuHu schreef op donderdag 03 april 2014 @ 09:01:
[...]

Persoonlijk vind ik een captcha in een contactformulier maar stom. Ik ben van mening dat het gebruikersvriendelijker is om een simpel contactformulier aan te bieden en dan server-side een goed spamfilter te draaien. Dat moet sowieso, want ook spammers kunnen een captcha correct invullen. Maar het weglaten van een captcha en een goed spamfilter is veel vriendelijker voor de normale gebruiker.

Hoewel het voor veel mensen synoniem is hoeft een captcha niet per se zo'n image te zijn. Er zijn ook minder intrusive vormen. Je kan bijvoorbeeld een veld in je contactformulier de verkeerde naam geven en die na het tikken in het formulier via javascript aanpassen naar de naam die het moet hebben. Dat is wat minder waterdicht dan zo'n plaatje maar helpt ook aardig tegen spam.

[ Voor 23% gewijzigd door NMe op 03-04-2014 12:21 ]

[drm]

NMe:
Ik weet niet of zijn hostingprovider er ook zo over denkt wanneer hun IP ineens op een blacklist staat.

Da's gelukkig meestal vrij snel weer gefixt.

[RobIII]

Even nog waarom je geen $_REQUEST wil gebruiken maar expliciet op $_POST wil checken is omdat je anders grapjassen krijgt die (bijv. hier op T.net) ofzo een image (o.i.d.) gaan maken:

[img]http://site.nl/index.php?submit=...&naam=...&postcode=...&woonplaats=..[/]

...of door 'm als avatar in te stellen of...

Wat voor jou, effectief, resulteert in een mail bij elke pageview en "de ander" hooguit in een plaatje dat niet laaft/kruisje. En die requests komen dus van élke bezoeker (en denk ook eens aan crawlers!) en dus telkens van een ander IP e.d. en dat ga je dus verdomd lastig kunnen "blocken" (maar tegen die tijd dat je die stap bereikt ben je toch al aan 't dweilen met de kraan open; je moet metéén $_POST gebruiken).

PsychoMantis_NL schreef op donderdag 03 april 2014 @ 08:37:
Zoals je kunt zien kun je dus via $_REQUEST variabelen setten die jij eigenlijk niet verwacht. Zou je dit zonder te controleren door een loopje gooien, bijvoorbeeld een for() of foreach() dan hoef je geen Einstein te zijn om te kunnen bedenken dat iets als delete=unlink('index.php') of delete=DROP TABLE users; wel eens vervelend kan uitpakken.

Ho, ho. Ongeacht of de waardes uit $_REQUEST, $_POST, $_GET of $_COOKIE (of elders) komen: de oplossing is hier escaping, niet alleen maar $_POST uitlezen en $_REQUEST e.d. negeren. Ook $_POST values zijn makkelijk zat (als in 0.0000000001% moeilijker dan $_GET) te forceren. Dat je ze niet in je adresbalk ziet (en "makkelijk kunt aanpassen") maakt niet dat je dan immuun bent voor injectie.

[ Voor 43% gewijzigd door RobIII op 03-04-2014 19:56 ]

[Cartman!]

Samenvattend:

- Geen $_REQUEST maar $_POST gebruiken zodat je form niet invulbaar is met een GET-request
- Alle user input altijd heel strict valideren
- Geen mail() functie zelf aanroepen maar een framework gebruiken (bijv. Swiftmailer, \Zend\Mail, PHPMailer)

[Ambianz]

Oké bedankt voor alle hulp, ik heb het toch allemaal onderschat vooral ook door de vele instructies die overal op het internet te vinden zijn, waar dingen als $_REQUEST aangeraden worden, blijkbaar door mensen die er geen verstand van hebben.

Moet zeggen dat jullie uitleg allemaal hartstikke duidelijk is, ik kan het allemaal prima volgen en ga er dus weer even mee aan de gang.

[PsychoMantis_NL]

RobIII schreef op donderdag 03 april 2014 @ 19:50:
Ho, ho. Ongeacht of de waardes uit $_REQUEST, $_POST, $_GET of $_COOKIE (of elders) komen: de oplossing is hier escaping, niet alleen maar $_POST uitlezen en $_REQUEST e.d. negeren. Ook $_POST values zijn makkelijk zat (als in 0.0000000001% moeilijker dan $_GET) te forceren. Dat je ze niet in je adresbalk ziet (en "makkelijk kunt aanpassen") maakt niet dat je dan immuun bent voor injectie.

Ho, ho Ik geef in mijn post niet aan dat het vervangen van $_REQUEST door $_POST de algehele controle wegneemt, maar uitsluitend dat je door het toepassen van $_POST i.p.v. $_REQUEST de variabelen terugkrijgt die je verwacht, en dat deze ook via de juiste wijze (in dit geval via $_POST) terugkomen.

En daarnaast zijn deze, doordat ze niet via een GET request toegankelijk zijn, toch iets lastiger te manipulieren (een ?foo=bar werkt dan dus niet). Nogmaals, 100% veilig is anders, en daarvoor heb je extra checks, maar POST vragen als je POST verwacht is natuurlijk beter als een REQUEST opvragen terwijl je POST verwacht. Dat was in ieder geval de intentie van mijn post

...
Ook dan geldt uiteraard dat je de variabelen nog moet checken voordat je ze uitvoert, dit omdat ook in een textbox gewoon het unlink() of DROP TABLE commando gegeven kan worden. Zou je hier vervolgens niet op checken dan gaat het alsnog mis, maar je voorkomt in ieder geval dat er variabelen binnenkomen die jij helemaal niet verwacht.

Edit @ Ambianz:
Een $_REQUEST kan wel degelijk handig zijn, maar (zoals ik het zie althans) is de basis dat je opvraagt wat je verwacht.

Je maakt een formulier met als actie action="post", dan moet je ook controleren of het formulier "gepost" is. Niet of er een request is die toevallig dezelfde variabelen bevat.

[ Voor 9% gewijzigd door PsychoMantis_NL op 03-04-2014 23:25 ]

[NMe]

PsychoMantis_NL schreef op donderdag 03 april 2014 @ 23:12:
[...]

En daarnaast zijn deze, doordat ze niet via een GET request toegankelijk zijn, toch iets lastiger te manipulieren (een ?foo=bar werkt dan dus niet). Nogmaals, 100% veilig is anders, maar POST vragen als je POST verwacht is natuurlijk beter als een REQUEST opvragen terwijl je POST verwacht.

Dat sowieso, maar dat POST manipuleren lastiger is dan GET...nou nee. Je kan het inderdaad niet meer in de URL aanpassen maar een eigen formuliertje is zo gemaakt, dus laten we vooral niet de illusie hebben dat het ook maar een klein beetje beveiligt tegen formuliermanipulatie.

Dat was in ieder geval de intentie van mij post

Het lullige is dat de topicstarter duidelijk nog wat meer moet leren en dan is de halve waarheid vertellen zo mogelijk nog erger dan totale onzin verkopen, vandaar waarschijnlijk dat RobIII even de rest erbij vertelde.

Een $_REQUEST kan wel degelijk handig zijn, maar (zoals ik het zie althans) is de basis dat je opvraagt wat je verwacht.

Ik kan me de laatste keer dat ik de $_REQUEST-superglobal gebruikt heb niet meer herinneren. Je weet eigenlijk altijd waar je input vandaan komt, dus tenzij je bijvoorbeeld een of andere logmodule schrijft die ook alle user input logt kan ik me niet echt een situatie voorstellen waar je de verzamelarray zou verkiezen voor de gesplitste arrays.

[ Voor 19% gewijzigd door NMe op 03-04-2014 23:24 ]

[Hydra]

Ambianz schreef op donderdag 03 april 2014 @ 23:08:
Oké bedankt voor alle hulp, ik heb het toch allemaal onderschat vooral ook door de vele instructies die overal op het internet te vinden zijn, waar dingen als $_REQUEST aangeraden worden, blijkbaar door mensen die er geen verstand van hebben.

Ach, je bent ze al een stap voor door om hulp te vragen nietwaar?

PsychoMantis_NL schreef op donderdag 03 april 2014 @ 23:12:
En daarnaast zijn deze, doordat ze niet via een GET request toegankelijk zijn, toch iets lastiger te manipulieren

Voor je grootmoeder misschien, maar iedereen die gaat zoeken naar injection attacks kan ook formulieren posten. I.p.v. REQUEST specifiek POST gebruiken (specifiek hiervoor, Rob gaf een veel betere reden) heeft erg weinig zin. Het geeft eerder een false sense of security.

[ Voor 37% gewijzigd door Hydra op 03-04-2014 23:29 ]

[PsychoMantis_NL]

@NMe:

De laatste keer dat ik een REQUEST gebruikt heb kan ik me zo snel ook niet herinneren, maar om te kijken welke variabele waar vandaan komt kan het handig zijn (true, je hoort natuurlijk van tevoren te weten hoe of wat, want als je POST verwacht check je op POST en niet op GET, maar toch).

V.w.b. "de halve waarheid vertellen", ik snap wat je bedoelt, maar het aanpassen van een GET request is natuurlijk voor meneer X vele malen makkelijker als het maken van een eigen formuliertje wat foutieve data doorgeeft en deze vervolgens door te sturen naar de betreffende pagina

Hoevaak heb jij voordat je chef-ICT (no pun intented) was wel niet geprobeerd om "?user=123" te veranderen in "?user=124", gewoon om te kijken wat er gebeurde. Dat zou je dus met een REQUEST mogelijk de kop kunnen kosten (net als met $_GET maar dat terzijde), terwijl je dit niet hebt als je controleert op $_POST als je een POST verwacht

[NMe]

Hydra schreef op donderdag 03 april 2014 @ 23:25:
[...]

Voor je grootmoeder misschien, maar iedereen die gaat zoeken naar injection attacks kan ook formulieren posten. I.p.v. REQUEST specifiek POST gebruiken (specifiek hiervoor, Rob gaf een veel betere reden) heeft erg weinig zin. Het geeft eerder een false sense of security.

Nouja, POST gebruiken in plaats van REQUEST heeft natuurlijk wel voordelen, alleen niet voor dit soort beveiliging. Ik weet dat jij dit ook gewoon weet, dit is wederom puur voor de TS en anderen die het mogelijk niet weten bedoeld: als je REQUEST gebruikt kunnen er nogal funky dingen gebeuren als er in twee verschillende superglobals variabelen met dezelfde index voorkomen. $_REQUEST bevat tegenwoordig alle informatie uit de GET-, POST- en COOKIE-superglobals. Als er twee variabelen met dezelfde index voorkomen in twee verschillende arrays, dan is het afhankelijk van de serversettings welke uiteindelijk "wint" en in je applicatie belandt.

PsychoMantis_NL schreef op donderdag 03 april 2014 @ 23:35:
Hoevaak heb jij voordat je chef-ICT (no pun intented) was wel niet geprobeerd om "?user=123" te veranderen in "?user=124", gewoon om te kijken wat er gebeurde. Dat zou je dus met een REQUEST mogelijk de kop kunnen kosten (net als met $_GET maar dat terzijde), terwijl je dit niet hebt als je controleert op $_POST als je een POST verwacht

In zekere zin heb je het juist sneller opgemerkt als je met REQUEST hebt gewerkt en je daarmee userinformatie op kan vragen die niet toegankelijk hoort te zijn. Voor het testen betekent makkelijke toegang tot je input ook dat je makkelijker dingen test.

Nogmaals, er is geen enkele reden om REQUEST te kiezen tenzij je heel specifiek de complete scope van door de user meegestuurde info nodig hebt en het is sowieso een goed idee om POST te gebruiken en alleen POST uit te lezen waar van toepassing, maar beveiliging is het niet in de zin die jij hier omschrijft.

[ Voor 32% gewijzigd door NMe op 03-04-2014 23:41 ]

[Hydra]

NMe schreef op donderdag 03 april 2014 @ 23:37:
Nouja, POST gebruiken in plaats van REQUEST heeft natuurlijk wel voordelen, alleen niet voor dit soort beveiliging. Ik weet dat jij dit ook gewoon weet, dit is wederom puur voor de TS en anderen die het mogelijk niet weten bedoeld: als je REQUEST gebruikt kunnen er nogal funky dingen gebeuren als er in twee verschillende superglobals variabelen met dezelfde index voorkomen. $_REQUEST bevat tegenwoordig alle informatie uit de GET-, POST- en COOKIE-superglobals. Als er twee variabelen met dezelfde index voorkomen in twee verschillende arrays, dan is het afhankelijk van de serversettings welke uiteindelijk "wint" en in je applicatie belandt.

Ik zei ook:

specifiek hiervoor, Rob gaf een veel betere reden

[PsychoMantis_NL]

NMe schreef op donderdag 03 april 2014 @ 23:37:
Nogmaals, er is geen enkele reden om REQUEST te kiezen tenzij je heel specifiek de complete scope van door de user meegestuurde info nodig hebt en het is sowieso een goed idee om POST te gebruiken en alleen POST uit te lezen waar van toepassing, maar beveiliging is het niet in de zin die jij hier omschrijft.

_{Haha oké, dan zijn we het in ieder geval eens over het feit dat het overgaan van POST naar REQUEST geen excuus is om je checks te skippen}

Het hele idee was dan ook om aan te tonen dat wanneer je een REQUEST gebruikt deze - afhankelijk van je php.ini - te beïnvloeden is door een $_GET terwijl je in dit geval wilt controleren op een $_POST.

Neemt nog steeds niet weg dat - hoewel ik dat in mijn posts nog niet genoemd hebt - je voor het versturen van e-mails gewoon gebruik moet maken van bestaande classes en niet het wiel voor de 23.340^e keer moet uitvinden, maar ik dacht ik geef even reactie op de vraag "Hoe zit het met de querystring", en dan denk ik dat mijn uitleg wel aangeeft waarom je in dit specifieke geval de REQUEST niet zou moeten gebruiken.

[MekZi]

Ik raad je aan om een framework te gebruiken. (@Cartman! Swiftmailer, \Zend\Mail, PHPMailer zijn geen vorobeelden van framework's, maar eerder een library). Een nu zeer populaire PHP framework is laravel(.com). Ze beschikken ook over een goede documentatie. Er is ook een zeer goed boek over Laravel, Code Bright.

( Ja, zelfs voor iemand die net begint kan het al interessant zijn om een framework te gebruiken. Je moet echter wel beschikken over wat "basis" kennis als: git, composer, de stack installeren (linux/vagrant/vm/LAMP/WAMP)), maar veel van de info die je nodig hebt worden ook toegelicht in de documentatie. Google is hierbij natuurlijk je trouwe vriend.).

Wil je toch verder gaan dan zal je moeten kijken naar:
- Mail injection (dit is o.a. belangrijk, omdat het spammen met gebruik van jouw email en server mogelijk maakt)
- Form validatie / validation
- Form sanisatie / sanitization (CSRF / form token / etc.)
- anti-Spam (limiet op aantal mails dat verzonden kan worden? Captcha)

Boven alles! Laat je niet overrompelen met informatie en blijf lezen, leren en natuurlijk programmeren

[NMe]

MekZi schreef op vrijdag 04 april 2014 @ 01:13:
Ik raad je aan om een framework te gebruiken. (@Cartman! Swiftmailer, \Zend\Mail, PHPMailer zijn geen vorobeelden van framework's, maar eerder een library). Een nu zeer populaire PHP framework is laravel(.com). Ze beschikken ook over een goede documentatie. Er is ook een zeer goed boek over Laravel, Code Bright.

Nou is er niet echt een bezwaar tegen het gebruiken van frameworks maar een framework aanraden voor een simpel problem met het verzenden van een e-mail bij een gebruiker die duidelijk nog veel moet leren is misschien een beetje overdreven. Met een kanon op een mug schieten kan ook maar een vliegenmepper is net zo goed.

Overigens is veel van de "basic"-kennis die je aanhaalt helemaal niet zo basic voor een beginner. Iemand die net leert programmeren wil zich niet bezighouden met niet-programmeertechnische dingen, die wil gewoon zien of programmeren hem ligt. Daarna valt er altijd nog over te stappen naar complexer spul.

[HuHu]

MekZi schreef op vrijdag 04 april 2014 @ 01:13:
Ik raad je aan om een framework te gebruiken. (@Cartman! Swiftmailer, \Zend\Mail, PHPMailer zijn geen vorobeelden van framework's, maar eerder een library). Een nu zeer populaire PHP framework is laravel(.com). Ze beschikken ook over een goede documentatie. Er is ook een zeer goed boek over Laravel, Code Bright.

Zend\Mail is onderdeel van het framework Zend Framework 2: http://framework.zend.com/

[Cartman!]

MekZi schreef op vrijdag 04 april 2014 @ 01:13:
Ik raad je aan om een framework te gebruiken. (@Cartman! Swiftmailer, \Zend\Mail, PHPMailer zijn geen vorobeelden van framework's, maar eerder een library).

Eens maar in dit geval boeit die naamgeving voor de TS niet zo. Een micro framework is zeer geschikt (ik zweer zelf bij Silex) maar denk dat dit voor de TS te hoog gegrepen is.

@HuHu je kan \Zend\Mail ook als losse package downloaden en gebruiken.

[ Voor 7% gewijzigd door Cartman! op 04-04-2014 08:15 ]