ვებსაიტების უსაფრთხოების სასიკვდილო ცოდვები: რაც ვისწავლეთ დაუცველობის სკანერის სტატისტიკიდან წლის განმავლობაში

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

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

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

მაგრამ უკრიტიკო არ ნიშნავს უვნებელს. მათ ასევე შეუძლიათ სერიოზული ზიანი მიაყენონ. 

ყველაზე "არაკრიტიკული" დაუცველობა

1. შერეული შინაარსის დაუცველობა.

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

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

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

   
   
   РуРРРР РвРРїР ° СЃРЅРР: თავდამსხმელები იყენებენ დაუცველ პროტოკოლს მომხმარებლის ინფორმაციის ჩასაჭრელად, სკრიპტების შესაცვლელად და საიტზე მისი სახელით მოთხოვნის გასაგზავნად. მაშინაც კი, თუ საიტის ვიზიტორმა არ შეიყვანა მონაცემები, ეს არ იცავს მას ფიშინგი - კონფიდენციალური ინფორმაციის მოპოვება თაღლითური მეთოდებით. მაგალითად, სკრიპტის გამოყენებით, შეგიძლიათ მომხმარებლის გადამისამართება სახიფათო საიტზე, რომელიც მომხმარებლისთვის ნაცნობი გახდა. ზოგიერთ შემთხვევაში, მავნე საიტი ორიგინალზე უკეთ გამოიყურება და მომხმარებელს შეუძლია თავად შეავსოს ფორმა და წარადგინოს კონფიდენციალური მონაცემები. 

   რა უნდა ახსოვდეს ვებ დეველოპერს: მაშინაც კი, თუ საიტის ადმინისტრატორმა დააინსტალირა და დააკონფიგურირა SSL/TLS სერთიფიკატი, დაუცველობა შეიძლება წარმოიშვას ადამიანის შეცდომის გამო. მაგალითად, თუ ერთ-ერთ გვერდზე თქვენ განათავსებთ არა შედარებით ბმულს, არამედ აბსოლუტურ ბმულს http-დან და გარდა ამისა, თქვენ არ დააყენეთ გადამისამართებები http-დან https-ზე. 

   თქვენ შეგიძლიათ იპოვოთ შერეული შინაარსი საიტზე ბრაუზერის გამოყენებით: მოძებნეთ გვერდის საწყისი კოდი, წაიკითხეთ შეტყობინებები დეველოპერის კონსოლში. თუმცა, დეველოპერს მოუწევს კოდის დალაგება დიდი ხნის განმავლობაში და მოსაბეზრებლად. თქვენ შეგიძლიათ დააჩქაროთ პროცესი ავტომატური ანალიზის ხელსაწყოებით, მაგალითად: SSL შემოწმება, უფასო Lighthouse პროგრამული უზრუნველყოფა ან ფასიანი პროგრამული უზრუნველყოფა Screaming Frog SEO Spider.

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

2. ქუქი ფაილები "HTTPOnly" და "უსაფრთხო" დროშების გარეშე.

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

   ორივე ატრიბუტი მითითებულია ქუქიების თვისებებში:

   Set-Cookie: Secure; HttpOnly

   РуРРРР РвРРїР ° СЃРЅРР: თუ საიტის შემქმნელმა არ დააკონკრეტა ეს ატრიბუტები, თავდამსხმელს შეუძლია მომხმარებლის ინფორმაციის ჩაჭრა ქუქიიდან და გამოიყენოს იგი. თუ ქუქი-ფაილები გამოიყენება ავთენტიფიკაციისა და ავტორიზაციისთვის, ის შეძლებს მომხმარებლის სესიის გატაცებას და საიტზე მისი სახელით მოქმედებების შესრულებას. 

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

   ამ შემთხვევაში, „HTTPOnly“ ატრიბუტი გახდის ქუქი-ფაილებს უხილავს თქვენი JavaScript-ისთვის.  

3. გზაზე დაფუძნებული დაუცველობა.

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

   РуРРРР РвРРїР ° СЃРЅРР: თუ ფაილური სისტემა „გაჩერდება“, თავდამსხმელს შეუძლია მოხვდეს ოპერაციული სისტემის ინტერფეისში და შეეცადოს იპოვოთ საქაღალდეები პაროლებით, თუ ისინი ინახება წმინდა ტექსტში (ნუ გააკეთებთ ამას!). ან შეგიძლიათ მოიპაროთ პაროლის ჰეშები და პაროლი უხეში ძალით, ასევე სცადოთ სისტემაში პრივილეგიების ამაღლება და ინფრასტრუქტურის სიღრმეში გადასვლა.  

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

