Project

General

Profile

Enhancement #3696

Spambeskyttelse af kontaktformularen

Added by René Krøll over 1 year ago. Updated 10 months ago.

Status:
Resolved (tag version)
Priority:
High
Assignee:
Estimated time:
URL med eksempel:
Kategorier:
Administration - Systemkonfiguration

Description

Vi er begyndt at få flere spammails (primært russiske) via kontaktformularen og egne webforms.

Så ville det være en idé at få Googles reCAPTCHA (https://www.drupal.org/project/google_recaptcha) ind og gerne med den ændring så man kan sætte den ind på egne webforms?

Det er en spambeskyttelse som de fleste brugere efterhånden er vant til rundt omkring på nettet.

honeypot_opsætning.PNG (17.4 KB) honeypot_opsætning.PNG Carsten Vilhelmsen, 07/31/2018 02:26 PM

History

#1 Updated by Morten Bøgvad Nielsen over 1 year ago


Vi oplever samme problem med spam/fishing via kontaktformularen. Muligheden for at indsætte en CAPTCHA ville være ideelt.

 

#2 Updated by Carsten Vilhelmsen over 1 year ago

Webmasterbiblioteker har adgang til et CAPTCHA-modul, som i princippet skulle kunne implementeres på de enkelte webforms (form_id) via /admin/config/people/captcha. Pt. fungerer det desværre ikke efter hensigten, men det kunne være en mulighed. Noget skal ihvertfald gøres Honeypot har ingen effekt og vi oversvømmes dagligt af spam. 

#3 Updated by Rolf Madsen over 1 year ago

  • Status changed from New to Need more info
  • Assignee set to René Krøll
  • Target version set to DDB CMS - Analyse og prioritering udestår

Hvor omfattende er problemet?

Problemstillingen og en række løsningsforslag er tidligere blevet diskuteret i https://platform.dandigbib.org/issues/654.

#4 Updated by Simon Holt over 1 year ago

Honeypot modulet er inkluderet i DDB CMS i https://platform.dandigbib.org/issues/654 og er som standard konfigureret til at blive brugt på kontaktformen.

Honeypot er ikke et CAPTCHA modul, men bruger en teknik til anti-spam beskyttelse, der ikke forstyrrer brugerne. 

Jeg har testet på https://bib.ballerup.dk/contact at honeypot virker på kontaktformen (hvis man bruger chrome dev-tools kan man bl.a. se et skjult "honeypot_time" felt).

Men Honeypot er ikke sat op til at virke på webforms, men der er en indstilling til dette. Jeg kan hurtigt lave et PR, der anvender denne indstilling.

Men vil gerne lige høre hvor stort problemet er på https://bib.ballerup.dk? Modtager I meget spam fra kontaktformularen eller er det meste fra webforms? Hvis I modtager meget spam fra kontaktformularen, der som sagt allerede er honeypot enablet, kan det godt ske at vi skal kigge på yderligere beskyttelse via CAPTCHA.

#5 Updated by Rolf Madsen over 1 year ago

  • Subject changed from Spambeskyttelse med Google reCAPTCHA to Spambeskyttelse med aktivering af Honeypot for alle webformularer
  • Status changed from Need more info to Ready for development
  • Assignee changed from René Krøll to Simon Holt
  • Target version changed from DDB CMS - Analyse og prioritering udestår to Release 30 - BPI, Kampagneplus og Sektioner (7.x-4.6.0)

#6 Updated by Carsten Vilhelmsen over 1 year ago

# Simon: I Tårnby bruger vi både webform og formularer, som er tilknyttet indholdstypen nyheder. Betyder det så, at hvis jeg går ind på admin/config/content/honeypot og enabler Webforms (all) og Nyhed node form, så vil mine formularer være beskyttes via Honeypot?

#7 Updated by Simon Holt over 1 year ago

@Carsten Ja. Indstillingen "Webforms (all)" burde dog være nok. Den anden "Nyhed node form" er når du redigerer en nyhed, hvilket ikke burde være nødvendigt, da den er adgangsbeskyttet.

#8 Updated by Simon Holt over 1 year ago

@Mortan @Rene Kan I svare på følgende (før jeg går videre med løsning):

1. Hvor omfattende er problemet?

2. Er det mest fra webforms I får spam eller kommer der en tilsvarende mængde fra DDB CMS standard kontakformular (som allerede er honeypot enablet)?

Hvis I f.eks. modtager en del spam fra kontakformularen, der allerede er honeypot enablet, synes jeg vi skal prøve at kigge på at kombinere honeypot med antibot: https://www.drupal.org/project/antibot.

Det tilføjer noget ekstra spambeskyttlesen uden at forstyrre brugeren. Har observeret at antibot er MEGET effektivt på en anden side jeg administerer.

Synes vi skal prøve at undgå at introducere CAPTCHA med mindre det er absolut nødvendigt.

#9 Updated by Rolf Madsen over 1 year ago

  • Status changed from Ready for development to Need more info
  • Assignee changed from Simon Holt to René Krøll
  • Priority changed from Normal to High

#10 Updated by René Krøll over 1 year ago

For vores vedkommende er det pt. mest via kontaktformullaren, og der ligger dagligt spam.

Jeg har sat en webform op til forslag til indkøb som brugerne kan indsende, og den sender til forskellige kollegaer. Jeg har bedt dem give mig besked hvis de begynder at få spam på den.

Vi havde en webform tidligere som jeg har fjernet igen, den gav nemlig en masse spam.

#11 Updated by Simon Holt over 1 year ago

@Rene, tak for svar :) Det tyder på der er nogle problemer med Honeypot, da jeg kan se at jeres kontaktformular i hvert fald er konfigureret til at bruge honeypot.

