---

hej
Jeg har nogle websider hvor brugere kan skrive indlæg via en formular.
På nogle af siderne bliver jeg oversmømmet af spam indlæg med adult stuff mv
på andre sider er der intet spam, uden at der er nogen påviselig grund til
at disse sider går fri.

Spørgsmålet er:
Er der en god måde at undgå disse spam indlæg på .....
har prøvet simple modeller med et password der skal indtastes for at få vist
formularen - men det hjælper ikke.
HAr I andre ideer ..?

på forhånd tak
Otto
..

---

"Otto" <ottoleholt@tele.dk> skrev i meddelelsen
news:47b190c9$0$2088$edfadb0f@dtext02.news.tele.dk...

> Spørgsmålet er:
> Er der en god måde at undgå disse spam indlæg på .....
> har prøvet simple modeller med et password der skal indtastes for at få
> vist formularen - men det hjælper ikke.

Da du indførte det med password, ændrede du så også filnavnet til den fil,
der udfører formular-indtastningen?
Spammerne tilgriber sandsynligvis dén fil direkte udenom din formular.

Sæt evt. en session-variabel hos brugerne, når de kommer ind på formularen.
I filen, der behandler formulardataene tjekkes der så, om dén session stadig
er i live.

Jeg eksperimenterer for tiden selv med en sådan løsning.
Sessionvariablen der sættes, er en tilfældig streng.
I formularen har jeg så et input-felt, hvor variablen ligger.
<input type="hidden" id="barberetged" name="barberetged" value="GX63Z" />

I filen, der behandler det, tjekkes der så, om session("tingeltangel") er
lig med request.post("barberetged")

Hvis ikke det er tilfældet, gemmes skidtet ikke, og brugeren får en form for
fejlmeddelelse, der ikke giver noget direkte tegn på, at den er afvist
p.g.a. spam. Blot at der er sket en fejl.

---

"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev i meddelelsen
news:47b1d414$0$2103$edfadb0f@dtext02.news.tele.dk...

> Sessionvariablen der sættes, er en tilfældig streng.

Tilføjelse:
Sessionvariablen genereres altså i dét øjeblik, man kommer ind på siden.
Næste gang man kommer ind, bliver variablen altså en anden.

---

"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev i en meddelelse >
Sessionvariablen genereres altså i dét øjeblik, man kommer ind på siden.
> Næste gang man kommer ind, bliver variablen altså en anden.
Tak for forslaget Philip - men jeg forstår egentlig ikke lige hvordan
session variabel vil forhindre misbruget ..? Men det skyldes nok at jeg ikke
ved hvordan alle disse spam data leveres - man skal formendtlig ikke
forestille sig at det er en person der sidder og taster .... eller er det
nogle ondsindede programmer der laver denne spam ..?

Se f.eks www.gymnasiereform.dk -> 'ordet er dit'
mvh otto

---

"Otto" <ottoleholt@tele.dk> skrev i meddelelsen
news:47b1fbfb$0$2089$edfadb0f@dtext02.news.tele.dk...

> Tak for forslaget Philip - men jeg forstår egentlig ikke lige hvordan
> session variabel vil forhindre misbruget ..?

Det kan ikke forhindre misbruget, men det eliminerer dét misbrug, der kommer
af, at span netop ikke indtastes af en person, men bare autosendes uden om
formularerne. De tilgriber højst tænkeligt din submit-fil direkte.
Her tjekker jeg altså, om folk også var inde på min side i splitsekundet før
spammen blev afsendt.

En helt anden mulighed i samme bolgade er at lave et direkte tjek på dette i
submit-filen.

Eksempel:
Du har formularen i filen formular.asp
Formulardataene behandles/submittes i formposted.asp.

Her laver du så dette, der tjekker, at personen vitterligt har været igennem
din formular (HTTP_REFERER):

<%
if request.servervariables("HTTP_REFERER") =
"http://www.ditdomæne.dk/formular.asp" then
...koden der behandler de indtastede data
end if

> man skal formendtlig ikke forestille sig at det er en person der sidder og
> taster .... eller er det nogle ondsindede programmer der laver denne spam
> ..?

Det er lige præcis ikke en person, men en robot, der laver det.

---

On Tue, 12 Feb 2008 13:27:43 +0100, "Otto" <ottoleholt@tele.dk> wrote:

>Jeg har nogle websider hvor brugere kan skrive indlæg via en formular.
<snip>
>Spørgsmålet er:
>Er der en god måde at undgå disse spam indlæg på .....
>har prøvet simple modeller med et password der skal indtastes for at få vist
>formularen - men det hjælper ikke.

