Skriptet e palëve të treta ende ngarkohen nga një domen CDN i braktisur

Skriptet e palëve të treta ende ngarkohen nga një domen CDN i braktisur

Dikush e riregjistroi një domen CDN të braktisur në korrik 2025, dhe mijëra faqe ende ngarkojnë skripte të palëve të treta nga emrat e hosteve që ai person tani kontrollon.

Mijëra faqe interneti ende ngarkojnë skripte të palëve të treta nga një domen i rrjetit të shpërndarjes së përmbajtjes që dikush e riregjistroi në korrik 2025, vite pasi shërbimi pas tij u mbyll. Domeni ishte lënë të skadonte, por ata që e thërrisnin nuk u larguan: një artikull i kontribuar nga Report URI, botuar nga The Hacker News, raporton se mijëra faqe interneti, depo kodike dhe faqe dokumentacioni ende përmbajnë referenca të koduara fort për emrat e hosteve nën të. Pronari i ri mban DNS me wildcard në të gjithë domenin, që do të thotë se çdo emër hosti nën të tani zgjidhet në infrastrukturën që ai person kontrollon. Apex-i, adresa kryesore e domenit, aktualisht shërben një faqe shkarkimi mediash të mbushur me reklama, e cila në vetvete nuk është e jashtëzakonshme. Ajo që ka rëndësi është se vendimi për atë që do të ngarkojnë më pas ato mijëra faqe tani i përket një të huaji, dhe askush i përfshirë nuk është njoftuar, sepse nga jashtë asgjë nuk u prish.

Ky model nuk është hipotetik. Në qershor 2024, domeni polyfill.io, një shim JavaScript i integruar në më shumë se 110,000 faqe, ndryshoi pronësinë dhe filloi të shërbente ridrejtime të kushtëzuara për vizitorët në celular. Faqet që e përdornin nuk ishin hakuar; ato kishin kontraktuar një etiketë skripti vite më parë dhe nuk e kishin rishikuar kurrë vendimin. Një etiketë skripti është një rresht kodi që i thotë një shfletuesi të marrë dhe të ekzekutojë një skedar të hostuar diku tjetër, dhe një shim është një pjesë e vogël kodi që plotëson boshllëqet në shfletuesit e vjetër. Të dyja rastet ndajnë një problem që shumica e ekipeve të sigurisë nuk kanë kontroll mbi të: kodi keqdashës nuk ishte kurrë në serverin e tyre, dhe mbërriti shumë kohë pasi ndodhi vendosja e fundit.

Mjetet nga ana e serverit po shikojnë në vendin e gabuar, argumenton artikulli. Analiza statike, skanimi i varësive dhe analiza e përbërjes së softuerit të gjitha shqyrtojnë atë që një organizatë ndërton dhe dërgon, por një skript i palës së tretë nuk është asnjë nga ato. Ai merret nga shfletuesi i vizitorit, nga një server që organizata nuk e drejton dhe nuk mund ta kontrollojë, drejtpërdrejt në çdo shikim faqeje. Kjo e bën atë unikisht armiqësor ndaj testimit konvencional, sepse përgjigja mund të ndryshojë sipas gjeografisë, agjentit të përdoruesit, referuesit, kohës së ditës dhe sesionit. Një crawler që e tërheq skedarin një herë nga një gamë adresash qendrash të dhënash mund t'i shfaqet një version i pastër, ndërsa një blerës në një rrjet celular në një vend tjetër merr diçka më të keqe. Vetë skripti i palës së tretë mban të njëjtat privilegje si kodi i palës së parë: ai mund të lexojë DOM-in (strukturën e faqes që ndërton një shfletues), të lexojë fushat e formularëve karakter pas karakteri ndërsa shkruhen, të lexojë cookies dhe ruajtjen lokale, dhe të bëjë kërkesa dalëse kudo që dëshiron. Sulmet nga ana e klientit të tipit Magecart nuk kërkojnë fare një shkelje të serverit; ato kërkojnë që një etiketë skripti e miratuar të fillojë të sillet ndryshe.

