MCS ღრუბლოვანი პლატფორმის უსაფრთხოების აუდიტი

SkyShip Dusk SeerLight-ის მიერ

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

სტატია ეხება გარე ექსპერტების ამ ყველაზე მარტივ შეხედულებას, რომლებიც დაეხმარნენ Mail.ru Cloud Solutions (MCS) გუნდს ღრუბლოვანი სერვისის გამოცდაში და იმის შესახებ, თუ რა აღმოაჩინეს. როგორც „გარე ძალა“, MCS-მა აირჩია ციფრული უსაფრთხოების კომპანია, რომელიც ცნობილია თავისი მაღალი გამოცდილებით ინფორმაციული უსაფრთხოების წრეებში. და ამ სტატიაში ჩვენ გავაანალიზებთ რამდენიმე საინტერესო დაუცველობას, რომელიც აღმოჩენილია გარე აუდიტის ფარგლებში - ისე, რომ თავიდან აიცილოთ იგივე საკომისიო, როდესაც შექმნით საკუთარ ღრუბლოვან სერვისს.

Описание продукта

Mail.ru Cloud Solutions (MCS) არის პლატფორმა ღრუბელში ვირტუალური ინფრასტრუქტურის შესაქმნელად. მასში შედის IaaS, PaaS და მზა აპლიკაციის სურათების ბაზარი დეველოპერებისთვის. MCS არქიტექტურის გათვალისწინებით, საჭირო იყო პროდუქტის უსაფრთხოების შემოწმება შემდეგ სფეროებში:

• ვირტუალიზაციის გარემოს ინფრასტრუქტურის დაცვა: ჰიპერვიზორები, მარშრუტიზაცია, ფაირვოლლები;
• მომხმარებელთა ვირტუალური ინფრასტრუქტურის დაცვა: ერთმანეთისგან იზოლაცია, მათ შორის ქსელი, კერძო ქსელები SDN-ში;
• OpenStack და მისი ღია კომპონენტები;
• ჩვენივე დიზაინის S3;
• IAM: მრავალბინიანი პროექტები მისაბაძი მაგალითით;
• ხედვა (კომპიუტერული ხედვა): API და დაუცველობა სურათებთან მუშაობისას;
• ვებ ინტერფეისი და კლასიკური ვებ შეტევები;
• PaaS კომპონენტების დაუცველობა;
• ყველა კომპონენტის API.

ალბათ ეს არის ყველაფერი, რაც აუცილებელია შემდგომი ისტორიისთვის.

რა სახის სამუშაოები ჩატარდა და რატომ იყო საჭირო?

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

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

1. სერვისში ავთენტიფიკაციის ანალიზი. ამ კომპონენტის დაუცველობა დაგვეხმარება დაუყოვნებლივ მოხვდეთ სხვა ადამიანების ანგარიშებში.
2. როლური მოდელის შესწავლა და წვდომის კონტროლი სხვადასხვა ანგარიშებს შორის. თავდამსხმელისთვის სხვის ვირტუალურ მანქანაზე წვდომის შესაძლებლობა სასურველი მიზანია.
3. კლიენტის მხრიდან დაუცველობა. XSS/CSRF/CRLF/ა.შ. შესაძლებელია თუ არა სხვა მომხმარებელზე თავდასხმა მავნე ბმულების საშუალებით?
4. სერვერის დაუცველობა: RCE და ყველა სახის ინექცია (SQL/XXE/SSRF და ასე შემდეგ). სერვერის დაუცველობა ზოგადად უფრო რთულია, მაგრამ ისინი იწვევს მრავალი მომხმარებლის კომპრომისს ერთდროულად.
5. მომხმარებლის სეგმენტის იზოლაციის ანალიზი ქსელის დონეზე. თავდამსხმელისთვის, იზოლაციის ნაკლებობა მნიშვნელოვნად ზრდის თავდასხმის ზედაპირს სხვა მომხმარებლების წინააღმდეგ.
6. ბიზნეს ლოგიკის ანალიზი. შესაძლებელია თუ არა ბიზნესის მოტყუება და ვირტუალური მანქანების უფასოდ შექმნა?

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

