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

დაჯავშნის საიტსა თუ შეკვეთების სისტემაში ყველაზე ძვირი ხვრელები სწორ კოდს ჰგავს. სერვერი შეკვეთას ნომრით გასცემს და არ კითხულობს, ვისია. პროფილში ველი „როლი“ იღებს იმას, რაც კლიენტმა გამოგზავნა. თანხას ბრაუზერი ითვლის, სერვერი კი ენდობა. უსაფრთხოების სკანერი აქ დუმს, რადგან საძებნი არაფერი აქვს: შემოწმება არ არის, კოდის არარსებობა კი შაბლონს არ ერგება. ამ კვირაში ამაზე GitLab-მა, Cloudflare-მა და Shopify-მ დაწერეს, მე კი გაქირავებიდან და ყავის შეკვეთებიდან მაქვს დასამატებელი.

რა გამოვიდა

GitLab-მა 20 ოქტომბერს Business Logic Security Analyzer წარადგინა, ჯერჯერობით ადრეულ წვდომაში Ultimate-ის კლიენტებისთვის GitLab.com-ზე. მათი ამოსავალი წერტილი სწორია: ობიექტის დონეზე ავტორიზაციის დარღვევა OWASP API Security Top 10-ში პირველ ადგილზეა, ჩვეულებრივი SAST კი ასეთ რამეებს ვერ პოულობს. ტექსტიდან სამი მაგალითი: ენდპოინტი შეკვეთის ID-ს მოთხოვნიდან იღებს და შეკვეთას მფლობელის შემოწმების გარეშე აბრუნებს; როლის ველი ნებისმიერ JSON-ს იღებს; მომხმარებლის ID მიმდევრობითი მთელი რიცხვია. ცალ-ცალკე ეს ვალიდური კოდია, ერთად კი ყველა კლიენტის ყველა შეკვეთა და ადმინისტრატორის უფლებები. ანალიზატორი რეპოზიტორიას მთლიანად კითხულობს და ყოველ დამმუშავებელს ამოწმებს მოდელზე, ვის რა შეუძლია. მათ დემოში ის პოულობს refund_order-ს, რომელიც refunded=1-ს მფლობელის შემოწმების გარეშე სვამს, და ამას CWE-639-ად ნიშნავს.

Cloudflare-მა 21 ოქტომბერს WAF-ს მთელი ტრანზაქციის შემოწმება დაუმატა: მოთხოვნას პასუხთან ერთად უყურებენ, და წესს შეუძლია სერვერის პასუხი დაბლოკოს, სანამ ის მომთხოვნამდე მივა. მაგალითი ტექსტიდან: მოთხოვნა ფაილზე ../../config/database.ini თავისთავად ჯერ არაფერს ამტკიცებს, პასუხი 200 ბაზის ლოგინითა და პაროლით კი ყველაფერს ამტკიცებს. ეს ყველას მისცეს, უფასო ტარიფის ჩათვლით. ერთი შენიშვნა იქიდანვე: პასუხის დაბლოკვა შეიძლება, იმის გაუქმება კი, რაც სერვერმა უკვე გააკეთა, არა. სხვისი შეკვეთის თანხის დაბრუნება ამ მომენტისთვის უკვე გავლილია.

Shopify-მ 20 ოქტომბერს აპლიკაციების ყველა დეველოპერს სთხოვა, ამ კვირაში უსაფრთხოებით დაკავდნენ: გაუშვან ახალი შემოწმება, გადავიდნენ ვადიან წვდომის ტოკენებზე, რომლებიც საჯარო აპლიკაციებისთვის მალე სავალდებულო გახდება, ნახონ მოთხოვნების ლოგები კლიენტის IP-ის მიხედვით და ყველგან ჩართონ ორფაქტორიანი დაცვა. თავად შემოწმება 15 ოქტომბერს გამოვიდა, როგორც ბრძანება shopify app security check Shopify CLI-ში. ის ლოკალურად ეშვება და კოდს, კონფიგურაციასა და დამოკიდებულებებს ათვალიერებს. პარტნიორებმა, რომლებმაც ის გამოსცადეს, საკუთარ კოდში აუთენტიფიკაციისა და მაღაზიებს შორის მონაცემების იზოლაციის ხარვეზები იპოვეს. ინსტრუმენტის კოდი ღიაა.

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

როგორ გამოიყურება ეს გაქირავებაში

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

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

როგორ არის ეს ჩემთან გაკეთებული

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

შიდა სერვისში „ყავა ერთად“ წესები უფრო მკაცრია, რადგან საქმე თანამშრომლების ფულს ეხება. Node.js-ზე აწყობილი gateway კლიენტის გამოგზავნილ იდენტობის სათაურებს შლის და მომხმარებელს თავად განსაზღვრავს ხელმოწერილი HttpOnly cookie-ით, ასე რომ „მე ადმინი ვარ“ მოთხოვნაში არაფერს ნიშნავს. შეკვეთის ფორმაში ფასები არ არის: თანხა მხოლოდ მას შემდეგ ჩნდება, რაც ორგანიზატორი მომწოდებლის ნამდვილ კალათას გადაამოწმებს. შეკვეთა გადახდილი მხოლოდ მაშინ ხდება, როცა ორგანიზატორი თანხის შემოსვლას გადაამოწმებს. ნიშნულის „შეკვეთილია“ დასმის უფლებას სერვისი მხოლოდ ყველა გადახდის შემოწმებისა და მომწოდებელთან შეკვეთის რეალურად განთავსების შემდეგ იძლევა. გაცემა მხოლოდ იმ შეკვეთისა შეიძლება, რომელიც სრულად მიღებულია. ყოველი გადასვლა სერვერზე შემოწმებაა, და სწორედ ასეთ შემოწმებებს, როცა ისინი არ არის, სკანერი ვერ ხედავს.

რას გავაკეთებდი

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

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

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

შეკვეთის სტატუსებსა და მათ შორის გადასვლებს წესებად აღვწერდი: რომელი მდგომარეობიდან რომელში შეიძლება გადასვლა და რომელი შემოწმების შემდეგ.

ლოგებს IP-ისა და ანგარიშის მიხედვით ვნახავდი, როგორც Shopify გვირჩევს.

შემოწმებებზე, სტატუსებსა და უფლებებზე: სტატია ბიზნეს-ლოგიკა: წესები, სტატუსები და უფლებები. მიმართულებები: ბიზნესთან დაკავშირებული კლიენტის პროდუქტი და API-ინტეგრაციები მონაცემების გადაცემის გასაგები წესებით. ამ ტექსტის სისტემები აღწერილია ქეისებში გაქირავება სამხრეთ აფრიკაში და „ყავა ერთად“. იმავე თემაზე: შესვლა კლიენტის კაბინეტში: passkeys, SSO და ბმული პაროლის გარეშე, მაღაზიები AI-აგენტებისთვის ვიტრინებს ამზადებენ და zero trust 30-კაციანი კომპანიისთვის; ადრე ვწერდი კალათაზე გადახდამდე და ვებჰუკების უსაფრთხოებაზე. თუ თქვენს შეკვეთების სისტემაში მისამართის ზოლში ID ჩანს და თანხას კლიენტი აგზავნის, მომიყევით, როგორ არის ის მოწყობილი, და გეტყვით, რა შევამოწმოთ პირველ რიგში. ამოცანის განხილვა.