PHP en het versturen van html mails

[Den_John]

Jongens,

Op het werk heb ik iets geschreven waarmee er automatisch een html-mail verzonden wordt. De $MailBody variabele krijgt inhoud naar gelang de keuzes die je maakt. Tevens krijgt deze variabele ook enkele url's mee met bijhorende sql's. In de mail die je krijgt, zie je de url waarna je erop kan klikken. Vervolgens opent er een document en zal dit document via $_GET bepaalde variabelen uit de url halen en verwerken.

Voorbeeld: http://www.voorbeeld.be/verwerk?sql1='insert into ....'&sql2='insert into ....' enz.

Het versturen en uitlezen van de variabelen lukt perfect, doch sluipen er her en der speciale tekens in. Vooral het !-teken komt regelmatig voor in de url's die ik mee stuur waardoor Outlook 2007 die url niet herkent.

Voorbeeld: http://www.voorbeeld.be/verwerk?sql1='insert !into ....'&sql2='in!sert into ....'

Heb tevens ook al volgende aanpassingen gedaan:
$MailHeader .= 'Content-type: text/html; charset=UTF-8'
en
$MailHeader .= 'Content-type: text/html; charset=iso 8559-15' of iso 8559-1

Beiden geven hetzelfde resultaat. Een str_replace is hier niet aan de orde aangezien die !-tekens pas zichtbaar zijn van zodra je de mail in Outlook 2007 ontvangt.

Iemand al gelijkaardige dingen meegemaakt of eventueel een oplossing voor mijn probleem?

Alvast bedankt.

[mithras]

1) waarom stuur je zelf emails zonder gebruik te maken van libraries? Nooit doen! Bekijk phpMailer en Zend_Mail.
2) email heeft een limitering zitten op het aantal karakters per regel. Hou je je hier niet aan, krijg je die vreemde tekens tussendoor.
3) waarom deze absoluut afschuwelijke url? WIl je alle lezers van je email de gelegenheid geven je database te wissen???

[ Voor 15% gewijzigd door mithras op 27-01-2010 17:13 . Reden: MueR: ik wil ook aandacht! ]

[Thomasje]

Een url is niet echt bedoeld voor rare tekens. Het is zoiezo erg lelijk om sql in een url te zetten.

Ik hoop ook stiekem dat je baas dit niet leest.

[ Voor 20% gewijzigd door Thomasje op 27-01-2010 17:17 ]

[MueR]

Ho, wacht.. Jij stuurt emails met daarin SQL queries? Ik hoef hopelijk niet uit te leggen dat dit een ENORM beveiligingsrisico (klik) is?

Overigens is de term waar je op zou moeten zoeken heet urlencode (met extragratis link). Maar dat is van latere zorg. Fix eerst die sql queries maar.

Oh ja, dit hoort in Programming (Waar hoort mijn topic?)

[ Voor 14% gewijzigd door MueR op 27-01-2010 17:20 ]

[RobIII]

Thomasje schreef op woensdag 27 januari 2010 @ 17:08:
Een url is niet echt bedoeld voor rare tekens.

Bullshit, je moet alleen zorgen dat ze juist ge-escaped worden. Dat het niet slim is om een query in de URL te zetten is andere koek; "lelijk" is dan nog lang niet eens een argument. Maar zoals je in het zoekveld van Google zult zien in voorgaande 3 voorbeelden komt alle "tekst en rare tekens" gewoon goed door als je op de links klikt.

MueR schreef op woensdag 27 januari 2010 @ 17:11:
Fix eerst die sql queries maar.

