სოკეტის პირი თუ გადაცემული სათაური: რომელ მისამართს ენდოთ?

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

აღწერეთ გზა, სანამ რამეს შეადარებთ:

Client -> approved reverse proxy -> application origin

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

მისამართის ორი სახის მტკიცებულება

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

გადაცემის ველი ჯაჭვის შესახებ მეტამონაცემია. X-Forwarded-For, X-Real-IP და სტანდარტიზებული ველი Forwarded შეიძლება დაწეროს ნებისმიერმა კლიენტმა, რომელიც აღწევს მათ ამსახველ საბოლოო წერტილს, ამიტომ მათი სანდოობა მთლიანად დამოკიდებულია იმაზე, თუ ვის მიეცა მათი დაყენების უფლება.

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

სათაური არასოდეს ცვლის კავშირის მარშრუტს

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

საპირისპირო შეცდომა ისეთივე გავრცელებულია: HTTPS არ აქცევს კლიენტის მიერ მოწოდებულ გადაცემის სათაურს ჭეშმარიტად. ის იცავს ცრუ მტკიცების ტრანსპორტირებას ზუსტად ისე, როგორც ჭეშმარიტისას.

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

დაასახელეთ პროქსი, რომელსაც მტკიცების უფლება აქვს

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

NGINX-ის რეალური IP მოდული ნათლად აჩვენებს გაყოფას. set_real_ip_from ასახელებს გამომგზავნებს, რომელთა მტკიცებაც ითვლება, და real_ip_header ამბობს, რომელი ველი ატარებს მას; პირველი ახორციელებს ნდობას, მეორე მხოლოდ ამბობს, სად უნდა ვიხილოთ.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

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

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

მრავალნახტომიან ჯაჭვებს გააზრებულად მოეპყარით

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

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

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

ორივე დაკვირვება შეინახეთ ჟურნალში

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

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