Det har været diskuteret flere gange i .html-gruppen.
En effektiv måde er CAPTCHA - hvor man bruger et billede af noget tekst,
som så skal indtastes. Bruges mange steder, og du har sikkert set det.
Det kræver, at du har en komponent, der kan generere din
CAPTCHA-challenge.

En simpel måde, men ret effektiv, er at lave et felt, som *ikke* må
udfyldes. Feltet skjules med CSS - men af hensyn til browsere, som ikke
understøtter dette, skal der stå i den del, der CSS-skjules, at man ikke
må udfylde det.
Når man checker formular-input, så kan den evt. bare droppes, hvis
feltet er udfyldt - eller hvis du gerne vil checke, om den laver falske
positive (negative ...), så send den til en anden mail-adr. end den
sædvanlige.
Jeg har brugt det på en tidligere meget spam-plaget side (ofte 10-20 om
dagen) og har stort set undgået spam siden (max 1-2 pr. måned).

Se yderligere forklaring:
<url: http://ekot.dk/www/spamtrap/>

Good luck!

--
Jørn Andersen,
Brønshøj

---

"Jørn Andersen" <jorn@jorna.dk> skrev i en meddelelse
news:rhp5r3h3tfcseaeauvskon15m9lod4des5@4ax.com...
> Se yderligere forklaring:
> <url: http://ekot.dk/www/spamtrap/>

Bare lige en lille skønhedsplet:
Du skriver: <textarea name="message" value="" cols="40"
rows="4"></textarea> i din fælde.
value er ikke gyldigt i textarea. Værdien i feltet kan dog findes med
javascript som message.value
Men ellers: Tak for den gode idé!
/Jørgen

---

On Feb 13, 1:53 pm, Jørn Andersen <j...@jorna.dk> wrote:

> En simpel måde, men ret effektiv, er at lave et felt, som *ikke* må
> udfyldes. Feltet skjules med CSS - men af hensyn til browsere, som ikke
> understøtter dette, skal der stå i den del, der CSS-skjules, at man ikke
> må udfylde det.
> Når man checker formular-input, så kan den evt. bare droppes, hvis
> feltet er udfyldt - eller hvis du gerne vil checke, om den laver falske
> positive (negative ...), så send den til en anden mail-adr. end den
> sædvanlige.
> Jeg har brugt det på en tidligere meget spam-plaget side (ofte 10-20 om
> dagen) og har stort set undgået spam siden (max 1-2 pr. måned).

Er det lang tid siden, du brugte det? For efter det blev et plugin til
flere af de dér gratis CMS, så er botsne altså også blevet klogere. Du
kan starte med at bede Google om ikke at cashe siden. For der er
masser af bots, som henter din side ind den vej, for at lede efter
huller (det kan minimere det, men ikke udrydde det, for de sender
spybots jævnligt til nye sider). Derefter kan du kalde din form, dine
felter, og din side noget på dansk. Guestbook.asp bør f.eks. hedde
gaestebog.asp, for det fatter bots nul af. De går efter feltnavne som
"message", "name" osv. Nøjagtigt, som de spammer dit domæne ved at
sende til standardadresser "webmaster", info", "mail" osv.

Så er der det med, hvordan det kan være, at lige én side er ramt. Og
det er ikke kun pga. navnet, men fordi, botsne én gang har lykkedes
med den side. Når først toget kører den vej, kan du ikke undgå, de
beskyder netop dén side med alt hvad de har. Ingen grund til at
beskæftige sig med sider, som _måske_ virker, hvis der har været
succes ét sted. Så den side må man rename, hvis ikke man gider se på
det.

Derudover, så skal du sørge for, din statistik ikke ligger offenligt.
Dén finder botsne også via Gogle, og dermed får du masser af referer
spam. Så sæt log in på den, eller bed din udbyder gøre det, og slet
den fra Google (igen cashen).

Jeg har selv en side, som - på dansk - spørger om at indtaste et tal i
formen "indtast tallet fire". Dén har været 100% effektiv indtil nu,
selvom jeg kan se i den interne statistik, hvordan botsne hamrer løs.
Hvis botsne finder ud af den, er det simpelt held, for de forstår
_ikke_ dansk (og så ændrer jeg bare tallet), eller også er det et
menneske, som spammer - og så ryger IPen på block-listen. Det er
_meget_ sjældent, der spammes fra DK, men har oplevet en enkelt
(sikkert en zoombiemaskine) fra norge.