აღმოჩენილი ხარვეზები

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

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

IDOR

IDOR (Insecure Direct Object Reference) დაუცველობა არის ერთ-ერთი ყველაზე გავრცელებული დაუცველობა ბიზნეს ლოგიკაში, რომელიც საშუალებას აძლევს ამა თუ იმ ობიექტებს მიიღონ წვდომა იმ ობიექტებზე, რომლებზეც წვდომა რეალურად არ არის დაშვებული. IDOR დაუცველობა ქმნის შესაძლებლობას მიიღოთ ინფორმაცია მომხმარებლის შესახებ კრიტიკულობის სხვადასხვა ხარისხით.

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

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

სერვერის მხრიდან მოთხოვნის გაყალბება (SSRF)

OpenSource-ის პროდუქტებზე კარგი ის არის, რომ მათ აქვთ ფორუმების დიდი რაოდენობა, წარმოქმნილი პრობლემების დეტალური ტექნიკური აღწერილობით და, თუ გაგიმართლათ, გადაწყვეტის აღწერა. მაგრამ ამ მონეტას აქვს მეორე მხარე: ცნობილი დაუცველობა ასევე დეტალურად არის აღწერილი. მაგალითად, OpenStack ფორუმზე არის დაუცველობის მშვენიერი აღწერა [XSS] и [SSRF], რომლის გამოსწორებას რატომღაც არავინ ჩქარობს.

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

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

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

SSRF დაუცველობა უკვე დიდი ხანია ცნობილია OpenStack-ში, რომელიც ბუნებით არის „ბრმა“: როდესაც თქვენ დაუკავშირდებით სერვერს, მისგან პასუხს არ იღებთ, მაგრამ იღებთ სხვადასხვა სახის შეცდომებს/დაყოვნებას, მოთხოვნის შედეგიდან გამომდინარე. . ამის საფუძველზე შეგიძლიათ შეასრულოთ პორტის სკანირება ჰოსტებზე შიდა ქსელში, ყველა შემდგომი შედეგით, რომელიც არ უნდა იყოს შეფასებული. მაგალითად, პროდუქტს შეიძლება ჰქონდეს back-office API, რომელიც ხელმისაწვდომია მხოლოდ კორპორატიული ქსელიდან. დოკუმენტაციით (არ დაივიწყოთ ინსაიდერების შესახებ), თავდამსხმელს შეუძლია გამოიყენოს SSRF შიდა მეთოდებზე წვდომისთვის. მაგალითად, თუ როგორმე შეძელით სასარგებლო URL-ების მიახლოებითი ჩამონათვალის მიღება, მაშინ SSRF-ის გამოყენებით შეგიძლიათ გაეცნოთ მათ და შეასრულოთ მოთხოვნა - შედარებით რომ ვთქვათ, გადარიცხოთ ფული ანგარიშიდან ანგარიშზე ან შეცვალოთ ლიმიტები.

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

ხოლო ეს საჯაროდ ხელმისაწვდომი ანგარიში HackerOne სერვისიდან (h1), აღარ ბრმა SSRF-ის ექსპლუატაცია მაგალითების მეტამონაცემების წაკითხვის შესაძლებლობით იწვევს Root წვდომას მთელ Shopify ინფრასტრუქტურაზე.

MCS-ში, SSRF დაუცველობა აღმოაჩინეს ორ ადგილას მსგავსი ფუნქციონირებით, მაგრამ მათი გამოყენება თითქმის შეუძლებელი იყო firewall-ისა და სხვა დაცვის გამო. ასეა თუ ისე, MCS-ის გუნდმა მაინც მოაგვარა ეს პრობლემა, საზოგადოების მოლოდინის გარეშე.

XSS ჭურვების ჩატვირთვის ნაცვლად

