[Beveiliging] Faken van post variabelen

[MisterE]

Ik probeer een website te maken die redelijk veilig is.
Nou zie je vaak gastenboeken die honderden spam berichten hebben. Dit wil ik gaan afvangen door van een IP de tijdsinterval te registreren. Doet een persoon bijv. dit x aantal keer onder een bepaalde tijd dan wil ik dat IP blocken. (plus waarschijnlijk captcha beveiliging later)

Maar ik had ook vernomen dat POST variabelen niet helemaal safe zijn en daarom wil ik ook gaan registreren of er bijv. namen van POST variabelen binnenkomen die niet bestaan, of dat ze een waarde hebben die niet juist is.

Om wat beter inzicht in dit te krijgen zou ik graag weten wat de spammers voor tools/scripts gebruiken. Ik weet niet of dit soort info hier mag maar alle informatie over gerelateerde onderwerpen stel ik op prijs.

[BasieP]

als je even zoekt op got zie dat er bergen manieren zijn om jezelf te beveiligen tegen spam.
zo kan je bijv. iets met JS doen, of captcha gebruiken.
Verder moet je jezelf beveiligen tegen sql injectie.

Je post vars checken kan je alleen zelf, aangezien jij weet wat 'acceptabel' is, en wat niet. Daar kunnen we je niet bij helpen.

[ Voor 61% gewijzigd door BasieP op 09-04-2007 15:30 ]

[MisterE]

Wat ik dus het meeste zoek is een progje/tool/script/component om mijn eigen website te spammen. Zonder dat ik dus telkens in de website op een knop moet drukken.

[RobIII]

Dat is prima te maken met (bijv.) een stukje VBScript en een HTTPRequest component (om maar eens wat te noemen).

Wat ik zelf altijd doe voor gastenboekjes is het volgende:
Als de 'gast' een berichtje invult wordt er een email verstuurd naar de eigenaar met de inhoud van het bericht en 3 links: goedkeuren, afkeuren en afkeuren + ipban. Dat is een kwestie van een URL aanroepen met het (GU)ID van het bericht en de actie. Bij goedkeuren gaat er een bit op 1 (het gastenboek toont alleen goedgekeurde berichten), bij een afkeuring wordt het bericht verwijderd (of een ander bit op 1 ofzo) en bij de laatste actie wordt er ook meteen een IP ban gezet en krijgt dat IP vanaf dat moment een 403 forbidden ofzo.

Dat is een van de weinige manieren om je gastenboek lekker schoon te houden en rommel er dus uit te houden. Het plaatsen van een bericht is dus wel met wat vertraging, maar als je dat duidelijk uitlegt op de 'bedankt voor uw berichtje' pagina is er niemand die daar een probleem mee heeft, i.t.t. sommige 'moeilijke' captcha's e.d.

[ Voor 19% gewijzigd door RobIII op 04-06-2007 10:29 ]

[Verwijderd]

Of je vraagt hoeveel 3 x 3 = had ik toevallig bij iemand gezien Werkt wel goed; bots weten niet dat het 9 is.

[ThunderNet]

MisterE schreef op maandag 09 april 2007 @ 18:17:
Wat ik dus het meeste zoek is een progje/tool/script/component om mijn eigen website te spammen. Zonder dat ik dus telkens in de website op een knop moet drukken.

Je zou kunnen kijken naar de testtool JMeter

[RobIII]

Verwijderd schreef op maandag 09 april 2007 @ 18:37:
Of je vraagt hoeveel 3 x 3 is, had ik toevallig bij iemand gezien Werkt waarschijnlijk wel goed, bots weten niet dat het 9 is.

Dat is natuurlijk ook een kwestie van tijd
En daarnaast vind ik (persoonlijk) dat je de 'last' niet bij de eindgebruiker moet leggen. Waarom een gebruiker lastigvallen als je prima zelf effe kunt 'screenen'? (Idd, als je op vakantie bent ofzo zul je wat meer 'vertraging' oplopen bij het online gaan van berichten, maar then again: niets weerhoudt je ervan om die 'screening mails' naar meer dan 1 adres te sturen ).

[BasieP]

RobIII schreef op maandag 09 april 2007 @ 18:35:
Dat is prima te maken met (bijv.) een stukje VBScript en een HTTPRequest component (om maar eens wat te noemen).

Wat ik zelf altijd doe voor gastenboekjes is het volgende:
Als de 'gast' een berichtje invult wordt er een email verstuurd naar de eigenaar me de inhoud van het bericht en 3 links: goedkeuren, afkeuren en afkeuren + ipban. Dat is een kwestie van een URL aanroepen met het (GU)ID van het bericht en de actie. Bij goedkeuren gaat er een bit op 1 (het gasteboek toont alleen goedgekeurde berichten), bij een afkeuring wordt het bericht verwijderd (of een ander bit op 1 ofzo) en bij de laatste actie wordt er ook meteen een IP ban gezet en krijgt dat IP vanaf dat moment een 404 forbidden ofzo.

