და არის ყოვლისმომცველი ჯვარედინი სკრიპტირების გაკვეთილი.
ნაწილი პირველი: მიმოხილვა
რა არის XSS?
საიტის სკრიპტირება ( ინგლისური ჯვარედინი საიტის სკრიპტირება) არის კოდის ინექციის შეტევა, რომელიც თავდამსხმელს საშუალებას აძლევს შეასრულოს მავნე JavaScript სხვა მომხმარებლის ბრაუზერში.
თავდამსხმელი პირდაპირ არ ესხმის თავს მსხვერპლს. ამის ნაცვლად, ის იყენებს დაუცველობას ვებსაიტზე, რომელსაც მსხვერპლი სტუმრობს და აყენებს მავნე JavaScript კოდს. მსხვერპლის ბრაუზერი აჩვენებს მავნე JavaScript-ს, როგორც ვებსაიტის ლეგიტიმურ ნაწილს და თავად ვებსაიტი მოქმედებს როგორც თავდამსხმელის უშუალო თანამონაწილე.
მავნე JavaScript კოდის ინექცია
თავდამსხმელისთვის მავნე JavaScript-ის გაშვების ერთადერთი გზა მსხვერპლის ბრაუზერში არის მისი შეყვანა ერთ-ერთ გვერდზე, რომელსაც მსხვერპლი ჩამოტვირთავს ვებსაიტიდან. ეს შესაძლებელია, თუ ვებსაიტი მომხმარებლებს საშუალებას აძლევს შეიყვანონ მონაცემები მის გვერდებზე და თავდამსხმელს შეუძლია შეიყვანოს ხაზი, რომელიც აღმოჩენილი იქნება, როგორც კოდის ნაწილი მსხვერპლის ბრაუზერში.
ქვემოთ მოყვანილი მაგალითი გვიჩვენებს სერვერის მხარის მარტივ სკრიპტს, რომელიც გამოიყენება საიტზე ბოლო კომენტარის საჩვენებლად:
ბეჭდვა" "
ბეჭდვა "ბოლო კომენტარი:"
მონაცემთა ბაზის დაბეჭდვა. უახლესი კომენტარი
ბეჭდვა""
სკრიპტი ვარაუდობს, რომ კომენტარი მხოლოდ ტექსტისგან შედგება. თუმცა, რადგან მომხმარებლის პირდაპირი შეყვანა ჩართულია, თავდამსხმელს შეუძლია დატოვოს ეს კომენტარი: "". ნებისმიერი მომხმარებელი, რომელიც ეწვევა გვერდს, ახლა მიიღებს შემდეგ პასუხს:
ბოლო კომენტარი:
როდესაც მომხმარებლის ბრაუზერი ჩატვირთავს გვერდს, ის შეასრულებს ყველაფერს, მათ შორის JavaScript-ს, რომელიც შეიცავს ტეგებს. ... ეს მიუთითებს, რომ თავდამსხმელის უბრალო სკრიპტის ინექციური არსებობა პრობლემაა, მიუხედავად იმისა, თუ რომელი კონკრეტული სკრიპტის კოდი სრულდება რეალურად.
ნაწილი მეორე: XSS შეტევა
XSS შეტევის მონაწილეები
სანამ დეტალურად აღვწერთ, თუ როგორ მუშაობს XSS შეტევა, უნდა განვსაზღვროთ მოქმედი პირები, რომლებიც მონაწილეობენ XSS შეტევაში. ზოგადად, XSS შეტევაში სამი მონაწილეა: ვებ საიტი, მსხვერპლი, და კრეკერი.
- ვებ საიტიაწარმოებს HTML გვერდებს მომხმარებლებისთვის, რომლებიც მათ ითხოვენ. ჩვენს მაგალითებში ის მდებარეობს http: // ვებსაიტზე /.
- ვებსაიტის მონაცემთა ბაზაარის მონაცემთა ბაზა, რომელიც ინახავს მომხმარებლის მიერ საიტის გვერდებზე შეყვანილ მონაცემებს.
- მსხვერპლიარის ვებსაიტის რეგულარული მომხმარებელი, რომელიც ითხოვს მისგან გვერდებს მისი ბრაუზერის გამოყენებით.
- თავდასხმაარის თავდამსხმელი, რომელიც აპირებს მსხვერპლზე თავდასხმას საიტზე XSS დაუცველობის გამოყენებით.
- კრეკერის სერვერიარის ვებ სერვერი თავდამსხმელის კონტროლის ქვეშ და ერთადერთი მიზნით, მოიპაროს მსხვერპლის კონფიდენციალური ინფორმაცია. ჩვენს მაგალითებში ის მდებარეობს http: // თავდამსხმელი /.
თავდასხმის სცენარის მაგალითი
ეს სკრიპტი შექმნის HTTP მოთხოვნას სხვა URL-ზე, რომელიც გადამისამართებს მომხმარებლის ბრაუზერს თავდამსხმელის სერვერზე. URL მოიცავს მსხვერპლის ქუქიებს, როგორც მოთხოვნის პარამეტრს, როდესაც HTTP მოთხოვნა შემოდის თავდამსხმელის სერვერზე, თავდამსხმელს შეუძლია ამ ქუქიების ამოღება მოთხოვნიდან. მას შემდეგ, რაც თავდამსხმელი მიიღებს ქუქი-ფაილებს, მას შეუძლია გამოიყენოს ისინი მსხვერპლის განსახიერების მიზნით და განახორციელოს შემდგომი თავდასხმა.
ამიერიდან ზემოაღნიშნული HTML კოდი გამოიძახება მავნე სტრიქონიან მავნე სკრიპტი... მნიშვნელოვანია გვესმოდეს, რომ თავად სტრიქონი მავნეა მხოლოდ იმ შემთხვევაში, თუ ის საბოლოოდ დამუშავდება როგორც HTML მსხვერპლის ბრაუზერში, რაც შეიძლება მოხდეს მხოლოდ იმ შემთხვევაში, თუ ვებსაიტზე არის XSS დაუცველობა.
როგორ მუშაობს ეს მაგალითი თავდასხმა
ქვემოთ მოყვანილი დიაგრამა გვიჩვენებს თავდამსხმელის შეტევის მაგალითს:
- თავდამსხმელი იყენებს ვებსაიტის ერთ-ერთ ფორმას ვებსაიტის მონაცემთა ბაზაში მავნე სტრიქონის ჩასართავად.
- მსხვერპლი ითხოვს გვერდს ვებგვერდიდან.
- საიტი პასუხში შეიცავს მავნე სტრიქონს მონაცემთა ბაზიდან და უგზავნის მას მსხვერპლს.
- მსხვერპლის ბრაუზერი ამუშავებს მავნე სკრიპტს პასუხის შიგნით, აგზავნის მსხვერპლის ქუქი-ფაილს თავდამსხმელის სერვერზე.
XSS ტიპები
XSS შეტევის მიზანი ყოველთვის არის მავნე JavaScript სკრიპტის შესრულება მსხვერპლის ბრაუზერში. ამ მიზნის მისაღწევად რამდენიმე ფუნდამენტურად განსხვავებული გზა არსებობს. XSS შეტევები ხშირად იყოფა სამ ტიპად:
- შენახული (მუდმივი) XSSსადაც მავნე სტრიქონი სათავეს იღებს ვებსაიტის მონაცემთა ბაზიდან.
- ასახული (არასტაბილური) XSSსადაც მავნე სტრიქონი წარმოიქმნება მსხვერპლის თხოვნით.
- DOMs XSSსადაც დაუცველობა ხდება კლიენტის მხარის კოდში და არა სერვერის კოდში.
წინა მაგალითი გვიჩვენებს შენახულ XSS შეტევას. ჩვენ ახლა აღვწერთ XSS შეტევების ორ სხვა ტიპს: Reflected XSS და DOM XSS.
ასახული XSS
ასახული XSS შეტევის დროს, მავნე სტრიქონი არის მსხვერპლის მოთხოვნის ნაწილი ვებსაიტზე. საიტი იღებს და ათავსებს ამ მავნე სტრიქონს პასუხში, რომელსაც უგზავნის მომხმარებელს. ქვემოთ მოცემული დიაგრამა ასახავს ამ სცენარს:
- მსხვერპლს თავდამსხმელი ატყუებს, რათა URL-ის მოთხოვნა გამოაგზავნოს ვებსაიტზე.
- საიტი შეიცავს მავნე სტრიქონს მოთხოვნის URL-დან მსხვერპლის პასუხში.
- მსხვერპლის ბრაუზერი ახორციელებს პასუხში მოცემულ მავნე სკრიპტს, აგზავნის მსხვერპლის ქუქი-ფაილს თავდამსხმელის სერვერზე.
როგორ წარმატებით დავიცვათ თავი XSS შეტევებისგან?
ასახული XSS შეტევა შეიძლება უვნებელი ჩანდეს, რადგან ის მოითხოვს მსხვერპლის გაგზავნას მოთხოვნის გაგზავნას მათი სახელით, რომელიც შეიცავს მავნე სტრიქონს. ვინაიდან არავინ ნებაყოფლობით თავს დაესხმება თავს, როგორც ჩანს, შეტევის რეალურად განხორციელების გზა არ არსებობს.
როგორც ირკვევა, არსებობს მინიმუმ ორი საერთო გზა, რათა მსხვერპლმა განახორციელოს ასახული XSS შეტევა საკუთარ თავზე:
- თუ მომხმარებელი კონკრეტული პიროვნებაა, თავდამსხმელს შეუძლია გაუგზავნოს მავნე URL მსხვერპლს (მაგალითად, ელექტრონული ფოსტით ან მყისიერი მესინჯერით) და მოატყუოს ისინი, რომ გახსნას ბმული ვებსაიტის მოსანახულებლად.
- თუ სამიზნე არის მომხმარებელთა დიდი ჯგუფი, თავდამსხმელს შეუძლია განათავსოს ბმული მავნე URL-ზე (მაგალითად, საკუთარ ვებსაიტზე ან სოციალურ ქსელში) და დაელოდოს ვიზიტორების მიერ ბმულზე დაწკაპუნებას.
ორივე ეს მეთოდი მსგავსია და ორივე შეიძლება იყოს უფრო წარმატებული URL-ის შემოკლების სერვისების გამოყენებით, რათა დაფაროს მავნე სტრიქონი მომხმარებლებისგან, რომლებმაც შეიძლება მისი იდენტიფიცირება.
XSS DOM-ში
DOM XSS არის როგორც შენახული, ასევე ასახული XSS შეტევის ვარიანტი. ამ XSS შეტევისას, მავნე სტრიქონი არ მუშავდება მსხვერპლის ბრაუზერის მიერ, სანამ არ შესრულდება ვებსაიტის რეალური JavaScript. ქვემოთ მოცემული დიაგრამა ასახავს ამ სცენარს ასახული XSS შეტევისთვის:
- თავდამსხმელი ქმნის URL-ს, რომელიც შეიცავს მავნე სტრიქონს და უგზავნის მას მსხვერპლს.
- მსხვერპლს თავდამსხმელი ატყუებს, რათა URL-ის მოთხოვნა გამოაგზავნოს ვებსაიტზე.
- საიტი იღებს მოთხოვნას, მაგრამ პასუხში არ შეიცავს მავნე სტრიქონს.
- მსხვერპლის ბრაუზერი ახორციელებს პასუხში მოცემულ ლეგიტიმურ სკრიპტს, რის შედეგადაც მავნე სკრიპტი ჩადება გვერდზე.
- მსხვერპლის ბრაუზერი ახორციელებს გვერდზე ჩასმული მავნე სკრიპტს და აგზავნის მსხვერპლის ქუქი-ფაილს თავდამსხმელის სერვერზე.
რა განსხვავებაა XSS-ს შორის DOM-ში?
შენახული და ასახული XSS შეტევების წინა მაგალითებში, სერვერი აწვდის მავნე სკრიპტს გვერდზე, რომელიც შემდეგ გადაგზავნილია მსხვერპლის საპასუხოდ. როდესაც მსხვერპლის ბრაუზერი იღებს პასუხს, ის თვლის, რომ მავნე სკრიპტი არის გვერდის ლეგიტიმური შინაარსის ნაწილი და ავტომატურად ახორციელებს მას გვერდის ჩატვირთვის დროს, ისევე როგორც ნებისმიერი სხვა სკრიპტი.
DOM XSS თავდასხმის მაგალითში, მავნე სკრიპტი არ არის ჩასმული გვერდის ნაწილად; ერთადერთი სკრიპტი, რომელიც ავტომატურად სრულდება გვერდის ჩატვირთვის დროს, არის გვერდის ლეგიტიმური ნაწილი. პრობლემა ის არის, რომ ეს ლეგიტიმური სკრიპტი პირდაპირ იყენებს მომხმარებლის შეყვანას გვერდზე HTML-ის დასამატებლად. ვინაიდან მავნე სტრიქონი ჩასმულია გვერდზე innerHTML-ის გამოყენებით, ის ანალიზდება როგორც HTML, რაც იწვევს მავნე სკრიპტის შესრულებას.
ეს განსხვავება მცირეა, მაგრამ ძალიან მნიშვნელოვანია:
- ტრადიციულ XSS-ში მავნე JavaScript შესრულებულია გვერდის ჩატვირთვაზე, როგორც სერვერის მიერ გაგზავნილი HTML-ის ნაწილი.
- DOM-ში XSS-ის შემთხვევაში, მავნე JavaScript შესრულებულია გვერდის ჩატვირთვის შემდეგ, რაც იწვევს ამ ლეგიტიმურ JavaScript გვერდზე წვდომას მომხმარებლის შეყვანის (მავნე სტრიქონის შემცველი) სახიფათო გზით.
როგორ მუშაობს XSS DOM-ში?
წინა მაგალითში JavaScript არ არის საჭირო; სერვერს შეუძლია დამოუკიდებლად შექმნას მთელი HTML. სერვერის მხარის კოდი რომ თავისუფალი იყოს დაუცველებისგან, ვებსაიტი არ იქნებოდა დაუცველი XSS დაუცველობის მიმართ.
თუმცა, როგორც ვებ აპლიკაციები უფრო დახვეწილი ხდება, უფრო და უფრო მეტი HTML გვერდი იქმნება JavaScript-ის გამოყენებით კლიენტის მხარეს და არა სერვერზე. ნებისმიერ დროს, შინაარსი უნდა შეიცვალოს მთელი გვერდის განახლების გარეშე, ეს შესაძლებელია JavaScript-ის გამოყენებით. კერძოდ, ეს არის შემთხვევა, როდესაც გვერდი განახლდება AJAX მოთხოვნის შემდეგ.
ეს ნიშნავს, რომ XSS დაუცველობა შეიძლება იყოს წარმოდგენილი არა მხოლოდ თქვენი საიტის კოდის სერვერის მხარეს, არამედ თქვენი საიტის კლიენტის JavaScript-ის მხარესაც. ამიტომ, სერვერის მხარის სრულიად უსაფრთხო კოდის შემთხვევაშიც კი, კლიენტის კოდი შეიძლება მაინც არ იყოს უსაფრთხო, რომ შეიცავდეს მომხმარებლის შეყვანას, როდესაც DOM განახლდება გვერდის ჩატვირთვის შემდეგ. თუ ეს მოხდება, მაშინ კლიენტის მხარის კოდი დაუშვებს XSS შეტევას სერვერის მხარის კოდის ბრალის გარეშე.
DOM-ზე დაფუძნებული XSS შეიძლება არ იყოს ხილული სერვერისთვის
არსებობს DOM XSS შეტევის განსაკუთრებული შემთხვევა, როდესაც მავნე სტრიქონი არასოდეს იგზავნება ვებსაიტის სერვერზე: ეს ხდება მაშინ, როდესაც მავნე სტრიქონი შეიცავს URL-ის იდენტიფიკატორის ნაწილს (ყველაფერი # სიმბოლოს შემდეგ). ბრაუზერები არ აგზავნიან URL-ის ამ ნაწილს სერვერზე, ამიტომ ვებსაიტზე წვდომა შეუძლებელია სერვერის მხარის კოდით. თუმცა, კლიენტის მხარის კოდს აქვს მასზე წვდომა და, ამრიგად, შესაძლებელია XSS შეტევის განხორციელება არასაიმედო დამუშავების გზით.
ეს შემთხვევა არ შემოიფარგლება მხოლოდ ფრაგმენტის იდენტიფიკატორით. არის მომხმარებლის სხვა შეყვანა, რომელიც უხილავია სერვერისთვის, როგორიცაა ახალი HTML5 ფუნქციები, როგორიცაა LocalStorage და IndexedDB.
ნაწილი მესამე:
XSS-ის პრევენცია
XSS პრევენციის ტექნიკა
შეგახსენებთ, XSS არის კოდის ინექციის შეტევა: მომხმარებლის შეყვანა შეცდომით განიმარტება, როგორც მავნე კოდი. ამ ტიპის კოდის ინექციის თავიდან ასაცილებლად საჭიროა შეყვანის უსაფრთხო მართვა. ვებ დეველოპერისთვის არსებობს ორი ფუნდამენტურად განსხვავებული გზა შეყვანის უსაფრთხო დამუშავების შესასრულებლად:
- კოდირებაარის გზა, რომელიც საშუალებას აძლევს მომხმარებელს შეიყვანოს მონაცემები მხოლოდ მონაცემების სახით და არ აძლევს ბრაუზერს კოდის სახით დამუშავების საშუალებას.
- ვალიდაციაარის მომხმარებლის შეყვანის გაფილტვრის საშუალება ისე, რომ ბრაუზერი განიმარტოს მას, როგორც კოდს მავნე ბრძანებების გარეშე.
მიუხედავად იმისა, რომ ეს არის ფუნდამენტურად განსხვავებული XSS პრევენციის მეთოდები, მათ აქვთ რამდენიმე საერთო რამ, რაც მნიშვნელოვანია გავიგოთ რომელიმე მათგანის გამოყენებისას:
კონტექსტი შეყვანის უსაფრთხო დამუშავება სხვაგვარად უნდა განხორციელდეს იმის მიხედვით, თუ სად გამოიყენება მომხმარებლის შეყვანა გვერდზე. შემომავალი/გამავალი შეყვანის უსაფრთხო დამუშავება შეიძლება განხორციელდეს ან როდესაც თქვენი საიტი მიიღებს შეყვანის (შემავალი ტრაფიკი) ან უშუალოდ მანამ, სანამ საიტი შეიტანს მომხმარებლის შეყვანას გვერდის შინაარსში (გამავალი). კლიენტის/სერვერის უსაფრთხო შეყვანის დამუშავება შეიძლება განხორციელდეს კლიენტის ან სერვერის მხარეს, რომელთაგან თითოეული საჭიროა სხვადასხვა გარემოებებში.
სანამ დეტალურად აგიხსნით როგორ მუშაობს კოდირება და ვალიდაცია, ჩვენ აღვწერთ თითოეულ ამ პუნქტს.
მომხმარებლის შეყვანის მართვა კონტექსტებში
ვებ გვერდზე ბევრი კონტექსტია, სადაც მომხმარებლის შეყვანის გამოყენება შესაძლებელია. თითოეულ მათგანს უნდა დაიცვან სპეციალური წესები, რათა მომხმარებლის შეყვანამ არ შეძლოს მისი კონტექსტიდან „გაქცევა“ და არ იყოს ინტერპრეტირებული, როგორც მავნე კოდი. შემდეგი არის ყველაზე გავრცელებული კონტექსტი:
რამდენად მნიშვნელოვანია კონტექსტი?
ყველა აღწერილ კონტექსტში, XSS დაუცველობა შეიძლება წარმოიშვას, თუ მომხმარებლის შეყვანა ჩასმული იყო პირველ კოდირებამდე ან ვალიდაციამდე. თავდამსხმელს შეუძლია მავნე კოდის შეყვანა უბრალოდ ამ კონტექსტისთვის დახურვის გამყოფის ჩასმით, რასაც მოჰყვება მავნე კოდი.
მაგალითად, თუ რაიმე მომენტში ვებსაიტი მოიცავს მომხმარებლის შეყვანას პირდაპირ HTML ატრიბუტში, თავდამსხმელს შეუძლია მავნე სკრიპტის შეყვანა ციტატების ნიშნით დაწყებით, როგორც ეს ნაჩვენებია ქვემოთ:
ამის თავიდან აცილება შეიძლებოდა მომხმარებლის შეყვანის ყველა ციტატის ამოღებით და კარგი იქნებოდა, მაგრამ მხოლოდ ამ კონტექსტში. თუ შეყვანა სხვა კონტექსტშია ჩასმული, დახურვის დელიმიტერი განსხვავებული იქნება და ინექცია შესაძლებელი იქნება. ამ მიზეზით, შეყვანის უსაფრთხო მართვა ყოველთვის უნდა იყოს ადაპტირებული იმ კონტექსტთან, სადაც მომხმარებლის შეყვანა იქნება ჩასმული.
შემომავალი/გამავალი მომხმარებლის შეყვანის მართვა
ინსტინქტურად, შეიძლება ჩანდეს, რომ XSS შეიძლება თავიდან იქნას აცილებული მომხმარებლის ყველა შეყვანის კოდირებით ან დადასტურებით, როგორც კი ჩვენი საიტი მიიღებს მას. ამ გზით, ნებისმიერი მავნე სტრიქონი უკვე განეიტრალდება, როდესაც ისინი შედის გვერდზე, და HTML გენერირების სკრიპტებს არ მოუწევთ ფიქრი მომხმარებლის შეყვანის უსაფრთხოდ მართვაზე.
პრობლემა ის არის, რომ, როგორც ადრე იყო აღწერილი, მომხმარებლის შეყვანის ჩასმა შესაძლებელია გვერდზე მრავალ კონტექსტში. და არ არსებობს მარტივი გზა იმის დასადგენად, თუ როდის შედის მომხმარებლის შეყვანა კონტექსტში - როგორ იქნება ის საბოლოოდ ჩასმული და ერთი და იგივე მომხმარებლის შეყვანა ხშირად საჭიროებს სხვადასხვა კონტექსტში ჩასმას. XSS-ის თავიდან ასაცილებლად შემომავალი შეყვანის დამუშავებაზე დაყრდნობით, ჩვენ ვქმნით ძალიან მყიფე გადაწყვეტას, რომელიც მიდრეკილია შეცდომებზე. (მემკვიდრეობითი PHP ჯადოსნური ციტატები ასეთი გადაწყვეტის მაგალითია.)
ამის ნაცვლად, გამავალი შეყვანის მართვა უნდა იყოს თქვენი მთავარი თავდაცვის ხაზი XSS-ისგან, რადგან მას შეუძლია გაითვალისწინოს კონკრეტული კონტექსტი, თუ რა მომხმარებლის შეყვანა იქნება ჩასმული. გარკვეულწილად, შემომავალი ვალიდაცია შეიძლება გამოყენებულ იქნას დაცვის მეორადი ფენის დასამატებლად, მაგრამ ამის შესახებ მოგვიანებით.
სადაც შესაძლებელია მომხმარებლის შეყვანის უსაფრთხოდ დამუშავება
უმრავლეს თანამედროვე ვებ აპლიკაციებში მომხმარებლის შეყვანის დამუშავება ხდება როგორც სერვერის მხარეს, ასევე კლიენტის მხარის კოდზე. ყველა ტიპის XSS-ისგან თავის დასაცავად, შეყვანის უსაფრთხო დამუშავება უნდა განხორციელდეს როგორც სერვერის მხარეს, ასევე კლიენტის მხარეს კოდით.
- ტრადიციული XSS-ისგან თავის დასაცავად, შეყვანის უსაფრთხო დამუშავება უნდა განხორციელდეს სერვერის მხარეს კოდით. ეს კეთდება სერვერის მიერ მხარდაჭერილი ენის გამოყენებით.
- DOM-ში XSS შეტევებისგან თავის დასაცავად, სადაც სერვერი არასოდეს იღებს მავნე სტრიქონს (როგორიცაა ადრე აღწერილი ID ფრაგმენტის შეტევა), შეყვანის უსაფრთხო დამუშავება უნდა განხორციელდეს კლიენტის მხარეს კოდით. ეს კეთდება JavaScript-ის გამოყენებით.
ახლა, როდესაც ჩვენ განვმარტეთ, რატომ არის მნიშვნელოვანი კონტექსტი, რატომ არის მნიშვნელოვანი განსხვავება შემომავალი და გამავალი შეყვანის დამუშავებას შორის და რატომ უნდა განხორციელდეს შეყვანის უსაფრთხო დამუშავება როგორც კლიენტის, ასევე სერვერის მხრიდან, შეგვიძლია განვაგრძოთ ახსნა, თუ როგორ არის ორი ტიპის უსაფრთხოება. შეყვანის დამუშავება (დაშიფვრა და ვალიდაცია) ფაქტობრივად შესრულებულია.
კოდირება
კოდირება არის გამოსავალი იმ სიტუაციიდან, როდესაც ბრაუზერისთვის აუცილებელია მომხმარებლის შეყვანის ინტერპრეტაცია მხოლოდ როგორც მონაცემები და არა კოდი. ვებ დეველოპმენტში კოდირების ყველაზე პოპულარული ტიპია HTML masking, რომელიც გარდაქმნის სიმბოლოებს, როგორიცაა < და > ვ < და > შესაბამისად.
შემდეგი ფსევდოკოდი არის მაგალითი იმისა, თუ როგორ შეიძლება მომხმარებლის შეყვანის (მომხმარებლის შეყვანა) კოდირება HTML masking-ის გამოყენებით და შემდეგ გვერდზე ჩასმა სერვერის მხარის სკრიპტის გამოყენებით:
ბეჭდვა" "
ბეჭდვა "ბოლო კომენტარი:"
ბეჭდვის encodeHtml (მომხმარებლის შეყვანა)
ბეჭდვა""
თუ მომხმარებელი შეიყვანს შემდეგ ხაზს, შედეგად მიღებული HTML ასე გამოიყურება:
ბოლო კომენტარი:
იმის გამო, რომ სპეციალური მნიშვნელობის ყველა სიმბოლო დაფარულია, ბრაუზერი არ აანალიზებს მომხმარებლის შეყვანის რომელიმე ნაწილს, როგორიცაა HTML.
კლიენტისა და სერვერის კოდირება
კლიენტის მხრიდან კოდირების შესრულებისას ყოველთვის გამოიყენება JavaScript, რომელსაც აქვს ჩაშენებული ფუნქციები, რომლებიც შიფრავს მონაცემებს სხვადასხვა კონტექსტში.
თქვენი სერვერის კოდის კოდირებისას, თქვენ ეყრდნობით თქვენს ენაზე ან ჩარჩოში არსებულ ფუნქციებს. ხელმისაწვდომი ენებისა და ჩარჩოების დიდი რაოდენობის გამო, ეს გაკვეთილი არ მოიცავს კოდირების დეტალებს რომელიმე კონკრეტულ სერვერზე ან ჩარჩო ენაზე. თუმცა, კლიენტის მხარეს JavaScript კოდირების ფუნქციები ასევე გამოიყენება სერვერის მხარის კოდის დაწერისას.
კლიენტის მხრიდან კოდირება
კლიენტის მხრიდან მომხმარებლის შეყვანის JavaScript-ით კოდირებისას, არსებობს რამდენიმე ჩაშენებული მეთოდი და თვისება, რომლებიც ავტომატურად შიფრავს ყველა მონაცემს კონტექსტში მგრძნობიარე სტილში:
ზემოთ ნახსენები ბოლო კონტექსტი (მნიშვნელობები JavaScript-ში) არ არის შეტანილი ამ სიაში, რადგან JavaScript არ იძლევა ჩაშენებულ გზას მონაცემთა კოდირებისთვის, რომელიც ჩართული იქნება JavaScript-ის წყაროს კოდში.
კოდირების შეზღუდვები
კოდირების დროსაც კი, შესაძლებელია მავნე სტრიქონების გამოყენება ზოგიერთ კონტექსტში. ამის მთავარი მაგალითია, როდესაც მომხმარებლის შეყვანა გამოიყენება URL-ის მოსაწოდებლად, როგორც ქვემოთ მოცემულ მაგალითში:
document.querySelector ("a"). href = userInput
მიუხედავად იმისა, რომ href ელემენტის თვისებაში მითითებული მნიშვნელობა ავტომატურად აკოდირებს მას ისე, რომ იგი გახდება სხვა არაფერი, თუ არა ატრიბუტის მნიშვნელობა, ეს თავისთავად ხელს არ უშლის თავდამსხმელს ჩასვას URL, რომელიც იწყება "javascript:"-ით. ბმულზე დაწკაპუნებისას, კონსტრუქციის მიუხედავად, URL-ში ჩაშენებული JavaScript შესრულდება.
კოდირება ასევე არ არის ეფექტური გადაწყვეტა, როდესაც გსურთ, რომ მომხმარებლებს შეეძლოთ გამოიყენონ ზოგიერთი HTML კოდი გვერდზე. მაგალითი იქნება მომხმარებლის პროფილის გვერდი, სადაც მომხმარებელს შეუძლია გამოიყენოს მორგებული HTML. თუ ეს მარტივი HTML დაშიფრულია, პროფილის გვერდი შეიძლება შედგებოდეს მხოლოდ უბრალო ტექსტისგან.
მსგავს სიტუაციებში კოდირებას უნდა დაემატოს ვალიდაცია, რასაც შემდეგში გავეცნობით.
ვალიდაცია
ვალიდაცია არის მომხმარებლის შეყვანის ფილტრაციის აქტი ისე, რომ მისი ყველა მავნე ნაწილი წაიშლება მასში არსებული ყველა კოდის წაშლის გარეშე. ვალიდაციის ერთ-ერთი ყველაზე გამოყენებული ტიპი ვებ დეველოპმენტში საშუალებას გაძლევთ გამოიყენოთ ზოგიერთი HTML ელემენტი (მაგალითად, და ) მაგრამ კრძალავს სხვებს (მაგ.