Til sidst, så er der vulnerability scanners, som leder efter huller i
standardscripts, og det er scripts, som er populære til f.eks.
gæstebøger eller chatbokse. Også her vil det være smart at rename
filer og directories om muligt og holde alle sine scripts opdateret.

Det sidste og mest effektive er, at den endelige spamsikring ikke må
være en standard. Jeg skrev den med "skriv tallet fire", og den virker
fordi den er dansk og ikke brugt af ret mange. Samme model kan
benyttes (f.eks. skriv ordet XXXX bagfra), som heller ikke er
standardbeskyttelse, og derfor ikke noget botprogrammørerne kan tjene
penge på at bryde. De vil allerhelst forsøge med allerede kendte
scripts og sikringsmetoder, som mange benytter, og som de derfor kan
spamme flere ad gangen.

PS: HTTP_REFERER kan fakes, hvilket jo også referer spam beviser.
Derfor er den ikke 100% at bruge, hvis du vil sikre, de kommer fra din
side. Men man kan sætte en cookie, oghvis den ikke kan sættes, så
_kan_ det være en bot. Evt. kan man skrive, at der ikke kan bruges
form uden cookies tilladt. Men stadig er den altså 100% effektiv, den
med "skriv tallet fire". Prøv også at kigge på lki hvor mange
spamforsøg de har, som er lykkedes. Og så kig på sikringsformen. Så
vidt jeg husker fra Kim Ludvigen skulle der være ret så mange forsøg
om dagen.


MVH
Rune Jensen

---

"Rune Jensen" <runeofdenmark@gmail.com> skrev i meddelelsen
news:0b29b5ba-4039-4b34-b119-95a1a7ac1988@v67g2000hse.googlegroups.com...
On Feb 13, 1:53 pm, Jørn Andersen <j...@jorna.dk> wrote:

> Jeg har selv en side, som - på dansk - spørger om at indtaste et tal i
> formen "indtast tallet fire". Dén har været 100% effektiv indtil nu,
> selvom jeg kan se i den interne statistik, hvordan botsne hamrer løs.

Her er pointen på ekot.dk vist, at dén løsning er irriterende for brugerne.
For mig vil det være noget med en afvejning i forhold til hvor tit den
enkelte bruger må formodes at anvende formularen.
En profiloprettelses- eller mailformular må antages kun at blive brugt én-
eller meget få gange pr. person, så her er den fin nok.

En formular, hvor man kan kommentere en artikel må antages at blive brugt
flere gange af hver bruger (specielt hvis det er en debat, hvor bølgerne går
højt), så her irriterer man dem bare.
Her vil jeg hellere anvende løsningen med en cookie eller session.

Selv har jeg løst problemet lige dér ved at kræve, at folk logger ind på
deres profiler for at kommentere, men det kræver så et vist antal faste
brugere, før man kan gøre det uden at "dræbe" debatten.

> Til sidst, så er der vulnerability scanners, som leder efter huller i
> standardscripts, og det er scripts, som er populære til f.eks.
> gæstebøger eller chatbokse. Også her vil det være smart at rename
> filer og directories om muligt og holde alle sine scripts opdateret.

Det lyder mest som et problem på sider, der er lavet med standard-CMSer.

> PS: HTTP_REFERER kan fakes, hvilket jo også referer spam beviser.

Tak for oplysningen. Så gider jeg ikke engang at forsøge mig med dén
løsning.


> Så vidt jeg husker fra Kim Ludvigen skulle der være ret så mange forsøg
> om dagen.

Det kunne være, at jeg skulle tænke på at lave en log over mulige
spamforsøg.

---

"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev i en meddelelse
news:47b3363a$0$15876$edfadb0f@dtext01.news.tele.dk...

> En formular, hvor man kan kommentere en artikel må antages at blive brugt
> flere gange af hver bruger (specielt hvis det er en debat, hvor bølgerne
går
> højt), så her irriterer man dem bare.
> Her vil jeg hellere anvende løsningen med en cookie eller session.

Så skal du sætte cookie/session tidligt i forløbet, f.ex. på forsiden af dit
site, eller dit forum.

En bot kan crawle siden, og svare korrekt med cookie,session og referer.

Jeg laver f.ex. 'botter', der logger på CBB og henter taletidssaldo; der
gemmer scriptet cookies, når det logger ind, og sender dem pænt med ved de
næste requests, der henter værdierne.

Leif

---