ასობით დაწერილი კვლევის მიუხედავად, ყოველწლიურად XSS (სივრცის სკრიპტირება) თავდასხმა მაინც ყველაზე მეტია ხშირად გვხვდება ვებ დაუცველობა (ან შეტევა?).

ფაილების ატვირთვა არის ნებისმიერი უსაფრთხოების მკვლევარის საყვარელი ადგილი. ხშირად ირკვევა, რომ თქვენ შეგიძლიათ ჩატვირთოთ თვითნებური სკრიპტი (asp/jsp/php) და შეასრულოთ OS ბრძანებები, პენტესტერების ტერმინოლოგიაში - "load shell". მაგრამ ასეთი დაუცველობის პოპულარობა მუშაობს ორივე მიმართულებით: მათ ახსოვთ და მათ წინააღმდეგ მუშავდება საშუალებები, ასე რომ, ბოლო დროს "ჭურვის ჩატვირთვის" ალბათობა ნულისკენ მიისწრაფვის.

შემტევ გუნდს (ციფრული უსაფრთხოების წარმომადგენლობით) გაუმართლა. OK, სერვერის მხარეს MCS-ში შემოწმდა გადმოწერილი ფაილების შინაარსი, დაშვებული იყო მხოლოდ სურათები. მაგრამ SVG ასევე სურათია. როგორ შეიძლება SVG სურათები იყოს საშიში? იმიტომ, რომ მათში შეგიძლიათ JavaScript სნიპეტების ჩასმა!

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

XSS შეტევის მაგალითი ფიშინგში შესვლის ფორმაზე

XSS შეტევის ექსპლუატაციის მაგალითები:

• რატომ სცადეთ სესიის მოპარვა (განსაკუთრებით მას შემდეგ, რაც ახლა ყველგან არის მხოლოდ HTTP-მხოლოდ ქუქიები, რომლებიც დაცულია ქურდობისაგან js სკრიპტების გამოყენებით), თუ ჩატვირთულ სკრიპტს შეუძლია დაუყოვნებლივ წვდომა რესურსის API-ზე? ამ შემთხვევაში, payload-ს შეუძლია გამოიყენოს XHR მოთხოვნები სერვერის კონფიგურაციის შესაცვლელად, მაგალითად, დაამატოთ თავდამსხმელის საჯარო SSH გასაღები და მოიპოვოს SSH წვდომა სერვერზე.
• თუ CSP პოლიტიკა (შინაარსის დაცვის პოლიტიკა) კრძალავს JavaScript-ის ინექციას, თავდამსხმელს შეუძლია მის გარეშე გაუძლოს. სუფთა HTML-ის გამოყენებით შექმენით საიტის ყალბი შესვლის ფორმა და მოიპარეთ ადმინისტრატორის პაროლი ამ მოწინავე ფიშინგის საშუალებით: მომხმარებლის ფიშინგის გვერდი მთავრდება იმავე URL-ზე და მომხმარებლისთვის უფრო რთულია მისი ამოცნობა.
• საბოლოოდ, თავდამსხმელს შეუძლია მოაწყოს კლიენტის DoS — დააყენეთ 4 კბაიტზე მეტი ქუქიები. მომხმარებელს მხოლოდ ერთხელ სჭირდება ბმულის გახსნა და მთელი საიტი მიუწვდომელი ხდება მანამ, სანამ მომხმარებელი არ იფიქრებს ბრაუზერის კონკრეტულად გაწმენდაზე: უმეტეს შემთხვევაში, ვებ სერვერი უარს იტყვის ასეთი კლიენტის მიღებაზე.

მოდით შევხედოთ კიდევ ერთი აღმოჩენილი XSS-ის მაგალითს, ამჯერად უფრო ჭკვიანური ექსპლოიტით. MCS სერვისი საშუალებას გაძლევთ დააკავშიროთ firewall პარამეტრები ჯგუფებად. ჯგუფის სახელი იყო XSS-ის აღმოჩენის ადგილი. მისი თავისებურება ის იყო, რომ ვექტორი დაუყოვნებლივ არ ამოქმედდა, არა წესების სიის ნახვისას, არამედ ჯგუფის წაშლისას:

