ProHoster > Blog > Lajmet e internetit > Qă‚ąă‚Żă‚»ă‚čo nĂ« tĂ« dhĂ«na nga repo tĂ« largĂ«ta dhe private nĂ« GitHub, qĂ« kanĂ« fork

Qă‚ąă‚Żă‚»ă‚čo nĂ« tĂ« dhĂ«na nga repo tĂ« largĂ«ta dhe private nĂ« GitHub, qĂ« kanĂ« fork

Kompania Truffle Security publikoi skenarët e sulmeve mbi disa metoda standard të punës me repositorët në GitHub, të cilat lejojnë nxjerrjen e të dhënave nga repositorët e largët, të cilët kanë forka publike ose janë krijuar si forka.

Mundësia për të aksesuar komitetet përmes hash-it në të gjitha forkat e lidhura të repositorëve është shkaktuar nga fakti që GitHub për qëllime optimizimi dhe për të eliminuar kopjet, ruan së bashku të gjitha objektet nga repositori kryesor dhe forka, duke e ndarë vetëm logjikisht përkatësinë e komiteteve. Kjo ruajtje lejon shikimin në repositorin kryesor të çdo komiteti nga çdo fork, duke treguar qartë hash-in e tij në URL. Për shembull, një përdorues mund të krijojë një fork të repositorit "\/torvalds\/linux" dhe të shtojë në të çdo kod, pas së cilës ky kod do të jetë i acessueshëm përmes një lidhjeje hash në repositorin "\/torvalds\/linux". Në rast se repoja fshihet, nëse ka të paktën një fork publik, të dhënat nga repositori i largët mbeten të aksesueshme përmes hash-it të komitetit.

Ofrohen tre skenarë që paraqesin rrezik për sigurinë:

  • Skenari i parĂ« prek situatat kur zhvilluesit krijojnĂ« forka tĂ« repositorĂ«ve publikĂ«, shtojnĂ« ndryshime nĂ« to, eksperimentojnĂ« dhe mĂ« pas i fshijnĂ«. PĂ«rveç rrjedhjes sĂ« kodit qĂ« nuk Ă«shtĂ« menduar pĂ«r publikim, rreziku paraqitet nga situata kur nĂ« eksperimente nĂ« kodin e skedarĂ«ve me shembuj shtohen çelĂ«sa tĂ« punĂ«s pĂ«r aksesin nĂ« API. NĂ« kĂ«tĂ« rast, sulmuesi mund tĂ« aksesojĂ« ndryshimin pĂ«rmes hash-it tĂ« komitetit, duke iu drejtuar pas fshirjes sĂ« forkut pĂ«rmes repositorit kryesor. PĂ«r shembull, me metodĂ«n e sugjeruar, studiuesit ishin nĂ« gjendje tĂ« identifikonin 30 çelĂ«sa tĂ« punĂ«s pĂ«r aksesin nĂ« API, duke studiuar tre repositorĂ« tĂ« lidhur me mĂ«simin e makinerive me njĂ« numĂ«r tĂ« madh forkas.
  • Skenari i dytĂ« lidhet me mundĂ«sinĂ« e aksesit nĂ« tĂ« dhĂ«na pas fshirjes sĂ« depozitĂ«s kryesore, nĂ«se pĂ«r kĂ«tĂ« depozitĂ« janĂ« krijuar fork-e. NjĂ« shembull Ă«shtĂ« rasti kur nĂ« njĂ« depo publike tĂ« njĂ« kompanie janĂ« publikuar aksidentalisht çelĂ«sat e mbyllur tĂ« njĂ«rit prej punonjĂ«sve, duke lejuar akses tĂ« plotĂ« nĂ« tĂ« gjitha depozitĂ« e kĂ«saj kompanie nĂ« GitHub. Kompania e fshiu depozitĂ«n pĂ«rmes sĂ« cilĂ«s ndodhi rrjedhja, por çelĂ«sat ende mbetĂ«n tĂ« aksesueshĂ«m pĂ«r ekstraktim pĂ«rmes kĂ«rkesave me hash-in e commit-it nĂ« depo me fork-e.
    Qă‚ąă‚Żă‚»ă‚čo nĂ« tĂ« dhĂ«na nga repo tĂ« largĂ«ta dhe private nĂ« GitHub, qĂ« kanĂ« fork
  • Skenari i tretĂ« lidhet me modelin e zhvillimit tĂ« projekteve, tĂ« cilat zhvillojnĂ« njĂ« version bazĂ« tĂ« hapur nĂ« njĂ« depo publike dhe njĂ« version tĂ« zgjeruar pronar nĂ« njĂ« depo private. NĂ«se kompania fillimisht e zhvilloi projektin nĂ« njĂ« depo private dhe mĂ« pas, pas hapjes sĂ« kodit tĂ« projektit, e transferoi atĂ« nĂ« statusin publik, por vazhdoi zhvillimin e njĂ« versioni tĂ« mbyllur tĂ« brendshĂ«m ose tĂ« zgjeruar nĂ« njĂ« fork private, ka mundĂ«si tĂ« aksesoni ndryshimet e shtuar nĂ« fork-un privat pĂ«rmes hash-ave tĂ« commit-eve nĂ« depo publike. NĂ« kĂ«tĂ« rast, aksesimi Ă«shtĂ« i mundur vetĂ«m pĂ«r ndryshimet e shtuara nĂ« fork-un privat para se depoja kryesore tĂ« kalonte nĂ« statusin publik (depozitat e depozitave private dhe publike janĂ« tĂ« ndara, por, kur dy depo ishin private, commit-et janĂ« ruajtur sĂ« bashku, ndaj mbetĂ«n nĂ« depo pasi ajo kaloi nĂ« statusin publik).
    Qă‚ąă‚Żă‚»ă‚čo nĂ« tĂ« dhĂ«na nga repo tĂ« largĂ«ta dhe private nĂ« GitHub, qĂ« kanĂ« fork

