---

Kan email adressen skjules?
I en formmail står der bl.a.:

<input type="hidden" name="require" value="mail,navn">
<input type="hidden" name="recipient" value="tilmelding@xxxxxxx.yy">
<input type="hidden" name="subject" value="Tilmelding til kursus">
<input type="hidden" name="redirect"
value="http://www.xxxxxxx.yy/zzzzzzz.html">
<input type="hidden" name="env_report" value="REMOTE_HOST,
HTTP_USER_AGENT">
<input name="submit" type="submit" class="style3"
onclick="MM_validateForm('navn','','R','mail','','RisEmail');return
document.MM_returnValue"
value="Send">

Det vil sige at <tilmelding@xxxxxxx.yy> står i koden, og kan ses af en
robot. Kan det skjules bedre?

- Mikael

---

nospamtoMike [8000 C] skrev:
> Kan email adressen skjules?
(...)
> Det vil sige at <tilmelding@xxxxxxx.yy> står i koden, og kan ses af en
> robot. Kan det skjules bedre?

Hvis tilmelding@xxxxxxx.yy er en fast værdi, dropper du bare den <input>
og definerer den i stedet i den fil der behandler afsendelsen af mailen
(altså den fil der står i <form action="filnavn.xxx">).

Det i hvert fald sådan jeg gør det.
Man er så selvfølgelig ikke garderet mod almindelig formularspam, men
det er der så også råd for, hvis det er.

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

> Hvis tilmelding@xxxxxxx.yy er en fast værdi, dropper du bare den <input>
> og definerer den i stedet i den fil der behandler afsendelsen af mailen
> (altså den fil der står i <form action="filnavn.xxx">).
>
> Det i hvert fald sådan jeg gør det.
> Man er så selvfølgelig ikke garderet mod almindelig formularspam, men
> det er der så også råd for, hvis det er.

Den ligger vist hos Unoeuro:
<form name="form1" method="post"
action="http://scripts.unoeuro.com/formmail/formmail.php">

- Mikael

---

nospamtoMike [8000 C] skrev:

> Den ligger vist hos Unoeuro:
> <form name="form1" method="post"
> action="http://scripts.unoeuro.com/formmail/formmail.php">

Ja, det gør den så.
Så er det jo ikke så ligetil.

Hvis du har mod på og mulighed for selv at brygge noget sammen, er der
en opskrift her:
http://www.phpartikler.dk/artikler/mail.php

Selv har jeg dog adskilt det i 2 filer, hvor den ene fil indeholder
formularen, og den anden er den der sender mailen af sted. Mest for at
være sikker på ikke at modtage flere ens mails fra folk der trykker F5,
efter mailen er skrevet og sendt.

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:

X8
>
> Man er så selvfølgelig ikke garderet mod almindelig formularspam, men
> det er der så også råd for, hvis det er.

Bare lave et tjek for, om afsenderen forstår GZIP. Gør vedkommende ikke
det, er det en spambot. I første omgang, kan man i stedet for at blocke,
sende det med påhæftet **SPAM** i subject, så det ikke lander i ind- men
i spam-bakken.

Dette er den nemme metode, det er ikke min idé, men jeg bruger den med
succes flere steder. Så prøv dette i første omgang.

En anden, lidt mere avanceret metode.. en spambot som en besøgende kan
ikke arbejde uden at have lavet en GET først, for den skal vide de
felter, som skal bruges (og det vil en "normal" human besøgende også
skulle selvfølgelig). Så enten skal den selv eller en harvester-bot have
hentet siden før der afsendes. Hvis botten altså kun sender, men ikke
henter siden først, er der noget galt. Det kan der også tjekkes for ved
at lave en hidden field med den besøgendes IP ved GET af formen, som så
skal være den samme IP ved POST. Eller nærmere: Det hidden field vil
altid være der ved POST, men svarer det ikke til hinanden, er det en
harvester, som har hentet siden først, og det hidden field vil derfor
indeholde dennes IP, ikke spambottens, og så kan man med sindsro blokere
afsendelsen. Harvesteren overlader jo formens felter og værdier til
spambotten i langt de fleste tilfælde helt ukritisk.

I den helt avancerede version tilføjer man i et yderligere hidden field
et timestamp til GET (det, som hedder star-date), og tidsforskellen på
GET og POST skal så ligge på en rimelig tid (1 sekund fra get til post,
er helt klart spam, f.eks. for man kan slet ikke udfylde en form så hurtigt)

Skriv, hvis du/i vil have flere idéer, der er mange. Man kan sågar
serverside tjekke op imod en gratis spam-database, hvis det er..

PS: Jeg lavede en gang for sjov et forsøg med en dynamisk fake
mailadresse, som det var meningen, der skulle harvestes. Den var baseret
på catch-all, sådan at den første del af adressen var den besøgendes IP,
så at mailadressen var forholdsvist unik, og derfor kunne spores. Det
blev så aldrig en succes.. måske var den skjult for godt eller for
mistænkelig, jeg fik i hvert fald aldrig mails til catch-all den vej,
men selve idéen tror jeg nu nok kan bruges med lidt udbygning, hvis man
vil se, hvem (hvilke IPer) der spammer og harvester.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Hvis botten altså kun sender, men ikke
> henter siden først, er der noget galt.

Jeg synes ikke jeg har set noget POST uden en forudgåene GET i vores
statistik.

Men jeg har heller ikke kigget så grundigt som du har.

> I den helt avancerede version tilføjer man i et yderligere hidden field
> et timestamp til GET (det, som hedder star-date), og tidsforskellen på
> GET og POST skal så ligge på en rimelig tid (1 sekund fra get til post,
> er helt klart spam, f.eks. for man kan slet ikke udfylde en form så
> hurtigt)

Man kan også lave det nummer med at have en .gif/.png, og levere den via
ASP/PHP, og sætte en cookie der.
Hvis cookien ikke er sat ved POST, ved man det er en bot.

Men det ser ud som om OP bruger et færdigt (fælles) script, så han kan nok
ikke gøre så meget den vej.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Hvis botten altså kun sender, men ikke
>> henter siden først, er der noget galt.
>
> Jeg synes ikke jeg har set noget POST uden en forudgåene GET i vores
> statistik.

Nej, naturligvis ikke, min forklaring var nok lidt ulden. Men forskellen
ligger i, hvilken IP, der henter siden inden POST, og om det er den
samme IP, som GETter, som også POSTer. Man kan sagtens have en IP, som
bare entrer siden, derefter POSTer, men den har selvfølgelig fået sine
informationer om formens felter fra en harvester, som så har hentet
siden inden. Så det ser bare ud, som om, spambotten ikke har hentet
siden, i virkeligheden har en anden bot hentet siden for spambottten*)

Eneste mulighed, jeg lige kan komme på, hvor der alene er en POST og
ikke andet, er hvis det er et standard, f.eks. Open Source CMS, eller et
offentligt script, her behøver man (måske) ikke hente, da sidens
opsætning og felters navne er offentlige, eftersom koden selv er
offentlig. Men det virker så kun til de allerdårligste opsætninger, som
kun smækkes op, og hvor intet er ændret i den bagvedliggende kode fra
originalkoden. Men det er da vidst også at bede om ballade i anden
forbindelse så. Hm.. ja, og så kan man måske hente informationer på
Google cashe.