On Wed, 13 Feb 2008 09:30:33 -0800 (PST), Rune Jensen
<runeofdenmark@gmail.com> wrote:

>On Feb 13, 1:53 pm, Jørn Andersen <j...@jorna.dk> wrote:
>> En simpel måde, men ret effektiv, er at lave et felt, som *ikke* må
>> udfyldes.
<snip>

>Er det lang tid siden, du brugte det? For efter det blev et plugin til
>flere af de dér gratis CMS, så er botsne altså også blevet klogere.

Jeg har brugt det siden juli 2007.
Jeg kan se, at knapt 1.000 spam-indlæg er blevet afvist (de ryger ind i
en særlig mailboks, og hvis jeg gider, går jeg nogle af dem igennem for
at se, om der er falske afvisninger).
Jeg husker ikke, at vi har fået egentlig spam i den periode (måske et
par enkelte).

Men det er så heller ikke et CMS-system, men "hjemme-gjort".


Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

On Thu, 14 Feb 2008 07:56:04 +0100, Jørn Andersen <jorn@jorna.dk> wrote:

>On Wed, 13 Feb 2008 09:30:33 -0800 (PST), Rune Jensen
><runeofdenmark@gmail.com> wrote:
>
>>On Feb 13, 1:53 pm, Jørn Andersen <j...@jorna.dk> wrote:
>>> En simpel måde, men ret effektiv, er at lave et felt, som *ikke* må
>>> udfyldes.
><snip>
>
>>Er det lang tid siden, du brugte det? For efter det blev et plugin til
>>flere af de dér gratis CMS, så er botsne altså også blevet klogere.
>
>Jeg har brugt det siden juli 2007.
>Jeg kan se, at knapt 1.000 spam-indlæg er blevet afvist (de ryger ind i
>en særlig mailboks, og hvis jeg gider, går jeg nogle af dem igennem for
>at se, om der er falske afvisninger).
>Jeg husker ikke, at vi har fået egentlig spam i den periode (måske et
>par enkelte).

Jeg prøvede lige at klikke mig igennem resten af dem, jeg endnu ikke
have set - og fandt 0 fejl-afviste (ud af knapt 1000).

Så min konlusion er, at til små og moderat store sites kan det være en
enkel og effektiv løsning.
Selvfølgelig kan det omgås, hvis man bliver offer for målrettet spam -
der er kun få permanente løsninger, når snakker kamp mod spam.

Så brug den så længe den virker - den er hurtig at implementere og
kræver ingen ekstra komponenter.


Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

On Feb 13, 7:25 pm, "Philip Nunnegaard" <phi...@fjerndettehitsurf.dk>
wrote:

> Det kunne være, at jeg skulle tænke på at lave en log over mulige
> spamforsøg.

<%

Dim filObj, textFil, IP, trno, rgx

IP = trim(Request.Servervariables("REMOTE_ADDR"))

if IP<>"din egen IP" then

