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

სერვერის დონის დაცვა:

Zend Encoder / Zend SafeGuard Suite - ყველაზე პოპულარული კომერციული დაცვა, Zend-ის მხარდაჭერის მოდულები, როგორც წესი, დამონტაჟებულია ყველა ფასიან ჰოსტინგზე. Zend უზრუნველყოფს სკრიპტების დაკავშირებას დომენებთან და ip-თან, ადგენს საცდელი სკრიპტების დროს და ძლიერ დაბნელებას. ყველა ოპერაციული სისტემა მხარდაჭერილია. არსებობს Zend-ის წაშლის რამდენიმე ვარიანტი საზოგადოებრივ დომენში, ყველა მათგანი შეცვლილია PHP 4 და 5 ვერსიებში. Zend-ის ძველი ვერსიები ამოღებულია უპრობლემოდ, ამ უკანასკნელში არის სირთულეები წყაროს კოდის დაბინდვის გამო.

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

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

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

ionCube PHP Encoder. მეორე ყველაზე პოპულარული კომერციული სკრიპტის დაცვის პროდუქტი. Zend-ისთვის საჯარო დეკოდერების გამოჩენის შემდეგ, ის სულ უფრო ხშირად გამოიყენება და დაინსტალირდება ვირტუალურ ჰოსტინგებზე. საშუალებას გაძლევთ დაშიფროთ არა მხოლოდ სკრიპტები, არამედ შაბლონები, xml დოკუმენტები, სურათები, ორობითი ფაილები. აკავშირებს დაცულ ფაილებს სერვერებზე, არის მძლავრი ობფუსკატორი, ყველა ოპერაციული სისტემა მხარდაჭერილია. არ არსებობს საჯარო დეკოდერები, მაგრამ ზოგიერთ შემთხვევაში ის ამოღებულია deZender-ის მიერ.

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

DWebEncoder. Windows-ის ეგზოტიკური დაცვა, შექმნილია სკრიპტირებული პრეზენტაციებისა და კატალოგების შესაქმნელად CD-ებზე. ინსტალაციისას, ეს არის რაღაც დამოუკიდებელი ვებ სერვერის მსგავსი, რომელზედაც შესრულებულია კოდირებული php სკრიპტები. არ არსებობს საჯარო დეკოდერები.

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

ღია კოდის დამატება ძველი php ამაჩქარებლებისთვის Turck MMCache და eAccelerator. თარგმნის სკრიპტებს ბაიტიკოდში, რათა გაზარდოს მათი შესრულების სიჩქარე. არსებობს მოდულების ვერსიები Windows-ისა და Linux-ისთვის. არ არსებობს საჯარო დეკოდერები, მაგრამ ალბათ პროექტის ღია წყარო როგორმე დაეხმარება კვლევაში.

წყარო კოდის დონის დაცვა:

PHP LockIt! . პოპულარული კომერციული დაცვა, რომელიც გვხვდება ძალიან ხშირად, ძირითადად უცხოელი დეველოპერების სკრიპტებზე. საშუალებას გაძლევთ დააყენოთ სკრიპტების საცდელი პერიოდი, დააკავშიროთ დომენები და ip-მისამართები, შეკუმშოს სკრიპტები სტანდარტული php ინსტრუმენტებით (gzinflate). ერთადერთი სირთულე არის კარგი დამაბნეველი. დაცვის სხვადასხვა ვერსიები განსხვავდება მხოლოდ შეფუთვის მოდულის მოდიფიკაციით. ადვილად იშლება როგორც ხელით, ასევე ავტომატურ რეჟიმში. ობფუსკატორის გარეშე ის ზუსტად ამოღებულია საწყის კოდში, ობფუსკატორით კი დამატებით დამუშავებას საჭიროებს.

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

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

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

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

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

TrueBug PHP Encoder, ახლახან TrueBug PHP Obfuscator & Encoder. ძალიან საინტერესო დამცავი შესასწავლად. 1.0.2 ვერსიამდე გამოიყენებოდა სტანდარტული php ინსტრუმენტები gzip შეკუმშვისთვის, 1.0.3 ვერსიიდან დაწყებული, ავტორებმა შეიმუშავეს საკუთარი შეკუმშვის ალგორითმი. ახალ პროდუქტს TrueBug PHP Obfuscator & Encoder-მა დაამატა დაბინდვის ფუნქცია და კოდის ოპტიმიზაცია. დაცვის ერთადერთი სუსტი წერტილი არის უცვლელი სკრიპტის გაშიფვრის ალგორითმი, მაგრამ თავად ალგორითმი იცვლება დაცვის თითოეული ვერსიისთვის. გაანალიზების შემდეგ, დაცვა ადვილად იშლება ზუსტად საწყის კოდზე, რა თქმა უნდა, იმ პირობით, რომ არ გამოიყენებოდა obfuscator.

Zorex PHP CryptZ. დაცვა, ისევე როგორც CodeLock, არის php აპლიკაცია, რომელიც საჭიროებს MySQL მონაცემთა ბაზას სამუშაოდ. დაცვის მოდული - plug-in სკრიპტი php-ში, დაშიფრული რამდენიმე ფენაში. ალგორითმის გაანალიზების შემდეგ, ის ძალიან მარტივად ამოღებულია ზუსტად საწყის კოდში. არ არის დამაბრკოლებელი ფუნქცია.

უფასო PHP Encoder. უფასო ონლაინ სერვისი php სკრიპტების კოდირებისთვის. დაცვის მოდული არის Plug-in php სკრიპტი, რომელიც დაფარულია Zend-ით, რომელიც უნდა გადმოიწეროს საიტიდან. Zend-ის წაშლისა და ალგორითმის გაანალიზების შემდეგ, დაცვა ადვილად იშლება საწყის კოდამდე. დაცვის ალგორითმი უცვლელია, არ არის დამაბინძურებელი ფუნქცია.