> Man kan også lave det nummer med at have en .gif/.png, og levere den via
> ASP/PHP, og sætte en cookie der.
> Hvis cookien ikke er sat ved POST, ved man det er en bot.

Det er den eneste metode, jeg mangler at afprøve, men når man kender
botternes normale fremgangsmåde, kan man allerede sige, den metode må
være yderst effektiv. Alene cookies, gør det svært for botten, men jeg
tvivler også på, der er mange botter, som henter andet end den rå HTML. **)

> Men det ser ud som om OP bruger et færdigt (fælles) script, så han kan nok
> ikke gøre så meget den vej.

Så skal man måske lave et eller andet før kaldet til scriptet. Så man
f.eks. kun viser formen, hvis man er sikker på, det er en human user.
Det kan nok løses, men er lidt vanskeligere, når man ikke har fuld
kontrol med scriptet. Det bedste er stadig (IMO) at teste ved POST om
det er human eller bot. Så undgår man også tvivlen, om det nu er en
søgemaskinebot.


MVH
Rune Jensen





NOTE:
*) "Lady Violet" var vidst en sådan, som havde sendt "spybots"
(harvesters) ud inden angrebet, så den (og en fire-fem andre) bare kunne
massespamme.

**) Men det er klart, jo højere man ligger i page rank, des mere
interessant vil det være at injecte spam (nu snakkes så spam på
hjemmesider eller forums), så hvis den er helt oppe at ringe i page
rank, kan det måske betale sig at betale nogen "human users" for at
lægge spam (nok russere, hvis det er, de er efter sigende "billige i
drift" - specielt i forbindelse med løsningen af CAPTCHAS er det vidst
brugt at sende det i licitation).


--
WinAMP:
Vanilla Ninja - Danger Zone
http://www.youtube.com/watch?v=Q5ajcfQDNnY

---

Rune Jensen skrev:
8X
> Så skal man måske lave et eller andet før kaldet til scriptet. Så man f.eks.
> kun viser formen, hvis man er sikker på, det er en human user. Det kan nok
> løses, men er lidt vanskeligere, når man ikke har fuld kontrol med scriptet.
> Det bedste er stadig (IMO) at teste ved POST om det er human eller bot. Så
> undgår man også tvivlen, om det nu er en søgemaskinebot.
8X


Jeg sætter en $_SESSION[] variabel på siden med formen, og checker den
i det script, der modtager data. Er den ikke sat til det rigtige - ud
til højre med data, de kommer ikke fra formen.
Har kun implementeret det i kontaktformular, som sender mail, men har
ikke haft een spam email siden - og der er vel ikke nogen grund til at
samme teknik ikke skulle kunne bruges til data der lagres, og/eller
vises på siden.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen skrev:

> Jeg sætter en $_SESSION[] variabel på siden med formen, og checker den i
> det script, der modtager data. Er den ikke sat til det rigtige - ud til
> højre med data, de kommer ikke fra formen.

Bruger selv 2 forskellige metoder, hvoraf denne er den ene. Den anden er
den med at skjule et felt via CSS.
Begge metoder virker, men min intuition siger mig at den med $_SESSION
må være den mest effektive.

Til gengæld er jeg arg modstander af at genere brugerne med at skulle
udfylde et ekstra felt med tekst a la "Skriv tallet fire".

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard wrote:

> Bruger selv 2 forskellige metoder, hvoraf denne er den ene. Den anden er
> den med at skjule et felt via CSS.

Her skal du være opmærksom på, at det ikke er det at skjule feltet, der gør
at det virker, men valgt af feltnavn der afgør 'effektiviteten'.

Rune og jeg har lave en ret omfattende statistik/afprøvning sidste år med
forskellige feltnavne.

Ud fra de navne vi har prøvet, er det kun email,comment,message, der giver
100% hit rate.

Andre felter som Author,Date,Homepage er ikke udfyldt i 100% at filfældene.

comment og message ville jeg mok ikke bruge, for det er hér alle tilbud om
viagra,medicin, se porno m.m. kommer, så de vil generere uforholdsmæssig
meget trafik.

Tilbage er der kun email (i vores tilfælde).

> Begge metoder virker, men min intuition siger mig at den med $_SESSION
> må være den mest effektive.

Se mit svar til Birger.

> Til gengæld er jeg arg modstander af at genere brugerne med at skulle
> udfylde et ekstra felt med tekst a la "Skriv tallet fire".

Ja, men den kan man også løse (for de fleste brugere).
Ovre på min Linkchecker:
<http://w-o-p-r.dk/wopr.tools/wopr.linkchecker.asp>
har jeg lagt dette felt i en <noscript> sektion.

Dvs har brugeren slået javascript fra, kommer der en 'skriv tallet fire',
som jeg tjekker på.

Har brugeren derimod javascript slået til, ændre jeg caption(value) på
submitknappen.

Denne value tester jeg også på serverside.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Her skal du være opmærksom på, at det ikke er det at skjule feltet, der gør
> at det virker, men valgt af feltnavn der afgør 'effektiviteten'.

Jeg kalder det gerne 'subject'. Kunne være at jeg skulle gå over til
'email'.

Egentlig synes jeg at det er fantastisk at det stadig virker, når man
tænker på hvor gammelt tricket er.

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:

> Egentlig synes jeg at det er fantastisk at det stadig virker, når man
> tænker på hvor gammelt tricket er.

Det viser vel blot at der stadig er nok ubeskyttede formmails.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Philip Nunnegaard skrev:
> Stig Johansen skrev:
>
>> Her skal du være opmærksom på, at det ikke er det at skjule feltet,
>> der gør
>> at det virker, men valgt af feltnavn der afgør 'effektiviteten'.
>
> Jeg kalder det gerne 'subject'. Kunne være at jeg skulle gå over til
> 'email'.
>
> Egentlig synes jeg at det er fantastisk at det stadig virker, når man
> tænker på hvor gammelt tricket er.

Så vent, til din side når højere op i Google. Det er kun i forhold til,
hvor nemt, det er at spamme naboen i stedet, der afgør det ellers, når
man ligger sådan i midterfeltet. Hvis du når, skal vi sige
hotmail-status i page rank, så vil du nok opleve helt andre og mere
succesfulde spamforsøg, for så vil spam på din side have meget høj
værdi. Hverken Google eller MSN bruger tricket med skjulte felter (ikke
sidste gang, jeg kiggede i hvert fald). Google bruger faktisk et trick,
som ligner Stigs JS-fif lidt, ret kløgtigt sat sammen, så man også kan
bruge det med billeder og JS slået fra. ..ah, OK, på tilmelding til
Gmail benyttes rene CAPTCHAS, nærmest ulæselige, så det er ikke dén, jeg
hentyder til, jeg må have set det på en af deres andre sider.

PS: Logger du alle egenskaber i HTTP? For så vil du måske se, at
Israelere er nogle rigtige sataner, ret kløgtige og imiterer ret
nøjagtigt human behavior, hvor russere bare spammer uden at vide, hvem
eller hvad de spammer (og derfor er langt de letteste at fange - nogle
gange giver de endda en ru i user-agent, bare for at være sikker på at
blive opdaget).

