როგორ შეიძლება იმავე საიტის ქუქიების გამოყენება CSRF შეტევების შესამცირებლად?
იმავე საიტის ქუქი-ფაილები მნიშვნელოვანი უსაფრთხოების მექანიზმია, რომლის გამოყენებაც შესაძლებელია ვებ-აპლიკაციებში საიტებს შორის მოთხოვნის გაყალბების (CSRF) შეტევების შესამცირებლად. CSRF შეტევები ხდება მაშინ, როდესაც თავდამსხმელი მსხვერპლს ატყუებს და აიძულებს მას განახორციელოს გაუთვალისწინებელი მოქმედება ვებსაიტზე, რომელზეც მსხვერპლი ავტორიზებულია. მსხვერპლის სესიის გამოყენებით, თავდამსხმელს შეუძლია შეასრულოს მოქმედებები მსხვერპლის სახელით მისი თანხმობის გარეშე.
ერთი და იმავე საიტის ქუქი-ფაილები ხელს უშლიან CSRF შეტევებს ქუქი-ფაილების მოქმედების არეალის ერთი და იმავე წყაროთი შეზღუდვით. წარმოშობა განისაზღვრება პროტოკოლის (მაგ., HTTP ან HTTPS), დომენისა და პორტის ნომრის კომბინაციით. როდესაც ქუქი-ფაილს აქვს „SameSite“ ატრიბუტი, ის განსაზღვრავს, უნდა გაიგზავნოს თუ არა ქუქი-ფაილი საიტებს შორის მოთხოვნებში.
„SameSite“ ატრიბუტისთვის სამი შესაძლო მნიშვნელობა არსებობს:
1. „Strict“: როდესაც „SameSite“ ატრიბუტი დაყენებულია „Strict“-ზე, ქუქი-ფაილი იგზავნება მხოლოდ ერთი და იგივე საიტიდან მომდინარე მოთხოვნებში. ეს ნიშნავს, რომ ქუქი-ფაილი არ გაიგზავნება საიტებს შორის მოთხოვნებში, რაც ეფექტურად უშლის ხელს CSRF შეტევებს. მაგალითად, თუ მომხმარებელი ავტორიზებულია „example.com“-ზე და ეწვევა მავნე საიტს, რომელიც ცდილობს CSRF შეტევის განხორციელებას, ბრაუზერი მოთხოვნაში არ ჩართავს „Strict“ იმავე საიტის ქუქი-ფაილს, რითაც თავიდან აიცილებს შეტევას.
2. „Lax“: როდესაც „SameSite“ ატრიბუტი დაყენებულია „Lax“-ზე, ქუქი იგზავნება საიტებს შორის მოთხოვნებში, რომლებიც უსაფრთხოდ ითვლება, მაგალითად, როდესაც მოთხოვნა გააქტიურებულია მომხმარებლის მიერ ზედა დონის ნავიგაციით. თუმცა, ქუქი არ იგზავნება მესამე მხარის ვებსაიტების მიერ ინიცირებულ მოთხოვნებში, მაგალითად, როდესაც სურათის ან სკრიპტის თეგი იტვირთება სხვა დომენიდან. ეს უზრუნველყოფს ბალანსს უსაფრთხოებასა და გამოყენებადობას შორის. მაგალითად, მომხმარებელი, რომელიც მავნე საიტს ბმულის საშუალებით სტუმრობს, არ გამოიწვევს CSRF შეტევას, რადგან „Lax“ იმავე საიტის ქუქი არ იქნება ჩართული მოთხოვნაში.
3. „None“: როდესაც „SameSite“ ატრიბუტი დაყენებულია „None“-ზე, ქუქი-ფაილი იგზავნება ყველა საიტებს შორის მოთხოვნაში, მათი წარმოშობის მიუხედავად. თუმცა, „None“-ის გამოყენების უსაფრთხოების უზრუნველსაყოფად, ქუქი-ფაილი ასევე უნდა იყოს მონიშნული, როგორც „Secure“, რაც ნიშნავს, რომ ის გაიგზავნება მხოლოდ HTTPS კავშირებით. ეს კომბინაცია საშუალებას აძლევს ვებ აპლიკაციებს მხარი დაუჭირონ საიტებს შორის ფუნქციონალურობას და ამავდროულად დაიცვან თავი CSRF შეტევებისგან. უნდა აღინიშნოს, რომ „None“ მნიშვნელობა უნდა იქნას გამოყენებული მხოლოდ საჭიროების შემთხვევაში, რადგან ის ზრდის შეტევის ზედაპირს და CSRF დაუცველობის პოტენციალს.
CSRF შეტევების შესამცირებლად იმავე საიტის ქუქი-ფაილების გამოყენების საილუსტრაციოდ განვიხილოთ შემდეგი სცენარი: საბანკო ვებსაიტი, რომელიც მომხმარებლებს საშუალებას აძლევს გადარიცხონ თანხები. იმავე საიტის ქუქი-ფაილების გარეშე, თავდამსხმელს შეუძლია შექმნას მავნე ვებსაიტი, რომელიც მოიცავს დაფარულ ფორმას, რომელიც ავტომატურად აგზავნის თანხის გადარიცხვის მოთხოვნას საბანკო ვებსაიტზე, როდესაც მას ავტორიზებული მომხმარებელი ეწვევა. თუ მომხმარებლის ბრაუზერი მოთხოვნაში სესიის ქუქი-ფაილს მოიცავს, გადარიცხვა შესრულდება მომხმარებლის თანხმობის გარეშე. თუმცა, სესიის ქუქი-ფაილის იმავე საიტის ქუქი-ფაილად „Strict“ ატრიბუტით დაყენებით, ბრაუზერი არ ჩართავს ქუქი-ფაილს საიტებს შორის მოთხოვნაში, რაც ეფექტურად ხელს უშლის CSRF შეტევას.
ერთი და იმავე საიტის ქუქი-ფაილები წარმოადგენს ღირებულ უსაფრთხოების მექანიზმს ვებ-აპლიკაციებში CSRF შეტევების შესამცირებლად. ქუქი-ფაილების ერთი და იმავე წყაროს ფარგლებში შეზღუდვით, ეს ქუქი-ფაილები ხელს უშლის თავდამსხმელებს მომხმარებლის სესიის ექსპლუატაციაში არაავტორიზებული ქმედებების შესასრულებლად. „მკაცრი“ მნიშვნელობა უზრუნველყოფს, რომ ქუქი-ფაილები გაიგზავნოს მხოლოდ ერთი და იმავე საიტიდან წარმოშობილ მოთხოვნებში, ხოლო „Lax“ მნიშვნელობა საშუალებას იძლევა, ქუქი-ფაილები გაიგზავნოს უსაფრთხო საიტებს შორის მოთხოვნებში. „None“ მნიშვნელობა, „Secure“ ატრიბუტთან ერთად, უზრუნველყოფს საიტებს შორის ფუნქციონირებას და ამავდროულად იცავს CSRF შეტევებისგან.
სხვა ბოლოდროინდელი კითხვები და პასუხები EITC/IS/WASF ვებ აპლიკაციების უსაფრთხოების საფუძვლები:
- იცავს თუ არა Do Not Track (DNT) დანერგვა ვებ ბრაუზერებში თითის ანაბეჭდისგან?
- ეხმარება თუ არა HTTP Strict Transport Security (HSTS) დაცვას პროტოკოლის შემცირების შეტევებისგან?
- როგორ მუშაობს DNS ხელახალი შეტევა?
- ხდება თუ არა შენახული XSS შეტევები, როდესაც მავნე სკრიპტი შედის ვებ აპლიკაციის მოთხოვნაში და შემდეგ უბრუნდება მომხმარებელს?
- გამოიყენება თუ არა SSL/TLS პროტოკოლი HTTPS-ში დაშიფრული კავშირის დასამყარებლად?
- რა არის Fetch მეტამონაცემების მოთხოვნის სათაურები და როგორ შეიძლება მათი გამოყენება ერთიდაიგივე წარმომავლობისა და ჯვარედინი მოთხოვნის განასხვავებლად?
- როგორ ამცირებენ სანდო ტიპები ვებ აპლიკაციების თავდასხმის ზედაპირს და ამარტივებს უსაფრთხოების მიმოხილვას?
- რა არის ნაგულისხმევი პოლიტიკის მიზანი სანდო ტიპებში და როგორ შეიძლება მისი გამოყენება არასაიმედო სტრიქონების მინიჭების იდენტიფიცირებისთვის?
- როგორია სანდო ტიპების ობიექტის შექმნის პროცესი სანდო ტიპების API-ს გამოყენებით?
- როგორ ეხმარება სანდო ტიპების დირექტივა კონტენტის უსაფრთხოების პოლიტიკაში DOM-ზე დაფუძნებული ჯვარედინი სკრიპტების (XSS) დაუცველობის შერბილებაში?
იხილეთ მეტი კითხვა და პასუხი EITC/IS/WASF ვებ აპლიკაციების უსაფრთხოების საფუძვლებში