PHP სკრიპტი, პრიმიტიული კოდირება, სტანდარტული base64. ის არ იმსახურებს მეტ ყურადღებას და არ წარმოადგენს პრაქტიკულ ინტერესს.

მოდით შევქმნათ ჩვენი საკუთარი მრავალსაიტიანი რეგისტრაციის გვერდი სტანდარტული wp-signup.php-ის ნაცვლად.

WordPress-ის ტიპიურ ინსტალაციაში რეგისტრაციის გვერდი (შესვლა, პაროლის აღდგენა) ნაჩვენებია wp-login.php ფაილში.

• /wp-login.php - ავტორიზაცია
• /wp-login.php?action=register - რეგისტრაცია
• /wp-login.php?action=lostpassword - პაროლის აღდგენა

არის ცალკე პირობები მულტისაიტისთვის wp-login.php-ში. ასე რომ, როდესაც დააწკაპუნებთ /wp-login.php?action=register on multisite, WordPress გადამისამართდება /wp-signup.php გვერდზე. ბევრ თემაში გვერდი არც თუ ისე მიმზიდველად გამოიყურება, ამიტომ ჩვენ საკუთარს გავაკეთებთ.

ქსელის მთავარი საიტი

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

functions.php?

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

ლირიკული დიგრესია

აღსანიშნავია, რომ MU დანამატები იტვირთება ჩვეულებრივ დანამატებამდე და WordPress-ის ბირთვის სრულად ჩატვირთვამდე, ამიტომ ზოგიერთი ფუნქციის გამოძახებამ შეიძლება გამოიწვიოს ფატალური შეცდომები PHP-ში. ამ "ადრეულ" დატვირთვას აქვს თავისი უპირატესობები. დავუშვათ, რომელიმე თემის შიგნით თქვენ არ შეგიძლიათ დაეყრდნოთ ზოგიერთ მოქმედებას, რომელიც მუშაობს მანამ, სანამ functions.php ფაილი ჩაიტვირთება თემიდან. ამის მაგალითია მოქმედებები Jetpack დანამატიდან jetpack_module_loaded_related-posts (related-posts არის მოდულის სახელი), რომლითაც შესაძლებელია Jetpack-ში მოდულების აქტივობის თვალყურის დევნება. ამ მოქმედების "მიმაგრება" შეუძლებელია თემის ფაილიდან, რადგან მოქმედება უკვე გააქტიურებულია თემის ჩატვირთვამდე - დანამატები იტვირთება თემებზე ადრე. შეგიძლიათ გადახედოთ WordPress-ის დატვირთვის შეკვეთის ზოგად სურათს კოდექსის სამოქმედო მითითების გვერდზე.

ფაილის შეკვეთა

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

|-mu-plugins |-|-load.php |-|-|-selena-network |-|-|-|-რეგისტრაცია |-|-|-|-|-plugin.php |-|-|-| -|-... |-|-|-|-jetpack |-|-|-|-|-plugin.php

load.php ფაილში ჩვენი ქსელისთვის ყველა საჭირო „პლაგინი“ არის დაკავშირებული:

// ჩატვირთეთ ტრანსლატები ყველა დანამატისთვის load_muplugin_textdomain("selena_network", "/selena-network/languages/"); // ქსელის რეგისტრაცია მოითხოვს WPMU_PLUGIN_DIR. "/selena-network/signup/plugin.php"; // სხვა დანამატები // საჭიროებს WPMU_PLUGIN_DIR ...

დანამატის საქაღალდეები ინახება selena-network საქაღალდეში, თითოეულს აქვს თავისი plugin.php , რომელსაც ჩვენ ვაერთიანებთ load.php-ში. ეს იძლევა მოქნილობას და უნარს სწრაფად გამორთოთ და ჩართოთ გარკვეული რამ.

რეგისტრაციის გვერდის URL

wp_signup_location ფილტრი გამოიყენება რეგისტრაციის გვერდის მისამართის დასაზუსტებლად. ის შეიძლება მოიძებნოს wp-login.php ფაილში და პასუხისმგებელია wp-signup.php-ზე გადამისამართებაზე.

შემთხვევა "რეგისტრაცია" : if (is_multisite()) (wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))); გასვლა;

მოდით დავამატოთ ჩვენი ფუნქცია mu-plugins/selena-network/signup/plugin.php , რომელიც მისცემს რეგისტრაციის გვერდის მისამართს მიმდინარე საიტზე:

ფუნქცია selena_network_signup_page ($url) ( return home_url () . "/signup/"; ) add_filter ("wp_signup_location", "selena_network_signup_page", 99);

selena_network არის პრეფიქსი, რომელსაც მე ვიყენებ ყველა ფუნქციის სახელებში MU დანამატების შიგნით ჩემს საიტზე, რათა თავიდან ავიცილოთ შეჯახება, ის უნდა შეიცვალოს თქვენი უნიკალური პრეფიქსით. დაამატეთ ფილტრის პრიორიტეტი 99, რადგან ზოგიერთ დანამატს, როგორიცაა bbPress და BuddyPress, შეუძლია გადაწეროს ეს მისამართი თავისით (MU დანამატები იტვირთება უფრო ადრე, ვიდრე ჩვეულებრივი დანამატები, იხილეთ ზემოთ). გაითვალისწინეთ, რომ home_url() გამოიყენება network_site_url()-ის ნაცვლად, რათა ვიზიტორი დარჩეს იმავე დომენზე. ნებისმიერი URL შეიძლება გამოყენებულ იქნას მისამართად.