Efter at have kigget lidt videre på det, lader det faktisk til at Varnish cacher de honeypot enablede forms. Det er ikke særlig smart, da det vil annullere den beskyttelse honeypot_time feltet giver.

Ser om jeg kan finde en løsning på det..

#12 Updated by Simon Holt over 1 year ago

PR: https://github.com/ding2/ding2/pull/1143

Som sagt, blev honeypot formen cachet i Varnish og honeypot_timefield beskyttelse burde derfor ikke virke.

Kan vi måske prøve at få patchet ovenstående PR (eftert code-review selvfølgelig) på Ballerup's hjemmeside for at se om det skulle fikse spam?

Ellers må vi have andre metoder i brug.

#13 Updated by Simon Holt over 1 year ago

  • Status changed from Need more info to Needs code review
  • Assignee changed from René Krøll to Gitte Barlach

#14 Updated by Gitte Barlach over 1 year ago

  • Assignee changed from Gitte Barlach to Kasper Garnæs

#15 Updated by Morten Bøgvad Nielsen over 1 year ago

Simon Holt skrev:

@Mortan @Rene Kan I svare på følgende (før jeg går videre med løsning):

1. Hvor omfattende er problemet?

2. Er det mest fra webforms I får spam eller kommer der en tilsvarende mængde fra DDB CMS standard kontakformular (som allerede er honeypot enablet)?

Hvis I f.eks. modtager en del spam fra kontakformularen, der allerede er honeypot enablet, synes jeg vi skal prøve at kigge på at kombinere honeypot med antibot: https://www.drupal.org/project/antibot.

Det tilføjer noget ekstra spambeskyttlesen uden at forstyrre brugeren. Har observeret at antibot er MEGET effektivt på en anden side jeg administerer.

Synes vi skal prøve at undgå at introducere CAPTCHA med mindre det er absolut nødvendigt.

 

Hej Simon

For vores vedkommende stammer al spam fra kontaktformularen, og der sker næsten dagligt.

 

#16 Updated by Jørgen Nielsen about 1 year ago

  • Status changed from Needs code review to Reviewed
  • Assignee changed from Kasper Garnæs to Gitte Barlach

reviewet og godkendt

#17 Updated by Martin Cording about 1 year ago

Simon jeg tror ikke dette er løsningen. Vi kører uden Varnish og oplever også SPAM.

#18 Updated by Simon Holt about 1 year ago

@Martin Ok, tak for det! Som jeg også skrev, kan det sagtens ske vi skal have andre metoder i brug. Så det må vi have kigget på.

Kunne bare konstatere at Varnish cachede honeypot felterne og så virker det i hvert fald ikke. Desuden er det også vigtigt at ding_varnish respekterer drupal_page_is_cacheable(), så PR var godt at få med under alle omstændigheder.

Jeg foreslå vi prøver at kombinere honeypot med antibot så: https://www.drupal.org/project/antibot. Eller måske gå helt over til antibot i stedet (kan dog ikke finde/se der skulle være noget problem med at bruge dem begge).

#19 Updated by Simon Holt about 1 year ago

@Martin: Har du en fornemmelse af om der er tale om "human spam" eller "bot spam"? Jf. denne artikel: https://www.jeffgeerling.com/blog/2018/post-mollom-what-are-best-options-preventing-spam-drupal

#20 Updated by Simon Holt about 1 year ago

