უსაფრთხოების ორი ფენა, რომლებიც უნდა შეთანხმდნენ

Content Security Policy (CSP) ბრაუზერს ეუბნება, რომელი წყაროებიდან შეუძლია გვერდს სკრიპტების, სტილების, სურათების, ფრეიმებისა და ქსელური მოთხოვნების ჩატვირთვა. თანხმობის მართვის პლატფორმა საპირისპირო საქმეს აკეთებს: მომხმარებლის არჩევანის მიხედვით წყვეტს, ამ სკრიპტებიდან რომელს აქვს გაშვების უფლება. როცა ორივე ცალ-ცალკეა დაკონფიგურირებული, ისინი ეჯახებიან. CMP ვერ იტვირთება, რადგან CSP მას ბლოკავს, ან CSP იმდენად ილაგმება CMP-სა და სარეკლამო თეგების დასატევად, რომ აღარაფერს იცავს.

ეს სახელმძღვანელო განმარტავს, რომელი CSP დირექტივები სჭირდება CMP-ს ჩვეულებრივ, როგორ ურთიერთქმედებს nonce სკრიპტების ინექციასთან და როგორ დავნერგოთ ცვლილებები ბანერის გაფუჭების გარეშე.

რა სჭირდება CMP-ს CSP-გან ჩვეულებრივ

ზუსტი მოთხოვნები ვენდორზეა დამოკიდებული, ამიტომ ყოველთვის თქვენი CMP-ის დოკუმენტაციიდან დაიწყეთ. ზოგადად, შეამოწმეთ ეს დირექტივები:

• script-src — დომენი, საიდანაც CMP სკრიპტი იტვირთება, პლუს ნებისმიერი დამატებითი სკრიპტის ფაილი, რომელსაც ის ტვირთავს.
• connect-src — ენდფოინთები, რომლებსაც CMP fetch-ით ან XHR-ით იძახებს, მაგალითად, კონფიგურაცია, ვენდორების სია, გეოლოკაცია და თანხმობის ლოგირება.
• style-src — სტილების დომენი და, შესაძლოა, inline სტილები, თუ CMP <style> ელემენტს ამატებს ან style ატრიბუტებს ადგენს.
• img-src — ლოგოები, ხატულები და ნებისმიერი თრექინგის გარეშე პიქსელი, რომელსაც CMP იყენებს.
• font-src — თუ ბანერი საკუთარ შრიფტებს ტვირთავს.
• frame-src — თუ CMP iframe-ებს იყენებს, მაგალითად, დომენთაშორისი თანხმობის გასაზიარებლად.

TCF საიტებზე გახსოვდეთ, რომ CMP გვერდზე ქმნის ლოკატორ ფრეიმსაც სახელად __tcfapiLocator. ეს ფრეიმი შორეული წყაროს გარეშე იქმნება, ამიტომ ჩვეულებრივ frame-src-ში ჩანაწერი არ სჭირდება, მაგრამ ღირს ტესტირებისას დადასტურება.

inline stub-ის პრობლემა

CMP-ების უმეტესობა გთხოვთ, გვერდის head-ში პატარა inline სკრიპტი — სტაბი — განათავსოთ, რათა სხვა სკრიპტებმა მთავარი CMP-ის ჩატვირთვამდე გამოძახებები რიგში დააყენონ. მკაცრი CSP inline სკრიპტებს ბლოკავს, თუ მათ პირდაპირ არ დაუშვებთ. სამი ვარიანტი გაქვთ:

1. Nonce. თითო პასუხზე შექმენით შემთხვევითი მნიშვნელობა, დაამატეთ CSP ჰედერში როგორც 'nonce-...' და სტაბის <script> თეგში. ეს დინამიკური გვერდებისთვის ყველაზე მოქნილი ვარიანტია.
2. Hash. დაამატეთ სტაბის ზუსტი შიგთავსის SHA-256 ჰეში script-src-ში. ეს სტატიკური საიტებისთვის კარგად მუშაობს, მაგრამ სტაბის ნებისმიერი ცვლილება, ჰარიც კი, მას არღვევს.
3. სტაბის თვითჰოსტინგი გარე ფაილად თქვენს დომენზე, რომელსაც 'self' ფარავს. ამას სიფრთხილე სჭირდება, რომ საკმარისად ადრე ჩაიტვირთოს.

მოერიდეთ 'unsafe-inline'-ს როგორც მოკლე გზას. ის ყველა inline სკრიპტს უშვებს, რაც CSP-ის მიერ უზრუნველყოფილი დაცვის დიდ ნაწილს აქრობს.

Nonce და CMP-ის მიერ ინექცირებული სკრიპტები

CMP, რომელიც სკრიპტებს თანხმობამდე ბლოკავს, ხშირად მათ შეჩერებითა და მოგვიანებით ინექციით მუშაობს. nonce-ზე დაფუძნებული CSP-ის პირობებში ეს ინექცირებული სკრიპტებიც უნდა იყოს დაშვებული. ორი გავრცელებული მიდგომაა:

• Nonce-ის გავრცელება. CMP კითხულობს nonce-ს საკუთარი სკრიპტის თეგიდან და ამატებს მას ყველა ინექცირებულ სკრიპტზე. შეამოწმეთ, მხარს უჭერს თუ არა ამას თქვენი CMP.
• 'strict-dynamic'. ეს საკვანძო სიტყვა მხარდამჭერ ბრაუზერებს ეუბნება, ენდონ სკრიპტებს, რომლებიც უკვე სანდო სკრიპტმა ჩატვირთა. ის ამარტივებს ცხოვრებას თეგ-მენეჯერებთან და CMP-ებთან, რომლებიც სკრიპტებს ინექციით ამატებენ, მაგრამ ასევე ნიშნავს, რომ ნებისმიერ სანდო სკრიპტს სხვების ჩატვირთვა შეუძლია, ამიტომ ფრთხილად ენდეთ.

თეგ-მენეჯერები იგივე კითხვას აჩენენ. თუ სარეკლამო და ანალიტიკურ თეგებს თეგ-მენეჯერით ტვირთავთ, მიჰყევით მის დოკუმენტაციას nonce-ზე და დარწმუნდით, რომ CMP და თეგ-მენეჯერი თანმიმდევრულ მიდგომას იყენებენ.

სარეკლამო თეგები CSP-ს ართულებს

პროგრამული რეკლამა სკრიპტებსა და ფრეიმებს ბევრი დომენიდან ტვირთავს და სია იცვლება, რადგან მოთხოვნის პარტნიორები იცვლებიან. გამომცემლები ჩვეულებრივ ორიდან ერთს ირჩევენ:

• მკაცრი CSP გვერდებზე პროგრამული რეკლამის გარეშე და უფრო ფართო პოლიტიკა იქ, სადაც რეკლამა მუშაობს.
• პოლიტიკა, რომელიც დირექტივებზეა ორიენტირებული, რომლებიც კვლავ მართვადია, მაგალითად, frame-ancestors, object-src 'none' და base-uri, ხოლო სკრიპტების წყაროები უფრო ფართო რჩება.

ორივე შემთხვევაში CMP მკაფიო დაშვებულთა სიაში უნდა იყოს და არა მხოლოდ ვაილდქარდით დაფარული, რათა CSP-ის ცვლილებამ ბანერი უხმაუროდ არ გამორთოს.

დანერგეთ Report-Only რეჟიმით

ჯერ გამოიყენეთ Content-Security-Policy-Report-Only ჰედერი. ბრაუზერი დარღვევებს აცხადებს რაიმეს დაბლოკვის გარეშე, რაც საშუალებას გაძლევთ ნახოთ, რას დააზიანებდა ახალი პოლიტიკა.

1. განათავსეთ პოლიტიკა report-only რეჟიმში რეპორტინგის ენდფოინთით.
2. ჩატვირთეთ გვერდები სუფთა ბრაუზერის პროფილებში და გაიარეთ თანხმობის სრული ნაკადი: პირველი ვიზიტი, ყველას მიღება, ყველაზე უარი, მორგებული არჩევანი, გაუქმება.
3. გადახედეთ დარღვევის ანგარიშებს და ბრაუზერის კონსოლს დაბლოკილი CMP რესურსების საპოვნელად.
4. შეცვალეთ პოლიტიკა, შემდეგ გადართეთ აღსრულებაზე.
5. აღსრულების შემდეგაც დატოვეთ რეპორტინგი ჩართული რეგრესიების დასაჭერად.

CSP კონფლიქტის სიმპტომები

• ბანერი არასდროს ჩნდება და კონსოლი CMP სკრიპტისთვის CSP დარღვევას აჩვენებს.
• ბანერი ჩნდება, მაგრამ უსტილოდ, რადგან style-src მის CSS-ს ბლოკავს.
• არჩევანი არ ინახება, რადგან connect-src თანხმობის ლოგირების გამოძახებას ბლოკავს.
• რეკლამები ან ანალიტიკა თანხმობის შემდეგ არასდროს იტვირთება, რადგან ინექცირებულ სკრიპტებს nonce აკლია.
• __tcfapi განუსაზღვრელია, რადგან inline სტაბი დაიბლოკა.

ძირითადი დასკვნები

• თქვენი CMP-სთვის შეამოწმეთ script-src, connect-src, style-src, img-src და frame-src.
• Inline სტაბი დაუშვით nonce-ით ან ჰეშით და არა 'unsafe-inline'-ით.
• დარწმუნდით, რომ თანხმობის შემდეგ ინექცირებული სკრიპტები იღებს nonce-ს ან 'strict-dynamic'-ით არის დაფარული.
• აღსრულებამდე გატესტეთ თანხმობის ყველა გზა report-only რეჟიმში.
• CMP მკაფიოდ დაშვებულთა სიაში შეინახეთ, რომ CSP-ის ცვლილებებმა ის ვერ გამორთოს.