Hvad du skal kigge efter, er:
- Er der en GET før POST, som har samme IP?
- Er tiden mere end ti-tyve sekunder fra GET til POST - og har
(spam)IPen evt. en lille række GET på andre sider først, så det ligner
en human user, der bare surfer lidt rundt? (Israelere er gode til dette)
- Forstår den GZIP?
- Er user-agent valid? (Ikke noget med LIBWWW-PERL o. lign.)
- Er user-agent Internet Explorer 6 eller mindre? (ikke direkte
mistænkeligt alene, men meget brugt af spambots - deres user-agent list
opdateres ret langsomt)
- Passer referers i forhold til, hvordan den bevæger sig på din side?
- Er accept, acceptlanguage osv. udfyldt? (en del kinesere er dumme nok
til at skrive HK-CN eller lign. i acceptlanguage - generelt vil en human
user have så meget udfyldt som muligt)
- Overholdes HTTP-standarden? (f.eks. ikke Protocol:http1.0 og
connection:Close, da close er en HTTPv1.1 standard. Hvis en eller begge
mangler, er det mistænkeligt)
- indeholder referer f.eks. viagra eller cialis? (referer spammer - en
bot kan godt være både referer spammer, harvester og spammer)
- findes den side, der refereres fra, som indgangspunkt til din side, og
findes der et link til din side på den side? (bør testes med en remote
service)
- IPer: russere, kinesere, israelere, tyrkere? Er de listet på
projecthoneypot.org eller stopforumspam.com?
- indgang fra Google/andre søgemaskiner: ser søgestrengen reel ud?

- Andre ting: skifter user-agent? Underlige koder i URL/querystring?
(mosConfig_absolute_path, SQL-strings) - Forkerte variable?

Og der er vidstnok mere..

HUSK... at hvis en bot identificerer sig som f.eks. Googlebot, så SKAL
den forstå Gzip. Det gør alle søgemaskiner, jeg har testet. Man skal
derimod passe på med validatorer, de skal testes særskilt, evt. på IPen,
så de kan whitelistes. Man kan grundlæggende også whiteliste alle danske
IPer. Skulle der endelig være spam fra dem, er det alligevel real human
beings, ikke botter.

Denne liste er i stor grad sammensat i samarbejde med Stig, og udfra
den, dannede vi nogle regler samt white- og blacklists til at blocke
bots på forskellige niveauer, hvis der var en vis mængde mistænkelig
opførsel - de fik en 404 - not found. Her et lille år efter, er der
nærmest ingen botter (kun nogle få russere - de spammer som sagt bare ud
i det blå), og det har der ikke været i 3-4 måneder. Jeg har til et
andet projekt forsøgt at lokke nogle botter til, men det er ikke
lykkedes særligt godt ;) Så denne måde at gå direkte til botterne er
yderst effektiv.


MVH
Rune Jensen

---

Rune Jensen skrev:

> - Er der en GET før POST, som har samme IP?

Det er helt sort snak for mig. Jeg bruger kun POST i mine formularer.
Jeg går ud fra at vi taler om et tjek på at formularsiden er indlæst,
før der postes.

> - Forstår den GZIP?

Hvordan tjekker man det? HTTP_ACCEPT_ENCODING?

> - Er accept, acceptlanguage osv. udfyldt? (en del kinesere er dumme nok
> til at skrive HK-CN eller lign. i acceptlanguage - generelt vil en human
> user have så meget udfyldt som muligt)

Kan man gå ud fra at det er en bot, hvis *ikke* HTTP_ACCEPT_LANGUAGE er
udfyldt?
Hidtil har jeg i hvert fald valgt at betragte dem som botter.

Jeg vil med det samme tage nogle af tingene i din tjekliste med i de
formularer jeg laver fremover. I hvert fald det af det som jeg kan finde
ud af at forholde mig til.

> Jeg har til et
> andet projekt forsøgt at lokke nogle botter til, men det er ikke
> lykkedes særligt godt ;) Så denne måde at gå direkte til botterne er
> yderst effektiv.

Jeg kan godt huske at du skrev et eller andet på din side om at lokke
dem til for at få udført nogle "cron jobs".

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:
> Rune Jensen skrev:
>
>> - Er der en GET før POST, som har samme IP?
>
> Det er helt sort snak for mig. Jeg bruger kun POST i mine formularer.
> Jeg går ud fra at vi taler om et tjek på at formularsiden er indlæst,
> før der postes.

Hvis du i din statistik logger HTTP_METHOD ud for hver besøgende, vil du
se for det meste GET og POST (der er andre, men de er ikke så
interessante lige her). GET er hent af siden, POST kan betragtes som
submit af forme.

Man kan ikke poste uden at vide, hvad der skal postes med og til, med
andre ord, siden skal hentes, før man kan submitte. Derfor, hvis en IP
kun laver en POST uden forudgående GET, må den have fået informationer
om formen og dens felter andetsteds fra, og så kan den kyles ud til
højre. Vil du være sikker, så læg IP-adressen i et hidden field ved GET
- det skal matche med den IP, som POSTer. Jeg gjorde nogenlunde sådan
her med det sidste:

GET:

<input type="hidden" value="<%=replace(
request.servervariables("REMOTE_HOST"), ".", "&#46")%>" name="iptjek" />

dette placerer IP-adressen ved nedhentning i et hidden field ved navn
iptjek. Punktummer i IPadressen udskiftes så også lige med en entitity
for punktm.

Og POST:

If trim(lCase( request.form("iptjek")))<>trim(lCase(
request.servervariables("REMOTE_HOST"))) then [spammer]

Dette tjekker for, om IPen i hidden field ved GET er lig med IP ved
POST, samt om entity er oversat til punktum (som den skal være, hvis det
er en human user - selv LYNX forstår entities)

Andre har forsøgt med en (forholdsvist) unik ID for hver besøgende,
baseret udfra user-agent, connection, acceptlanguage osv. Princippet er
dog det samme, at det skal være ens ved GET og POST. Man skal udvælge de
rigtige her, for IE blandt andet laver ændringer på et par af dem, alt
efter om siden ligger i cashe. Men ellers er metoden ret ligetil.

>> - Forstår den GZIP?
>
> Hvordan tjekker man det? HTTP_ACCEPT_ENCODING?

Ja. Lav en instring eller hvad det nu hedder i PHP (men endelig KUN ved
POST, ikke ved GET), for at se, om gzip er indeholdt. Er den ikke det,
ud til højre.

Kun nogle få israelere er sluppet igennem denne test hos mig. Men det er
lang tid siden nu, og jeg kan ikke afvise det var human users.

>> - Er accept, acceptlanguage osv. udfyldt? (en del kinesere er dumme
>> nok til at skrive HK-CN eller lign. i acceptlanguage - generelt vil en
>> human user have så meget udfyldt som muligt)
>
> Kan man gå ud fra at det er en bot, hvis *ikke* HTTP_ACCEPT_LANGUAGE er
> udfyldt?

