spammers via mailform

[Jeroen Heijmans]

Hya,

Misschien kunnen jullie me helpen.
Ik blijf spam(pogingen) krijgen via een mailformulier.
Ik hoopte het opgelost te hebben door het formulier te hernoemen, maar
helaas.

Ik heb al zitten denken aan CAPTCHA, maar vind het nog lastig om dat te
implementeren. Welke mogelijkheden zijn er nog meer? Ik kan natuurlijk
zorgen dat *@domain vervangen wordt door <1naam>@domain, maar dan blijft het
mailtje van het formulier nog altijd aankomen op het afleveradres.

Volgens mij is het meestal in het weekend en dan zo'n 20 keer. Het 'leuke'
is dat elk mailtje 2x aankomt. 1x origineel verstuurd naar adres wat door
het formulier gebruikt wordt en 1x als antwoord naar de afzender.

Dit is wat er in de mail staat (en waarschijnlijk ingevoerd is). ****** is
het mijn domein. Als jullie willen kan ik ook de berichten met complete
headers geven, maar die zijn natuurlijk allemaal 'intern' (mailformulier ->
mailserver).

---begin versie met shit in bericht veld---
================================================== ====================
Naam: xxamzchqb@******
================================================== ====================
Email: xxamzchqb@******
================================================== ====================
Onderwerp: xxamzchqb@******
================================================== ====================
Bericht:

xxamzchqb@******
Content-Type: multipart/mixed; boundary="===============0604132221=="
MIME-Version: 1.0
Subject: 74e2f4aa
To: xxamzchqb@******
bcc: jrubin3546@aol.com
From: xxamzchqb@******

This is a multi-part message in MIME format.

--===============0604132221==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

ptzo
--===============0604132221==--

================================================== ====================
Note: xxamzchqb@****** stuurde deze email op 11-09-2005 om 03:55.

Het IP adres van xxamzchqb@****** is: 212.249.5.232
Het hostadres van xxamzchqb@****** is: host232.romaco.com
================================================== ====================
---einde versie met shit in bericht veld---


en


---begin versie met shit in onderwerpsveld---
================================================== ====================
Naam: xmpajeifxr@******
================================================== ====================
Email: xmpajeifxr@******
================================================== ====================
Onderwerp: xmpajeifxr@******
Content-Type: multipart/mixed; boundary="===============1621250290=="
MIME-Version: 1.0
Subject: 2c77b577
To: xmpajeifxr@******
bcc: jrubin3546@aol.com
From: xmpajeifxr@******

This is a multi-part message in MIME format.

--===============1621250290==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

mnhgvgnmo
--===============1621250290==--

================================================== ====================
Bericht:

xmpajeifxr@******
================================================== ====================
Note: xmpajeifxr@****** stuurde deze email op 10-09-2005 om 16:14.

Het IP adres van xmpajeifxr@****** is: 128.223.43.247
Het hostadres van xmpajeifxr@****** is: d43-247.uoregon.edu
================================================== ====================
---einde versie met shit in onderwerpsveld---

en


---begin versie met shit in afzender mailadres veld---
================================================== ====================
Naam: oqbv@******
================================================== ====================
Email: oqbv@******
Content-Type: multipart/mixed; boundary="===============1689681865=="
MIME-Version: 1.0
Subject: a5987c68
To: oqbv@******
bcc: jrubin3546@aol.com
From: oqbv@******

This is a multi-part message in MIME format.

--===============1689681865==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

ovobbohl
--===============1689681865==--

================================================== ====================
Onderwerp: oqbv@******
================================================== ====================
Bericht:

oqbv@******
================================================== ====================
Note: oqbv@****** stuurde deze email op 10-09-2005 om 10:00.

Het IP adres van oqbv@****** is: 212.62.46.101
Het hostadres van oqbv@****** is: 212.62.46.101
================================================== ====================

---einde versie met shit in afzender mailadres veld---

[Rene Pijlman]

Jeroen Heijmans:
>Ik blijf spam(pogingen) krijgen via een mailformulier.

Ja, die krijg ik ook. Raadselachtig, want het dient geen enkel doel (het
is geen spam).

>Ik heb al zitten denken aan CAPTCHA, maar vind het nog lastig om dat te
>implementeren. Welke mogelijkheden zijn er nog meer?