გვერდის შექმნა

ახლა მოდით შევქმნათ გვერდი მისამართით site.com/signup/ ჩვეულებრივი ინტერფეისის საშუალებით და ბავშვის თემების საქაღალდეში ჩვენი ახალი გვერდის შაბლონია page-signup.php. სიტყვის "რეგისტრაციის" ნაცვლად შეგიძლიათ გამოიყენოთ უნიკალური ID.

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

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

wp-signup.php და wp-activate.php

ახლა შევქმნათ ფუნქცია, რომელიც აჩვენებს რეგისტრაციის ფორმას. ამისათვის დააკოპირეთ wp-signup.php და wp-activate.php ფაილები WordPress root-დან mu-plugings/selena-network/signup/-ში (და არ დაგავიწყდეთ მათი ჩართვა mu-plugins/selena-network-ში. /signup/plugin.php) . ფაილების შემდგომი მანიპულაციები ძალიან რთული და გრძელია აღსაწერად, ასე რომ თქვენ მოგიწევთ მათი შესრულება. მე უბრალოდ აღვწერ რა ზუსტად უნდა გაკეთდეს და გამოვაქვეყნებ ჩემი პროექტის წყაროს ფაილებს:

1. ფაილის დასაწყისში წაშალეთ ყველა მოთხოვნა, ფუნქციის ზარი და სხვა კოდი ფუნქციების გარეთ.
2. გადაარქვით ყველა ფუნქცია სახელებს უნიკალური პრეფიქსების დამატებით.
3. wp-signup.php კოდის ქვედა ნაწილი გადაიტანეთ selena_network_signup_main ფუნქციაში და თავიდანვე ჩაწერეთ გლობალური $active_signup; .
4. შეცვალეთ განლაგება თქვენით სწორ ადგილებში.

შიგნით wp-activate.php თქვენ უნდა გააკეთოთ იგივე:

1. წაშალეთ ყველა კოდი ფუნქციების გარეთ, გადაიტანეთ განლაგება ცალკე ფუნქციაში.
2. შეცვალეთ განლაგება, სადაც საჭიროა.

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

აქტივაციის ელფოსტის გაგზავნა

რეგისტრაციის გვერდი ვიზიტორს უგზავნის ელ.წერილს ანგარიშის გასააქტიურებლად ბმულით. ნაგულისხმევად, ამას ამუშავებს wpmu_signup_user_notification() ფუნქცია ms-functions.php ფაილიდან. მისი ფუნქციონირება შეიძლება ნასესხები იყოს მისი ფუნქციისთვის. ამ ფუნქციის გამოყენების შეწყვეტის მიზეზი არის ის, რომ ის აგზავნის ანგარიშის აქტივაციის ბმულს wp-activate.php-დან. თქვენ შეგიძლიათ „გამორთოთ“ ეს ფუნქცია wpmu_signup_user_notification ფილტრის გამოყენებით, თუ ეს არ გაკეთებულა, აქტივაციის წერილი გაიგზავნება ორჯერ, კარგი, რეალურად ორი განსხვავებული ასო).