Waarmee MueR bedoelt dat je geen queries in de url moet zetten maar enkel de benodigde gegevens (id's en andere waardes). De query hou je in de afhandelende pagina zélf en vul je met de waarden die je uit $_GET krijgt. Hou dan wel (alsnog) rekening met SQL Injection dus zorg wel dat je op je juiste plek escaped! Alleen de waardes in de URL ga je url-encoden.

Je krijgt dus http://bla.be/somescript.php?id=<$id>&name=<urlencode:$name>&action=<urlencode:$action>. Daarbij neem ik aan dat je $id, $name en $action variabelen hebt waarbij $id een integer is en de overige 2 strings zijn. Vervolgens HTML-encode je de complete url met htmlspecialchars() of htmlentities() als je de mail als HTML mail stuurt; anders is dat niet nodig. Dat hele ding zet je vervolgens in de mail.

Vervolgens vraag je in somescript.php de $_GET values voor id, name en action respectievelijk uit. $name en $action ga je mysql_real_escapen en $id ga je intvallen of op een andere manier garanderen dat er een integer uit komt (en voor mijn part ook escapen als je 't niet vertrouwt; al zal bij een integer nooit iets ge-escaped worden). En nog beter: gebruik je gewoon parameterized queries m.b.v. (o.a) mysqli_stmt::bind_param etc.

[ Voor 77% gewijzigd door RobIII op 27-01-2010 18:16 ]

[Den_John]

Een enorm beveiligingsrisico is reeds duidelijk van in het begin. De mails die verzonden worden, worden eigenlijk maar naar 4 personen verzonden die niet de volledige link zien (ze zien enkel 'klik hier om door te voeren' waarna ze op een pagina komen en de $_GET-ters z'n werk doen. De website is enkel voor intern gebruik en er staat een filter op dat er enkel updates uitgevoerd kunnen worden, geen drop tables etc. Originele code is niet de mijne trouwens Momenteel dient alles nog via mail te gebeuren qua controle maar heb al meermaals laten vallen dat het automatisch verwerken van deze data veel veiliger is dan het eerst via mail versturen naar hun (m'n bazen) mailbox om vervolgens op ok te klikken.

Anyway, als we op pagina 1 de url volledig opbouwen en op de laatste regel doen we een echo, toont hij wel degelijk de correcte output zonder rare tekens. Van zodra het in de mailbox zit, zitten er !-tekens tussen. Niet enkel in de url, ook in de html opbouw van de mail zelf.

[mithras]

Den_John schreef op woensdag 27 januari 2010 @ 19:45:
Anyway, als we op pagina 1 de url volledig opbouwen en op de laatste regel doen we een echo, toont hij wel degelijk de correcte output zonder rare tekens. Van zodra het in de mailbox zit, zitten er !-tekens tussen. Niet enkel in de url, ook in de html opbouw van de mail zelf.

Daar heb ik ook al antwoord op gegeven

Maar over dat intern, vier mensen, blabla: als iemand zo'n mailtje doorstuurd kan het in no-time bij onbedoelde ontvangers terecht komen. Maak dan links als http://voorbeeld.nl/verwe...ie=insert&item=1&name=boe. Daar kan je al een heel stuk meer omheen beveiligen

[Den_John]

Zal morgen ff die code herschrijven. Die 4 mensen en ikzelf hebben enkel toegang tot die server. Iemand anders kan geen enkele pagina openen op die server zonder de juiste rechten te hebben trouwens.

Alvast bedankt voor de reacties!

[MueR]

Den_John schreef op woensdag 27 januari 2010 @ 20:04:
Die 4 mensen en ikzelf hebben enkel toegang tot die server. Iemand anders kan geen enkele pagina openen op die server zonder de juiste rechten te hebben trouwens.

Leuk. Tot er een genie langskomt wat besluit de serverconfiguratie te wijzigen, of dit vergeten wordt bij een servermigratie. Dan zit je ineens met een enorm probleem. Het is gewoon een dermate groot lek wat je vrijwillig introduceert.. je kan beter zelf tegen de muur gaan staan en de blinddoek omdoen, dan dat iemand anders dit doet.

[Den_John]

Mja, dat zal niet zo snel gebeuren aangezien toegang tot de servers vast hangt aan de NT login. Zonder rechten kom je daar helemaal niet op. Maar hoe dan ook heb ik voldoende stof om tot actie over te gaan ;-)

[mithras]

Even als aanvulling en ondersteuning van mijn antwoord de RFC erbij gehaald. Lees hier het hoe & wat van email

quote: http://www.ietf.org/rfc/rfc2822.txt

2.1.1. Line Length Limits

There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.

[CH4OS]

mithras schreef op woensdag 27 januari 2010 @ 20:53:
Even als aanvulling en ondersteuning van mijn antwoord de RFC erbij gehaald. Lees hier het hoe & wat van email

[...]

Een RFC zijn vaak aanbevelingen, getuige het feit dat je ook nu nog een URL kan hebben die langer dan 78 tekens is.

[RobIII]

GJtje schreef op woensdag 27 januari 2010 @ 21:27:
[...]
Een RFC zijn vaak aanbevelingen, getuige het feit dat je ook nu nog een URL kan hebben die langer dan 78 tekens is.

En waar staat "aanbevolen" in welke RFC dat een URL gelimiteerd is op 78 tekens

quote: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Totaal andere RFC, totaal ander doel.

quote: http://en.wikipedia.org/wiki/Request_for_Comments

Through the Internet Society, engineers and computer scientists may publish discourse in the form of an RFC, either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The IETF adopts some of the proposals published as RFCs as Internet standards.

[ Voor 67% gewijzigd door RobIII op 27-01-2010 21:44 ]

[Creepy]

GJtje schreef op woensdag 27 januari 2010 @ 21:27:
[...]
Een RFC zijn vaak aanbevelingen, getuige het feit dat je ook nu nog een URL kan hebben die langer dan 78 tekens is.

Je hebt niet door dat je reageert op een RFC die over "Internet Message Format" aka e-mail gaat? Daar staat z'n URL in. Het hele probleem met de URL is geen probleem net de URL, maar met de verstuurde e-mail. mithras heeft al aangeveven hoe, wat en waarom

[CH4OS]

Creepy schreef op woensdag 27 januari 2010 @ 21:42:
Je hebt niet door dat je reageert op een RFC die over "Internet Message Format" aka e-mail gaat? Daar staat z'n URL in. Het hele probleem met de URL is geen probleem net de URL, maar met de verstuurde e-mail. mithras heeft al aangeveven hoe, wat en waarom

Ah, dat verklaard een boel.

[NMe]

Den_John schreef op woensdag 27 januari 2010 @ 19:45:
De website is enkel voor intern gebruik en er staat een filter op dat er enkel updates uitgevoerd kunnen worden, geen drop tables etc.

SQL:

UPDATE tabel SET veld1 = '', veld2 = '', veld3 = ''

Need I say more?

[Tharulerz]

Je bedoelt

SQL:

UPDATE users SET password = '' WHERE user = 'admin'

[NMe]

De hele clou was het weglaten van de WHERE en het overschrijven van elk veld met een lege string, wat effectief hetzelfde is als een truncate. Verder zal doorgaans deze meer zin hebben:

SQL:

UPDATE users SET password = MD5('') WHERE user = 'admin'

En zelfs dat alleen als er geen salt wordt gebruikt.