Zo te zien vult het ook niet-bestaande en/of hidden fields in. Daar kun je
het aan herkennen, want dat doen bezoekers niet. Met een if-then-else in
het formulierscript moet het op te lossen zijn (klop klop).

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[# martin]

Hieronder volgt een reactie op dit bericht:
>> Ik blijf spam(pogingen) krijgen via een mailformulier.
>
> Ja, die krijg ik ook. Raadselachtig, want het dient geen enkel doel
> (het is geen spam).
>
>> Ik heb al zitten denken aan CAPTCHA, maar vind het nog lastig om dat
>> te implementeren. Welke mogelijkheden zijn er nog meer?
>
> Zo te zien vult het ook niet-bestaande en/of hidden fields in. Daar
> kun je het aan herkennen, want dat doen bezoekers niet. Met een
> if-then-else in het formulierscript moet het op te lossen zijn (klop
> klop).

Bij mij ook opeens:


[ start ontvangen bericht ]



Onderstaand bericht is verzonden op vrijdag 9 september 2004 om 16:17 uur.

Onderwerp:
"dimfqzidh@winampnederlands.nl":

Bericht:
dimfqzidh@winampnederlands.nl

__________________________________________________ _____

Opgegeven naam: dimfqzidh@winampnederlands.nl
E-mail adres: dimfqzidh@winampnederlands.nl
IP-adres: 217.160.108.59





[ einde ontvangen bericht ]

[Jeroen Heijmans]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
> Jeroen Heijmans:
>>Ik blijf spam(pogingen) krijgen via een mailformulier.
>
> Ja, die krijg ik ook. Raadselachtig, want het dient geen enkel doel (het
> is geen spam).
>
>>Ik heb al zitten denken aan CAPTCHA, maar vind het nog lastig om dat te
>>implementeren. Welke mogelijkheden zijn er nog meer?
>
> Zo te zien vult het ook niet-bestaande en/of hidden fields in. Daar kun je
> het aan herkennen, want dat doen bezoekers niet. Met een if-then-else in
> het formulierscript moet het op te lossen zijn (klop klop).

Het is al een paar maanden aan de gang. Soms met een stop van een paar weken
ertussendoor.

Maar wat ik zou moeten bekijken weet ik niet.
Volgens mij, worden bij mij alle bestaande velden ingevuld.

Ik heb nu iig alle 'verkeerde' mailadressen naar een ander account geleidt,
kijken hoeveel mails er nu nog wel binnenkomen. Bouncen zou tot een loop
kunnen leiden ben ik bang

[Ronald Klip]

Jeroen Heijmans schreef:
>
> Misschien kunnen jullie me helpen.
> Ik blijf spam(pogingen) krijgen via een mailformulier.
> Ik hoopte het opgelost te hebben door het formulier te hernoemen, maar
> helaas.

[snip]

Het heerst nogal. Als ik het goed begrijp wordt er gekeken of forminvoer
ongecontroleerd in de headers wordt gezet, bijvoorbeeld in Subject: of
From: . Als daar newlines in geschreven kunnen worden, biedt het script
perspectieven voor spammers. Zie
ook http://www.anders.com/cms/75/Crack.Attempt/Spam.Relay

Het zoveelste bewijs dat je userinvoer altijd goed moet controleren op
ongewenste tekens.

--
groet, Ronald

[Jeroen Heijmans]

Ronald Klip <nieuws@bladibla.net.invalid> wrote:
> Jeroen Heijmans schreef:
>>
>> Misschien kunnen jullie me helpen.
>> Ik blijf spam(pogingen) krijgen via een mailformulier.
>> Ik hoopte het opgelost te hebben door het formulier te hernoemen, maar
>> helaas.
>
> [snip]
>
> Het heerst nogal. Als ik het goed begrijp wordt er gekeken of forminvoer
> ongecontroleerd in de headers wordt gezet, bijvoorbeeld in Subject: of
> From: . Als daar newlines in geschreven kunnen worden, biedt het script
> perspectieven voor spammers. Zie
> ook http://www.anders.com/cms/75/Crack.Attempt/Spam.Relay
>
> Het zoveelste bewijs dat je userinvoer altijd goed moet controleren op
> ongewenste tekens.

Maar wat zijn ongewenste tekens? In mijn voorbeeld zitten eigenlijk weinig
foute tekens....

[Operator]

In article <dg4d5m$d4$1@max.ff.fm>,
Jeroen Heijmans <news@nospam.ff.fm> writes:
> Ronald Klip <nieuws@bladibla.net.invalid> wrote:

[...]
>> Het zoveelste bewijs dat je userinvoer altijd goed moet controleren op
>> ongewenste tekens.
>
> Maar wat zijn ongewenste tekens?

Alles wat niet in de volgende set zit:
1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWX YZ

en verander alles wat kleiner is dan "spatie" in "spatie"

> In mijn voorbeeld zitten eigenlijk weinig
> foute tekens....

Toch zijn ze in staat om headers te beinvloeden?

Zet alle userinvoer in een zelf-geformatteerde body,
desnoods eerst in een file die later door een cron-job gemaild wordt.
Liefst geen auto-reply en als je dat wel wilt:
zet alle ontvangers in een database om te voorkomen dat ze nogmaals
iets krijgen.

[Erick T. Barkhuis]

Operator [on 12 Sep 2005 18:28:59 GMT] wrote:

> Liefst geen auto-reply en als je dat wel wilt:
> zet alle ontvangers in een database om te voorkomen dat ze nogmaals
> iets krijgen.

Heh?
Door alle ontvangers in een database te zetten voorkom je toch niet dat
ze nogmaals iets krijgen?

--
Erick

"Ideale computer, nog uit te vinden: je stopt er je problemen in en ze
komen er nooit meer uit." - M. Callewaert

[Rene Pijlman]

Operator:
>Zet alle userinvoer in een zelf-geformatteerde body,
>desnoods eerst in een file die later door een cron-job gemaild wordt.
>Liefst geen auto-reply en als je dat wel wilt:
>zet alle ontvangers in een database om te voorkomen dat ze nogmaals
>iets krijgen.

Brand het eerst op een CD-ROM, laat die per fietskoerier bezorgen en
bewaar hem eerst 2 weken in een driesterrenvriesvak. Bekijk de inhoud van
de CD-ROM dan op een computer die niet op Internet is aangesloten en die
je na afloop helemaal formatteert.

Wat is dit voor onzinnige Voodoo? Gewoon een correct mailtje construeren
met geverifieerde gebruikersinvoer is prima.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Jan Reilink]