ფუნქცია armyofselenagomez_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) (// ... // კოდი wpmu_signup_user_notification() ფუნქციიდან wp_mail($user_email, wp_specialchars_ages,$smes)$mes ; დაბრუნება false; ) add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);

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

დასკვნა

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

აღვნიშნავ, რომ ფაილები ფრთხილად უნდა დაარედაქტიროთ და ეცადოთ, ძალიან არ გადაუხვიოთ ორიგინალს, რათა მომავალში, თუ WordPress შეცვლის wp-signup.php და wp-activate.php ფაილებს, უფრო ადვილი იყოს შედარება. მათ იპოვონ ცვლილებები.

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

ბონუსი. სპამისგან დაცვა

WordPress-ის ყველაზე პატარა საიტებიც კი ხშირად იბომბება სპამის რეგისტრაციებით. შეგიძლიათ დაწეროთ გაუთავებელი პირობები ბოტების გაფილტვრისთვის, ხშირად უფრო მეტად ხელოვნური ინტელექტის შექმნის მცდელობა 🙂 მულტისაიტის შემთხვევაში, ძალიან დამეხმარა Apache-ში ჩვეულებრივი გადამისამართება, რომლითაც ვთხოვე 404-ის გაცემა /wp-signup.php გახსნისას. და /wp-acitvate.php (მე არ ვარ Apache-ს დაყენების ექსპერტი, ამიტომ ჩემი წესები შეიძლება არ იყოს ძალიან სწორი).

RewriteEngine On RewriteBase / RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # BEGIN WordPress # WordPress-ის ნაგულისხმევი წესები :) # ... # END WordPress

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

”ბანკების ვებსაიტები იშლება ფულის გულისთვის, პენტაგონი არის ჯაშუშობისთვის და არავის სჭირდება ჩემი პროექტი,” სამწუხაროდ, ეს არის ზუსტად ის, რაც პერსონალური ბლოგების, ონლაინ სავიზიტო ბარათების და ვირტუალური წარმომადგენლობითი ოფისების მფლობელების უმეტესობაა. მცირე კომპანიები ფიქრობენ. მხოლოდ რამდენიმე ფიქრობს, როგორ დაიცვას საიტი, მაგრამ ამაოდ. თანამედროვე რეალობაში, აბსოლუტურად ნებისმიერი საიტი, განურჩევლად ტიპისა თუ პოპულარობისა, საინტერესოა ჰაკერების თვალში. ვის შეიძლება დასჭირდეს თქვენი რესურსი და რატომ? მოდით გავარკვიოთ:
1. Pranks scriptkiddis. ჟარგონი ეხება დამწყებ ჰაკერებს, რომლებიც პირველ ნაბიჯებს დგამენ "ბნელ მხარეს". შეიძინეს რამდენიმე ინსტრუმენტი, ან დაწერეს რამდენიმე საკუთარი პროგრამა, მათ სურთ შეამოწმონ თავიანთი შესრულება პირველ მსხვერპლზე და, როგორც წესი, აირჩიონ ყველაზე მარტივი (სუსტად დაცული და არ განახლებული CMS) სამიზნეები.
2. შავი ქუდი SEO. არაკეთილსინდისიერი ოპტიმიზატორების სერვისები კვლავ გამოიყენება - 10-ზე მეტი TCI-ის მქონე პროექტების კოდში ფარული ბმულების განთავსება ჯერ კიდევ პრაქტიკულია. და, უპირველეს ყოვლისა, რესურსები ღია კოდის ძრავებზე (Joomla, Drupal, OpenCart და ა.შ.) თავდასხმის ქვეშ ექცევა.
3. ბოტ-ნეტის აგება. WordPress-ის დაცვა htaccess-ით და დანამატებით ასევე აქტუალურია, რადგან აბსოლუტურად ნებისმიერი რესურსის გამოყენება შესაძლებელია ზომბების ქსელის შესაქმნელად, რომელიც გამოიყენება DDoS შეტევების, სპამის და ა.შ.
4. გირაოს დაზიანება. დაბოლოს, შეიძლება არ დაგეზაროთ - მთავარი მიზანი იქნება ჰოსტინგი და საიტი იქნება პროვაიდერის IT ინფრასტრუქტურის მხოლოდ ერთი დიდი დაუცველობა. რა თქმა უნდა, მისი ბედი გულგრილი იქნება ჰაკერების მიმართ.

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

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

WordPress საიტის დაცვის მეთოდები

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

1. გამოიყენეთ უნიკალური ადმინისტრატორის შესვლა

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

ადმინის საშუალებით. გადადით "მომხმარებლების" განყოფილებაში, დააჭირეთ ღილაკს "ახლის დამატება" და შექმენით ანგარიში. "როლი" ველში აირჩიეთ "ადმინისტრატორი" და დაადასტურეთ ოპერაცია. შემდეგ შედით სისტემაში ახლად შექმნილი ანგარიშის სახელით, დაბრუნდით "მომხმარებლების" განყოფილებაში, აირჩიეთ "admin" და დააჭირეთ "Delete". ფანჯარაში, რომელიც იხსნება, დააყენეთ რადიოს ღილაკი „ყველა შინაარსის მიბმა“ და ჩამოსაშლელი სიიდან აირჩიეთ ახალი ადმინისტრატორი და შემდეგ დააწკაპუნეთ „დაადასტურეთ წაშლა“.
. phpMyAdmin-ის გამოყენებით. ბევრად უფრო ადვილია იგივე პროცედურის განხორციელება მონაცემთა ბაზის მართვის პანელის მეშვეობით. აირჩიეთ საჭირო მონაცემთა ბაზა, იპოვეთ wp_users ცხრილი, იპოვეთ სტრიქონი “admin” (ID=1), დააწკაპუნეთ “Edit”-ზე და შეიყვანეთ სასურველი სახელი.

2. შექმენით გამოქვეყნების სპეციალური ანგარიში

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

3. დააყენეთ რთული პაროლი

დაიცავით ზოგადად მიღებული მითითებები: პაროლები უნდა შედგებოდეს მინიმუმ 10 სიმბოლოსგან, იყოს უნიკალური და შეიცავდეს დიდი და პატარა ასოების, რიცხვებისა და სპეციალური სიმბოლოების შემთხვევით თანმიმდევრობას.
არავითარ შემთხვევაში არ უნდა:
. შეადგინეთ პაროლი მნიშვნელოვანი ფრაზებისგან
. გამოიყენეთ ნებისმიერი ფაქტობრივი მონაცემები (დაბადების თარიღი, ქალიშვილობის გვარი, საბანკო ანგარიშის ნომერი, მიმდინარე წელი...)
ეს გამორიცხავს ლექსიკონიდან პაროლის შერჩევის რისკს და ასევე მნიშვნელოვნად გაზრდის უხეში ძალისთვის საჭირო დროს. ასე რომ, 10-სიმბოლოიანი თანმიმდევრობის გატეხვას, რომელიც შედგება მხოლოდ მცირე ასოებისა და რიცხვებისგან (hki458p1fa) დასჭირდება 10 დღის მანქანის დრო ერთ კომპიუტერზე, მაგრამ თუ დაამატებთ დიდ ასოებს და დამატებით სიმბოლოებს (Nv6$3PZ~w1), ეს პერიოდი გაიზრდება. 526 წლამდე, WordPress-ის თითქმის აბსოლუტური დაცვის გარანტია. ასეთი პაროლების შექმნა და დამახსოვრება საკმაოდ რთულია, განსაკუთრებით თუ რამდენიმე პროექტს აკონტროლებ. ამიტომ, მათი გენერირებისთვის და შესანახად, უმჯობესია გამოიყენოთ სპეციალური მენეჯერები, მაგალითად, უფასო KeePassX, ან ჩვეულებრივი სატესტო დოკუმენტი (უმჯობესია ის არქივში პაროლით იყოს შეფუთული).

4. შეცვალეთ მონაცემთა ბაზის პაროლი

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

1. გადადით phpMyAdmin მართვის პანელზე
2. გახსენით ჩანართი „მომხმარებლები“ ​​და აირჩიეთ მონაცემთა ბაზის მფლობელი
3. დააწკაპუნეთ „პრივილეგიის რედაქტირებაზე“
4. იპოვეთ სვეტი „პაროლის შეცვლა“ და შეიყვანეთ ახალი საიდუმლო თანმიმდევრობა შესაბამის ველებში
5. შეინახეთ ცვლილებები „OK“-ზე დაწკაპუნებით

ახლა რჩება wp-config.php რედაქტირება, წინააღმდეგ შემთხვევაში WordPress ვერ დაუკავშირდება მონაცემთა ბაზას. იპოვეთ ხაზი define('DB_PASSWORD', 'პაროლი'); და შეიყვანეთ ახალი პაროლი სიტყვის პაროლის ნაცვლად. გაითვალისწინეთ, რომ რადგან (‘) სიმბოლო გამოიყენება SQL ბრძანებების იზოლირებისთვის, ის არ უნდა იქნას გამოყენებული, როგორც საიდუმლო ფრაზის ნაწილი.

5. რეგულარულად განაახლეთ თქვენი პაროლები

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

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

6. არ დაგავიწყდეთ თქვენი ქუქიების საიდუმლოების შეცვლა

ისინი განლაგებულია wp-config.php ფაილში. სულ არის 8:

define("AUTH_KEY" , "უნიკალური გასაღები" ); define("SECURE_AUTH_KEY" , "უნიკალური გასაღები" ); define("LOGGED_IN_KEY" , "უნიკალური გასაღები" ); define("NONCE_KEY" , "უნიკალური გასაღები" ); define("AUTH_SALT" , "უნიკალური გასაღები" ); define("SECURE_AUTH_SALT" , "უნიკალური გასაღები" ); define("LOGGED_IN_SALT" , "უნიკალური გასაღები" ); define("NONCE_SALT" , "უნიკალური გასაღები" );

define("AUTH_KEY", "უნიკალური გასაღები"); define("SECURE_AUTH_KEY", "უნიკალური გასაღები"); define("LOGGED_IN_KEY", "უნიკალური გასაღები"); define("NONCE_KEY", "უნიკალური გასაღები"); define("AUTH_SALT", "უნიკალური გასაღები"); define("SECURE_AUTH_SALT", "უნიკალური გასაღები"); define("LOGGED_IN_SALT", "უნიკალური გასაღები"); define("NONCE_SALT", "უნიკალური გასაღები");

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

უსაფრთხოების გასაუმჯობესებლად, სიმბოლოების ნაგულისხმევი თანმიმდევრობები უნდა შეიცვალოს უნიკალურით CMS-ის დანერგვისთანავე. მოხერხებულობისთვის დეველოპერებმა შექმნეს ვებ გენერატორი, რომელიც მდებარეობს მისამართზე www.api.wordpress.org/secret-key/1.1/salt/ - შესვლისას დაინახავთ კლავიშებს, ხოლო თუ გვერდს განაახლებთ, კომბინაციები განახლდება. .

7. ორმაგი ავტორიზაცია ადმინისტრატორის პანელისთვის

Htaccess საშუალებას გაძლევთ კიდევ უფრო დაიცვათ თქვენი WordPress საიტი სერვერის დონის ავთენტიფიკაციის დამატებით. კოდი ასე გამოიყურება:

< Files wp- login. php> # დააყენეთ ავთენტიფიკაციის ძირითადი ტიპი - ეს ნიშნავს, რომ როდესაც ცდილობთ# მითითებულ დირექტორიაში ან ფაილზე წვდომას მოგეთხოვებათ პაროლი: AuthType ძირითადი # შეიყვანეთ ტექსტი, რომელიც გამოჩნდება ფორმის სათაურში: AuthName "იდენტიფიცირება საკუთარი თავის" # მიუთითეთ პაროლის შემცველი ფაილის გზა: AuthUserFile "/home/site/.htpasswd" # მიუთითეთ, რომ wp-login.php ფაილზე წვდომისას უნდა შეიყვანოთ პაროლი:მოითხოვეთ მოქმედი მომხმარებელი # უარყოთ წვდომა .htpasswd ფაილზე მესამე მხარეებისთვის:< Files . htpasswd>უბრძანა დაუშვას, უარყოს ყველასგან

# აირჩიეთ ავტორიზაციის სკრიპტის ფაილი: # დააყენეთ ავთენტიფიკაციის ძირითადი ტიპი - ეს ნიშნავს, რომ როდესაც ცდილობთ # შეხვიდეთ მითითებულ დირექტორიაში ან ფაილში, მოგეთხოვებათ პაროლი: AuthType basic # შეიყვანეთ ტექსტი, რომელიც იქნება ნაჩვენები ფორმის სათაურში: AuthName "Identify yourself" # მიუთითეთ პაროლის ფრაზის შემცველი ფაილის გზა: AuthUserFile "/home/site/.htpasswd" # მიუთითეთ, რომ პაროლი საჭიროა wp-login.php ფაილზე წვდომისას: მოითხოვეთ ვალიდური მომხმარებელი# უარყოთ წვდომა .htpasswd ფაილზე მესამე მხარეებისთვის: შეუკვეთე ნება, უარვყოთ ყველასგან

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

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

1) შექმენით .php ფაილი notepad-ში, მაგალითად crypt.php
2) შეიყვანეთ იქ კოდი, შეცვალეთ თქვენი მოფიქრებული პაროლი სიტყვის „პაროლის“ ნაცვლად:

