It-kriminelle: Tjen 3 øre for hver CAPTCHA
Når man i dag registrerer sig for at få en ny e-mailadresse eller skriver en kommentar på mange weblogs, så skal man ofte først tyde et billede med forvrængede bogstaver.
Disse såkaldte CAPTCHA'er er beregnet på at forhindre automatiske scripts i at misbruge tjenesterne til spam.
Gennem de seneste år er CAPTCHA teknologien blevet gjort mere og mere avanceret i forsøg på at forblive et skridt foran spammerne, som samtidig har forbedret den automatiske tekstgenkendelse.
Men de CAPTCHA'er, som spammerne endnu ikke kan tyde ved hjælp af automatisk analyse af bogstaverne, har de i stedet valgt at outsource til lyssky firmaer.
I stedet for at lade et computerprogram forsøge at tyde en CAPTCHA, sender firmaet billedet til en person, som indtaster løsningen.
Der skal imidlertid løses rigtigt mange CAPTCHA'er for at tjene en hæderlig løn foran skærmen, skriver avisen USA Today. Et af de russiske firmaer, som tilbyder CAPTCHA-løsninger, lover en gennemsnitsløn på knapt 3 øre for hvert billede, man løser.
Firmaet forventer, at personerne kan løse omkring 10 CAPTCHA'er i minuttet og således opnå en teoretisk timeløn på knapt 18 kroner i timen.
Sikkerhedsfirmaet PC Tools afprøvede firmaets tilbud for at se, hvor hurtigt personerne var i stand til at løse opgaverne. To tredjedele af ordbillederne blev løst og returneret på under et halvt minut. Resten var vanskeligere selv for mennesker at tyde, og derfor var der flere eksempler på, at personen blot indtastede en tilfældig løsning for at komme videre til den næste opgave.
Kommentarer (13)
Det er da et godt signal, hvis de bliver tvunget til at outsource CAPTCHA cracks til mennesker. Det bliver således dyrere og sværere at spamme. For det er DET det handler om ved spam: profit vs. omkostninger per tidsenhed.
Jeg tvivler også på om der er fremtid i den "løsning". Hvis tiden er en faktor, kan man jo udvikle scripts der forlænger valideringstiden, således at en timeløn bliver latterlig lav.
Man kan man også allerede i dag tvinge registreringer/kommentarer til at bruge den rigtige IP, uden brug af proxy relays. En eventuel cross-reference i processen, med en database over de lyssky firmaer, vil således aflive outsourcing.
Ultimativt, så er også meget online-spam i dag rettet mod webcrawlers som Google. Hvis der nu alligevel kommer spam på et website, kan webmaster sagtens konfigurere hvad og hvornår webcrawlers skal indexere noget. Det gør det endnu dyrere at spamme.
Problemet i dag, er de der ikke er opdateret med sikkerhed. Det er som med virus-programmer og OS-systemer... Og sådan vil det altid være, indtil der opstår problemer. Det er en evig kamp. Lige nu :-)
-
0 -
0
1 Opret en webside med porno eller andet materiale der kan forventes at vække interesse.
2 Forlang indtastning af CAPTCHA mod udlevering af materiale.
3 Benyt CAPTCHA fra mål-side.
På den måde udnyttes arbejdskraften af store mængder liderlige aber (afhængig af materialevalg forstås - det kunne også være en side med billeder af ponyer).
-
0
-
0
Denne metode er utvivlsomt allerede i brug. Noget lignende bliver sikkert også brugt til at opsamle kreditkortinformation.
-
0
-
0
CAPTCHA'er er egentlig en slags Turing test: Den skal afgøre, om der sidder et menneske eller en maskine ved tastaturet. Når spammere er nødt til at bruge mennesker, er det vel en indikation af, at det fungerer som Turing test.
Og en fungerende Turing test omgås vel nemmest ved at bruge mennesker i stedet for maskiner.
Men billig arbejdskraft er også ukvalificeret arbejdskraft. Så udbyderne burde kombinere en Turing-test-agtig test med en test, der kræver et minimum af kvalifikationer, f.eks. kendskab til engelsk. En russer eller kineser, der er villig til at arbejde for 3 øre pr. CAPTCHA, kender nok ikke tilstrækkeligt engelsk til at svare på sproglige spørgsmål, som enhver med reel interesse i en engelsksproget side ville kunne uden at blinke.
Man skal dog forhindre, at spørgsmålene besvares maskinelt. Det kan dels gøres ved at forhindre computeraflæsning af spørgsmålet (ligesom CAPTCHA'er) og dels ved at variere spørgsmålene tilstrækkeligt til, at der ikke kan bygges en database over spørgsmål og svar.
-
0
-
0
Ja, det er mig selv jeg hentyder til.
Nogle gange, efterhånden, synes jeg det er lidt svært at se hvad der egentlig skulle stå på de der billeder.
Det er ikke ualmindeligt jeg skal have et par forsøg før det lykkes mig at tyde 'skriftsproget'.
Men bortset fra det, så brug Javascript til at forhindre bot'er, kombineret med en <noscript> hvor der kan stilles mere eller mindre avancerede spørgsmål.
Hvis bot'er engang får indbygget en javascript fortolker, 'haben wir anderen metoden', som ikke går ud over brugeren.
-
0
-
0
Det er i forbindelse med problemet også værd at læse en artikel fra Slate, som min kone gjorde mig opmærksom på: http://www.slate.com/id/2216837/
Mvh.
Jesper Stein Sandal
Version2
-
0
-
0
en artikel fra Slate
Der er nogle gode ideer i artiklen, men pånær den naive om at have et hvid-på-hvidt inputfelt, som skal stå tomt, så er de svære at implementere. Specielt ideen om at genkende den måde, man udfylder tekst: Normalt sker det lokalt i browseren, og man ser på serveren kun det endelige resultat. Og de løser heller ikke rigtig problemet med underbetalte kinesere.
Man skal nok kombinere tekstforståelse med billedopfattelse. Vis et kompliceret billede (som f.eks. http://www.allthingsjacq.com/images/iSpy_review/chest.jpg) og sig "click on the spider and the lollipop".
-
0
-
0
hader selv det captcha ofte så svære læse opgiver.
men skal det være mere sikkert,kunne man vel sætte en timer på så captcha skal skrives inden for f.eks 20 sek hvis man ikke nåede det så sætte en pause på 20 sek før der kom en ny captcha.
og kunne tilføje et ur der tæller ned for stresse folk.
-
0
-
0
Man skal nok kombinere tekstforståelse med billedopfattelse. Vis et kompliceret billede (som f.eks. http://www.allthingsjacq.com/images...) og sig "click on the spider and the lollipop".
Nu ved jeg ikke om det er tilfældigt, det du skriver, men hvis jeg kigger på det billede du henviser til, kan jeg hverken se spider eller lollipop.
Når man kommer op i 'brillealderen', er det ikke kun størrelsen, men også kontrastforholdende man skal passe på.
Ud fra det eksemel er jeg altså en non-human.
En anden ting, som vistnok også har været diskuteret, er barrieren.
Jo sværere, eller mere besværligt, det er at 'udfylde' en captcha, jo flere lokker man vær, og decimerer muligvis værdien af blogindlæg.
Vi har duiskuteret det jævnlig i .webdesign grupperne, og en af de angrebsvinkler jeg har kigget på er bot vs. browser, og ikke bot vs. human.
En af metoderne kunne være at antage, at bot'er ikke fårstår javascript.
Via en ekstern .js fil ændrer jeg teksten, og dermed værdien af en submit knap.
Serverside tjekkes op mod den ændrede værdi i stedet for den oprindelige (fra HTML'et).
Hvis man ønsker understøttelse for browseren, der ikke forstår javascript, kan man læggen en ekstra <input> i en <noscript> sektion.
Derved påvirkes (generes) brugerne mindst muligt.
En anden metode er at sætte en cookie i en 'altenativ' fil.
Det kan være en .css, .js eller en <img> m.m.
Browsere vil hente de tilhørende ekstra filer, hvorimod bot'er formentlig ikke vil.
Ved at tjekke op mod cookien ved den efterfølgende POST, kan man afgøre hvorvidt det er bot eller browser.
Afslutningsvis skal det nævnes, at det kun er nogle brainstorming ideer ud fra analyse af bot-adfærd i begrænset omfang.
De er ikke afprøvet på et 'bot-centric' site.
Hvis man tænker i de baner, skal de forskellige værdier ikke være statiske, da man derved kan aflure dem en gang for alle.
-
0
-
0
Når man kommer op i 'brillealderen', er det ikke kun størrelsen, men også kontrastforholdende man skal passe på.
Billed-CAPTCHA er en pine. Jeg kan heller ikke læse dem mere. En tekst-CAPTCHA skulle være mere tilgængelig - men på min statistik lader det til, også disse volder problemer. Desværre har jeg ikke kunnet analysere nærmere, end at en del kræver flere end ét forsøg for at poste. Det synes jeg ikke tyder godt.
Jo sværere, eller mere besværligt, det er at 'udfylde' en captcha, jo flere lokker man vær, og decimerer muligvis værdien af blogindlæg.
Jeg tror, det er på tide helt at gå helt væk fra CAPTCHAs, som involverer brugeren.
En af metoderne kunne være at antage, at bot'er ikke fårstår javascript. Via en ekstern .js fil ændrer jeg teksten, og dermed værdien af en submit knap. Serverside tjekkes op mod den ændrede værdi i stedet for den oprindelige (fra HTML'et). Hvis man ønsker understøttelse for browseren, der ikke forstår javascript, kan man læggen en ekstra <input> i en <noscript> sektion. Derved påvirkes (generes) brugerne mindst muligt.
Jeg kan godt lide den metode. Den kan kombineres med flere forskellige tests af, hvordan en browser "opfører" sig. Som vi har været inde på tidligere, at alle browsere forstår GZIP, men ikke mange (spam)botter gør (søgemaskiner forstår det også). De dummeste botter bruger samtidig JAVA+versionsnummer i useragent, eller libWWWPerl. Man må også kunne sige, at hvis user-agent er IE5, så er den mistænkelig. Samt hvis der er egentlige fejl (ja, spambotproducenterne er ret sloppy i deres kodning).
En anden metode er at sætte en cookie i en 'altenativ' fil. Det kan være en .css, .js eller en <img> m.m. Browsere vil hente de tilhørende ekstra filer, hvorimod bot'er formentlig ikke vil. Ved at tjekke op mod cookien ved den efterfølgende POST, kan man afgøre hvorvidt det er bot eller browser.
Den lyder interessant - kan du give nærmere forklaring? Skal img, eller CSS-filen lægges som en f.eks. ASP, som så er den, som henter filen?
Iøvrigt, kan man med fordel lave en whitelist. Jeg har en white-list af udelukkende danske IPer, og det virker ganske fortrintligt. White-listing vil sige, at hvis IPen er dansk, så slipper den forbi resten af spamtjeksne automatisk. Danskere er meget moralske, af en eller anden grund. Jeg har aldrig oplevet spamforsøg fra danske IPer via en bot.
Desuden, så tror jeg, at hvad man end anvender som spambeskyttelse, så skal den del holdes ude fra søgemaskinerne. Så linket til dit javascript skal fjernes fra siden, hvis det er en Googlebot, som vil indeksere. Så kan man ikke se beskyttelsen via en Googlesøgning, som nogle botter vel stadig bruger. Samme, hvis man bruger CSS-skjulte felter o. lign. ...bare en idé.
-
0
-
0
Desuden, så tror jeg, at hvad man end anvender som spambeskyttelse, så skal den del holdes ude fra søgemaskinerne. Så linket til dit javascript skal fjernes fra siden, hvis det er en Googlebot, som vil indeksere. Så kan man ikke se beskyttelsen via en Googlesøgning, som nogle botter vel stadig bruger. Samme, hvis man bruger CSS-skjulte felter o. lign. ...bare en idé.
Humm, jah... vel hele form-feltet med text-felt og input/submit kan man også holde ude. Det er cashen på søgemaskinerne, jeg tænker på. Reelt kan man bare lade være med at vise det, hvis user-agent indeholder http:// eller bot? Så slipper man også for at tænke på, om man blir indekseret af en falsk søgemaskine. Jeg har ikke oplevet en reel human user med http:// eller bot i user-agent.
-
0
-
0
Den lyder interessant - kan du give nærmere forklaring? Skal img, eller CSS-filen lægges som en f.eks. ASP, som så er den, som henter filen?
Udgangspunktet er bot'er er, og forbliver relativt simple (små) programmer.
Hvis de bliver så store og omfattende, så de har næsten fuld browserfunktionalitet, bliver de for lette at opdage for anti-programmerne.
Det er naturligvis min egen teori, og kun tiden vil vise.
Som det ser ud nu, laver bot'erne først en GET, og derefter en POST - eventuelt en efterfølgende 'kontrol' - GET.
Hvis man blot styrer det med en cookie/session variabel på HTML'et, bliver den sat ved den indledende GET, og kan derfor ikke bruges.
Browsere hentet de resterende filer, css,javascript,img osv.
Eksemplet med en <img> i ASP har jeg en demo af et eller andet sted, men det går ud på, som du også skriver, at det er en ASP fil, der leverer billedet, og sætter en session variabel.
Kort sagt så et tag af formen:
<img src="billede.gif.asp/>
ASP filen sætter så session variablen, og laver et binært dump af gif filen med tilhørende MIME type.
Det er kun lige det konceptuelle, og man bør lave varians i det, så det ikke er nemt at lave en målrettet bot.
Hvis billedet altid ligger samme sted, og hedder det samme, vil det være nemt at debugge f.eks. Google, og lave en målrettet bot.
Der er masser af muligheder for at kombinere det med javascript, lægge billedet ind via CSS (url=) osv, men det vil nok føre for vidt at diskutere her.
-
0
-
0
Jeg kan godt lide den metode. Den kan kombineres med flere forskellige tests af, hvordan en browser "opfører" sig.
Jeg kom i tanke om, at jeg faktisk har en (lavpraktisk) demo af det med 'knapperne'/javascript.
http://w-o-p-r.dk/wopr.tools/wopr.linkchecker.asp
Det med billedet har jeg ikke lige en (online) demo af, men her er lidt (ASP) kildekode til inspiration(her er der hardcoded gif):
response.ContentType = "image/gif"
Dim objStream
Dim Filename
Filename = Request.Servervariables("PATH_TRANSLATED")
Filename = left(Filename,Len(Filename)-3) + "gif"
Set objStream = Server.CreateObject("ADODB.Stream")
Const adTypeBinary = 1
objStream.Type = adTypeBinary
objStream.Open
objStream.LoadFromFile Filename
Response.BinaryWrite objStream.Read
objStream.Close
Set objStream = Nothing
Session("IP") = Request.Servervariables("REMOTE_ADDR")
%>-
0
-
0
