Hacker News

CSP პენტესტერებისთვის: საფუძვლების გაგება

კომენტარები

2 min read Via www.kayssel.com

Mewayz Team

Editorial Team

Hacker News

რატომ სჭირდება ყველა პენტესტერს კონტენტის უსაფრთხოების პოლიტიკის დაუფლება

კონტენტის უსაფრთხოების პოლიტიკა (CSP) გახდა ერთ-ერთი ყველაზე კრიტიკული დამცავი მექანიზმი ბრაუზერის მხრიდან, საიტის სკრიპტის (XSS), მონაცემთა ინექციისა და დაწკაპუნების შეტევებისგან. მიუხედავად ამისა, შეღწევადობის ტესტირების პროცესში, CSP სათაურები რჩება ერთ-ერთ ყველაზე ხშირად არასწორ კონფიგურაციად და არასწორად გაგებულ უსაფრთხოების კონტროლად. 2024 წელს ჩატარებულმა კვლევამ, რომელიც აანალიზებდა 1 მილიონზე მეტ ვებსაიტს, დაადგინა, რომ მხოლოდ 12.8%-მა გამოიყენა CSP სათაურები და მათგან თითქმის 94% შეიცავდა მინიმუმ ერთ პოლიტიკის სისუსტეს, რომლის გამოყენებაც შეიძლებოდა. Pentesters-ისთვის CSP-ის გაგება არ არის არჩევითი — ეს არის განსხვავება ზედაპირული დონის შეფასებასა და მოხსენებას შორის, რომელიც რეალურად აძლიერებს კლიენტის უსაფრთხოების პოზას.

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

რას აკეთებს კონტენტის უსაფრთხოების პოლიტიკა რეალურად

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

CSP-ის თავდაპირველი მოტივაცია იყო XSS შეტევების შერბილება. ტრადიციული XSS თავდაცვა, როგორიცაა შეყვანის გაწმენდა და გამომავალი კოდირება, ეფექტურია, მაგრამ მყიფე – ერთმა გამოტოვებულმა კონტექსტმა ან კოდირების შეცდომამ შეიძლება ხელახლა გამოავლინოს დაუცველობა. CSP ამატებს თავდაცვის სიღრმისეულ ფენას: მაშინაც კი, თუ თავდამსხმელმა DOM-ში მოახდინოს მავნე სკრიპტის ტეგი, სწორად კონფიგურირებული პოლიტიკა ხელს უშლის ბრაუზერს მის შესრულებაში.

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

CSP-ის სათაურის ანატომია: დირექტივები და წყაროები

CSP სათაური შედგება დირექტივებისაგან, თითოეული აკონტროლებს რესურსის კონკრეტულ ტიპს. ამ დირექტივების გაგება აუცილებელია ნებისმიერი პენტესტერისთვის, რომელიც აფასებს სამიზნე პოლიტიკას. ყველაზე მნიშვნელოვანი დირექტივებია: default-src (ნებისმიერი დირექტივის სარეზერვო საშუალება, რომელიც ცალსახად არ არის დაყენებული), script-src (JavaScript შესრულება), style-src (CSS), img-src (სურათები), connect-src, კავშირი, WebSket, WebSket, XR frame-src (ჩაშენებული iframes) და object-src (პლაგინები, როგორიცაა Flash ან Java აპლეტები).

თითოეული დირექტივა იღებს ერთ ან მეტ წყარო გამონათქვამს, რომელიც განსაზღვრავს დაშვებულ საწყისებს. ეს მერყეობს კონკრეტული ჰოსტის სახელებიდან (https://cdn.example.com) უფრო ფართო საკვანძო სიტყვებამდე:

  • 'self' — საშუალებას აძლევს რესურსებს იგივე წარმოშობიდან, როგორც დოკუმენტი
  • 'არცერთი' — ბლოკავს ამ ტიპის ყველა რესურსს
  • 'unsafe-inline' — იძლევა ინლაინ სკრიპტებს ან სტილებს (ეფექტურად ანეიტრალებს XSS დაცვას)
  • 'unsafe-eval' — იძლევა eval(), setTimeout(string) და მსგავსი დინამიური კოდის შესრულების საშუალებას
  • 'nonce-{შემთხვევითი}' — ნებას რთავს კონკრეტულ შიდა სკრიპტებს, რომლებიც მონიშნულია შესატყვისი კრიპტოგრაფიული ნონსით
  • „მკაცრი-დინამიური“ — ენდობა უკვე სანდო სკრიპტებით ჩატვირთულ სკრიპტებს, უგულებელყოფს ჰოსტზე დაფუძნებულ დაშვებულ სიებს
  • მონაცემები: — იძლევა მონაცემთა URI-ებს კონტენტის წყაროებად

რეალური სამყაროს CSP სათაური შეიძლება ასე გამოიყურებოდეს: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net 'nonce-abc123'; style-src 'self' 'unsafe-inline'; img-src *; object-src 'none'. როგორც პენტესტერს, თქვენი ამოცანაა წაიკითხოთ ეს პოლიტიკა და დაუყოვნებლივ დაადგინოთ, სად არის ის ძლიერი, სად არის სუსტი და სად არის გამოსაყენებელი.

ჩვეულებრივი CSP არასწორი კონფიგურაციები Pentesters უნდა იყოს მიზანმიმართული

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

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