Operator wrote:
> In article <dg4d5m$d4$1@max.ff.fm>,
> Jeroen Heijmans <news@nospam.ff.fm> writes:
>
>>Ronald Klip <nieuws@bladibla.net.invalid> wrote:
>
>
> [...]
>
>>>Het zoveelste bewijs dat je userinvoer altijd goed moet controleren op
>>>ongewenste tekens.
>>
>>Maar wat zijn ongewenste tekens?
>
>
> Alles wat niet in de volgende set zit:
> 1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWX YZ
>

De uitleg op http://securephp.damonkohler.com/ind...mail_Injection
gaat *juist* uit van de tekens: %, 0 en A (%0A een linefeed). Lijkt me
in die volgorde dus best wel een ongewenst teken (voorzover er van een
teken te spreken valt).

--
Met vriendelijke groet / Best regards,
Jan Reilink, VEVIDA Nederland BV

Postbus 329, 9700 AH GRONINGEN, +31(0)50 - 5492234

[Jan Smeelen]

"Jeroen Heijmans" <news@nospam.ff.fm> schreef in bericht
news:dg0ssa$sdu$1@max.ff.fm...
> Hya,
>
> Misschien kunnen jullie me helpen.
> Ik blijf spam(pogingen) krijgen via een mailformulier.
> Ik hoopte het opgelost te hebben door het formulier te hernoemen, maar
> helaas.
>

> Grote Knip <

Behalve de oplossingen die je hier al gelezen hebt, kun je ook als extra
beveiliging
toepassen een controle of een sessie variabele bestaat.

Ik neem aan, dat men extern post naar het scriptje dat e.e.a. verstuurt. ?

Dus op de pagina met het invulformuliertje zet je een variabele in een
sessie
en het script wat de gegevens verstuurt controleert of die sessie inderdaad
bestaat.

Ik hoop dat ik wat heb kunnen bijdragen... ;o)