Ekziston një vëzhgues i pranishëm në mënyrë të besueshme për secilin nga ato shikime faqesh: shfletuesi që ekzekutoi kodin. Content Security Policy (CSP), një grup udhëzimesh që një faqe u dërgon shfletuesve duke listuar cilat burime kodi mund të ekzekutohen, zakonisht diskutohet si një mbrojtje kundër skriptimit ndër-faqe, dhe është një mbrojtje e mirë. Funksioni i tij i dytë është më i dobishëm për një ekip sigurie që ende nuk e di se çfarë kodi po ekzekuton: një politikë mund të kontrollojë se çfarë kodi lejohet të ekzekutohet, të bllokojë kodin që nuk është i autorizuar të ekzekutohet, dhe të raportojë kur kjo ndodh. Ato raporte vijnë nga sesione reale, në vende reale, nga përdorues realë në pajisjet e tyre reale, kështu që një ngarkesë keqdashëse që aktivizohet vetëm për përdoruesit e identifikuar në një vend ende raportohet, sepse shfletuesi që e ekzekutoi është ai që dërgon alarmin. Artikulli citon një shembull konkret: në shtator 2026, alarmet e mbledhura nga Report URI zbuluan një grup faqesh të komprometuara e-commerce që drejtonin një fushatë inxhinierie sociale të familjes 'ClickFix'. Ngarkues të koduar në base64, që do të thotë kod i maskuar si tekst i zakonshëm, ishin mbjellë brenda përmbajtjes së CMS pas një kompromisi administrativ, duke u zinxhiruar përmes një ridrejtuesi në një mbulesë të rreme 'verifiko që je njeri' që vendoste një komandë PowerShell në clipboard-in e viktimës dhe e ruante atë si një detyrë të planifikuar. Emrat e hosteve të kontrolluar nga sulmuesi u shfaqën në alarmet nga shfletuesit e viktimave, ndërsa disa nga ato domene ende vlerësoheshin të pastra nga shërbimet kryesore të reputacionit. Asnjë skaner nuk i kishte shënuar faqet, sepse në server ato ishin në rregull.

Kundërshtimi i zakonshëm është se një Content Security Policy do të prishë faqen, por në modalitetin report-only nuk mundet. Content-Security-Policy-Report-Only nuk zbaton asgjë, nuk bllokon asgjë dhe nuk ndryshon asnjë sjellje; ai vetëm raporton atë që një politikë do të kishte bllokuar. Kjo e kthen vendosjen e parë në një ushtrim të sigurt matjeje dhe mbledh të gjitha të dhënat e nevojshme për atë se çfarë kodi po ekzekutohet në një faqe. Për shumicën e organizatave, ajo listë është shumë më e gjatë nga sa prisnin, thotë artikulli.

Për këdo që merret me pagesa me kartë, argumenti është tashmë i zgjidhur. Kërkesat 6.4.3 dhe 11.6.1 të PCI DSS versionit 4.0.1 pushuan së qeni praktikë më e mirë dhe u bënë të detyrueshme më 31 mars 2025. Së bashku, ato kërkojnë që çdo skript në një faqe pagese të jetë i autorizuar, që integriteti i tij të sigurohet, që të ekzistojë një inventar i shkruar me justifikim biznesi, dhe që një mekanizëm të zbulojë dhe alarmojë për modifikime të paautorizuara të përmbajtjes së faqes së pagesës dhe titujve HTTP (informacioni i prapaskenës që një server web dërgon bashkë me çdo faqe). Një QSA, një vlerësues i kualifikuar sigurie që kontrollon përputhshmërinë e pagesave me kartë, mund dhe do të kërkojë inventarin, mekanizmin e alarmit dhe gjurmën e provave që ai prodhoi. Report URI deklaron se produkti i tij mund t'i sigurojë të treja.

Artikulli përshkruan një vendosje në tre hapa: mblidhni të dhënat fillestare për një javë, ndërtoni një inventar nga ajo që u raportua, pastaj monitoroni ndryshimet me kalimin e kohës dhe miratoni ose refuzoni ato. Ai gjithashtu citon një skanim ditor dhjetëvjeçar të një milion faqeve kryesore që tregon rritjen e adoptimit të CSP me më shumë se 12,000% gjatë dekadës; artikulli nuk përmend kush e drejtoi atë skanim. Kjo rritje, argumenton ai, pasqyron një ndryshim më të gjerë në atë se ku organizatat kanë nevojë për dukshmëri: jo vetëm në atë që ato vendosin, por në atë se çfarë kodi ekzekutojnë në të vërtetë shfletuesit e përdoruesve të tyre.

Report URI e përshkruan veten në artikull si një platformë sigurie nga ana e klientit që u përgjigjet pyetjeve që një ekip sigurie nuk mund t'u përgjigjet ndryshe për faqen e vet: cilat palë të treta po ekzekutojnë kod në faqet e tij, cilat ndryshuan që nga dje, dhe cilat po marrin të dhëna ose komunikojnë me infrastrukturë të njohur si armiqësore. Skriptet e shërbyera për përdoruesit realë hash-ohen dhe arkivohen në mënyrë që ndryshimet të identifikohen dhe hetohen pas faktit, emrat e hosteve kontrollohen kundër inteligjencës së kërcënimeve, dhe politikat monitorohen për zhvendosje, duke mbyllur hendekun midis asaj që u miratua dhe asaj që po ekzekutohet në të vërtetë. Vendosja nuk shton JavaScript në faqe dhe asnjë agjent, modul ose SDK në stak; hapi i parë është të shtoni një titull përgjigjeje HTTP dhe të lexoni atë që kthehet gjatë 48 orëve në vijim. Lexuesit duhet t'i vlerësojnë rekomandimet duke e ditur se artikulli është një pjesë e kontribuar nga Report URI, shitësi i platformës që ai përshkruan, dhe se ai mbyllet me një ofertë për një provë falas 30-ditore që nuk kërkon kartë krediti dhe as ndryshime kodi në faqe.

Mësimi praktik për pronarët e faqeve është se një etiketë skripti është një vendim jetëgjatë. Çdo referencë për një emër hosti të jashtëm është një varësi nga kushdo që e zotëron atë emër hosti sot, jo nga kushdo që e zotëronte kur u shtua kodi, dhe ato nuk janë gjithmonë e njëjta kompani. Një inventar, një politikë report-only dhe një zakon për të rishikuar integrimet e vjetra nuk do të ndalojnë një sulmues, por ato e bëjnë të mundur të vërehet kur një adresë nga e cila varen faqet tuaja ndryshon duar. Lexuesit që dëshirojnë një rishikim të strukturuar të asaj që ngarkojnë faqet e tyre, dhe si të fillojnë monitorimin e saj, mund të shohin atë që ofron AEU-I në IT, infrastrukturë dhe konsulencë të fokusuar në sigurinë (https://aeu-i.com).

Si të Mbroheni

  1. Pyetni këdo që ndërtoi ose mirëmban faqen tuaj për një listë të thjeshtë të çdo shërbimi të jashtëm që ngarkojnë faqet tuaja, pastaj hiqni ato që askush nuk i njeh ose nuk i përdor më.
  2. Aktivizoni monitorimin vetëm-raportues për politikën e përmbajtjes së faqes tuaj (hosti ose zhvilluesi juaj mund ta bëjë këtë), lexoni raportet për një javë përpara se të bllokoni ndonjë gjë, në mënyrë që asgjë të mos prishet.
  3. Kurrë mos shtoni një pjesë kodi nga një kompani tjetër nëse nuk mund të përmendni kompaninë dhe ta kontaktoni atë sot, dhe kontrolloni që adresa e internetit nga e cila ngarkohet t'i përkasë ende asaj.
  4. Mbronini hyrjet e administratorit të faqes tuaj me një fjalëkalim të gjatë unik dhe vërtetim me dy faktorë, pasi sulmi e-commerce i përshkruar këtu filloi me një llogari administratori të rrëmbyer.
  5. Nëse vizitorët shohin ndonjëherë një kuti të papritur që u kërkon të 'verifikojnë se jeni njerëz' në faqen tuaj, trajtojeni atë si një shenjë se faqja është ndryshuar dhe kërkoni ndihmë nga hosti ose zhvilluesi juaj menjëherë.
  6. Nëse pranoni pagesa me kartë, pyesni ofruesin tuaj të pagesave ose këshilltarin e sigurisë se çfarë u nevojitet për inventarin e skripteve dhe alarmet që tani kërkohen për përputhshmërinë e kartave.

Termat e Shpjeguar

  • third-party script Një pjesë kodi në faqen tuaj të internetit që ruhet dhe dorëzohet nga serveri i një kompanie tjetër, jo nga i juaji.
  • content delivery network (CDN) Një shërbim që ruan kopje të skedarëve të faqes në shumë servera, në mënyrë që faqet të ngarkohen më shpejt për vizitorët në mbarë botën.
  • wildcard DNS Një cilësim që dërgon çdo adresë të mundshme që mbaron me një emër domeni në të njëjtin vend, kështu që pronari i atij domeni i kontrollon të gjitha.
  • Content Security Policy (CSP) Udhëzime që një faqe interneti u dërgon shfletuesve të vizitorëve, duke thënë se cilat burime të jashtme kodi lejohen të ekzekutohen në faqe.
  • report-only mode Një cilësim monitorimi që ju tregon se çfarë do të kishte bllokuar një rregull sigurie pa bllokuar në të vërtetë asgjë.
  • Magecart attack Një lloj vjedhjeje online ku kodi i fshehur në një faqe interneti kopjon në heshtje atë që blerësit shkruajnë në formularët e pagesës ose të hyrjes.
  • PCI DSS Standardi ndërkombëtar i sigurisë që çdo biznes që pranon pagesa me kartë duhet të ndjekë.
  • base64 Një mënyrë për të rishkruar kodin si tekst i zakonshëm, në mënyrë që të jetë më e vështirë të dallohet si kod me një shikim të shpejtë.

Shërbime AEU të lidhura

  • AEU DNS Resolver DNS i enkriptuar