3) შეინახეთ ფაილი და ატვირთეთ root დირექტორიაში
4) მიჰყევით ბმულს site_name.ru/crypt.php - ეკრანზე გამოჩნდება პაროლის ჰეში
5) შეინახეთ ეს მნიშვნელობა .htpasswd ფაილში და ატვირთეთ root დირექტორიაში და წაშალეთ crypt.php

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

ოფციები ყველა - ინდექსები

ოფციები All-Indexes

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

8. დააინსტალირეთ captcha

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

დაყენება დიდ პრობლემას არ წარმოადგენს. ჩანართი „ძირითადი“ საშუალებას გაძლევთ აირჩიოთ სად უნდა აჩვენოთ captcha, ასევე მიუთითოთ სათაური და სიმბოლო საჭირო ველების აღსანიშნავად.

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

კიდევ ერთი სასარგებლო ფუნქცია არის IP მისამართების ჩაშენებული თეთრი სია, რომლებისთვისაც captcha არ იქნება ნაჩვენები.

მოდულის ინსტალაციისა და გააქტიურების შედეგი იქნება ფორმის გამოჩენა ავტორიზაციის გვერდზე:

9. შეცვალეთ ადმინისტრატორის მისამართი

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

1. გადაარქვით სახელი wp-login.php ფაილს. გამოიყენეთ მცირე ინგლისური ასოების, რიცხვების და ტირეების შემთხვევითი თანმიმდევრობა. მაგალითად: abc-123.php
2. შედეგად ფაილში იპოვეთ wp-login.php-ის ყველა ნახსენები და შეცვალეთ ისინი ახალი სახელით.
3. საიტის სწორად მუშაობისთვის ჩანაცვლება ასევე უნდა მოხდეს: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general. -template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, my -sites.php, schema.php, ru_RU.po

