როგორ უნდა შემოვიტანოთ საჯარო ფორმების გაგზავნები კერძო ქსელში

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

დაიწყეთ იქ, სადაც გაგზავნა ეშვება

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

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

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

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

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

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

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

გადაამოწმეთ, სანამ შიგნით რამე შეიცვლება

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

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

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

შექმენით განმეორებითი ცდის წერტილი ერთ ოპერაციაზე

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

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

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

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

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