Kérdés:
Miért kell a Google Recaptcha válasz hosztnevének érvényesítésével bajlódnia?
AJB
2017-01-25 02:12:32 UTC
view on stackexchange narkive permalink

A Google Recaptcha hostname ellenőrzése "be van sütve". Amikor egy felhasználó elküldi a Recpatcha választ, a tartomány, amelyről a választ kapta, érvényesül a tartományok engedélyezőlistáján, amelyet a Recaptcha telepítésekor adott meg.

Ha azonban a Recaptchát több domainnel használja, akkor lehetősége van letiltani a Google alapértelmezett hosztnév érvényesítését és saját maga kezelni ( https://developers.google.com/recaptcha/docs/domain_validation).

A Google ezt kiemelt figyelmeztetéssel kíséri, miszerint a hostname érvénytelenítése bármely adott válasz esetén biztonsági rést jelent. De ha figyelembe vesszük, hogy milyen könnyű hamisítani a hostname -ot, nem látom, hogy ez a valaha milyen fokú biztonságot nyújtott volna.

Egyszerű teszt számomra bebizonyította, mennyire könnyű elcsalni azt a hostname értéket, amelyet a Google használ a Recaptcha válasz eredetének ellenőrzéséhez:

  $ sudo nano / etc / hosts127. 0.0.1 spoofedhostname.com  

És amikor egy teszt Recaptcha választ küldtem, az eredmény a következő volt:

  {"siker": true, "challenge_ts": "2016-12-24T14: 15: 22Z", "hosztnév": "spoofedhostname.com"}  

Miért bántja tehát egyáltalán a hosztnév érvényesítését ?

  1. A gazdagépnév ellenőrzése nagyrészt haszontalan, tekintve, hogy mennyire könnyű hamisítani.
  2. Úgy tűnik, hogy ennek köze van ahhoz, hogy megakadályozzuk a támadókat abban, hogy ellopják a nyilvános Recaptcha kulcsot, majd generáljanak egy csomó érvényes Recaptcha választ, amelyeket tárolhatnak, majd felhasználhatnak az érzékeny végpontok elleni támadás automatizálásához ( / login , / reset-password ). Elméletileg ezt fel lehetne használni valamiféle durva erő támadásban, de ennek valójában nincs értelme, tekintve, hogy a válaszjelzők 1 perc után lejárnak. És akkor is manuálisan kell megoldania az összes Recaptchát, amit egyszerűen megtehet a tényleges tartományban. És megint: könnyen megcsalhatják a domainjét, még akkor is, ha hosztnév ellenőrzést végez.

Ez egyszerűen nem teszi lehetővé van értelme számomra, de ha egy Google-termékről van szó, akkor azt kell gondolnom, hogy a biztonsági mérnökeik tudnak valamit, amit én nem.

Mi hiányzik?

van nyilvános kulcs?A Google azt mondta, hogy ez egy megosztott kulcs a domain és a recaptcha között.
Azt állítom, hogy egy másik ellenőrzése, amelyet korán építettek be, talán egy megosztott könyvtárból, és az eltávolításának újrafeldolgozása felesleges (mi a kockázata vagy kára, ha elhagyja?).Lehetséges arra is, hogy letiltsa a reCaptcha folyamatot egy másik ponton, nem annyira biztonsági ellenőrzésre, mint például gyorsítótár-vezérlésre.
Az @purefan google komoly biztonsági résként említi, ha nem érvényesíti a gazdagép nevét.Nem vagyok 100% -ig biztos abban, hogy mégis miért van ez.Van néhány elméletem, de semmi sem hangzik különösebben
Három válaszokat:
André Borie
2017-02-14 09:55:11 UTC
view on stackexchange narkive permalink

Lehet, hogy köze van ahhoz, hogy az emberek beágyazzák az Ön captcháit egy általuk létrehozott webhelyre, és a megoldott captchákat felhasználják a webhely spamjéhez.

Például beállíthatja egy webhelyet, és adjon valamit ingyen (kalózfilmek / szoftverek, pornó stb.), de kérje a captchát. Belsőleg ez valójában a captcha, és minden megoldott captcha átkerül egy spam robotnak, amely az Ön webhelyét célozza. Ez a támadók számára költséghatékony hozzáférést biztosít az emberi captcha megoldásokhoz, a hagyományos captcha farmokhoz képest.

A hosztnév ellenőrzése megakadályozná a captcha JS-jének egy illetéktelen webhelyre történő betöltését.

Frissítés: Nemrégiben megvalósítottam egy demót, amellyel ezt megkerültem azzal, hogy a captchát az eredeti webhelyen fej nélküli böngészőben rendereltem, majd a Websocket varázslatával streameltem a "csali" webhelyemen (ebben az esetben egy egyszerű URL-rövidítő, amely a captchát kéri korábban átirányítás a célhelyre). Ehhez jelentős mennyiségű RAM-ra volt szükség (mindegyik Firefox-példány kb. 500 MB volt), összehasonlítva azzal az egyenértékűséggel, hogy a captcha-t közvetlenül a csali oldalon renderelték, így ez a gazdagépnév-ellenőrzési szolgáltatás mindenképpen komoly fájdalmat okoz a spamelők számára.

Ez egy érdekes ötlet ...
Ászok.Köszönet mindenkinek a nevében, hogy üldözte ezt @André Borie-t.Lenyűgöző, hova vezet.
V2-ről vagy v1-ről beszél?Mivel a v2 kéréseket küld a Google-nak, amikor rákattint a jelölőnégyzetre, és amikor képeket választ a rejtvényben, majd a Kész gombra kattint.Ezeket a kéréseket a Javascript nyújtja be, így a csali webhelyen hajtják végre, így még akkor is, ha sikerül megjeleníteni a captchát a csali webhelyen, a JavaScript láthatja a csali gazdagépnevét, és ellenőrizheti, hogy nincs-e az ilyen webhely engedélyezett domainjeinek listájában.kulcs.
WorWin
2017-02-10 03:25:39 UTC
view on stackexchange narkive permalink

Két kulcs van. A webhelykulcs és a titkos kulcs. Mindkettőt megkapja a webadminisztrátor a reCAPTCHA beállításakor.

Az ügyféloldali integrációhoz megadják az api.js-t, a kódrészletet és a webhelykulcsot, amelyet be kell illeszteni a webhelyre.

"Amikor a felhasználók beküldik az űrlapot, ahová integráltátok a reCAPTCHA-t, akkor a hasznos teher részeként kapunk egy" g-recaptcha-response "nevű karakterláncot. Annak ellenőrzése érdekében, hogy a Google ellenőrizte-e ezt felhasználó, küldjön egy GET kérést a következő paraméterekkel: "<- tehát ha meghamisítom az url-t, akkor a szervere soha nem kapja meg a g-recaptcha-választ. A titkot soha nem küldjük el, a 'g-recaptcha-response' értékét soha nem küldjük el, és a távoli ip-t sem küldjük el.

Hiányzik, hogy a hacker hogyan szerzi be a titkos kulcsot a webszerverről. Ezt csak közvetlenül a google-nak küldik el.

------ További magyarázat a látottakra.

A Webhelykulcs könnyen látható a webhelye HTML kódjában. A szerveren tárolt titkos kulcs azonban nem érhető el vagy hamisítható. Nem tudom, hogyan jutna hozzá a hacker a titkos kulcshoz, hogy a kétirányú hitelesítést a google segítségével teljesítse.

Azt hiszem, ez az, ami hiányzik neked. (kétirányú hitelesítés)

Refrenciák: https://www.youtube.com/watch?v=Fvt1S0nBmwQ (videó a google reCAPTCHA beállításáról.

https://developers.google.com/recaptcha/docs/verify

Továbbá: a Google reCAPTCHA kihasználja, vannak nagyon érdekes bizonytalanságok, amelyekben valaki más reCAPTCHA-ját ágyazza be a webhely automatikusan hitelesít, amikor az oldal bármely pontjára kattintanak.

(A hírnév alacsony, ha több mint 2 linket tesz közzé)

Worwin, senkinek nem kell hozzáférnie a titkos kulcshoz.Ez arról szól, hogy szándékosan letiltja az Ön által létrehozott Recaptcha `siteKey` érvényesítését (a Google Recaptcha kezelői konzolon keresztül) annak érdekében, hogy ugyanazt a` siteKey`-t tetszőleges számú webhelyhez használja.A használati eset akkor áll fenn, amikor egy hosztolt CMSaaS-ot épít, és a Recaptcha-validációt az API-rétegen keresztül kezeli a rendszer „n” domainjeihez.
Nem vagyok teljesen biztos abban, hogy ez miért kap szavazatokat, nem válaszol a feltett kérdésre.
Tron
2018-08-24 15:48:36 UTC
view on stackexchange narkive permalink

A hosztnév érvényesítését bot-ellenes intézkedésként használják. Ha a CAPTCHA betakarítót a localhoston futtatja azon az URL-címen keresztül, amelyen be kell szedni a CAPTCHA-t, akkor már nem küldhet közvetlenül kéréseket a webhelyre a számítógépéről, mivel azok át lesznek irányítva a localhost-ra. Vannak azonban dolgok, amelyekkel megkerülheti ezt.



Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...