ამ მანიპულაციების შემდეგ, ადმინისტრატორის პანელი განთავსდება საიტზე/abc-123.php. ახალ ფაილზე წვდომა უნდა იყოს შეზღუდული და პაროლით დაცული, როგორც ზემოთ იყო აღწერილი. გარდა ამისა, თქვენ შეგიძლიათ მოატყუოთ სავარაუდო ჰაკერები ყალბი wp-login.php ფაილის შექმნით და ასევე პაროლის დაყენებით.

კიდევ უფრო მარტივი ვარიანტია "გადარქმევა wp-login.php" დანამატის გამოყენება. საიტის დაცვის მოდულის ინსტალაციის შემდეგ, მენიუში გამოჩნდება ახალი ველი "პარამეტრები" -> "პერმალინკები":

10. მიუთითეთ ადმინისტრატორის IP

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

< Files wp- login. php>შეკვეთა უარყოფა, დაშვება უარყოფა ყველა დაშვებიდან 127.0.0.1, 127.0.02 #გამოყავით თქვენი IP მისამართები მძიმით

order deny, allow deny from all allow from 127.0.0.1, 127.0.02 # მიუთითეთ თქვენი IP მისამართები გამოყოფილი მძიმეებით

11. ავტორიზაციის შეცდომების გამორთვა

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

add_filter("login_errors" , create_function ("$a" , "return null;" ) );

add_filter("login_errors",create_function("$a", "return null;"));

ამისათვის აირჩიეთ "Appearance" -\u003e "Editor" -\u003e "Theme Features" ადმინისტრაციულ პანელში. კოდი უნდა დაიწეროს გახსნის ტეგის შემდეგ.

12. გამოიყენეთ უსაფრთხო კავშირი.

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

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

< IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine On RewriteCond % ( HTTPS) = გამორთულია RewriteCond % ( REQUEST_URI) = / wp-login. php RewriteRule (.*) https:

ოფციები +FollowSymlinks RewriteEngine On RewriteCond %(HTTPS) =off RewriteCond %(REQUEST_URI) =/wp-login.php RewriteRule (.*) https://%(HTTP_HOST)%(REQUEST_URI)

თქვენ ასევე შეგიძლიათ აიძულოთ SSL სერთიფიკატების გამოყენება ძრავის დონეზე. ამისათვის გახსენით wp-config.php ფაილი და დაამატეთ შემდეგ

define("FORCE_SSL_ADMIN" , true ) ;

define("FORCE_SSL_ADMIN", true);

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

< IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine on RewriteCond % ( HTTPS) = გამორთულია RewriteRule ^(.* ) $ https: //%(HTTP_HOST)%(REQUEST_URI)

ოფციები +FollowSymlinks RewriteEngine on RewriteCond %(HTTPS) =off RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

13. დაბლოკეთ შემოჭრილები

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

Order Allow, Deny Allow from all Deny from 127.0.0.1, 127.0.02 # მიუთითეთ არასასურველი IP-ები

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

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

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

„IP-ის დაბლოკვა wp-login.php მოთხოვნის“ გვერდით უნდა იყოს მონიშნული, თუ შეცვლით ადმინისტრატორის მისამართს ზემოთ აღწერილი გზით.

ამ მიზნებისათვის, შეგიძლიათ გამოიყენოთ თქვენი საკუთარი WP Cerber ინსტრუმენტი:

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

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

14. გადაიტანეთ კონფიგურაციის ფაილი

როგორც ზემოთ გავარკვიეთ, wp-config.php ინახავს ისეთ კრიტიკულ მონაცემებს, როგორიცაა მომხმარებლის სახელი და პაროლი MySQL წვდომისთვის, ასევე API გასაღებები. შემდეგი ნაბიჯი აშკარაა - WordPress-ის დაცვა htaccess-ის საშუალებით ფაილზე წვდომის შეზღუდვით:

< Files wp- config. php>შეუკვეთეთ დაშვება, უარყავით ყველასგან უარი

შეუკვეთეთ დაშვება, უარყავით ყველასგან უარი

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

15. დაამატეთ REFERER Check

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

< IfModule mod_rewrite. c>RewriteEngine On RewriteCond % ( REQUEST_METHOD) POST RewriteCond % ( REQUEST_URI) . (wp-comments-post|wp-login)\. php* RewriteCond % ( HTTP_REFERER) !.* tekseo. su.* [ OR] RewriteCond % ( HTTP_USER_AGENT) ^$ RewriteRule (.* ) http: //%(REMOTE_ADDR)/$1