Nej, desværre ikke 100% (ikke ifølge min statistik altså). Det skal
sættes sammen med andre tests. Men en CN eller TR eller RU er da
mistænkelig.. En anden mistænkelig opførsel er, hvis hverken connection
eller protocol eller accept eller acceptlanguage er sat.

> Hidtil har jeg i hvert fald valgt at betragte dem som botter.

Vi gjorde dette: Giv hver mistænkelig opførsel en bitværdi i en
statusvariabel. Sådan her (vi lavede en include-fil til disse tests, som
blev indsat helt i toppen af hvert HTML-dokument):

Mistænkelig opførsel test nummer (bit sat ved dårlig opførsel):

1. BIT 0 = STATUS or 1
2. BIT 1 = STATUS or 2
3. BIT 2 = STATUS or 4
4. BIT 3 = STATUS or 8

osv.

Når du så tester på status, skal der helst være 0 bits sat, STATUS=0
(hvis du sætter for dårlig opførsel), men du kan teste individuelt på
enkelte bits også. Man kan lave kombinationer, så én eller flere
"dårlige opførsler" er tilladt, andre ikke. Det, som tog tid var at lave
SQL søgestrenge til STATUS i statistikken og så sammenligne med, om de
spammede, injectede, harvestede, om de var blaclistet i spamdatabaser
osv. Der må ikke være nogen false positives i nogle af testene, og man
kan først være sikker, når man har et vidst materiale.

> Jeg vil med det samme tage nogle af tingene i din tjekliste med i de
> formularer jeg laver fremover. I hvert fald det af det som jeg kan finde
> ud af at forholde mig til.

Nu ved jeg ikke, hvor langt du vil gå. Hvis du i første omgang ikke er
interesseret i andet end alm. spamblocking, bare start med test for
GZIP, den tager langt de fleste, og den er hammer nem at lægge ind. Hvis
du får behov for mere, så kan du gå i gang med det lidt mere avancerede,
som f.eks. entites i hidden fields, eller en egentlig test af, hvad der
skal til for at udpege og blocke hver bot-type, som ovenfor nævnt med en
status-variabel. Du kan lave tests og undertests til disse med
tilhørende statusvariabler, så du kan komme meget langt op i
nøjagtigthed (f.eks. gå direkte efter referer spammere), men det er ikke
sikkert, det er nødvendigt (jeg tænker på tiden, som skal bruges til
for-tests, der er _mange_ muligheder). GZIP er en overordnet generel
løsning.

Jeg vil dog godt råde til (men det er alene min egen holdning) at tjekke
querystring, at denne ikke indeholder SQL-strenge eller HTTP-værdier.
Det er helt klart XSS eller SQL-injection-forsøg. Følgende tvinger også
én til at overholde god kodeskik (ikke SQL direkte i URLer eller URLer
direkte i querystrings)

Prøv dette:
http://runejensen.dk/index .asp?keynav=1

Og derefter dette:
http://runejensen.dk/index .asp?keynav=http://viagra4u.example.com

Eller dette:
http://runejensen.dk/index .asp?page='droptable

(af hensyn til Google - fjern lige mellemrum)

Der er via RegEx indsat tjek for, om der forsøges at bruge andre end
lige nøjagtigt de tilladte tegn i en URL, og mine querystringe må alene
indeholde alfanumeriske tegn, underscore, samt &. Der blockes for hele
strengen, hvis der er bare ét tegn, som ikke er tilladt. Nu bruger jeg
så en "moved permanently", men man kan snildt bruge "404 - not found"
for at minimere load på serveren i stedet. Det er under ingen
omstændigheder godartet ment de to sidste ;)

Af samme grund også et råd om at logge querystring i din statistik.

>> Jeg har til et
>> andet projekt forsøgt at lokke nogle botter til, men det er ikke
>> lykkedes særligt godt ;) Så denne måde at gå direkte til botterne er
>> yderst effektiv.
>
> Jeg kan godt huske at du skrev et eller andet på din side om at lokke
> dem til for at få udført nogle "cron jobs".

Jep ;)


MVH
Rune Jensen

---

Rune Jensen skrev:

> GET:
>
> <input type="hidden" value="<%=replace(
> request.servervariables("REMOTE_HOST"), ".", "&#46")%>" name="iptjek" />

Nå, OK, det skal være REMOTE_ADDR og ikke REMOTE_HOST. Men i ASP får man
IPen ved begge.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Nå, OK, det skal være REMOTE_ADDR og ikke REMOTE_HOST. Men i ASP får man
> IPen ved begge.

Kommer an på hvordan serveren er sat op.
Hvis den er sat op til at lave rDNS på REMOTE_ADDR, vil REMOTE_HOST
indeholde navnet.

Men det frarådes generelt, da det er ret performancekrævende.
(kræver opslag på DNS servere for hver request)

Samme gælder Apache, hvor man formentlig heller ikke får remote host navnet.

--
Med venlig hilsen
Stig Johansen

---

Rune Jensen skrev:

>>> - Er der en GET før POST, som har samme IP?
>>
>> Det er helt sort snak for mig. Jeg bruger kun POST i mine formularer.
>> Jeg går ud fra at vi taler om et tjek på at formularsiden er indlæst,
>> før der postes.
>
> Hvis du i din statistik logger HTTP_METHOD ud for hver besøgende, vil du
> se for det meste GET og POST (der er andre, men de er ikke så
> interessante lige her). GET er hent af siden, POST kan betragtes som
> submit af forme.

OK! Så svaret er "ja".
Jeg lod mig bare forvirre af at GET i min verden er variabler man henter
fra forespørgselsstrengen (f.eks. a og b i fil.xxx?a=2&b=3).

Jeg forstår det sådan at det du kalder "GET" er det jeg kalder selve
formularen eller siden som den ligger på.


> Ja. Lav en instring eller hvad det nu hedder i PHP (men endelig KUN ved
> POST, ikke ved GET), for at se, om gzip er indeholdt. Er den ikke det,
> ud til højre.

Så havde jeg forstået det rigtigt, og den havde jeg så sat ind i min nye
formular.

>> Jeg vil med det samme tage nogle af tingene i din tjekliste med i de
>> formularer jeg laver fremover. I hvert fald det af det som jeg kan
>> finde ud af at forholde mig til.
>
> Nu ved jeg ikke, hvor langt du vil gå. Hvis du i første omgang ikke er
> interesseret i andet end alm. spamblocking, bare start med test for
> GZIP, den tager langt de fleste, og den er hammer nem at lægge ind.

Det er til ren spamblokering i mit tilfælde, og den har jeg som sagt
allerede lagt ind.

> Jeg vil dog godt råde til (men det er alene min egen holdning) at tjekke
> querystring, at denne ikke indeholder SQL-strenge eller HTTP-værdier.
[snip]
> Prøv dette:
> http://runejensen.dk/index .asp?keynav=1
>
> Og derefter dette:
> http://runejensen.dk/index .asp?keynav=http://viagra4u.example.com
>
> Eller dette:
> http://runejensen.dk/index .asp?page='droptable

Her er vi vel inde på helt almindelig inputvalidering, som selvfølgelig
skal med.

