საერთო ქვედომენები, ორი შესასვლელი: ვინ რომელ ჩანაწერებს ხედავს?

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

პირველი: ჰოსტის სახელი მხოლოდ მოიჯარეს ასახელებს

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

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

მეორე: წევრობა სესიიდან მოდის

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

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

Cookie-ების ფარგლები და ერთიანი შესვლა განსაზღვრავს, სად შეიძლება ანგარიშის წარდგენა. ისინი არ განსაზღვრავენ, რისი წაკითხვა შეუძლია ამ ანგარიშს.

მესამე: ქსელი ადამიანზე არაფერს ამტკიცებს

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

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

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

მეოთხე: გაუშვით მატრიცა ორივე შესასვლელში

გამოიყენეთ კონტროლირებული ანგარიშები A-ს A-ში, B-ს B-ში, A-ს B-ში, უცნობი ჰოსტის სახელისა და წევრობის გარეშე ავთენტიფიცირებული ანგარიშის გამოსაცდელად. მეოთხე და მეხუთე დახურულად უნდა ჩავარდეს და არასოდეს დაეცეს ნაგულისხმევ მოიჯარეს. გაუშვით იგივე მატრიცა VPN-ის შესასვლელითაც, თითო სესიის ქილით თითოეული ანგარიშისთვის:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

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

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