4. სენსიტიური მონაცემების შეყვანის ფორმები ჩართულია ავტომატური შევსებით.

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

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

   РуРРРР РвРРїР ° СЃРЅРР: თუ მომხმარებლის ბრაუზერი ინახავს სენსიტიურ ინფორმაციას, თავდამსხმელს შეუძლია მოგვიანებით გადაჭრას იგი, მაგალითად, ფიშინგის საშუალებით. არსებითად, ვებ დეველოპერი, რომელმაც დაივიწყა ეს ნიუანსი, აყენებს თავის მომხმარებლებს. 

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

   ბრაუზერების უმეტესობისთვის შეგიძლიათ გამორთოთ ავტომატური დასრულება autocompete=off“ ატრიბუტით, მაგალითად:

    <body>
       <form action="/ka/form/submit" method="get" autocomplete="off">
         <div>
           <input type="text" placeholder="First Name">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Credit card number">
         </div>
         <input type="submit">
       </form>
     </body>

   მაგრამ ეს არ იმუშავებს Chrome-ისთვის. ეს არის გვერდის ავლით JavaScript-ის გამოყენებით, შეგიძლიათ იპოვოთ რეცეპტის ვარიანტი აქ. 

5. X-Frame-Options სათაური არ არის მითითებული საიტის კოდში. 

   ეს სათაური გავლენას ახდენს ჩარჩოზე, iframe-ზე, ჩაშენებაზე ან ობიექტის ტეგებზე. მისი დახმარებით თქვენ შეგიძლიათ მთლიანად აკრძალოთ თქვენი საიტის ჩარჩოში ჩასმა. ამისათვის თქვენ უნდა მიუთითოთ მნიშვნელობა X-Frame-Options: deny. ან შეგიძლიათ მიუთითოთ X-Frame-Options: sameorigin, შემდეგ iframe-ში ჩაშენება ხელმისაწვდომი იქნება მხოლოდ თქვენს დომენზე.

   РуРРРР РвРРїР ° СЃРЅРР: ასეთი სათაურის არარსებობა შეიძლება გამოყენებულ იქნას მავნე საიტებზე clickjacking. ამ შეტევისთვის თავდამსხმელი ქმნის გამჭვირვალე ჩარჩოს ღილაკების თავზე და ატყუებს მომხმარებელს. მაგალითად: თაღლითები აყალიბებენ სოციალური ქსელის გვერდებს ვებსაიტზე. მომხმარებელი ფიქრობს, რომ ამ საიტზე აჭერს ღილაკს. სამაგიეროდ, დაწკაპუნება იკვეთება და მომხმარებლის მოთხოვნა იგზავნება სოციალურ ქსელში, სადაც არის აქტიური სესია. ასე აგზავნიან თავდამსხმელები მომხმარებლის სახელით სპამს ან იძენენ აბონენტებს და მოწონებებს. 

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

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

   X-Frame-Options სათაურის უარყოფა და იგივე წარმოშობის მნიშვნელობები ხელს უშლის Yandex ვებ მაყურებლის მუშაობას. ვებ მაყურებლისთვის iframes-ის გამოყენების დასაშვებად, თქვენ უნდა დაწეროთ ცალკე წესი პარამეტრებში. მაგალითად, nginx-ისთვის შეგიძლიათ მისი კონფიგურაცია ასე:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. PRSSI (Path-relative stylesheet import) დაუცველობა.  

   ეს არის დაუცველობა საიტის სტილში. ეს ჩნდება, თუ შედარებითი ბმულები, როგორიცაა href="/ka/somefolder/styles.css/" გამოიყენება სტილის ფაილებზე წვდომისთვის. თავდამსხმელი ისარგებლებს ამით, თუ იპოვის მომხმარებლის მავნე გვერდზე გადამისამართების გზას. გვერდი ჩასვამს შესაბამის ბმულს მის url-ში და მოახდენს სტილის ზარის სიმულაციას. თქვენ მიიღებთ მოთხოვნას, როგორიცაა badsite.ru/…/somefolder/styles.css/, რომელსაც შეუძლია შეასრულოს მავნე მოქმედებები სტილის საფარქვეშ. 

   РуРРРР РвРРїР ° СЃРЅРР: თაღლითს შეუძლია გამოიყენოს ეს დაუცველობა, თუკი აღმოაჩენს უსაფრთხოების სხვა ხვრელს. შედეგად, შესაძლებელია მომხმარებლის მონაცემების მოპარვა ქუქიებიდან ან ტოკენებიდან.

   რა უნდა ახსოვდეს ვებ დეველოპერს: დააყენეთ X-Content-Type-Options სათაური: nosniff. ამ შემთხვევაში, ბრაუზერი შეამოწმებს კონტენტის ტიპს სტილისთვის. თუ ტიპი არის ტექსტის/css-ის გარდა, ბრაუზერი დაბლოკავს მოთხოვნას.

კრიტიკული დაუცველობა