maar hier zul jij (als eigenaar van het gastenboek) een berg mailtjes krijgen, en veel tijd nodig hebben met goed- en afkeuren...
lijkt me ook vrij lastig.

wat ik zelf doe is dmv een JS, een waarde in een formpje stoppen en die mee submitten. De meeste (lees: 99%) van de spambots snappen geen JS (zeker niet als je het wat lastig maakt) en vullen die waarde dus niet in. Zodoende is dus je input niet correct.
Ik heb nog nooit spam gehad met deze methode.

[RobIII]

BasieP schreef op maandag 09 april 2007 @ 21:39:
[...]

maar hier zul jij (als eigenaar van het gastenboek) een berg mailtjes krijgen, en veel tijd nodig hebben met goed- en afkeuren...
lijkt me ook vrij lastig.

Misschien bij een héééél druk gastenboek, maar een gemiddeld gastenboekje (in mijn ervaring) wordt echt niet vaker dan een paar keer per week 'getekend', hooguit een paar per dag. Voordeel is dat je meteen weet dat er iemand in geschreven heeft, wat diegene geschreven heeft (de reactie zit immers ook in de mail), en de spam pik je er zo (eerste regel / paar woorden lezen is al voldoende meestal) uit en in diezelfde mail klik je 1 van de 3 genoemde links aan. Zoveel werk is dat niet hoor.

[Verwijderd]

Bij een gastenboek zou ik zowiezo al gaan checken hoevaak er een url in de post voorkomt. De meeste spam bevat namelijk meerdere url's en op die manier kan je al een hele bult afvangen.
Wat ook nog wel es voor kan komen is dat de spam bot een email adres achter laat met jou domein ([e-mail]), dit zou je ook kunnen gaan filteren.

[P.O. Box]

op een gastenboek dat ik gemaakt heb (zo'n 15 berichten per jaar, dus niet schokkend) zet ik een bit op 0 en stuur ik een mailtje naar mezelf als er een URL in het bericht voorkomt... mocht het dan toch een valide bericht zijn, dan kan ik hem in de database zo weer aanzetten...
verder heet de php-file vna mijn gastenboek geen gastenboek.php ofzo, maar kp.php dat maakt het ook alweer ietsje lastiger blijkbaar, want waar ik nog 25 spamberichten per dag kreeg op gastenboek.php, krijg ik er nu nog nul (dus eigenlijk heeft mijn URL beveiliging nog niet echt zijn nut bewezen) en dat al een paar maanden lang...

[Verwijderd]

BasieP schreef op maandag 09 april 2007 @ 21:39:
[...]

maar hier zul jij (als eigenaar van het gastenboek) een berg mailtjes krijgen, en veel tijd nodig hebben met goed- en afkeuren...
lijkt me ook vrij lastig.

wat ik zelf doe is dmv een JS, een waarde in een formpje stoppen en die mee submitten. De meeste (lees: 99%) van de spambots snappen geen JS (zeker niet als je het wat lastig maakt) en vullen die waarde dus niet in. Zodoende is dus je input niet correct.
Ik heb nog nooit spam gehad met deze methode.

deze gebruik ik ook altijd ja
soms gaat het ook wel eens mis en wordt je nog steeds gespamt
dan is het tijd voor sommetjes helaas

[Blaise]

soms gaat het ook wel eens mis en wordt je nog steeds gespamt
dan is het tijd voor sommetjes helaas

Dat zal dan wel handmatige spam zijn, daar doe je niets tegen.

Bij de spam tools van Wordpress kan je ook inspiratie opdoen voor een goede anti-spam tool. De tools zijn grotendeels speciaal gemaakt voor Wordpress, maar vaak zo aan te passen dat ze in elke site gebruikt kunnen worden.

Er zijn trouwens al massa's topics over het spam probleem.

[ Voor 6% gewijzigd door Blaise op 10-04-2007 13:15 ]

[Blue-eagle]

Twee oplossingen die in het verleden goed hebben gewerkt:

1. Capcha
2. IP opslaan in database, instelbare timeout voordat deze record wordt verwijderd

Dus:

1. sla ip op in tabel "tblGuestbookEntries";
2. verwijder records in deze tabel ouder dan X-minuten;
3. als huidige ip niet voor komt in tabel, voeg record toe;
4. error/succes melding laten zien.

Maargoed, een beetje "hacker" weet ook zijn IP wel te spoofen als het nodig is lijkt me. En als ze dit soort acties doen vanuit een groot netwerk met geinfecteerde computers schiet je er nog niet zoveel mee op.

Capcha werkt tot nu toe het beste (Wel leesbaar houden!)

[Zoefff]

RobIII schreef op maandag 09 april 2007 @ 18:41:
[...]

Dat is natuurlijk ook een kwestie van tijd
En daarnaast vind ik (persoonlijk) dat je de 'last' niet bij de eindgebruiker moet leggen. Waarom een gebruiker lastigvallen als je prima zelf effe kunt 'screenen'? (Idd, als je op vakantie bent ofzo zul je wat meer 'vertraging' oplopen bij het online gaan van berichten, maar then again: niets weerhoudt je ervan om die 'screening mails' naar meer dan 1 adres te sturen ).

Absoluut mee eens. Je moet je bezoekers niet lastigvallen met rare anti-ocr plaatjes, rekensommetjes, etc. Maar ook het reageren via javascript vind ik daar onder vallen, het gaat ten koste van de toegankelijkheid van je website.

Er worden op mijn site gemiddeld iets van 5 reacties per dag geplaatst ofzo. Ik had eerst redelijk last van spam, maar filter op dit moment heel bruut gewoon alle berichten met "http://" er uit. Dat helpt, maar is natuurlijk ook niet echt netjes omdat je bezoekers dan geen linkjes kunnen plaatsen.

Wat ik zelf nog moet doen (simpel, maar ik neem er de tijd niet voor ) is een reactie-queue bouwen die filtert op emailadres (wat op dit moment toch al verplicht is). Staat je emailadres al in de database en is het goedgekeurd, dan wordt je reactie meteen geplaatst. Zo niet, dan moet ik het bericht eerst goedkeuren (en kan je de volgende keer -mits het emailadres gelijk is- wel direct reageren). Dat zal in mijn geval redelijk goed werken omdat ik veel terugkerende bezoekers heb

[Zyppora]

Zoefff schreef op dinsdag 10 april 2007 @ 16:07:
[...]

Wat ik zelf nog moet doen (simpel, maar ik neem er de tijd niet voor ) is een reactie-queue bouwen die filtert op emailadres (wat op dit moment toch al verplicht is). Staat je emailadres al in de database en is het goedgekeurd, dan wordt je reactie meteen geplaatst. Zo niet, dan moet ik het bericht eerst goedkeuren (en kan je de volgende keer -mits het emailadres gelijk is- wel direct reageren). Dat zal in mijn geval redelijk goed werken omdat ik veel terugkerende bezoekers heb

Da's in principe ook 'de gebruiker lastigvallen', aangezien deze (de eerste keer) moet wachten totdat zijn/haar reactie geplaatst wordt. Nu geef je zelf aan dat je niet zoveel gastboek-visitors hebt, maar het lijkt me dat een sommetje of captcha (of 'wat is de tweede letter van "blauw"?' oid) dan toch iets gebruiksvriendelijker is. Zeker wanneer men 'even een vraag tussendoor' heeft, dan is zo'n delay toch echt irritant (en een sommetje maken, daar hebben de meesten al sinds de basisschool geen 5 seconden meer voor nodig).

[Verwijderd]

ik weet niet of bots flash niet snappen ,maar met mijn flash gastenboeken heb ik nog nooit spam gehad, en je kan redelijk snel een kant en klare interface vinden die met php&mysql werkt

[Voutloos]

Zyppora schreef op woensdag 11 april 2007 @ 11:24:
[...]
Da's in principe ook 'de gebruiker lastigvallen', aangezien deze (de eerste keer) moet wachten totdat zijn/haar reactie geplaatst wordt. Nu geef je zelf aan dat je niet zoveel gastboek-visitors hebt, maar het lijkt me dat een sommetje of captcha (of 'wat is de tweede letter van "blauw"?' oid) dan toch iets gebruiksvriendelijker is.

Een queue, mits je hem goed bijhoudt is imo toch echt gebruiksvriendelijker.

Bovendien is het site-vriendelijker: Iemand kan dan makkelijk een reactie plaatsen, maar helaas, moet even wachten tot de reactie verschijnt. Resultaat: een reply @ site en een entry in de white-list. Captcha's/sommetjes/inloggen: Iemand kan moeilijker een reactie plaatsen, je hebt een zichtbare drempel vóór het plaatsen opgeworpen, hoe laag de drempel ook volgens jou is. Resultaat: sommige mensen haken af en dus geen reply @ site.

En nog een argument waarom het leuker is voor je site: de gemiddelde captcha is ongelooflijk lelijk.

For the record: Ik heb wel een grote hekel aan slecht bijgehouden queues zonder fatsoenlijke feedback. Dus indien je naar het queue middel grijpt: Meld duidelijk waarom de reply nog niet zichtbaar is, hou de queue bij, en denk na over een white-list mogelijkheid. Die white-list optie mag best wat loose zijn (desnoods makkelijk false positives); zolang het grootste deel van de trouwe bezoekers niet in de queue komt scheelt het je namelijk alsnog queue/verwijder acties.

Verwijderd schreef op woensdag 11 april 2007 @ 15:25:
ik weet niet of bots flash niet snappen ,maar met mijn flash gastenboeken heb ik nog nooit spam gehad, en je kan redelijk snel een kant en klare interface vinden die met php&mysql werkt

Alleen maar vanwege de replyfeature van je site over willen stappen naar een Flash geheel is ook weer een beetje overdreven. Verder is Flash dan ook een extra requirement, doe dan gewoon maar javascript.