Det sidste link afholder jeg dog mig fra at indsætte i min browser, selv
om jeg regner med at jeg bare bliver omdirigeret til index.asp som i de
to andre eksempler.

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:
> Rune Jensen skrev:
>
>>> Det er helt sort snak for mig. Jeg bruger kun POST i mine formularer.
>>> Jeg går ud fra at vi taler om et tjek på at formularsiden er indlæst,
>>> før der postes.

Ja.

>> Hvis du i din statistik logger HTTP_METHOD ud for hver besøgende, vil
>> du se for det meste GET og POST (der er andre, men de er ikke så
>> interessante lige her). GET er hent af siden, POST kan betragtes som
>> submit af forme.
>
> OK! Så svaret er "ja".

Ja ;)

> Jeg lod mig bare forvirre af at GET i min verden er variabler man henter
> fra forespørgselsstrengen (f.eks. a og b i fil.xxx?a=2&b=3).
> Jeg forstår det sådan at det du kalder "GET" er det jeg kalder selve
> formularen eller siden som den ligger på.

Jeg betragter alt andet end POST (submit af form) som en GET
(nedhentning af hele sidens HTML) for nemheds skyld, fordi det er POST,
som er interessant, da det er der spamtjekket udføres. Så jeg tester på
post helt i toppen, og alle andre metoder ligger så bare i én "else" hos
mig, og er altså ikke testet individuelt. Men den eneste anden metode,
jeg har oplevet var også HEAD iflg. min statistik, og den får ikke
formen ind alligevel. Hvis du vil have den nøjagtige forklaring på især
POST og GET, er det nok bedst at læse standarden for de forskellige
metoder, så jeg ikke roder mig ud i noget..:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1

Desværre er det ret teknisk, W3C har jo ikke ligefrem ry for at gøre
ting letforståelige, da alt skal specificeres ud.. Du kan også prøve
Wikipedia:
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Den danske version er (som sædvanligt) ikke færdig.

>> Ja. Lav en instring eller hvad det nu hedder i PHP (men endelig KUN
>> ved POST, ikke ved GET), for at se, om gzip er indeholdt. Er den ikke
>> det, ud til højre.
>
> Så havde jeg forstået det rigtigt, og den havde jeg så sat ind i min nye
> formular.

Fino.

>> Nu ved jeg ikke, hvor langt du vil gå. Hvis du i første omgang ikke er
>> interesseret i andet end alm. spamblocking, bare start med test for
>> GZIP, den tager langt de fleste, og den er hammer nem at lægge ind.
>
> Det er til ren spamblokering i mit tilfælde, og den har jeg som sagt
> allerede lagt ind.

Tænkte jeg også.

<SNIP>

> Her er vi vel inde på helt almindelig inputvalidering, som selvfølgelig
> skal med.

Forskellen er såmænd, at chekket laves på hele querystring, og ikke
individuelt på indholdet af hver variabel. Så hvis man f.eks. forsøger
sig med en ikke-defineret variabel med ulovlige tegn, vil man også få en
blocking. Det er en generel funktion, og alene minded på sikkerhed og på
at blocke sådanne forsøg så tidligt som muligt.

> Det sidste link afholder jeg dog mig fra at indsætte i min browser, selv
> om jeg regner med at jeg bare bliver omdirigeret til index.asp som i de
> to andre eksempler.

Man kan gøre, hva fanden det skal være af injectionforsøg via URLen på
det site, man vil stadig blive redirectet.. Nu kan jeg ikke huske hvor
mange injectionforsøg der var, men der var _mange_ i det første halve
år. Og en del senere forsøg var rigtigt nasty og kløgtige udført, hvor
selve koderne var skjult med %-tegn, jeg tror, visse af dem var rigtige
hackere, ikke bots. So far dog stadig ingen succesfulde angreb, % er
nemlig ikke en del af whitelisten (hvilket så har tvunget mig til at
encode alle URLer, hvis ikke de skulle blockes, men det er jo så en
yderligere fordel). Tænk på VALUS-hackeren, hvor man bare kunne lægge
SQL direkte i URLen, fordi de fuldstændigt ukritisk hældte kode ind med
en kulskovl. Dette lille tjek på 10-12 linjer villa have taget samtlige
forsøg med alle variable fra alle sider (men ville så stadig ikke være
en undskyldning for ikke lave sikker kode i sig selv - klart nok - men
jeg bruger ikke DB på min egen side, så jeg undgår at tænke på stored
procedures og deslige i den forbindelse).


MVH
Rune Jensen

---

Rune Jensen skrev:

> Tænk på VALUS-hackeren, hvor man bare kunne lægge
> SQL direkte i URLen, fordi de fuldstændigt ukritisk hældte kode ind med
> en kulskovl.

Det var lige præcis Valus-hackeren jeg havde i tankerne, da du skrev den
URL med droptable.


--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:
> Rune Jensen skrev:
>
>> Tænk på VALUS-hackeren, hvor man bare kunne lægge SQL direkte i URLen,
>> fordi de fuldstændigt ukritisk hældte kode ind med en kulskovl.
>
> Det var lige præcis Valus-hackeren jeg havde i tankerne, da du skrev den
> URL med droptable.

Fair nok, nu er URLen godt nok helt harmløs, men det kan jeg jo så
sagtens påstå... thumbs up, da du har bestået første prøve i ikke at
klikke på hvad som helst på nettet ;)


MVH
Rune Jensen

---

Rune Jensen skrev:

> Nu ved jeg ikke, hvor langt du vil gå.

Jeg lavede på et tidspunkt en lille statistrik over, hvad der egentlig
virker imod botspam, som er nemt at implementere, og som samtidig ikke
lukker en "menneskelig" bruger ude.

- CSS-skjult felt: Tager samtlige spambotforsøg
- Skriv tallet fire: Tager samtlige spambotforsøg
- Test af GZIP: Tager samtlige spambotforsøg (minus nogle få israelere)
- Test af at entity er oversat fra GET til POST: Tager samtlige russere

Man kan gøre sådan her for at lave entity- og GZIP-test i én varme - det
er kun submit-knappen, som skal ændres lidt:

GET:
.... formen og dennes input felter som normalt
....
....
<input type="submit" name="submit" id="submit" value="Send komment&#97;r" />


Og ved POST:

Dim METHOD, ACCEPT_ENC, SUBMIT

METHOD=lCase( request.servervariables("HTTP_METHOD"))
ACCEPT_ENC=lCase( request.servervariables("HTTP_ACCEPT_ENCODING"))
SUBMIT=trim( request.form("submit"))

if METHOD="post" and _
instr( ACCEPT_ENC, "gzip") and _
SUBMIT="Send kommentar" then [tillad posting]
Else
spammer
end if

---

Derudover er Stigs test af, at der hentes en ekstra fil, billede,
CSS-fil eller andet formentlig 100% effektiv imod både botspam.

En blacklist på max. 20-30 IPnumre, som altid blockes er et godt tillæg.
Det er en slags hitliste over de mest ondartede IPer, og egentlig også
for at minimere load på serveren. Indtil for nylig redigerede jeg denne
manuelt ca. ugentligt udfra bl.a. projecthoneypot.org og stopforumspam.com.

