datagott > internet.* > internet.www.ontwerp

Sjoerd (12.12.2018, 23:10)
Ik heb een PHP mailformulier met o.a. deze code:

$onderwerp = htmlspecialchars($_POST['onderwerp']);
.....
mail($aan,$onderwerp,$bericht,"From: " . $naam . " <" . $email . ">");

Het gaat goed zolang het onderwerp geen speciale tekens bevat.
Maar is het onderwerp bijvoorbeeld 'TÚst', dan krijg ik dit terug:

host outboundmailfilter.mijndomein.nl [188.93.148.250]
SMTP error from remote mail server after end of data:
550 Subject contains invalid characters.

Op
[..]
wordt deze oplossing gesuggereerd:

$subject = htmlentities("TÚst", UTF-8);

In mijn geval wordt dit dus:

$onderwerp = htmlentities($_POST['onderwerp'], UTF-8);

Het bericht komt nu wel aan - dat is tenminste een verbetering - maar het
onderwerp is T&eacute;st .
Is het mogelijk om deze html-code weer weer te geven als gewone tekst?
Het zou me weinig uitmaken als de mails die met het mailformulier zijn
verstuurd, aan mezelf waren gericht. Maar het gaat naar een info-adres dat
ook anderen onder ogen komt.
Rob (13.12.2018, 12:12)
Sjoerd <xx> wrote:
> Ik heb een PHP mailformulier met o.a. deze code:
> $onderwerp = htmlspecialchars($_POST['onderwerp']);
> ....
> mail($aan,$onderwerp,$bericht,"From: " . $naam . " <" . $email . ">");


Het is in het algemeen onverstandig om dit soort velden te vullen
vanuit data die de gebruiker kan invullen. Dit is namelijk een
potentiele bron van veel van de security problemen waar je altijd
over leest.

Je kunt "onderwerp" beter vullen met een constante zoals "Ingezonden
webformulier op de site" en dan het onderwerp wat de inzender invult
toevoegen in het bericht zelf.

Ook het vullen van de From: header met het daadwerkelijke afzender
adres wat door de gebruiker is ingevuld is niet slim. Zet daar
gewoon een vast adres neer "From: Website <no.reply>" ofzo
en zet de ingevulde naam en e-mail in het bericht.

Het is wel iets onhandiger bij het verwerken van de berichten maar
het kan je allerlei ellende besparen.
Sjoerd (13.12.2018, 14:42)
Rob:
> Sjoerd:
> Het is in het algemeen onverstandig om dit soort velden te vullen
> vanuit data die de gebruiker kan invullen. Dit is namelijk een
> potentiele bron van veel van de security problemen waar je altijd
> over leest.


Op deze pagina, onder de kop 'Big Note on PHP Form Security' (ongeveer
halverwege) wordt getoond wat die securityproblemen inhouden.

[..]

En hoe dit voorkomen kan worden met de htmlspecialchars()-functie.
"The exploit attempt fails, and no harm is done!"

Zijn hiermee jouw bezwaren nu weggenomen, of zie je nog meer adders onder
het gras?
Rob (13.12.2018, 14:53)
Sjoerd <xx> wrote:
> Rob:
> Op deze pagina, onder de kop 'Big Note on PHP Form Security' (ongeveer
> halverwege) wordt getoond wat die securityproblemen inhouden.
> [..]
> En hoe dit voorkomen kan worden met de htmlspecialchars()-functie.
> "The exploit attempt fails, and no harm is done!"
> Zijn hiermee jouw bezwaren nu weggenomen, of zie je nog meer adders onder
> het gras?


Er kan nog veel meer mis gaan dan dat!
Met wat pech lukt het om de hacker extra To: adressen toe te voegen door
een subject met een newline erin in te voeren.
(dit is bijv ook het geval als de $aan niet hardcoded is maar bijvoorbeeld
in een hidden form veld staat - ook een big NONO!)

Maar als je op deze manier zelf de From: samenstelt en op het domein
van de invuller is een SPF en/of DMARC policy ingesteld (in DNS) dan
zal de ontvanger van de e-mail (of diens provider) de mails weigeren
of als spam classificeren omdat een mail "From iemand" gestuurd
is door jouw mailserver die daartoe niet gerechtigd is. Spoof dus.

