De PHPhulp kroeg
spam weren
Ik heb sinds een weekje een gastenboek online staan en ja hoor, er komt al spam binnen.
Tot nog toe wist ik het enigzins (in een formulier had ik dat zo) te vermijden met de honeypot methode (een inputveld dat leeg moet zijn en de style nodisplay meekrijgt), maar dit werkt dus niet meer.
Nou gebruik ik voor dat gastenboek tinymce en min of meer per ongeluk, worden de commentaren opgeslagen in de dbase met de html, head en body tags. Nou zag ik dat de spambot deze niet schrijft, dus heb ik om te beginnen het script aangepast, zodat alleen commentaren mét <!DOCTYPE html> worden weergegeven. Maar nu twijfel ik of:
1. Het wel veilig is dat die tags met de tinymce in de database terechtkomen. (Ik gebruik trouwens pdo try/catch om weg te schrijven in de dBase.)
2. De spam staat dan wel tot aan verwijderen in de database, is dat onveilig?
Graag jullie mening.
Zo nee: gewoon niet opslaan en het script laten sterven?
Na een sleep() van 28 seconden uiteraard!
Gewijzigd op 27/04/2015 13:25:20 door Eddy E
Waarom niet gewoon plain text opslaan en HTML eruit filteren. Een captcha erbij om de spam écht te weren, en je bent klaar.
Gewijzigd op 27/04/2015 13:27:38 door - Ariën -
- Aar - op 27/04/2015 13:27:01:
Waarom niet gewoon plain text opslaan en HTML eruit filteren.
Als je hiermee bedoelt: HTML eruit filteren voordat je opslaat, dan lijkt mij dit geen goed idee, omdat je hiermee allerlei interpretaties op de gesubmitte tekst toepast. En interpretaties kunnen nou eenmaal fout zijn. Daarnaast is dit wederom een soort van blacklist. Het nadeel van blacklists is: vergeet je een geval, dan ben je de sjaak. Tevens, als je input op voorhand stript is het niet meer mogelijk om deze op enig moment te wijzigen. Het beste is gewoon om berichten (en vaak, data in het algemeen) in hun rauwe, ongewijzigde vorm op te slaan. En/of gewoon eisen dat dit voldoet aan een bepaalde vorm/patroon.
Sowieso is het vreemd dat er complete HTML-documenten worden opgeslagen? Dit zouden (in de meest uitgebreide vorm) snippets HTML moeten zijn, maar geen complete documenten - je voegt deze berichten toch in in een webpagina ofzo?
---
Ook hier kun je je weer bedienen van het credo filter input, escape output. Input filtering zou oa kunnen plaatsvinden door een CAPTCHA. Of je zou een token kunnen toevoegen aan het formulier zodat CSRF niet mogelijk is (maar misschien is dat niet genoeg, je legt hiermee wel de lat wat hoger).
Bij het afdrukken van het bericht dient alle output (wat voorheen USER INPUT was) ge-escaped te worden en misschien kun je enkele UBB-codes toestaan (dit is dus een whitelist ipv een blacklist).
Vertrouw nooit user input.
Uiteraard is een header volstrekt overbodig, hoewel ik me afvraag of het ook onveilig is, maar ik had deze instelling van tinymce over het hoofd gezien, waardoor die tags wel in de database mee opgeslagen worden. En daardoor zag ik dus het verschil tussen berichten ingevoerd via de webpagina en de spambot. En is het natuurlijk een eenvoudige manier om de spambots te weren. Uiteraard Eddy, beter al voordat het de database ingaat.
Maar als ik dat doe, dan hou ik dus de html, head en body tag in m´n database. Problemen heb ik er zo te zien niet mee, alleen dus de vraag van het veoiligheidsrisico.
Toevoeging op 27/04/2015 14:47:32:
Thomas van den Heuvel op 27/04/2015 14:19:06:
Ook hier kun je je weer bedienen van het credo filter input, escape output. Input filtering zou oa kunnen plaatsvinden door een CAPTCHA. Of je zou een token kunnen toevoegen aan het formulier zodat CSRF niet mogelijk is (maar misschien is dat niet genoeg, je legt hiermee wel de lat wat hoger).
- Aar - op 27/04/2015 13:27:01:
Waarom niet gewoon plain text opslaan en HTML eruit filteren.
Ook hier kun je je weer bedienen van het credo filter input, escape output. Input filtering zou oa kunnen plaatsvinden door een CAPTCHA. Of je zou een token kunnen toevoegen aan het formulier zodat CSRF niet mogelijk is (maar misschien is dat niet genoeg, je legt hiermee wel de lat wat hoger).
Wat is dat: CSRF?
Door middel van het inbouwen van een token dwing je (in ieder geval) af dat het POST request vanaf jouw domein geschiedt.
En over HTML en dergelijke toestaan in berichten: een kwaadwillende partij kan dan waarschijnlijk ook een stuk JavaScript invoegen waarmee jouw cookie-informatie ongemerkt naar hun wordt doorgestuurd op het moment dat je het bericht bekijkt.
Als jij dan toevallig als admin ingelogd bent (via sessies) en jouw loginmechanisme heeft geen IP-check (of men weet ook je IP) dan kan je sessie (en daarmee jouw identiteit als admin) mogelijk gehijacked (gekaapt) worden.
Ik herhaal: Vertrouw nooit user input.
:p
Gewijzigd op 27/04/2015 15:03:03 door Thomas van den Heuvel
Tortuga web op 27/04/2015 14:45:29:
@Aar: Dat is dus één van m´n vragen, wat is het veiligheidsrisico? Tinymce is juist er voor bedoelt dat er html-tags worden toegestaan voor de opmaak en images van een bericht.
Het ligt eraan hoe die door de POST-request gaan. Hopelijk niet in HTML, maar in ongevaarlijke code zoals UBB. Als het HTML-codes zijn, is er een gevaar voor XXS, waarbij op sluwe doch simpele wijze cookies kunnen worden gestolen.
Thomas van den Heuvel op 27/04/2015 14:58:20:
En over HTML en dergelijke toestaan in berichten: een kwaadwillende partij kan dan waarschijnlijk ook een stuk JavaScript invoegen waarmee jouw cookie-informatie ongemerkt naar hun wordt doorgestuurd op het moment dat je het bericht bekijkt.
Dat is XSS dus!
Gewijzigd op 27/04/2015 20:57:42 door - Ariën -
http://blog.kotowicz.net/2010/09/bbcode-wont-protect-you-from-xss.html
Volgens deze site is BBcode ook niet de oplossing.
Omdat het gastenboek dat ik gemaakt heb, maar beperkte mogelijkheden hoeft te kennen, heb ik vandaag een whitelist gemaakt.
Om te checken wat mogelijke hackers and other evil persons or computers kunnen dumpen, gebruik ik deze pagina: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
Die lijkt me behoorlijk compleet.
Tortuga web op 27/04/2015 21:12:55:
@Aar:
http://blog.kotowicz.net/2010/09/bbcode-wont-protect-you-from-xss.html
Volgens deze site is BBcode ook niet de oplossing
http://blog.kotowicz.net/2010/09/bbcode-wont-protect-you-from-xss.html
Volgens deze site is BBcode ook niet de oplossing
Uhh, de "exploit" die daar wordt aangehaald betreft een bagger implementatie van UBB-functionaliteit in JavaScript. Als je eerst zorgt dat al je output ge-escaped wordt met bijvoorbeeld htmlentities() en je daarna in PHP (niet met een of ander lijp stuk JavaScript) je UBB-tags omschrijft kan er eigenlijk weinig misgaan. Daarbij moet je natuurlijk wel een beetje je gezond verstand blijven gebruiken. Ook is het van groot belang dat je overal dezelfde character encoding toepast, anders werkt je escaping functionaliteit naar alle waarschijnlijkheid niet goed.
Het is trouwens helemaal niet erg om HTML op te slaan, mits je de persoon die dit doet maar vertrouwt :). Maar dat kun je dus alleen maar bereiken als je gebruikers kunt identificeren (dmv een loginsysteem) en je hun expliciet toestemming geeft om dit te kunnen doen.
In dat geval (en alleen in dat geval) escape je de output niet, en alleen als het echt de bedoeling is dat de input ook echt als HTML gebruikt dient te worden.