1. პაროლის ველის მქონე გვერდი გადაიცემა სერვერიდან დაუცველი არხით (HTML ფორმა, რომელიც შეიცავს პაროლის ველ(ებ)ს, ემსახურება HTTP-ზე).

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

   РуРРРР РвРРїР ° СЃРЅРР: თაღლითს შეეძლება შეცვალოს გვერდი და გაუგზავნოს მომხმარებელს ფორმა კონფიდენციალური მონაცემებისთვის, რომელიც გადავა თავდამსხმელის სერვერზე. 

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

2. ფორმის გაგზავნა შესვლისა და პაროლით დაუცველ არხზე (შესვლის ფორმა არ არის გაგზავნილი HTTPS-ით).

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

   РуРРРР РвРРїР ° СЃРЅРР: წინა შემთხვევისგან განსხვავებით, ეს უკვე კრიტიკული დაუცველობაა. სენსიტიური მონაცემების გადაჭრა უფრო ადვილია, რადგან ამისთვის კოდის დაწერაც კი არ გჭირდებათ. 

3. JavaScript ბიბლიოთეკების გამოყენება ცნობილი დაუცველობით.

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

   РуРРРР РвРРїР ° СЃРЅРР: არსებობს ექსპლოიტები ცნობილი დაუცველობისთვის, მაგალითად:

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

4. ჯვარედინი სკრიპტირება (XSS). 
   Cross-Site Scripting (XSS), ან cross-site სკრიპტირება, არის თავდასხმა ვებ აპლიკაციაზე, რომელიც იწვევს მონაცემთა ბაზაში მავნე პროგრამის შეტანას. თუ Qualys აღმოაჩენს ასეთ დაუცველობას, ეს ნიშნავს, რომ პოტენციურ თავდამსხმელს შეუძლია ან უკვე შემოიტანა საკუთარი js სკრიპტი საიტის კოდში მავნე ქმედებების შესასრულებლად.

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

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

   <script>/*+что+то+плохое+*/</script> 

   შემდეგ კლიენტის სახელით გაიგზავნება მავნე მოთხოვნა.

   XSS-ის თვალსაჩინო მაგალითი: js sniffers, რომლებიც ახდენენ გვერდების სიმულაციას CVC-ის შესაყვანად, ბარათის ვადის გასვლის თარიღს და ა.შ. 

   რა უნდა ახსოვდეს ვებ დეველოპერს: Content-Security-Policy სათაურში გამოიყენეთ script-src ატრიბუტი, რათა აიძულოთ კლიენტის ბრაუზერი ჩამოტვირთოს და შეასრულოს კოდი მხოლოდ სანდო წყაროდან. მაგალითად, script-src 'self' ათავსებს ყველა სკრიპტს მხოლოდ ჩვენი საიტიდან. 
   საუკეთესო პრაქტიკა არის Inline კოდი: დაუშვით მხოლოდ inline javascript სახიფათო-inline მნიშვნელობის გამოყენებით. ეს მნიშვნელობა საშუალებას იძლევა გამოიყენოს inline js/css, მაგრამ არ კრძალავს js ფაილების ჩართვას. script-src 'self'-თან ერთად ჩვენ გამოვრიცხავთ გარე სკრიპტების შესრულებას.

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

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

   РуРРРР РвРРїР ° СЃРЅРР: თუ თავდამსხმელი შეიყვანს SQL მოთხოვნას ამ ფორმაში, მას შეუძლია დააზიანოს მონაცემთა ბაზა ან გამოავლინოს კონფიდენციალური ინფორმაცია. 

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

   კლიენტის მხარეს ჩაწერეთ ველის დადასტურება JavaScript-ის გამოყენებით. 

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

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

   ურთიერთქმედება ხდება მაშინ, როდესაც ვიღებთ რაიმე ინფორმაციას: მოთხოვნა id-ით (id-ის შეცვლა), ახალი მომხმარებლის შექმნა, ახალი კომენტარი ან ახალი ჩანაწერები მონაცემთა ბაზაში. ეს არის სადაც SQL ინექციები შეიძლება მოხდეს. მაშინაც კი, თუ ჩვენ წავშლით ჩანაწერს მონაცემთა ბაზიდან, SQL ინექცია შესაძლებელია.

ზოგადი რეკომენდაციები

ნუ გამოიგონებთ ბორბალს - გამოიყენეთ დადასტურებული ჩარჩოები. ზოგადად, პოპულარული ჩარჩოები უფრო უსაფრთხოა. .NET-ისთვის - ASP.NET MVC და ASP.NET Core, Python-ისთვის - Django ან Flask, Ruby-სთვის - Ruby on Rails, PHP-სთვის - Symfony, Laravel, Yii, JavaScript-ისთვის - Node.JS-Express.js, Java-სთვის - საგაზაფხულო MVC.

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

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

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

დაიცავით თქვენი ვებ აპლიკაცია ვებ აპლიკაციის Firewall და დაუცველობის სკანერიდან მოხსენებების ინტეგრირება მასთან. მაგალითად, DataLine იყენებს Qualys-ს და FortiWeb-ს, როგორც სერვისების პაკეტს.

წყარო: www.habr.com