RewriteEngine On RewriteCond %(REQUEST_METHOD) POST RewriteCond %(REQUEST_URI) .(wp-comments-post|wp-login)\.php* RewriteCond %(HTTP_REFERER) !.*site.* Rewrite_Cond %(HTTP) *) http://%(REMOTE_ADDR)/$1

16. უსაფრთხო XML-RPC

3.5 ვერსიით დაწყებული, WordPress-ს აღარ აქვს XML-RPC დისტანციური პროცედურის გამოძახების პროტოკოლის გამორთვის შესაძლებლობა. ძირითადად, საჭიროა მობილურ აპლიკაციებთან ურთიერთობა, მაგრამ ყველას არ სჭირდება ასეთი ფუნქციონირება. ამავდროულად, xmlrpc.php აქტიურად გამოიყენება DDoS შეტევებისთვის, რაც არის მთელი პროექტის აქილევსის ქუსლი.

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

< methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>ადმინისტრატორი < param>< value>< string> 12345

wp.getUsersBlogs ადმინისტრატორი 12345

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

1) htaccess-ის საშუალებით xmlrpc.php ფაილზე წვდომის დაბლოკვით

require_once(ABSPATH . "wp-settings.php");

აუცილებელია რეგისტრაცია

ფუნქცია remove_x_pingback($headers) ( unset($headers["X-Pingback"]); დაბრუნება $headers; ) add_filter("wp_headers", "remove_x_pingback");

4) Control XML-RPC გამოქვეყნების მოდულის გამოყენებით, რომელიც აბრუნებს შესაბამის ვარიანტს "პარამეტრებში" -> "ჩაწერაში":

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

17. უხეში ძალის შეტევების მონიტორინგი

დაბოლოს, აღსანიშნავია საინტერესო მოდული ლოგის ჰაკერების მცდელობისთვის - Authentication და xmlrpc log writer. მიუხედავად იმისა, რომ WP Cerber-ს აქვს ჩაშენებული მონიტორინგის ხელსაწყოები, ეს მოდული მაინც სასარგებლო იქნება, განსაკუთრებით მათთვის, ვისაც ზემოთ აღწერილი პროტოკოლის შესაძლებლობები სჭირდება. AX LogWriter-ს შეუძლია თვალყური ადევნოს უხეში ძალას xmlrpc.php-ის საშუალებით, რომლის წყალობითაც შეგიძლიათ შეაფასოთ საფრთხის ხარისხი და მისი შესაძლებლობების გამოყენებაზე სრულად უარის თქმის მიზანშეწონილობა. დაბოლოს, მათთვის, ვინც საერთოდ არ შეხებია მათი პროექტის უსაფრთხოებასთან, საიტის დაცვის მოდული გაუხსნის მათ თვალებს ზემოთ აღნიშნული ზომების მნიშვნელობაზე.

AX LogWriter-ის გამოყენება მარტივია. ინსტალაციის შემდეგ ადმინისტრატორის მენიუში გამოჩნდება შესაბამისი განყოფილება, სადაც შეგიძლიათ შეასრულოთ ყველა საჭირო ცვლილება:

"შეცდომის ტიპი" ველში აირჩიეთ შენახვის მეთოდი. იგი მხარს უჭერს სისტემის ჟურნალში ჩაწერას, Apache სერვერის ჟურნალს, ასევე პერსონალური ფაილის შექმნის შესაძლებლობას. ამ უკანასკნელ შემთხვევაში, თქვენ ასევე შეგიძლიათ დააკონფიგურიროთ სახელი (Custom Error Log Name) და დირექტორია (Custom Error Log Path). ეს უხსნის ფართო შესაძლებლობებს სისტემის ადმინისტრატორს - მაგალითად, გამოსავალი შეიძლება გამოყენებულ იქნას fail2ban-თან ერთად. ასევე არ დაგავიწყდეთ დროის სარტყლის სვეტში შესაბამისი დროის ზონის არჩევა.

მორგებული ჟურნალის ნახვა შესაძლებელია პირდაპირ ადმინისტრატორის პანელიდან Custom Log Viewer გვერდზე:

Შეჯამება:

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

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

1. შემომავალი მონაცემების დადასტურება
2. დაცვა XSS შეტევებისგან
3. დაცვა CSRF შეტევებისგან
4. SQL ინექციის პრევენცია
5. ფაილური სისტემის დაცვა
6. სესიის მონაცემთა დაცვა
7. შეცდომის დამუშავება
8. მიმაგრების დაცვა

შემომავალი მონაცემების დადასტურება

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

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

დაცვა XSS შეტევებისგან

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

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

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

დაცვა CSRF შეტევებისგან

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

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

შემდეგი მარტივი მაგალითი გვიჩვენებს, თუ როგორ შეიძლება დაუცველი საიტი დაექვემდებაროს CSRF შეტევას:

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

ეწვიეთ ჩემს საიტს!

თუ ალისა ავტორიზებულია example.com-ზე და მიჰყვება ამ ბმულს, მაშინ $1000 გადაირიცხება მისი ანგარიშიდან ბობის ანგარიშზე. ალტერნატიულად, ბობს შეუძლია გამოსახულების გაგზავნაც და src ატრიბუტში "ცუდი" მისამართის ჩასმა.

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

ამ ტიპის თავდასხმის თავიდან ასაცილებლად, გამოიყენეთ მხოლოდ POST მოთხოვნები პროცესებზე, რომლებიც გამიზნულია მონაცემთა ბაზაში ინფორმაციის შესაცვლელად. არ გამოიყენოთ $_REQUEST. გამოიყენეთ $_GET GET პარამეტრების დასამუშავებლად და $_POST POST პარამეტრების მისაღებად.

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