Truku që lejon aksesin në commit-et në fork-e të depozitës përmes lidhjes me depozitën kryesore është i njohur prej shumë vjetësh dhe përdoret periodikisht për shaka të ndryshme dhe për të mashtruar zhvilluesit (për shembull, shakatë herë pas here krijojnë një dukje të zëvendësimit të backdoor-eve në depozitën e bërthamës Linux në GitHub). Si masë për të kundërshtuar këto shaka, GitHub ka shtuar një paralajmërim që tregon se commit-i i kërkuar nuk i përket degëve në depozitën aktuale dhe mund të përkasë një fork. Ndërkohë, mundësia për të aksesuar commit-et përmes hash-it në çdo depo të lidhur me fork-e është konsideruar si e pafajshme, pasi për kërkesat ndaj të dhënave në fork-e të largëta dhe private është e nevojshme të dihet hash-i i commit-it.

Gjetja e një commit hash-i, i cili formohet në bazë të algoritmit SHA-1 dhe përfshin 32 karaktere, është e pamundur, por rezulton se nuk është e nevojshme. GitHub mbështet një formë të shkurtuar të referencës për commit-et, e cila lejon adresimin e ndryshimeve sipas disa karaktereve të para të hash-it, nëse nuk ekzistojnë mbivendosje me commit-et e tjera. Numri minimal i karaktereve për adresimin e shkurtruar të hash-it është 4, çka është e barabartë me përllogaritjen e rreth 65 mijë kombinacioneve (16^4). Në këtë rast, ndoshta nuk është e nevojshme të bëhet përllogaritje, pasi API-ja e GitHub-it lejon lidhjen e trajtuesve për kapjen e ngjarjeve, të cilat përdoren nga projekte të tjera të jashtme që mbajnë një arkiv me të gjithë log-ët e operacioneve, në të cilin informacioni mbi hash-et e commit-eve mbetet dhe pas fshirjes së repozitorive.

Burimi: opennet.ru

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster