CORS პოლიტიკის ანალიზი ბრაუზერში
Cross-Origin Resource Sharing (CORS) წარმოადგენს ბრაუზერის უსაფრთხოების ფუნდამენტურ მექანიზმს. იგი განსაზღვრავს, აქვს თუ არა ვებგვერდს უფლება წაიკითხოს სხვა წარმოშობიდან (origin) მიღებული პასუხი. CORS შემოწმება არის სპეციალიზებული ხელსაწყო, რომელიც აანალიზებს HTTP პასუხის სათაურებს და ადგენს, დაუშვებს თუ არა ბრაუზერი კონკრეტულ cross-origin მოთხოვნას თქვენ მიერ მითითებული პარამეტრების საფუძველზე.
ეს ინსტრუმენტი განკუთვნილია ფრონტენდ, ბექენდ, API პლატფორმებისა და ოპერაციების დეველოპერებისთვის. ის სასარგებლოა ყველასთვის, ვისაც სურს გაიგოს, შეუძლია თუ არა ბრაუზერის კოდს კონკრეტული პასუხის წაკითხვა, ან აკმაყოფილებს თუ არა OPTIONS პასუხი შემდგომი მეთოდისა და მოთხოვნილი სათაურების პირობებს.
ხელსაწყოს შეყვანის პარამეტრები და ვალიდაცია
CORS პოლიტიკის შესამოწმებლად საჭიროა რამდენიმე პარამეტრის მითითება:
- პასუხი შემოწმებაზე: შეგიძლიათ აირჩიოთ "ფაქტობრივი პასუხი" ან "ფრენის წინ პასუხი".
- HTTP პასუხის სათაურები: ტექსტური ველი, სადაც უნდა ჩასვათ HTTP პასუხის სათაურები. ფრენის წინ პასუხის შემოწმებისას აუცილებელია სტატუსის სტრიქონის ჩასმაც. შეყვანილი ტექსტის მაქსიმალური სიგრძეა 200,000 სიმბოლო.
- მოითხოვეთ წარმოშობა: ტექსტური ველი, სადაც მიეთითება მოთხოვნის სქემა, ჰოსტი და არჩევითი პორტი (მაგალითად,
https://app.example.com). შეყვანილი მნიშვნელობა უნდა იყოს სუფთა წარმოშობა ანnull— URL-ის გზა, მოთხოვნის პარამეტრები (query) ან ავტორიზაციის მონაცემები დაუშვებელია. - მოთხოვნილი მეთოდი: HTTP მეთოდი, რომლის გამოყენებასაც აპირებთ.
- მოითხოვა სათაურის სახელები: სათაურების სახელები
Access-Control-Request-Headers-დან, რომლებიც გამოყოფილია მძიმეებით ან ახალი ხაზებით. - ჩართეთ რწმუნებათა სიგელები: გადამრთველი, რომელიც მიუთითებს, შეიცავს თუ არა მოთხოვნა ქუქი-ფაილებს ან HTTP ავთენტიფიკაციას.
ვალიდაციის შეცდომების დროს სისტემა აჩვენებს შეტყობინებას: "შეასწორეთ მონიშნული შეყვანა და სცადეთ ხელახლა.". კონკრეტული შეცდომების ფორმატები მოიცავს:
- ცარიელი სათაურების დროს: "ჩასვით HTTP პასუხის სათაურები შემოწმებამდე."
- ლიმიტის გადაჭარბებისას: "ეს პასუხი უჩვეულოდ დიდია. შეინახეთ იგი
‹max›სიმბოლოების ქვეშ." - არასწორი ხაზის ფორმატისას: "ხაზი
‹line›არ არის სწორი HTTP სათაური ან სტატუსის ხაზი." - არასწორი სათაურის დასახელებისას: "ხაზი
‹line›შეიცავს არასწორი HTTP სათაურის სახელს." - არასწორი წარმოშობის მითითებისას: "შეიყვანეთ საწყისი მხოლოდ სქემით, ჰოსტით და არასავალდებულო პორტით, როგორიცაა https://app.example.com."
- არასწორი მეთოდისას: "შეიყვანეთ სწორი HTTP მეთოდის ჟეტონი."
- აკრძალული მეთოდის გამოყენებისას: "ბრაუზერები არ უშვებენ
‹method›მეთოდს fetch მოთხოვნებში." - არასწორი მოთხოვნის სათაურისას: "„
‹header›“ არ არის სწორი HTTP მოთხოვნის სათაურის სახელი."
ბრაუზერის გადაწყვეტილების ლოგიკა
ხელსაწყო აანალიზებს შეყვანილ მონაცემებს და აჩვენებს ბრაუზერის გადაწყვეტილების ერთ-ერთ სტატუსს:
- "ჩასვით პასუხი მისი CORS პოლიტიკის შესამოწმებლად." (საწყისი მდგომარეობა).
- "შეიყვანეთ პასუხი და მოითხოვეთ დეტალები, შემდეგ შეამოწმეთ CORS პოლიტიკა." (როდესაც ველები ცარიელია).
- "დაშვებულია ჩასმული CORS პასუხით.".
- "დაბლოკილია ჩასმული CORS პასუხით.".
- "სათაურები გადის, მაგრამ წინასწარი გაფრენის სტატუსი უცნობია.".
ანალიზის დროს სისტემა ეყრდნობა CORS-ის მკაცრ წესებს და აჩვენებს შესაბამის დასაბუთებებს:
| კონტექსტი | წესი და შეტყობინება |
|---|---|
| წარმოშობის შემოწმება | Access-Control-Allow-Origin ზუსტად ემთხვევა ‹origin›.<br>Access-Control-Allow-Origin ამ მოთხოვნის ნებისმიერი წარმოშობის საშუალებას იძლევა.<br>Access-Control-Allow-Origin აკლია.<br>Access-Control-Allow-Origin არ შეიძლება იყოს *, როდესაც რწმუნებათა სიგელები შედის.<br>Access-Control-Allow-Origin არის ‹actual› და არა ‹expected›.<br>Access-Control-Allow-Origin აქვს არასწორი მნიშვნელობა: ‹value›. |
| რწმუნებათა სიგელები | Access-Control-Allow-Credentials ზუსტად მართალია.<br>სერთიფიკატის მქონე მოთხოვნას სჭირდება Access-Control-Allow-Credentials: მართალია.<br>სერთიფიკატები არ შედის, ამიტომ Access-Control-Allow-Credentials გავლენას არ ახდენს ამ გადაწყვეტილებაზე. |
| წინასწარი შემოწმება (Preflight) | გაფრენის წინ სტატუსი ‹status› წარმატებულია.<br>გაფრენის წინ სტატუსი ‹status› არ არის წარმატებული 2xx სტატუსი.<br>არცერთი HTTP სტატუსის ხაზი არ იყო ჩასმული, ამიტომ საჭირო 2xx ფრენამდე სტატუსის შემოწმება შეუძლებელია. |
| მეთოდების შემოწმება | წინასწარი გაფრენა იძლევა ‹method›.<br>‹method› არის CORS უსაფრთხო მეთოდი და არ საჭიროებს Access-Control-Allow-Methods-ში გამოჩენას.<br>Access-Control-Allow-Methods არ დაუშვებს ‹method›. |
| სათაურების შემოწმება | არცერთი მოთხოვნილი სათაურის სახელები არ საჭიროებს ფრენის წინ დამტკიცებას.<br>წინასწარი ფრენა იძლევა მოთხოვნილი სათაურის სახელებს: ‹headers›.<br>Access-Control-Allow-Headers: * მოიცავს ამ სახელებს სერთიფიკატების გარეშე მოთხოვნისთვის: ‹headers›.<br>Access-Control-Allow-Headers არ იძლევა: ‹headers›.<br>Authorization უნდა იყოს ჩამოთვლილი მკაფიოდ; Access-Control-Allow-Headers: * არ ფარავს მას. |
მნიშვნელოვანი წესები და გამონაკლისები
CORS სპეციფიკაცია შეიცავს რამდენიმე მნიშვნელოვან ზღვრულ შემთხვევას, რომლებსაც ეს ხელსაწყო მკაცრად ამოწმებს:
- რწმუნებათა სიგელები და ველური ნიშნები: როდესაც მოთხოვნაში ჩართულია რწმუნებათა სიგელები (ქუქი-ფაილები ან HTTP ავთენტიფიკაცია),
Access-Control-Allow-Originარ შეიძლება იყოს*. ამასთანავე, ნებადართული მეთოდებისა და სათაურების ველური ნიშნები (*) კარგავენ თავიანთ ძალას და აღარ მოქმედებენ როგორც უნივერსალური შაბლონები. - მრავალჯერადი წარმოშობა: თუ
Access-Control-Allow-Originშეიცავს რამდენიმე მნიშვნელობას ან გამოყოფილია მძიმეებით, სათაური ითვლება არასწორად. - სათაური Authorization: ეს სათაური წარმოადგენს გამონაკლისს. მაშინაც კი, თუ პასუხში მითითებულია
Access-Control-Allow-Headers: *, სათაურიAuthorizationმაინც ცალკე და მკაფიოდ უნდა იყოს ჩამოთვლილიAccess-Control-Allow-Headersსათაურში. - სტატუსის კოდები: წინასწარი გაფრენის (preflight) წარმატებით დასასრულებლად აუცილებელია 2xx ჯგუფის HTTP სტატუსის კოდი. თუ სტატუსის ხაზი არ არის მითითებული, წინასწარი შემოწმების შედეგი განისაზღვრება როგორც გაურკვეველი.
კონფიდენციალურობა და დამუშავების პრინციპი
თქვენი სათაურები და მოთხოვნის დეტალები თქვენს ბრაუზერში რჩება. არაფერი არ არის ატვირთული და შენახული BroBroGo-ის მიერ.
გაითვალისწინეთ, რომ ეს ხელსაწყო მხოლოდ აანალიზებს თქვენ მიერ მიწოდებულ მონაცემებს. ის არ უკავშირდება გარე სერვერებს, არ კითხულობს რეალურ URL მისამართებს, არ წერს ქუქი-ფაილებს, არ ამოწმებს DNS/TLS ჩანაწერებს და არ ცვლის სერვერის კონფიგურაციას. მიღებული დადებითი პასუხი ვრცელდება მხოლოდ ჩასმულ მონაცემებზე და არ იძლევა გარანტიას, რომ რეალური ქსელური მოთხოვნა წარმატებით დასრულდება, რადგან მასზე გავლენა შეუძლია მოახდინოს გადამისამართებებმა, ქეშირებამ, ბრაუზერის გაფართოებებმა ან სერვერის დინამიურმა წესებმა.
ხშირად დასმული კითხვები
უნდა ჩასვა რეალური პასუხი თუ გაფრენის წინ?
გამოიყენეთ ფაქტობრივი პასუხი, რათა შეამოწმოთ, შეუძლია თუ არა ბრაუზერის კოდს ერთი პასუხის წაკითხვა. გამოიყენეთ Preflight პასუხი OPTIONS პასუხისთვის, რომელიც ამტკიცებს შემდგომ მეთოდს და მის მოთხოვნილ სათაურების სახელებს.
რატომ შეიძლება მარცხი ჩავარდეს სერთიფიკატებით?
როდესაც ქუქი-ფაილები ან HTTP ავთენტიფიკაცია შედის, დაშვებული საწყისი ზუსტად უნდა ემთხვეოდეს მოთხოვნის საწყისს. ნებადართული მეთოდებისა და სათაურების ველური ნიშნები ასევე კარგავს მათ მნიშვნელობას.
გამსვლელი შედეგი ადასტურებს, რომ პირდაპირი მოთხოვნა იმუშავებს?
არა. ეს შედეგი მოიცავს მხოლოდ ჩასმულ პასუხს და აქ შეყვანილ მოთხოვნის დეტალებს. გადამისამართებებმა, ქეშირებულმა პასუხებმა, სერვერის წესების შეცვლამ, ბრაუზერის გაფართოებებმა და ფაქტობრივმა პასუხმა წინასწარ გაფრენის შემდეგ მაინც შეიძლება შეცვალოს შედეგი.