ანუ, სცენარი შემდეგი აღმოჩნდა: თავდამსხმელი ქმნის Firewall-ის წესს სახელში „ჩატვირთვით“, ადმინისტრატორი ამას ცოტა ხნის შემდეგ ამჩნევს და იწყებს წაშლის პროცესს. და სწორედ აქ მუშაობს მავნე JS.

MCS დეველოპერებისთვის, ჩამოტვირთულ SVG სურათებში XSS-ისგან დასაცავად (თუ მათი მიტოვება შეუძლებელია), ციფრული უსაფრთხოების გუნდი გირჩევთ:

• განათავსეთ მომხმარებლების მიერ ატვირთული ფაილები ცალკე დომენზე, რომელსაც საერთო არაფერი აქვს „ქუქი-ფაილებთან“. სკრიპტი შესრულდება სხვა დომენის კონტექსტში და არ შეუქმნის საფრთხეს MCS-ს.
• სერვერის HTTP პასუხში გაგზავნეთ სათაური „Content-disposition: attachment“. შემდეგ ფაილები ჩამოიტვირთება ბრაუზერის მიერ და არ შესრულდება.

გარდა ამისა, ახლა დეველოპერებისთვის ხელმისაწვდომია მრავალი გზა XSS-ის ექსპლუატაციის რისკების შესამცირებლად:

• „მხოლოდ HTTP“ დროშის გამოყენებით, შეგიძლიათ სესიის „ქუქიების“ სათაურები მიუწვდომელი გახადოთ მავნე JavaScript-ისთვის;
• სწორად განხორციელებული CSP პოლიტიკა გაცილებით გაურთულებს თავდამსხმელს XSS-ის ექსპლუატაციას;
• თანამედროვე შაბლონების ძრავები, როგორიცაა Angular ან React, ავტომატურად ასუფთავებენ მომხმარებლის მონაცემებს მომხმარებლის ბრაუზერში გაგზავნამდე.

ორფაქტორიანი ავთენტიფიკაციის დაუცველობა

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

მაგრამ ავთენტიფიკაციის მეორე ფაქტორის გამოყენება ყოველთვის უზრუნველყოფს ანგარიშის უსაფრთხოებას? არსებობს უსაფრთხოების შემდეგი საკითხები 2FA-ს განხორციელებისას:

• OTP კოდის უხეში ძალის ძიება (ერთჯერადი კოდები). ოპერაციის სიმარტივის მიუხედავად, შეცდომებს, როგორიცაა OTP უხეში ძალისგან დაცვის ნაკლებობა, ასევე ხვდება მსხვილი კომპანიები: სქელი საქმე, ფეისბუქის საქმე.
• სუსტი გენერირების ალგორითმი, მაგალითად შემდეგი კოდის პროგნოზირების შესაძლებლობა.
• ლოგიკური შეცდომები, როგორიცაა თქვენი ტელეფონზე სხვისი OTP-ის მოთხოვნის შესაძლებლობა იყო Shopify-დან.

MCS-ის შემთხვევაში, 2FA დანერგილია Google Authenticator-ზე და Duo. თავად პროტოკოლი უკვე გამოცდილია დროში, მაგრამ აპლიკაციის მხარეს კოდის გადამოწმების განხორციელება შესამოწმებელია.

MCS 2FA გამოიყენება რამდენიმე ადგილას:

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

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

OTP-ის არჩევის პროცესი 2FA-ს გამორთვაზე "Burp: Intruder" ინსტრუმენტის გამოყენებით

შედეგი

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

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

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

• რეგულარულად ატარებს აუდიტს გარე კომპანიების მიერ;
• მხარი დაუჭიროს და განავითაროს მონაწილეობა Mail.ru Group Bug Bounty პროგრამაში;
• ჩაერთონ უსაფრთხოებაში. 🙂

წყარო: www.habr.com