SQL ინექციის პრევენცია

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

მოდით შევხედოთ შემდეგ მაგალითს:

ზემოთ მოცემულ კოდში, ჩვენ ვუგზავნით მოთხოვნას përgatit() მეთოდზე, დასახელებული პარამეტრების ჩათვლით: :name და :age . ამრიგად, მოთხოვნა წინასწარ არის შედგენილი მონაცემების შემდგომი ჩანაცვლებისთვის. execute() მეთოდის გამოძახებისას მოთხოვნა სრულად ყალიბდება და სრულდება. თუ იყენებთ ამ ტექნიკას, მაშინ თავდამსხმელის ყველა მცდელობა განახორციელოს SQL ინექცია გაუქმდება.

ფაილური სისტემის დაცვა

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

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

სესიის მონაცემთა დაცვა

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

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

PHP 5.4-დან შეგიძლიათ გადასცეთ SessionHandlerInterface ტიპის ობიექტი session_set_save_handler()-ს.

შეცდომის დამუშავება

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

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

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

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

მიმაგრების დაცვა

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

შედეგი

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

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

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

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

როგორ მოძებნოთ ჩართვა...

ჯერ გავიგოთ, როგორ ცდილობს თავდამსხმელი აღმოაჩინოს დაუცველობა.

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

ბუნებრივია, თუ თავდამსხმელი მოქმედებს გარედან, მაშინ მან არ იცის დირექტორიებისა და ფაილების ადგილმდებარეობის სტრუქტურა და არ შეიძლება შეიცავდეს არცერთ ფაილს, რადგან არ იცის მისკენ მიმავალი გზა. მაგრამ არის ფაილები, რომლებიც ყოველთვის არსებობს სისტემაში და რომლებზეც ყოველთვის არის წაკითხვის უფლებები. Linux-ისთვის ეს არის /etc/passwd, ხოლო Windows-ისთვის C:\boot.ini. სხვათა შორის, Windows ჩვენთვის ნაკლებად საინტერესოა, ამიტომ შემდგომში ვისაუბრებთ passwd-ზე

/etc/passwd

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

მოქმედება=../etc/passwd%00
?action=../../etc/passwd%00
?action=../../../etc/passwd%00
?action=../../../../etc/passwd%00
?action=../../../../../etc/passwd%00
?do=../etc/passwd%00
?do=../../etc/passwd%00
?do=../../../etc/passwd%00
?do=../../../../etc/passwd%00
?do=../../../../../etc/passwd%00
?id=../etc/passwd%00
?id=../../etc/passwd%00
?id=../../../etc/passwd%00
?id=../../../../etc/passwd%00
?id=../../../../../etc/passwd%00

თუ კი, მაშინ თქვენ იცით, რომ ისინი ცდილობდნენ ეპოვათ php მოიცავს თქვენს საიტზე (კარგად, ან თვითნებური ფაილების წაკითხვის შესაძლებლობა, მაგრამ ჩვენ ახლა ეს არ გვაინტერესებს). ასე რომ, თუ თქვენი რომელიმე პარამეტრი სწორად არ არის დამუშავებული და სრულდება ფუნქციაში მოიცავს (), შემდეგ შეიტანება /etc/passwd ფაილი, მისი შიგთავსი განიმარტება როგორც php სკრიპტი და რადგან ის არ შეიცავს php კოდის ტეგებს, ის უცვლელი იქნება ნაჩვენები ბრაუზერში. ეს იქნება „მარკერი“ კრეკერისთვის, რომ ჰქონდეს დაუცველობა.

რატომ ვწერ ამას, იმ ფაქტს, რომ შიგთავსის ძიებისას თავდამსხმელი აუცილებლად (გარწმუნებთ, რომ 90% შემთხვევაში) შეეცდება ფაილის ჩართვას /etc/passwd.

დაიცავი თავი, ბატონო!

ალბათ ახლა ფიქრობთ: „უნდა შესთავაზოს ჩვეულებრივი WAF და გაფილტროს პაკეტები მათში /etc/passwd-ის არსებობით?“. არა. ეს არის სტანდარტული გზა. ეს არის მაგალითი იმისა, თუ როგორ ფიქრობს ჩვეულებრივი ადამიანი.

მოდით ვაჩვენოთ ცოტა ფანტაზია. რატომ არ ვამატებთ php კოდს passwd ფაილის შიგთავსში? და თუ მოულოდნელად თავდამსხმელმა მოახერხა მისი ჩართვა, მაშინ ჩვენი php კოდი შესრულდება. (თქვენ ფიქრობთ, რომ ეს სისულელეა? - შეხედეთ დასკვნას)

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

მაგრამ როგორ დავამატოთ php კოდი /etc/passwd-ს, რადგან მისი სინტაქსი მკაცრად რეგულირდება? თითოეულ მომხმარებელს აქვს "კომენტარის" ველი - მომხმარებლის აღწერა, შეგიძლიათ იქ შეიყვანოთ ყველაფერი, რაც მოგწონთ (რა თქმა უნდა, ორწერტილის გარდა). ამიტომ, ჩვენ ვიღებთ და ვამატებთ მომხმარებელს სისტემაში საჭირო კომენტარით. ამის შემდეგ /etc/passwd შეიცავს შემდეგ ხაზს

root:x:0:0:სუპერმომხმარებელი:/:
დემონი:*:1:5::/:/სბინ/შ
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
უსაფრთხოების მომხმარებელი:*:1001:1001::/:

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

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

დასკვნა

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

გმადლობთ ყურადღებისთვის =)