@Morten @Martin Kan I komme med nogle eksempler på det Spam I modtager? Kunne være interessant at se.

Angående bot spam vs human spam, så er det efter nærmere eftertanke nok bot spam der er tale om, da det er en kontaktformular. Honeypot (og antibot) er specialiseret i at kigge efter bot spam, så mit gæt er at de bots, der spammer, har lært at omgå vores honeypot protection. Hvis honeypot kombineres med antibot, vil dette blive markant sværere, da de så også skal fake at bevæge musen som et menneske før form submission godkendes.

Jeg vil helst undgå CAPTCHA-løsninger. Jf. følgende:

https://www.gravityforms.com/rip-captcha/ 

https://gizmodo.com/google-has-finally-killed-the-captcha-1793190374

I Google's nyeste version af recaptcha har de også droppet checkboksen: https://www.google.com/recaptcha/intro/v3beta.html (ser ud som det er muligt at få det med denne, dog ikke-reviewede, patch til recaptcha module: https://www.drupal.org/project/recaptcha/issues/2852269)

Jeg er i gået dybden med hvordan antibot og honeypot virker og skal prøve at forklare det så simpelt som muligt.

Sådan virker honeypot (https://www.jeffgeerling.com/blogs/jeff-geerling/introducing-honeypot-form-spam)

Bruger to skjulte felter:

1. Et skjult felt med et "lokkende" navn som f.eks. "URL" eller "Hjemmeside". Almindelige brugere ser ikke dette felt og vil aldrig udfylde det, men bots ser det og kan blive lokket til udfylde det. Det skjules med css display: none, så det ikke er indlysende for bots, at det er et skjult felt.

2. Et skjult felt med en tidskode.

Honeypot ignorerer indsendelser hvis felt 1. er udfyldt og/eller brugeren ikke har brugt mindst et antal sekunder (udregnes fra feltet med timestamp) på at udfylde formen. I DDB CMS er dette tidsrum indstillet til 5 sekunder og navnet på "lokke-feltet" er "URL". Vi ser her, at hvis tidskoden caches, vil denne beskyttelse blive fuldstændig neutraliseret. Så det eneste en spam bot så skal gøre er at lade være med at udfylde "lokke-feltet".

Et problem med honeypot er, som jeg ser det, at den outputter en label sammen med det skjulte felt, der ikke skal udfyldes, med teksten: "Leave this field blank". Begrundelsen for at have det er, at hvis CSS ikke virker, så skal det være muligt for brugerne at se, at de ikke skal udfylde feltet, så de har mulighed for at indsende formularen. Men på samme tid giver det også et fingerpeg til bots om, at de ikke skal udfylde feltet. Se denne tråd for nærmere info: https://www.drupal.org/project/honeypot/issues/1833192. Specielt denne kommentar tyder på, at netop dette gør modulet ubrugeligt: https://www.drupal.org/project/honeypot/issues/1833192#comment-12553757

Sådan virker antibot (https://www.drupal.org/project/antibot)

Antibot enabled forms vises som udgangspunkt "låst", så de ikke kan submittes. Først når brugeren bevæger musen, swiper eller trykker tab/enter låses formularen op og kan indsendes. For at beskytte mod remote post, der ikke tager udgangspunkt i den låste form, genereres et felt med et key, når formularen låses op, der også skal valideres på serveren.

Da alt dette håndteres i Javascript, kræver det at brugeren har Javascript aktiveret. Jeg har kigget på statistikken for det i Webtrekk for vejlebib. For de sidse seks kalendermåneder:

235.905 besøg i alt / 354 besøg med javascript deaktiveret = 0,15 % af besøg havde javascript deaktiveret. Jeg vil sige det er så lavt, at det er et non-issue. Desuden vises også en informerende tekst til brugeren om, at de skal aktivere Javascript for at bruge formen, hvis vi skulle være så uheldige, at de lige en af de meget få brugere med Javascript deaktiveret, der har behov for at udfylde kontaktformularen.

 

#21 Updated by Martin Cording about 1 year ago

Eksempel 1:

Fra: rburke22@msn.com rburke22@msn.com 
Sendt: 18. oktober 2018 12:27
Til: Bibliotek Voksenbiblioteket <bibvok@guldborgsund.dk>
Emne: [Fornyelse af materialer] Dating Hot Girls in your city

Jeffreyneuby (rburke22@msn.com) sendte en besked via kontaktformularen på https://guldbib.dk/contact.

Find yourself a girl for an evening for sex in your city:
http://sl.3agel.net/hotgirls90356

Eksempel 2:

----Oprindelig meddelelse----
Fra: katewzx@gmail.com katewzx@gmail.com
Sendt: 26. oktober 2018 00:25
Til: Guldborgsund-bibliotekerne <nyfac@guldborgsund.dk>
Emne: [Ingen af overstående] подробности…

kolyasSlect (katewzx@gmail.com) sendte en besked via kontaktformularen på https://guldbib.dk/contact.

Здравствуйте! только для Вас самая
интересная информация о
[url=http://mamaimalysh.com.ua/category/detskie_kolyaski]коляски
купить интернет магазин[/url] Этот чехол надежная защита вашей коляски от дождя и снега.Если хотите купить коляску классическую, купить коляску новую
(Украина) , обратите внимание на
соответствующий ассортимент нашего
магазина!Такая коляска обычно содержит
люльку для Вашего малыша до возраста 6-7 месяцев, а также прогулочный вариант, который используют для ребеночка до 3-х лет.

 

#22 Updated by Simon Holt about 1 year ago

Tak for det Martin.

Det tyder jo på at disse bots har lært at de ikke skal udfylde URL-feltet og vente mindst 5 sekunder efter page load med at submitte.

På baggrund af dette og problematikken beskrevet i https://www.drupal.org/project/honeypot/issues/1833192, synes jeg vi skal droppe honeypot og prøve antibot i stedet.

#23 Updated by Kasper Garnæs about 1 year ago

PR'et https://github.com/ding2/ding2/pull/1143 er merged.

Tråden her er blevet lang og jeg er usikker på om den implementerede ændring i PR'et reelt set hænger sammen med overskriften længere.

 

#24 Updated by Kasper Garnæs about 1 year ago

  • Status changed from Reviewed to Technical test

#25 Updated by Gitte Barlach about 1 year ago

  • Subject changed from Spambeskyttelse med aktivering af Honeypot for alle webformularer to Spambeskyttelse med aktivering af Honeypot for alle webformularer (HVORDAN TESTES DENNE?)

#26 Updated by Anonymous 12 months ago

René Krøll skrev:

Vi er begyndt at få flere spammails (primært russiske) via kontaktformularen og egne webforms.

Så ville det være en idé at få Googles reCAPTCHA (https://www.drupal.org/project/google_recaptcha) ind og gerne med den ændring så man kan sætte den ind på egne webforms?

Det er en spambeskyttelse som de fleste brugere efterhånden er vant til rundt omkring på nettet.

 

Vi er redaktørbibliotek - og modtager en del spam via kontaktformular (dagligt) - hvor endte denne sag, dvs. udvikles der på den - eller er der noget, vi allerede kan gøre?

#27 Updated by Rolf Madsen 12 months ago

@Mette, som du kan se er status Technical test.

Det betyder at vi nu får udrullet ændringen på en hjemmeside hvor vi kan teste det der er udviklet.

#28 Updated by Gitte Barlach 11 months ago

  • Subject changed from Spambeskyttelse med aktivering af Honeypot for alle webformularer (HVORDAN TESTES DENNE?) to Spambeskyttelse af kontaktformularen med antibot

Jeg har ændret titlen på sagen jvf. Kaspers bemærkning, så der er en bedre sammenhæng mellem PR og titel.

 

#29 Updated by Gitte Barlach 11 months ago

  • Subject changed from Spambeskyttelse af kontaktformularen med antibot to Spambeskyttelse af kontaktformularen
  • Status changed from Technical test to Reviewed - Needs info/rework
  • Assignee changed from Gitte Barlach to Simon Holt

nå der rettede jeg titlen i dette issue for tidligt! af PR´et fremgår:

"honeypot was trying to mark page as non-cacheable, but because of the logic in ding_varnish module this wasn't respected. I have testet with Varnish that the contact-form isn't cached anymore with the changes in this PR."

PÅ den anden side lyder seneste konklusion i kommentar 22 fra Simon således: "På baggrund af dette og problematikken beskrevet i https://www.drupal.org/project/honeypot/issues/1833192, synes jeg vi skal droppe honeypot og prøve antibot i stedet."

Jeg kan ikke se noget til antibot modulet noget steds i den version af DDB CMS jeg tester, nemlig 4.6.0-rc3. 

Jeg kunne rigtigt godt tænke mig en entydig konklusion her i kommentarsporet på sagen ift. om vi er i mål med løsningen, samt hvordan den skal testes?

#30 Updated by Simon Holt 11 months ago

@Gitte beklager den manglende opdatering af denne sag.

Med hensyn til det med Varnish, så er det rigtig nok, at en af de primære metoder til beskyttelse, bliver fuldstændig neutraliseret, hvis Varnish cacher tidskode-feltet fra Honeypot. Men mange sider caches tilsyneladende ikke i Varnish for webmaster og redaktør biblioteker, så PR fra #note-12 har kun effekt for programmørbiblioteker, der cacher sider for anonyme brugere i Varnish. 

Og da man kan se på de spam-eksempler Martin kommer med, at de har lært at omgå Honeypot, var mit forslag at prøve antibot. I #note-20 prøver jeg at give en forklaring og fordele/ulemper på honeypot vs. antibot. Der var egentlig nogle ret vigtige informationer. Som f.eks.:

"Da alt dette håndteres i Javascript, kræver det at brugeren har Javascript aktiveret. Jeg har kigget på statistikken for det i Webtrekk for vejlebib. For de sidse seks kalendermåneder:

235.905 besøg i alt / 354 besøg med javascript deaktiveret = 0,15 % af besøg havde javascript deaktiveret. Jeg vil sige det er så lavt, at det er et non-issue. Desuden vises også en informerende tekst til brugeren om, at de skal aktivere Javascript for at bruge formen, hvis vi skulle være så uheldige, at de lige en af de meget få brugere med Javascript deaktiveret, der har behov for at udfylde kontaktformularen."

Så hvis vi går over til antibot, kræver det altså, at brugeren har Javascript aktiveret, før de kan bruge formularerne (de bliver præsenteret for en besked om at aktivere Javascript, hvis de ikke kan bruge formularen).

Så går ud fra I er med på den, så jeg laver et PR, hvor vi går over til antibot? :)

#31 Updated by Simon Holt 11 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Simon Holt to Gitte Barlach

PR der bl.a. tilføjer antibot spam protection til kontaktformularen og webforms: https://github.com/ding2/ding2/pull/1310

#32 Updated by Anonymous 11 months ago

Jeg har mistet overblikket i denne sag om spamfilter, dvs. hvornår bør der være et bedre filter klar?

Min kollega har netop sendt mig denne besked:

I går fik jeg en mærkelig mail ad den vej og her til morgen lå der 215 mærkelige mails til mig fra book en bibliotekar.

Mailen ser sådan ud og jeg vil gerne have, at I stopper det, så jeg ikke kommer tilbage fra juleferie til 1000000 mails!

Submitted on Fredag, 21. december, 2018 00:08 Submitted by anonymous user: 42.49.180.17 Submitted values are:

 

Navn: 1

E-mail / telefonnummer: sample@email.tst

Beskrivelse: JyI=

 

 

The results of this submission may be viewed at:

https://fkb.dk/node/344/submission/706

 

Vi får meget spam i vores kontaktformularer på hjemmesiden, så vi glæder os til en løsning.

#33 Updated by Simon Holt 11 months ago

I kommentar ovenfor har jeg lavet nyt PR, hvov vi afprøver en ny metode til spambeskyttelse.

Men jeg vil gerne lige understrege, at det her med spam-beskyttelse og hvad der er effektivt, har ændret sig meget de seneste par år. Pga bl.a. fremskridt indenfor maskinlæring, er det blevet særdeles vanskeligt at holde spam-bot'erne væk. Så kan ikke på nogen måde garanteret, at den nye metode vil virke i alle tilfælde. Det er nye tider inden for dette område, og vi bliver nødt til at eksperimentere lidt for at se hvad der virker. Bare lige en disclaimer :)

#34 Updated by Gitte Barlach 10 months ago

  • Assignee changed from Gitte Barlach to Jesper Kristensen

#35 Updated by Jesper Kristensen 10 months ago

  • Status changed from Needs code review to Reviewed
  • Assignee changed from Jesper Kristensen to Gitte Barlach

Reviewed og afventer release

#36 Updated by Kasper Garnæs 10 months ago

  • Status changed from Reviewed to Technical test

Merged.

#37 Updated by Gitte Barlach 10 months ago

  • Assignee changed from Gitte Barlach to Nhi A Sy

ift. test samt info. til bibliotekerne: 
Simon gør opmærksom på at "hvis vi går over til antibot, kræver det altså, at brugeren har Javascript aktiveret, før de kan bruge formularerne (de bliver præsenteret for en besked om at aktivere Javascript, hvis de ikke kan bruge formularen)."

#38 Updated by Nhi A Sy 10 months ago

  • Status changed from Technical test to Resolved (tag version)

Javascript skal være slået til for at DDB CMS er brugbart, den er lidt svært og test, håber at bilibotekerne melder ind, hvis problem ikke er løst.

Also available in: Atom PDF