
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
- 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ë.
- 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.
- 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.
- 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.
- 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ë.
- 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ë.