Kas ta CSP ir kodėl ji turėtų rūpėti?
Kai kuriate svetainę, saugumas dažnai lieka kažkur gale prioritetų sąrašo. Veikia? Gerai atrodo? Puiku, galima leisti į produkciją. Tačiau realybė tokia, kad kibernetinės atakos tampa vis rafinuotesnės, o Lietuvos įmonių svetainės – ne išimtis. Content Security Policy (CSP) yra vienas iš tų saugumo mechanizmų, apie kurį daug kalbama, bet mažai kas iš tiesų įgyvendina.
CSP – tai HTTP antraštė, kuri nurodo naršyklei, kokius resursus svetainė gali įkelti ir iš kur. Skamba paprasta, bet praktikoje tai galinga gynybos linija prieš cross-site scripting (XSS) atakas, duomenų vagystes ir kitus piktavališkus veiksmus. Problema ta, kad daugelis Lietuvos verslo svetainių vis dar neturi jokios CSP politikos arba turi tokią silpną, kad ji praktiškai nieko neapsaugo.
Pagalvokite taip: jūsų svetainė yra kaip namas. CSP yra tarsi apsaugos sistema, kuri leidžia įeiti tik tiems, kuriuos jūs patvirtinote. Be jos, bet kas gali įeiti per bet kurias duris ar langą.
Kodėl Lietuvos svetainės atsilieka saugumo srityje
Pažvelgus į Lietuvos e-komercijos, naujienų portalų ar net kai kurių valstybinių institucijų svetaines, matosi aiški tendencija – saugumas dažnai yra antrinė mintis. Kodėl taip yra?
Pirma, trūksta žinių. Daugelis programuotojų ir svetainių administratorių tiesiog nežino, kas yra CSP arba kaip ją tinkamai sukonfigūruoti. Antra, yra klaidinga nuomonė, kad „mums to nereikia, mes maža įmonė”. Tačiau būtent mažesnės svetainės dažnai tampa lengvais taikiniais, nes jų saugumas yra silpnesnis.
Trečia priežastis – legacy kodas. Daugelis Lietuvos svetainių veikia ant senų sistemų, kuriose integruoti CSP reikštų perdarinėti pusę kodo. Tai brangsta, tai užima laiko, tai „padarysime vėliau”. Tik tas vėliau niekada neateiną.
Dar viena problema – trečiųjų šalių skriptai. Lietuvos svetainėse rasite Google Analytics, Facebook pixelį, įvairius reklaminius tinklus, chat botus ir dar dešimt kitų dalykų. Kiekvienas iš jų įkelia savo skriptus, o kai kurie iš tų skriptų įkelia dar daugiau skriptų. Bandymas visa tai suvaldyti su CSP tampa tikru galvos skausmu.
Kaip pradėti diegti CSP be streso
Gera žinia ta, kad CSP diegti nereikia viską iškart. Galite pradėti nuo report-only režimo, kuris tik stebi pažeidimus, bet jų neblokuoja. Tai puikus būdas suprasti, kas vyksta jūsų svetainėje, nesulaužant nieko.
Štai praktinis pavyzdys, kaip pradėti:
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations
Ši antraštė sako: „Pagal nutylėjimą leisk resursus tik iš mūsų domeno, bet kol kas tik stebėk ir praneš man, kas vyksta”. Jūs gausite ataskaitas apie visus pažeidimus ir galėsite matyti, kokie skriptai, stiliai ar vaizdai įkeliami iš išorinių šaltinių.
Kai suprasite, kas vyksta, galite pradėti griežtinti politiką. Pavyzdžiui:
Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
Ši politika leidžia:
– Pagal nutylėjimą įkelti resursus tik iš jūsų domeno
– Skriptus iš jūsų domeno ir Google Analytics
– Stilius iš jūsų domeno (su inline stiliais, nors tai nėra idealu)
– Vaizdus iš jūsų domeno, data URI ir bet kokių HTTPS šaltinių
Dažniausios klaidos ir kaip jų išvengti
Pirmoji ir dažniausia klaida – per daug leidžiantis CSP. Kai kurie kūrėjai nustato 'unsafe-inline' ir 'unsafe-eval' visur, kur tik įmanoma, nes taip „viskas veikia”. Bet tokiu atveju CSP tampa beveik beprasmis. Jei leidžiate inline skriptus, piktavališkas kodas gali būti įterptas tiesiai į HTML ir CSP jo nesustabdys.
Antra klaida – wildcard naudojimas be reikalo. Kai matau script-src *, man daro fiziškai skaudu. Tai reiškia, kad skriptai gali būti įkelti iš bet kur internete. Kokia prasmė turėti CSP, jei leidžiate viską?
Trečia problema – nonce ar hash nenaudojimas inline skriptams. Jei jums tikrai reikia inline skripto, naudokite nonce (vienkartinį atsitiktinį kodą) arba hash. Pavyzdžiui:
Content-Security-Policy: script-src 'self' 'nonce-r4nd0m123';
Tada jūsų HTML:
<script nonce="r4nd0m123">
console.log('Šis skriptas veiks');
</script>
Svarbu, kad nonce būtų generuojamas kiekvienam užklausai iš naujo. Jei naudosite tą patį nonce, tai bus beveik tas pats kaip ‘unsafe-inline’.
Realūs pavyzdžiai iš Lietuvos praktikos
Dirbdamas su keliais Lietuvos e-komercijos projektais, mačiau įvairiausių situacijų. Vienas klientas turėjo svetainę, kurioje veikė apie 15 skirtingų trečiųjų šalių skriptų – nuo analitikos iki live chat, nuo A/B testavimo iki reklamos tinklų. Kai bandėme įdiegti CSP, paaiškėjo, kad pusė tų skriptų dinamiškai įkelia dar daugiau skriptų iš nežinomų domenų.
Sprendimas buvo ne atsisakyti CSP, o peržiūrėti, kurie skriptai tikrai reikalingi. Pasirodė, kad trys analitikos įrankiai darė tą patį darbą, o du chat botai buvo įdiegti, nes niekas nepašalino senojo. Išvalius nereikalingus skriptus, CSP konfigūracija tapo valdoma.
Kitas atvejis – naujienų portalas, kuris leido vartotojams komentuoti. Komentaruose buvo galima įterpti HTML, o tai reiškė XSS riziką. Įdiegus CSP su griežta script-src politika, net jei piktavališkas skriptas būtų įterptas į komentarą, jis neveiktų, nes naršyklė jį blokuotų.
Testavimas ir monitoringas – ne mažiau svarbu
CSP nėra „nustatyk ir pamiršk” sprendimas. Jums reikia nuolat stebėti pažeidimus ir koreguoti politiką. Tam puikiai tinka report-uri arba naujesnė report-to direktyva.
Galite nustatyti endpoint’ą, kuris priims CSP pažeidimų ataskaitas:
Content-Security-Policy: default-src 'self'; report-uri /csp-report
Serverio pusėje sukuriate endpoint’ą, kuris priima POST užklausas su JSON duomenimis apie pažeidimus. Tada galite tuos duomenis analizuoti, siųsti į logging sistemą arba net gauti pranešimus, kai įvyksta įtartinų pažeidimų.
Yra ir trečiųjų šalių servisai, kaip report-uri.com, kurie padeda stebėti CSP pažeidimus. Tai gali būti naudinga, jei nenorite patys kurti monitoringo infrastruktūros.
Svarbu suprasti, kad ne visi pažeidimai reiškia ataką. Kartais naršyklės plėtiniai ar antivirusinės programos įterpia savo skriptus į puslapį, ir tai sukelia CSP pažeidimus. Reikia mokėti atskirti tikrus saugumo incidentus nuo false positive.
CSP ir modernūs JavaScript framework’ai
Jei naudojate React, Vue ar Angular, CSP gali sukelti papildomų iššūkių. Daugelis šių framework’ų pagal nutylėjimą naudoja inline stilius ar eval() funkcijas, kurios prieštarauja griežtai CSP politikai.
React pavyzdžiui, development režime naudoja eval(), todėl jums reikės skirtingų CSP politikų development ir production aplinkose. Production versijoje React veikia gerai su griežta CSP, jei nenaudojate inline stilių.
Vue turi panašių problemų, ypač jei naudojate template kompiliavimą naršyklėje. Sprendimas – naudoti pre-compiled templates arba leisti ‘unsafe-eval’, bet tik jei tikrai reikia.
Angular iš visų trijų yra draugiškiausias CSP. Jie net turi oficialią dokumentaciją, kaip konfigūruoti Angular aplikacijas su CSP. Pagrindinis patarimas – naudokite AOT (Ahead-of-Time) kompiliavimą, kuris eliminuoja poreikį eval() production aplinkoje.
Jei kuriate Single Page Application (SPA), apsvarstykite nonce strategiją. Serveris generuoja nonce kiekvienam page load, įterpia jį į HTML ir CSP antraštę. Jūsų JavaScript bundle’as gali būti įkeltas su tuo nonce, ir viskas veikia sklandžiai.
Ką daryti, kai viskas sudėta į krūvą
Realybė tokia, kad daugelis Lietuvos svetainių yra „legacy” projektai su dešimtmečių senumo kodu, jQuery, inline skriptais visur ir trečiųjų šalių integracijomis, apie kurias niekas nebeprisimena, kodėl jos ten.
Jei esate tokioje situacijoje, štai pragmatiškas planas:
**1. Pradėkite nuo audito.** Naudokite browser developer tools ir pažiūrėkite, kokie skriptai, stiliai ir kiti resursai įkeliami. Užrašykite visus domenus.
**2. Įdiekite report-only CSP.** Pradėkite nuo labai griežtos politikos report-only režime. Pavyzdžiui, default-src 'none'. Taip gausite visų pažeidimų sąrašą.
**3. Analizuokite ataskaitas.** Per savaitę ar dvi surinksite pakankamai duomenų, kad suprastumėte, kas vyksta. Išfiltruokite browser extension’ų triukšmą.
**4. Kurkite politiką palaipsniui.** Pradėkite nuo leisti tai, kas būtina. Pirma – jūsų domenai, paskui – kritiniai trečiųjų šalių servisai (mokėjimų procesoriai, būtina analitika).
**5. Pereikite į enforcing režimą.** Kai įsitikinsite, kad politika nesulaužo funkcionalumo, pašalinkite -Report-Only ir pradėkite tikrai blokuoti pažeidimus.
**6. Stebėkite ir tobulinkite.** CSP – tai gyvas dokumentas. Kai pridedame naują integraciją, atnaujinkite politiką.
Svarbu nepulti į perfekcionizmo spąstus. Geriau turėti neidealia, bet veikiančią CSP, nei neturėti jos visai, nes „dar nepasiruošę”.
Kai saugumas tampa konkurenciniu pranašumu
Lietuvos IT rinkoje vis dar galima išsiskirti paprasčiausiai darydami dalykus teisingai. Kai jūsų svetainė turi tinkamą CSP, HTTPS, saugius cookies ir kitus saugumo mechanizmus, tai tampa pardavimo argumentu, ypač B2B sektoriuje.
Įsivaizduokite situaciją: potencialus klientas renkasi tarp dviejų SaaS platformų. Abi atrodo panašiai, abi turi panašų funkcionalumą. Bet viena turi aiškią saugumo politiką, CSP, reguliarius saugumo auditus, o kita – nieko iš to. Kurią jūs pasirinktumėte?
GDPR taip pat daro CSP aktualesniu. Jei jūsų svetainėje veikia trečiųjų šalių skriptai, kurie gali rinkti vartotojų duomenis, CSP padeda kontroliuoti, kas gali tai daryti. Tai ne tik techninis, bet ir teisinis klausimas.
Be to, Google ir kitos paieškos sistemos vis labiau vertina saugias svetaines. Nors CSP tiesiogiai neįtakoja SEO, bendras svetainės saugumas tampa vis svarbesniu ranking faktoriumi.
Taigi CSP – tai ne tik gynybos mechanizmas, bet ir investicija į jūsų svetainės reputaciją ir patikimumą. Lietuvos rinkoje, kur daugelis vis dar ignoruoja pagrindinius saugumo principus, tai gali būti tas dalykas, kuris jus išskiria iš konkurentų.
Pradėkite šiandien. Net jei tai bus tik report-only režimas, tai jau žingsnis teisinga kryptimi. Jūsų vartotojai, jūsų duomenys ir jūsų ramybė to verta.