En yderligere mulighed er, man lave remote database look-up på netop
stopforumspam.com. Jeg synes ikke normalt om at man skal kontakte 3.
parts servere, da det kan sløve ens side, men det kan være nyttigt i
visse tilfælde, og metoden er forholdsvist nem - også en måde at lære
lidt om, hvordan en bot henter ens side ned iøvrigt, for det er
nogenlunde samme metode.

http://www.stopforumspam.com/apis


MVH
Rune Jensen

---

Rune Jensen wrote:

> Gmail benyttes rene CAPTCHAS, nærmest ulæselige, så det er ikke dén, jeg
> hentyder til, jeg må have set det på en af deres andre sider.

He - tell me about it :)
Sidste gang jeg skulle lave en Gmail måtte jeg prøve 3 billeder, for jeg
kunne simpelthen ikke læse lortet.

Det er vist ikke for folk i 'brillealderen'.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> He - tell me about it :)
> Sidste gang jeg skulle lave en Gmail måtte jeg prøve 3 billeder, for jeg
> kunne simpelthen ikke læse lortet.
>
> Det er vist ikke for folk i 'brillealderen'.

Jeg kender ikke til Gmail, men har oplevet det andre steder, hvor
billedet enten var ulæseligt, eller jeg af anden grund ikke anede hvad
jeg egentlig skulle indtaste.

Og hvorfor skal de så genere mig unødigt ved ikke alene tvinge mig til
at udfylde et unødvendigt felt, men oven i købet også tvinge mig til at
holde shift-tasten nede, mens jeg skriver. Og af og til aner jeg ikke om
der menes bogstavet 'O' eller tallet '0'.

Hundehoveder, hængerøve, elendige socialdemokrater...

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard skrev:

> Jeg kender ikke til Gmail, men har oplevet det andre steder, hvor
> billedet enten var ulæseligt, eller jeg af anden grund ikke anede hvad
> jeg egentlig skulle indtaste.

Tilføjelse: Jeg bruger *ikke* briller og kan normalt læse hvad der står
på en bus på lang afstand.

--
Philip - http://chartbase.dk | http://www.hitsurf.dk

---

Rune Jensen wrote:

> Google bruger faktisk et trick,
> som ligner Stigs JS-fif lidt, ret kløgtigt sat sammen, så man også kan
> bruge det med billeder og JS slået fra. ..ah,

Jeg ved ikke om vi snakker om det samme, for jeg skrev vist et par tricks.
Men jeg har lige kigget i analerne, og det trick jeg nævnte med billeder og
uden JS var ikke med separate cookies, men en session variabel, der bliver
sat ved kald af billedet.

Ved POST tjekker jeg om denne variabel er sat.

Det har den fordel, at der ikke er unødige felter osv i formularerne, samt
at der ikke skal hentes unødige billeder/filer eller lign.

Hvis man tager udgangspunkt i f.eks:
<http://webdesigngruppen.dk/diskussion.asp>
samt det tilhærende CSS:
<http://webdesigngruppen.dk/css/meeting.css>