Succes !
Jan Smeelen.

--
Interesse in bedrijfsovernames of je bedrijf verkopen ?
Neem eens een kijkje bij Hermans en Partners Corporate Finance
http://www.hermansenpartners.nl

[Rene Pijlman]

Jan Smeelen:
>Behalve de oplossingen die je hier al gelezen hebt, kun je ook als extra
>beveiliging toepassen een controle of een sessie variabele bestaat.

Het zou kunnen dat dat in dit geval werkt, maar er is toch geen
principiële reden waarom dit soort misbruikscripts niet ook cookies zouden
meenemen?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Operator]

In article <MPG.1d8feb5794d3c5cd989947@news.individual.de>,
Erick T. Barkhuis <erick@ardane.c-o-m> writes:
> Operator [on 12 Sep 2005 18:28:59 GMT] wrote:
>
>> Liefst geen auto-reply en als je dat wel wilt:
>> zet alle ontvangers in een database om te voorkomen dat ze nogmaals
>> iets krijgen.
>
> Heh?
> Door alle ontvangers in een database te zetten voorkom je toch niet dat
> ze nogmaals iets krijgen?

Zoek voordat je weer een auto-reply geeft de ontvanger in de database.
Als ie bestaat: _niet_ mailen.
Net als bij een opt-in systeem.

[Operator]

In article <17lbi1d61rtk9ou5ct84ths3on4rh70f4g@4ax.com>,
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> writes:
> Operator:
>>Zet alle userinvoer in een zelf-geformatteerde body,
>>desnoods eerst in een file die later door een cron-job gemaild wordt.
>>Liefst geen auto-reply en als je dat wel wilt:
>>zet alle ontvangers in een database om te voorkomen dat ze nogmaals
>>iets krijgen.
>
> Brand het eerst op een CD-ROM, laat die per fietskoerier bezorgen en
> bewaar hem eerst 2 weken in een driesterrenvriesvak. Bekijk de inhoud van
> de CD-ROM dan op een computer die niet op Internet is aangesloten en die
> je na afloop helemaal formatteert.
>
> Wat is dit voor onzinnige Voodoo? Gewoon een correct mailtje construeren
> met geverifieerde gebruikersinvoer is prima.

Geen Voodoo. Gewoon scheiden van functionaliteit.
De hoofd taak van het webserver proces is het verwerken van form-data
en de response aan de surfer. Hoe de data verder verwerkt wordt is
daarvoor niet van belang. Op de webserver hoeft geen smtp te draaien,
de data kan ook op een andere manier in de applicatie van de functionaris
die de data verwerkt terecht komen. Die applicatie hoeft geen e-mail
client te zijn.

[Operator]

In article <4325dcf5$0$11079$e4fe514c@news.xs4all.nl>,
Jan Reilink <janreilink@vevida.nl> writes:
> Operator wrote:
>> In article <dg4d5m$d4$1@max.ff.fm>,
>> Jeroen Heijmans <news@nospam.ff.fm> writes:
>>
>>>Ronald Klip <nieuws@bladibla.net.invalid> wrote:
>>
>> [...]
>>
>>>>Het zoveelste bewijs dat je userinvoer altijd goed moet controleren op
>>>>ongewenste tekens.
>>>
>>>Maar wat zijn ongewenste tekens?
>>
>> Alles wat niet in de volgende set zit:
>> 1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWX YZ
>
> De uitleg op http://securephp.damonkohler.com/ind...mail_Injection
> gaat *juist* uit van de tekens: %, 0 en A (%0A een linefeed). Lijkt me
> in die volgorde dus best wel een ongewenst teken (voorzover er van een
> teken te spreken valt).

Als je eerst een translatie doet kan de translatie misbruikt worden.
Mijn set is een voorbeeld van een van de expansion_filter in postfix.
Bij het gebruik van php zal je op andere tekens moeten testen
dan bij bv. perl.

Het direct injecteren in een mailsysteem vanuit een webscript
levert imo beperkingen op. Het definieren van koppelvlakken tussen
processen met verschillende functionaliteit levert minder onderhoud
en afhankelijkheden op.

Het ontwerp van het kanon hangt natuurlijk wel af van de target:
een mug of een kudde aanstormende olifanten.
Ik ga op het Net uit van olifanten :-)