En als er op jouw mailbox een foutmelding of andere vorm van ontvangst
bevestiging gestuurd wordt dan zal die gaan naar de invuller van het
formulier, die niet gechecked is op authenticiteit.
(dus als iemand een vals mail adres invult wordt er een onschuldige gespamd)

Niet doen dus.
Sjoerd (16.12.2018, 17:20)
Op 13 december schreef Rob:
> > > Het is in het algemeen onverstandig om dit soort velden te vullen
> > > vanuit data die de gebruiker kan invullen. Dit is namelijk een
> > > potentiele bron van veel van de security problemen waar je altijd
> > > over leest.


Wat ik mij afvroeg, is of het feit dat de site voorzien is van SSL, nog
een rol speelt.

En over hacken gesproken, in de statistieken zie ik welke pagina's
mensen zoal zoeken waarop ze een 404-error krijgen, dus een melding dat
de pagina niet bestaat. Daaronder de onderstaande.
Zijn dit hackpogingen?? Des te merkwaardiger als je weet dat het geen
Wordpress-site is.

/login.html
/wp/
/wordpress/
/wp-login.php
/wp/wp-login.php
/wordpress/wp-login.php
/wp-includes/wlwmanifest.xml
/wp/wp-includes/wlwmanifest.xml
/wordpress/wp-includes/wlwmanifest.xml
/blog/wp-login.php
/blog/wp-includes/wlwmanifest.xml
/cms/wp-includes/wlwmanifest.xml
/site/wp-includes/wlwmanifest.xml
/assets/components/gallery/css/mgr.css
/wp-content/plugins/wp-homepage-slideshow/readme.txt
/wp-content/plugins/dzs-videogallery/admin/dzsuploader/upload.js
/wp-content/plugins/php-event-calendar/readme.txt
Rob (16.12.2018, 19:13)
Sjoerd <xx> wrote:
> Op 13 december schreef Rob:
>> > > Het is in het algemeen onverstandig om dit soort velden te vullen
>> > > vanuit data die de gebruiker kan invullen. Dit is namelijk een
>> > > potentiele bron van veel van de security problemen waar je altijd
>> > > over leest.

> Wat ik mij afvroeg, is of het feit dat de site voorzien is van SSL, nog
> een rol speelt.


Nee dat speelt geen enkele rol!

[..]
> /wp/wp-includes/wlwmanifest.xml
> /wordpress/wp-includes/wlwmanifest.xml
> /blog/wp-login.php
> /blog/wp-includes/wlwmanifest.xml
> /cms/wp-includes/wlwmanifest.xml
> /site/wp-includes/wlwmanifest.xml
> /assets/components/gallery/css/mgr.css
> /wp-content/plugins/wp-homepage-slideshow/readme.txt
> /wp-content/plugins/dzs-videogallery/admin/dzsuploader/upload.js
> /wp-content/plugins/php-event-calendar/readme.txt


Ja dat zijn mensen die zoeken naar lekken in de diverse CMS'en.
Maar ook in die mailformulieren zitten vaak lekken en daar zijn ze
ook vaak naar op zoek.
robert (16.12.2018, 20:47)
Rob <nomail>:
> Sjoerd <xx> wrote:
> Nee dat speelt geen enkele rol!


Even een smiley erbij zetten, Rob, anders denkt ie dat je serieus bent :P
Rob (17.12.2018, 11:55)
robert <US3N37+{n.i.w.o}> wrote:
> Rob <nomail>:
> Even een smiley erbij zetten, Rob, anders denkt ie dat je serieus bent :P


Dat is ook serieus. Veel mensen denken dat een site veilig is als je SSL
gebruikt maar in werkelijkheid maakt dat niets uit. Alleen het transport
zou veilig kunnen zijn, de site zelf (de scripts en formulieren) daar heeft
dat geen enkele invloed op.
robert (17.12.2018, 12:00)
Rob <nomail>:
> robert <US3N37+{n.i.w.o}> wrote:
> Dat is ook serieus. Veel mensen denken dat een site veilig is als je SSL
> gebruikt maar in werkelijkheid maakt dat niets uit. Alleen het transport
> zou veilig kunnen zijn, de site zelf (de scripts en formulieren) daar heeft
> dat geen enkele invloed op.


Ah excuus, ik had de opmerking van Sjoerd verkeerd gelezen. Inderdaad, dat
een site SSL gebruikt is geen enkele reden om aan te nemen dat daardoor je
(PHP) scripts ineens veilig zouden zijn.
Soortgelijke onderwerpen