kan man f.eks benytte dette billede:
body{
background: #cd9f6b url(../images/cork-large1.jpg);
Hvis man i stedet serverer billedet via ASP (eller PHP) rettes til:
body{
background: #cd9f6b url(../images/cork-large1.asp);

ASP-filen:
cork-large1.asp
skal blot dumpe billedet med den rette mime-type, og sætte denne session
variabel.

Hvis bot'erne skal knække den, så kræver det, at de læser CSS og parser den
og læser diverse baggrundsbilleder.

Det kommer nok aldrig til at ske, for det kræver for meget kode, som er for
nemt at opdage for anti-'ware'.

--
Med venlig hilsen
Stig Johansen

---

"Philip Nunnegaard" <nunnenospam@hitsurf.dk> wrote in message
news:4abcd987$0$56783$edfadb0f@dtext02.news.tele.dk...
> Stig Johansen skrev:
>
> > Her skal du være opmærksom på, at det ikke er det at skjule feltet, der
gør
> > at det virker, men valgt af feltnavn der afgør 'effektiviteten'.
>
> Jeg kalder det gerne 'subject'. Kunne være at jeg skulle gå over til
> 'email'.

Hov, lige et øjeblik.
Jeg skrev: 'de feltnavne vi har afprøvet'.

Ingen kender bot'er og deres adfærd (=programmørerne), så jeg vil ikke
udtale mig om eksakt viden, blot emperi.

Jeg lavede lige et kort udtræk over feltnavne, og deres indhold (20 første
tegn), og det ser ikke ud til vi har prøvet 'subject', ergo kan jeg ikke
udtale mig om det feltnavn.
http://w-o-p-r.dk/test/q.fieldnames.html
(NB knap 400 KB).

Jeg vil forslå, at man selv laver sine egne forsøg, men hvis man kigger på
f.eks feltet 'author', så er der 35 tilfælde med værdien 'author.', som er
den viste værdi, og dermed uberørt.

'date' som jeg nok havde forventet altid ville være udfyldt, har 46 uberørte
tilfælde ('dont type date here').

'homepage' har 358 uberørte.
osv, osv.

> Egentlig synes jeg at det er fantastisk at det stadig virker, når man
> tænker på hvor gammelt tricket er.

Så længe der er nok 'bid', bliver der nok ikke gjort noget ved det (fra bot
kodernes side).

--
Med venlig hilsen/Best regards
Stig Johansen

---

Birger Sørensen wrote:

> Jeg sætter en $_SESSION[] variabel på siden med formen, og checker den
> i det script, der modtager data. Er den ikke sat til det rigtige - ud
> til højre med data, de kommer ikke fra formen.
> Har kun implementeret det i kontaktformular, som sender mail, men har
> ikke haft een spam email siden - og der er vel ikke nogen grund til at
> samme teknik ikke skulle kunne bruges til data der lagres, og/eller
> vises på siden.

Her skal du være opmærksom på, at cookien bliver sendt sammen med HTML'et
ved en GET af formularen.

Hvis bot'en sende cookien med tilbage, vil PHP (eller ASP) tro data kommer
fra formen.

Det var derfor jeg lavede det der fif med at lægge en cookie via .gif/png
eller lign.

Det kræver at bot'en parser HTML'et og finder <img> tags osv, hvilket jeg
ikke tror er nært forestående.

Nu skriver jeg bare .gif/.png, men det kan lige så godt være en ekstern CSS
fil eller JS fil, som man alligevel har på siden.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen har bragt dette til verden:
> Birger Sørensen wrote:
>
>> Jeg sætter en $_SESSION[] variabel på siden med formen, og checker den
>> i det script, der modtager data. Er den ikke sat til det rigtige - ud
>> til højre med data, de kommer ikke fra formen.
>> Har kun implementeret det i kontaktformular, som sender mail, men har
>> ikke haft een spam email siden - og der er vel ikke nogen grund til at
>> samme teknik ikke skulle kunne bruges til data der lagres, og/eller
>> vises på siden.
>
> Her skal du være opmærksom på, at cookien bliver sendt sammen med HTML'et
> ved en GET af formularen.
>
> Hvis bot'en sende cookien med tilbage, vil PHP (eller ASP) tro data kommer
> fra formen.
>
> Det var derfor jeg lavede det der fif med at lægge en cookie via .gif/png
> eller lign.
>
> Det kræver at bot'en parser HTML'et og finder <img> tags osv, hvilket jeg
> ikke tror er nært forestående.
>
> Nu skriver jeg bare .gif/.png, men det kan lige så godt være en ekstern CSS
> fil eller JS fil, som man alligevel har på siden.

$_SESSION[] ligger på serveren.
Set eneste der ligger cookien, er session id'et.

I index cleares værdien
$_SESSION[ 'kontakt'] = '';
index.php includer form.php, og form.php sætter også værdien
$_SESSION[ 'kontakt'] = 'OK';
formen sender data til send.php, hvor værdien checkes
if ( $_SESSION[ 'form'] == 'OK') {
$_SESSION[ 'kontakt'] = ''; // clearer værdi, så der kun kan sendes
een gang efter besøg af formen
// behandling af form data
}
else {
echo 'No spam. Thank you. Bye';
}

Så selvom cookien kommer med, og den har samme session id som
tidligere, vil værdien af $_SESSION[ 'kontakt'] være forkert.
Jeg har så faktisk også et hidden field med name="email", der skal være
tomt også.

Og om det nu er det ene, eller det andet, eller en kombination, der
fanger affaldet, er vel i bund og grund ligegyldigt.
Hovedsagen er, at vi ikke skal fjerne alle reklamerne, fra hverken
inbox eller siden... ;>)

Jeg kan godt se, at ovenstående kan omgås, hvis en harvester gemmer
session id til bot'en. Det skal så bruges indenfor tidsbegrænsningen -
30 minutter tror jeg.
Kunne man forestille sig en kombination, med check på IP adresse også?
Vil harvester og bot kunne bruge samme IP?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> $_SESSION[] ligger på serveren.

Ja.

> Set eneste der ligger cookien, er session id'et.

Også ja.

> Så selvom cookien kommer med, og den har samme session id som
> tidligere, vil værdien af $_SESSION[ 'kontakt'] være forkert.

Værdien af din $_SESSION kendes _kun_ af serveren.
Men som nævnt andetsteds, så kunne jeg godt fristes til at lave en 'bot
emulator', hvor disse problemstillinger kunne synliggøres.

I bund og grund er jeg ikke ret meget interesseret i at lave sådan en, men
hvis det kan kaste lys over 'problemstillingen', så vil jeg godt bruge et
par timer på det - det kan måske genbruges i senere diskussioner.

> Jeg har så faktisk også et hidden field med name="email", der skal være
> tomt også.

Ja, email ser ud til at virke - p.t.
Så må du selv vurdere om det er en 'ever lasting' løsning, eller om bot'erne
fremover laver 2 requests - en med email udfyldt, og en uden - eller.
bot-snotaberne- er jo ikke dummere end andre, og hvis metoden med at bruge
'email' bliver for meget udbredet, så undgår 'de' også den metode.

> Og om det nu er det ene, eller det andet, eller en kombination, der
> fanger affaldet, er vel i bund og grund ligegyldigt.

Fuldstændig enig, men da de ikke er dumme, så handler det nok om at (forsøge
at) være et skridt foran.

> Jeg kan godt se, at ovenstående kan omgås, hvis en harvester gemmer
> session id til bot'en. Det skal så bruges indenfor tidsbegrænsningen -
> 30 minutter tror jeg.

Bot'er kan sagtens lave forespørgsler (GET's) og efterfølgende posteringer
(POST's) inden for de 30 minutter, faktisk inden for sekunder.

Jeg har ikke fulgt bot'erne så nøje som Rune, men jeg har bemærket et par
ting:
- Time delay: Nogle bot'er har tilsyneladende indbygget et time delay, som
beviker, at der går ~ 20 sek. fra GET til POST.
- Quality assurance: Nogle bot'er laver en GET, og (selvfølgelig også) en
POST, for derefter at lave en fornyet GET, formentlig for at sikre at den
førangivne POST var succesfuld.

(Jeg har set rygter om, at bot-koderne nærmest yder garanti fort success.)

> Kunne man forestille sig en kombination, med check på IP adresse også?
> Vil harvester og bot kunne bruge samme IP?

Jeg tror vi er ovre i en anden boldgade her (mht IP osv).

På en eller anden mystisk måde var Runes side særdeles attraktiv for alle
mulige bot'er.

Der skete det (mystiske - da det er en .ASP side), at der var _mange_ forsøg
fra 'namogofer', med en URI, der angiveligt skulle køre en Remote Code
Execution, hvor indholdet kun var:

echo md5("just_a_test")

Selv om det var et 'PHP' attack, så lagde vi en 'fiskesnøre' ud med positiv
response, for at se hvad der skete efterfølgende.

Efter den positive response, gik der ikke ret lang tid før det væltede ind
med 'Phase II' attacks fra _mange_ forskellige IP'er.

Det er vist lidt ude af en tangent her, men jo -
Bot'erne _snakker_ sammen.

--
Med venlig hilsen
Stig Johansen

---

Birger Sørensen wrote:

> Jeg sætter en $_SESSION[] variabel på siden med formen, og checker den
> i det script, der modtager data. Er den ikke sat til det rigtige - ud
> til højre med data, de kommer ikke fra formen.

Inspireret af dit indlæg, og andres, her jeg overvejet at udvide mit
'toolset' med forskellige ting.

Måske vil jeg lave en 'bot simulator', men indtil videre har jeg udvidet det
med at vise headers for en given request.

Indtil videre har jeg blot udvidet det med at vise headers hvis man
forespørger på 'As Plain text':
<http://w-o-p-r.dk/wopr.tools/probes/wopr.probes.asp>

Jeg har i forvejen udvidet det med en user agent, da jeg erfarede, at
ASP.NET sender forskellig HML afhængig af hvilken useragent, der er brugt.

I forhold til Rune's input, overjer jeg lidt at udvide den med eks.
Accept-encoding/language eller lign.

Nu må vi se om det bliver til noget, men en 'bot simulator' kunne måske være
interessant.

--
Med venlig hilsen
Stig Johansen

---

Rune Jensen wrote:

> Det er den eneste metode, jeg mangler at afprøve, men når man kender
> botternes normale fremgangsmåde, kan man allerede sige, den metode må
> være yderst effektiv. Alene cookies, gør det svært for botten, men jeg
> tvivler også på, der er mange botter, som henter andet end den rå HTML.

Ja, men vær opmærksom på at en cookie bliver sendt med i headerne ved GET af
den rå HTML, så en cookie på 'hovedsiden' vil ikke hjælpe ret meget.

--
Med venlig hilsen
Stig Johansen

---

On Thu, 24 Sep 2009 14:58:21 +0200, "nospamtoMike [8000 C]"
<nospam@kern.dk> wrote:

> value="tilmelding@xxxxxxx.yy">

I en extern js fil:
x1" = 'tilmelding';
x2 = '@xxxxxxxx.yy';   
spam = x1 + x2;   

eller i <HEAD>:

<script type="text/javascript">
I en extern js fil:
x1" = 'tilmelding';
x2 = '@xxxxxxxx.yy';   
spam = x1 + x2;   
</script>


<script type="text/javascript">
document.write('<input type="hidden" name="recipient" value="'+ spam
+'">');</script>

spam kan være noget andet fx: blabla

---

>> value="tilmelding@xxxxxxx.yy">
>
> I en extern js fil:
> x1" = 'tilmelding';
> x2 = '@xxxxxxxx.yy';
> spam = x1 + x2;
>
> eller i <HEAD>:
>
> <script type="text/javascript">
> I en extern js fil:
> x1" = 'tilmelding';
> x2 = '@xxxxxxxx.yy';
> spam = x1 + x2;
> </script>
>
>
> <script type="text/javascript">
> document.write('<input type="hidden" name="recipient" value="'+ spam
> +'">');</script>
>
> spam kan være noget andet fx: blabla

Tak, men jeg er ikke helt med. Hvordan ekstern js fil?

- Mikael

---

nospamtoMike [8000 C] wrote in dk.edb.internet.webdesign.html:
> >> value="tilmelding@xxxxxxx.yy">
> >
>
> Tak, men jeg er ikke helt med. Hvordan ekstern js fil?
>
> - Mikael
>

Hej Mikael

Jeg fik engang hjælp her igennem.
Og man laver en fil der hedder kontakt.html der i står alt hvad man ser
på siden. Men man laver også en PHP fil som hedder kontaktformular.php.
Men at skrive hele koden her vil være at frose med pladsen.

Mvh.

Kim

http://sandvadnyt.dk
http://oz1jux.dk

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

On Fri, 25 Sep 2009 10:45:00 +0200, "nospamtoMike [8000 C]"
<nospam@kern.dk> wrote:

> Tak, men jeg er ikke helt med. Hvordan ekstern js fil?

Du laver i notesblok en fil som du fx kalder whatever.js
med indholdet:

x1 = 'tilmelding';
x2 = '@xxxxxxxx.yy';
spam = x1 + x2;

og gemmer den i samme folder som din form,
så indsætter du i <head>
<script src="whatever.js" type="text/javascript"></script>

---

> Du laver i notesblok en fil som du fx kalder whatever.js
> med indholdet:
>
> x1 = 'tilmelding';
> x2 = '...@xxxxxxxx.yy';
> spam = x1 + x2;
>
> og gemmer den i samme folder som din form,
> så indsætter du i <head>
> <script src="whatever.js" type="text/javascript"></script>

OK, så er jeg med så langt.

linien:
document.write('<input type="hidden" name="recipient" value="'+ spam
+'">');</script>
er jeg ikke hlt sikker på heller?

- Mikael

---

M [8000] kom med følgende:
>> Du laver i notesblok en fil som du fx kalder whatever.js
>> med indholdet:
>>
>> x1 = 'tilmelding';
>> x2 = '...@xxxxxxxx.yy';
>> spam = x1 + x2;
>>
>> og gemmer den i samme folder som din form,
>> så indsætter du i <head>
>> <script src="whatever.js" type="text/javascript"></script>
>
> OK, så er jeg med så langt.
>
> linien:
> document.write('<input type="hidden" name="recipient" value="'+ spam
> +'">');</script>
> er jeg ikke hlt sikker på heller?
>
> - Mikael

Den skriver linien
<input type="hidden" name="recipient" value="tilmelding@xxxxxxxx.yy">
til dokumentet.
Så en bot der læser dit dokument efter udførelse af js, vil have din
email adresse i klar tekst alligevel.
Det kan også gøres manuelt, med f.eks. FF og HTML-validator plugin.

Man kan ikke skjule indhold ved hjælp af js, af den simple årsag, at
det hele foregår hos clienten - skal det kunne bruges, skal det også
kunne læses.
Den eneste måde at skjule sin email adresse på, er kun at have den på
serveren, og lade det script der behandler data fra formen (og sender
email), indsætte de nødvendige oplysninger.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Ja, hvis den forstår JavaScript. Til dato er det dog ikke mange hvis
overhovedet nogen bot'er som gør det. Selvfølgelig vil det blot være
et spørgsmål om tid hvis Javascript tricket bliver så udbredt at det
bliver besværet værd for bagmændende at programmere en fortolker til
deres bot. Men for tiden i det mindste virker det.

Regards Jens Peter Karlsen.

On Fri, 25 Sep 2009 13:49:30 +0200, Birger Sørensen
<sdc@bbsorensen.com> wrote:

>Den skriver linien
><input type="hidden" name="recipient" value="tilmelding@xxxxxxxx.yy">
>til dokumentet.
>Så en bot der læser dit dokument efter udførelse af js, vil have din
>email adresse i klar tekst alligevel.

---

> Man kan ikke skjule indhold ved hjælp af js, af den simple årsag, at
> det hele foregår hos clienten - skal det kunne bruges, skal det også
> kunne læses.

Så det er alt sammen skønne spildte kræfter?

> Den eneste måde at skjule sin email adresse på, er kun at have den på
> serveren, og lade det script der behandler data fra formen (og sender
> email), indsætte de nødvendige oplysninger.

Altså php. Det har jeg ikke mod på lige pt. Og et ret stort arbejde at
lave en site om fra html, tror jeg.

- Mikael

---

On Fri, 25 Sep 2009 04:55:17 -0700 (PDT), "M [8000]" <nospam@kern.dk>
wrote:

> > Man kan ikke skjule indhold ved hjælp af js, af den simple årsag, at
> > det hele foregår hos clienten - skal det kunne bruges, skal det også
> > kunne læses.
>
> Så det er alt sammen skønne spildte kræfter?
>
> > Den eneste måde at skjule sin email adresse på, er kun at have den på
> > serveren, og lade det script der behandler data fra formen (og sender
> > email), indsætte de nødvendige oplysninger.
>
> Altså php. Det har jeg ikke mod på lige pt. Og et ret stort arbejde at
> lave en site om fra html, tror jeg.

Jeg har flere end 20 formmails, og har i 12 år ikke fået en eneste
spam derfra.

---

M [8000] skrev den 25-09-2009:
>> Man kan ikke skjule indhold ved hjælp af js, af den simple årsag, at
>> det hele foregår hos clienten - skal det kunne bruges, skal det også
>> kunne læses.
>
> Så det er alt sammen skønne spildte kræfter?
>
>> Den eneste måde at skjule sin email adresse på, er kun at have den på
>> serveren, og lade det script der behandler data fra formen (og sender
>> email), indsætte de nødvendige oplysninger.
>
> Altså php. Det har jeg ikke mod på lige pt. Og et ret stort arbejde at
> lave en site om fra html, tror jeg.
>
> - Mikael

Du behøver ikke lave sitet om.
Det handler kun om det script der modtager data fra din form, og sender
dem videre som email.
Det er ikke så galt, hvis man kan bare lidt php. Men kan godt se det
kan være det, hvis man skal starte fra bunden...
Der må da kunne findes noget?
Problemet med formmail, er vel egentlig, at det bliver installeret som
et tilbud fra hosten, som så skal kunne fungere for alle, og dermed
ikke kan anvendes til at skjule email adressen.
Du skal have din egen kopi på serveren.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk