OAuth VPN-ის შიგნით: რომელი მონაკვეთები კვლავ მოითხოვს TLS-ს

კერძო მარშრუტიზაცია წყვეტს, ვინ აღწევს სერვერამდე; OAuth-ის ტრანსპორტის წესები წყვეტს, როგორ მოგზაურობს თითოეული შეტყობინება. ბრაუზერი, ავტორიზაციის სერვერი, ტოკენის საბოლოო წერტილი და რესურსების სერვერი შეიძლება ყველა ერთი და იმავე VPN-ის უკან იყოს და მაინც გაცვალონ შეტყობინებები სხვადასხვა მონაკვეთით. თითოეულ მონაკვეთს თავისი ტრანსპორტის მოთხოვნა აქვს და VPN არც ერთ მათგანს არ ამსუბუქებს. VPN-ის საზღვარი და პროტოკოლის საზღვარი ორი განსხვავებული ხაზია.

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

გადაწყვიტეთ მონაკვეთის მიხედვით და არა ქსელის მიხედვით

ცალკე ჩამოწერეთ საბოლოო წერტილები: ავტორიზაციის საბოლოო წერტილი, ტოკენის საბოლოო წერტილი, გადამისამართების URI, რესურსების სერვერის URL, TLS-ის დასრულების წერტილი და VPN-ის კარიბჭე. შემდეგ მონიშნეთ, რომელი მხარე იწყებს თითოეულ მოთხოვნას და სად მიდის პასუხი.

კარიბჭეზე დამთავრებული VPN შიფრავს მონაკვეთს იმ კარიბჭემდე. მოთხოვნა შეიძლება გაგრძელდეს როგორც ჩვეულებრივი HTTP მის უკან და ეს დარჩენილი მონაკვეთი არ გამხდარა HTTPS იმიტომ, რომ წინა მონაკვეთი იყო დაშიფრული. სწორედ ეს გაგრძელება არის ის მონაკვეთი, რომელიც პროტოკოლს აინტერესებს. პირველი ნახტომის დაშიფვრა მეორე ნახტომს უსაფრთხოს არ ხდის.

ტრანსპორტი ასევე ატარებს სერვისის იდენტობის შემოწმებას. ბრაუზერი ამოწმებს აპლიკაციის URL-ის სერტიფიკატს; VPN ამ შემოწმებას ბრაუზერის ნაცვლად არ ასრულებს და შეუმოწმებელ საბოლოო წერტილს მისაღებს არ ხდის. სერტიფიკატი ასახელებს იმ საბოლოო წერტილს, რომელსაც კლიენტი ფიქრობს, რომ იძახებს. გვირაბი კარიბჭემდე არ ასახელებს ახლიდან ამ წერტილს და არ ამოწმებს მას.

ავტორიზაციის პასუხი და გადამისამართების URI

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

იგივე მითითება კრძალავს HTTP გადამისამართების URI-ებს, გარდა მითითებული native-კლიენტის loopback შემთხვევისა. შიდა ჰოსტის სახელი ახალ გამონაკლისს არ ქმნის და DNS სახელი, რომელიც მხოლოდ VPN-ის შიგნით წყდება, მაინც HTTP URL-ია, თუ სქემა ასე ამბობს. შეამოწმეთ სქემა რეგისტრირებულ URI-ში და არა მხოლოდ ჰოსტის სახელი.

დარეგისტრირეთ ზუსტი HTTPS გადამისამართების URI ავტორიზაციის სერვერზე და დატოვეთ სერტიფიკატის შემოწმება ჩართული კლიენტზე. განვითარების მოკლე გზა, რომელიც თრგუნავს HTTPS-ის მოთხოვნას, ქმნის დინებას, რომელიც სხვაგვარად იქცევა, ვიდრე ის წარმოების კონფიგურაცია, რომლის მოდელირებაც მას უნდა შეეძლოს.

ტოკენის საბოლოო წერტილი და მატარებელი ტოკენის მოთხოვნები

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

მატარებელი ტოკენის მქონე რესურსების მოთხოვნებისთვის RFC 6750 TLS-ს ამ სპეციფიკაციისთვის განხორციელებისა და გამოყენების თვალსაზრისით სავალდებულოდ მიიჩნევს. ოფისის ქვექსელის სანდოდ წოდება არ არის ის ზოგადი პროტოკოლური გამონაკლისი, რომელიც ღია ტექსტში მატარებელი ტოკენის განლაგებას სჭირდება.

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

სად მთავრდება TLS და რა რჩება

თუ TLS მთავრდება უფლებამოსილ ფრონტენდზე, დაასახელეთ ეს ფრონტენდი და გადახედეთ მისგან აპლიკაციამდე მიმავალ გზას. ფრონტენდი პასუხისმგებელი ხდება დარჩენილ სეგმენტზე გადაცემაზე, ნდობასა და კონფიდენციალურობაზე და სერვისის მხარდაჭერილმა არქიტექტურამ ეს განლაგება უნდა აღწეროს.

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

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

native loopback-ის გამონაკლისი ვიწროა

loopback გადამისამართების გამონაკლისი ეხება უკუგამოძახებას თავად მომხმარებლის მოწყობილობაზე, სადაც კლიენტი და ბრაუზერი ამ მოწყობილობას იზიარებენ. ეს განლაგება ერთ მოწყობილობაზე უკუგამოძახებას ეკუთვნის და არ იძლევა უფლებას ჩვეულებრივი ავტორიზაციის სერვერი ან ტოკენის მატარებელი API HTTP-ით მიეწოდოს ოფისის ქვექსელს.

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

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