Set filObj = Server.Createobject("Scripting.FilesystemObject")
Set textFil = filObj.Opentextfile(Server.Mappath("/logfil-et-svært-
navn-at-gætte.txt"), 8, true)

rem tiden for submit.forsøg
textFil.WriteLine("Dato: " & FormatDateTime(now,2)) & " Kl: " & time

rem Den IP, som forsøger submit
textFil.WriteLine("IP: " & Request.Servervariables("REMOTE_ADDR"))

Den referer, som submitteren bruger
textFil.WriteLine("Referering page: " &
Request.Servervariables("HTTP_REFERER"))

rem Den side, som der forsøges at tilgå
rem her kigger jeg på, om det er hovedsiden eller den includede side
rem hvis der forsøges at tilgå included side
rem er det sikkert en bot
textFil.WriteLine("URL: " & Request.Servervariables("URL"))

rem meddelelsen - message er et form-felt
textFil.WriteLine("Tekststykke: " & left(Trim(request.form("message")),
20))

rem det kodeord, som forsøges brugt - no er et form-felt
textFil.WriteLine("Kodeord: " & left(trim(request.form("no")),7))
textFil.WriteLine
Set filObj = NOTHING
Set textFil = NOTHING

end if
%>


Lad den køre et par dage, så kan du se, i hvilken rækkefølge der
forsøges at tilgå din side, og hvad man forsøger at submitte med.
Langt det meste spam forsøges at blive sendt på én enkelt af mine
sider. Den første, som blev uploadet (og der var ikke spamsikring på),
og den eneste, de derfor har haft succes med.

Din logfil vil ligge i roden med det navn, du vælger, og den vil ikke
logge tilgang fra din IP. Hvilket ikke gør så meget i DK, da det som
sagt er minimalt hvad der forsøges af spam herfra.

Ovenstående vil formentlig virke bedst til mindre sider, da de laves
skriv/læs-operationer.

Du kan stadig bruge referer i modsat retning - til at redirecte alle
sider, som tilgår med referer som
instr(referer,"viagra")
instr(referer,"gambling")
instr(referer,"casino")
samt et par stykker mere. Min egen referer block list er ikke stor, og
tager de fleste. Det er mest den referer spam, som gør man får links
til infected/virus sider i sin statistik - det er her, man skal bede
sin udbyder om at holde den fra Google og andre. Ellers risikerer man
at ryge _meget_ langt ned. Google kan ikke skelne imellem links i din
statistik
(referers) og så sider, du linker til selv. Hvis din statistik ligger
i Google, vil den blive behandlet som alle dine andre sider. Dette
gælder også for spambots, som ser, de har adgang til din statistik, og
så ruller ruletten.

Jeg redirecter til en søgeside med bottens IP og ordet spam i
søgestrengen (man har vel humor) - men ellers ved jeg ikke, om denne
kan bruges, det er noget, jeg overvejer:
http://www.solit4u.dk/public/hackerslist.asp

Tjek mistænkelige IPer på
http://projecthoneypot.org/search_ip.php

og navn og udbyder på:
http://www.ip2location.com/free.asp


MVH
Rune Jensen

---

On Feb 14, 12:08 am, Rune Jensen <runeofdenm...@gmail.com> wrote:

> Jeg redirecter til en søgeside med bottens IP og ordet spam i
> søgestrengen

Skal selvfølgelig sættes ind på hovedsiden øverst - ellers har det
mindre virkning:

<% script=vbscript %>

<%

dim IP2, Referer

IP2 = trim(Request.Servervariables("REMOTE_ADDR"))
Referer = lcase(request.ServerVariables("HTTP_REFERER"))

Rem referer block list
if instr( Referer, "phentermine") or instr( Referer, "mebel-
fabrika.ru") or instr( Referer, "spycam") or instr( Referer,
"camgirl") or instr( Referer, "]") or instr( Referer, "viagra") or
instr( Referer, "casino") or instr( Referer, "porn") then
response.redirect "http://www.altavista.com/web/results?itag=ody&q=
%22" & IP2 & "%22+spam&kgs=0&kls=0"

%>


MVH
Rune Jensen

---

On Feb 14, 9:26 am, Jørn Andersen <j...@jorna.dk> wrote:

> Så min konlusion er, at til små og moderat store sites kan det være en
> enkel og effektiv løsning.
> Selvfølgelig kan det omgås, hvis man bliver offer for målrettet spam -
> der er kun få permanente løsninger, når snakker kamp mod spam.

Interessant. For de spamforsøg jeg får, der bytter den bare rundt på
langt de fleste. Det vil sige, at hvis mit kodefelt IKKE må skrives i,
og de kan se, de ikke kommer igennem første gang, så prøver de bare
igen og bytter formfelt til spammen. Og hvorfor ikke, det koster jo
ikke dem noget at forsøge sig frem...


> Så brug den så længe den virker - den er hurtig at implementere og
> kræver ingen ekstra komponenter.

Det, jeg mente var, at selve det med de skjulte felter nu er blevet
plugin til i hvert fald ét open souce CMS - hvilket vil sige, at den
metode nu er standard - hvilket igen vil sige, det kan betale sig at
bygge programmer, som snører disse felter. I starten vil de nok
forsøge på standardscripts (jeg får ca. et par forsøg på
vulnerabilityscanning om måneden), fordi de har genkendelige/ens
filnavne - men der er altså ikke langt til at gå efter hjemmegjorte
skjulte felter og så bare prøve sig frem. Ikke fordi jeg så vil lyde
pessimistisk... Man kan jo gøre som Toke foreslår, og så sætte
tilfældigt form/feltnavn hver gang og flytte rundt på dem i koden. Det
burde kunne holde dem hen et godt stykke tid, mens de tager de nemme
ofre;)

PS: Det kommer man så ikke af med referer spam af, og de sidste tre
bots jeg har haft var både refererspammere og commentspammere - 2 i
én... så det gælder stadig at holde includefilens navn hemmeligt og
iøvrigt sin statistik fri fra søgemaskinerne.


MVH
Rune Jensen