Всички софтуерни продукти за защита на 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 кодер. Вторият най-популярен търговски продукт за защита на скриптове. След появата на публични декодери за Zend, той става все по-използван и инсталиран на споделен хостинг. Позволява ви да криптирате не само скриптове, но и шаблони, xml-документи, изображения, двоични файлове. Свързва защитени файлове със сървъри, има мощен обфускатор, поддържат се всички операционни системи. Няма публични декодери, но в някои случаи може да бъде премахнат от deZender.
PHTML кодер. Рядка търговска система за сигурност, която осигурява обичайната функционалност за продукти от този тип, работи под всички операционни системи. Срещу отделна такса можете да закупите оригиналните кодове за сигурност и да ги модифицирате, за да отговарят на вашите нужди. Няма публични декодери.
DWebEncoder. Екзотична защита за Windows, предназначена за създаване на скриптирани презентации и каталози на компактдискове. В инсталираната форма това е нещо като независим уеб сървър, на който се изпълняват кодирани php скриптове. Няма публични декодери.
PHP Compact. Защитата е по-скоро теоретична, отколкото практическа. Разработен е на един от родните форуми, но изглежда не е напреднал отвъд изданията на автора. Няма декодери, както и защитени скриптове.
Добавка с отворен код към старинните php ускорители Turck MMCache и eAccelerator. Преобразува скриптове в байткод, за да увеличи скоростта на тяхното изпълнение. Има версии на модули за Windows и Linux. Няма публични декодери, но може би отвореният код на проекта по някакъв начин ще помогне в изследването.
Защити на ниво източник:
PHP LockIt! ... Популярна търговска защита, тя е много разпространена, главно в скриптове от чуждестранни разработчици. Позволява ви да зададете пробен период за работа на скриптове, обвързване към домейни и ip-адреси, компресира скриптове с помощта на стандартни php инструменти (gzinflate). Единствената трудна част е добър обфускатор. Различните версии на защита се различават само по модификацията на модула за разопаковане. Лесно се сваля както в ръчен, така и в автоматичен режим. Без обфускатор се премахва точно до изходния код, с обфускатор изисква допълнителна обработка.CNCrypto. Няма дори демо версия в публичното пространство, анализът е извършен с помощта на защитени скриптове. Шарнирният модул не е труден за разопаковане, защитата се основава само на добро замъгляване на изходния код.
PHPCipher. Защитата е онлайн услуга. В сайта се качва архив с вашите скриптове и вече защитеният се изтегля обратно. Платеният лиценз ви позволява да подписвате защитени скриптове с вашите данни и да ги използвате за търговски цели. Безплатният лиценз позволява само лична употреба. Самата защита е php-модул, защитен от Zend, който се свързва със защитени скриптове.След deZend модулът за защита и получаването на всички необходими константи от него се премахва изцяло в изходния код. Няма функция за обфускация.
ByteRun Protector за PHP. Търговски продукт, в зависимост от вида на лиценза, ви позволява да защитите скриптове както на ниво сървър, така и на ниво изходен код. Защита на сървъра със стандартни функции, нищо особено. Защитата на ниво скрипт може да бъде премахната много лесно автоматично и ръчно. Няма публичен декодер за версията на сървъра.
Защитата е много популярна сред местните разработчици. Това е модул за защита, силно затрупан с празен код, който е свързан чрез включване към защитени скриптове. Алгоритъмът за декодиране е много прост, не причинява никакви затруднения при ръчно и автоматично премахване. Във всички случаи се премахва напълно в изходния код, няма функция за обфускация. Има малки функции за специални случаи на декодиране, но те няма да бъдат описани тук.
CodeLock. Друга популярна защита, чудесен пример за неграмотно програмиране. Това е php приложение, което ви позволява да кодирате както самите скриптове, така и резултата от тяхната работа в браузъра с помощта на javascript. Скриптовете могат да бъдат защитени с парола, но поради посредственото изпълнение, паролата е лесна за откриване дори без премахване на шарнирната защита. Модулът за защита е php скрипт, пълен с празен код, който се свързва със защитени скриптове. Алгоритъмът за защита е много прост, премахва се изцяло в изходния код. Няма функция за обфускиране.
TrueBug PHP Encoder, по-скоро TrueBug PHP Obfuscator & Encoder. Много интересен път за изследване. Преди версия 1.0.2 са използвани стандартните php инструменти за gzip-компресия, след версия 1.0.3 авторите са разработили свой собствен алгоритъм за компресиране. Новият продукт TrueBug PHP Obfuscator & Encoder добавя функцията за обфускация и оптимизиране на изходния код. Единственото слабо място на защитата е неизменният алгоритъм за декодиране на скрипт, но самият алгоритъм се променя за всяка версия на защитата. След синтактичен анализ защитата лесно се премахва точно в изходния код, разбира се, при условие че обфускаторът не е бил използван.
Zorex PHP CryptZ. Protection, подобно на CodeLock, е php приложение, изисква MySQL база данни, за да работи. Модулът за защита е добавен php скрипт, криптиран на няколко слоя. След анализ, алгоритъмът се премахва много лесно точно в изходния код. Няма функция за обфускация.
Безплатен PHP енкодер. Безплатна онлайн услуга за кодиране на php скриптове. Модулът за защита е 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 на мултисайт, WordPress ще пренасочи към страницата /wp-signup.php. В много теми страницата не изглежда много привлекателна, така че ще направим своя собствена.
Основен сайт на мрежата
По подразбиране WordPress отваря страница за регистрация (wp-signup.php) в основния домейн (сайт) на мрежата. Въпреки това, можете да направите отделна страница за регистрация за всеки сайт в мрежата, дори ако има различни теми. Ще разгледаме случая, когато всички сайтове в мрежата имат собствена страница за регистрация, но се използва една и съща тема и сайтовете се различават само по език. Ако използвате различни теми, ще трябва да напишете повече код.
функции.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 | - | - | - | - | -... | - | - | - | -джетпак | - | - | - | - | -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. Това ви дава гъвкавост и възможност бързо да изключвате и включвате нещата.
Адрес на страницата за регистрация
За да посочите адреса на страницата за регистрация, се използва филтърът wp_signup_location. Може да се намери във файла wp-login.php и е отговорен за пренасочването към wp-signup.php.
Случай "register": 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) (връщане home_url (). "/ Регистрация /";) add_filter ("wp_signup_location", "selena_network_signup_page", 99);
selena_network е префиксът, който използвам в имената на всички функции в MU плъгините на моя сайт, за да избегна сблъсъци, той трябва да бъде заменен с моя собствен уникален префикс. Филтърът има приоритет 99, тъй като някои плъгини като bbPress и BuddyPress могат да презапишат този URL със свой собствен (MU плъгините се зареждат по-рано от обикновените плъгини, вижте по-горе). Имайте предвид, че home_url () се използва вместо network_site_url (), за да запази посетителя в същия домейн. Всеки URL може да се използва като адрес.
Създайте страница
Сега нека създадем страница с адрес site.com/signup/ през обикновения интерфейс, а в папката на дъщерната тема шаблонът за новата ни страница е page-signup.php. Вместо думата „регистрация“ може да се използва уникален идентификатор.
В новия шаблон трябва да извикате функцията selena_network_signup_main (), която ще покаже формуляра за регистрация.
Трябва да се отбележи, че целият процес с шаблони не е задължителен и вместо това можете да създадете свой собствен кратък код, който също ще извика функцията selena_network_signup_main ().
wp-signup.php и wp-activate.php
Сега нека започнем да създаваме функция, която ще показва формата за регистрация. За да направите това, копирайте файловете wp-signup.php и wp-activate.php от корена на WordPress в mu-plugings / selena-network / signup / (и не забравяйте да ги свържете вътре в mu-plugins / selena-network / регистрация / plugin.php) ... По-нататъшните манипулации с файлове са изключително трудни и отнемащи време за описване, така че ще трябва да ги направите сами. Просто ще опиша какво точно трябва да се направи и ще публикувам изходните файлове на моя проект:
- В началото на файла премахнете всички изисквания, извиквания на функции и друг код извън функциите.
- Преименувайте всички функции чрез добавяне на уникални префикси към имената.
- Увийте долната част на wp-signup.php кода във функцията selena_network_signup_main и напишете глобален $ active_signup в самото начало; ...
- Заменете оформлението със свое собствено на правилните места.
Вътре в wp-activate.php трябва да направите приблизително същото:
- Премахнете целия код извън функциите, увийте оформлението в отделна функция.
- Променете оформлението, където е необходимо.
Файлът wp-activate.php е отговорен за страницата за активиране на акаунта. Както при страницата за регистрация, трябва да създадете отделен шаблон за нея, вътре в който да извикате функцията от файла wp-activate.php.
Изпращаме писма за активиране
Страницата за регистрация изпраща на посетителя имейл с връзка за активиране на акаунта си. По подразбиране това се прави от функцията wpmu_signup_user_notification () от файла ms-functions.php. Функционалността му може да бъде заимствана за вашата функция. Причината да спрете да използвате тази функция е, защото тя изпраща връзката за активиране на акаунта от wp-activate.php. Можете да „деактивирате“ тази функция с помощта на филтъра wpmu_signup_user_notification, като зададете false (ако не направите това, писмото за активиране ще бъде изпратено два пъти, добре, всъщност две различни писма).
Функция armyofselenagomez_wpmu_signup_user_notification ($ user, $ user_email, $ ключ, $ meta = array ()) (// ... // Код от функция wpmu_signup_user_notification () wp_mail ($ user_email, wp_specialchars_decode ($ message_headers), $ message_headers); върне false;) add_filter ("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);
В резултат на това страницата за регистрация в темата Selena изглежда много по-чиста и по-точна.
Заключение
Има много други не много правилни начини да направите същото в Интернет - Apache пренасочвания, AJAX форми, които няма да работят без Java Script и т.н. собствен уебсайт.
Имайте предвид, че трябва внимателно да редактирате файловете и да се опитате да не се отклонявате много от оригинала, така че в бъдеще, ако WordPress промени файловете wp-signup.php и wp-activate.php, ще бъде по-лесно да ги сравните, за да намерите промени.
Не забравяйте да разгледате изходния код на всички функции, описани по-горе, за да разберете напълно какво и как се случва вътре в кода.
Бонус. Защита от спамер
Дори и най-малките WordPress сайтове са обект на чести регистрации за спам. Можете да пишете безкрайни условия за филтриране на ботове, често повече като опит за създаване на изкуствен интелект 🙂 В случай на мултисайт, обичайното пренасочване в Apache много ми помогна, с което при отваряне на /wp-signup.php и /wp- acitvate.php, поисках 404 (аз не съм експерт по конфигурацията на Apache, така че правилата ми може да не са много правилни).
RewriteEngine на RewriteBase / RewriteRule ^ wp-signup \ .php - RewriteRule ^ wp-активиране \ .php - # НАЧАЛО WordPress # Не докосвайте правилата на WordPress по подразбиране :) # ... # КРАЙ WordPress
P. S. Опитвам се да опиша възможно най-подробно някои неща на трети страни, защото когато започнах, понякога нямаше кой да подскаже и обясни много неща. Вярвам също, че подобни малки съвети за други материали ще подтикнат някой да научи нещо ново и да разшири полето си на знания. В записите на RewriteRule се използват регулярни изрази, те изобщо не са сложни, например символът ^ означава началото на ред.
„Те разбиват банкови сайтове за пари, Пентагона за шпионаж и никой не се нуждае от моя проект“, за съжаление, така мислят повечето собственици на лични блогове, интернет визитки, виртуални офиси на малки компании. Само няколко души мислят как да защитят сайта, но напразно. В съвременните реалности абсолютно всяка платформа, независимо от вида или популярността, представлява интерес в очите на хакерите. Кой може да се нуждае от вашия ресурс и защо? Нека го разберем:
1. Шеги на scriptkiddis. Жаргонът се отнася до амбициозни хакери, които правят първите си стъпки към „тъмната страна“. След като са придобили няколко инструмента или са написали няколко свои собствени програми, те са нетърпеливи да тестват работата си на първата жертва, на която попаднат, и като правило избират най-лесните (слабо защитени и неактуализирани CMS) цели.
2. Черно SEO. Услугите на нечестни оптимизатори все още се използват - все още се практикува поставянето на скрити връзки в кода на проекти с повече от 10 TCI. И на първо място, ресурсите на двигатели с отворен код (Joomla, Drupal, OpenCart и така нататък) са обект на атака.
3. Изграждане на ботнет. Защитата на WordPress с htaccess и плъгини също е уместна, защото абсолютно всеки ресурс може да се използва за създаване на зомби мрежа, използвана при DDoS атаки, спам и т.н.
4. Съпътстващи щети. И накрая, може да не бъдете атакувани - основната цел ще бъде хостинг, а сайтът ще служи само като една голяма уязвимост на ИТ инфраструктурата на доставчика. Разбира се, хакерите няма да се интересуват от съдбата му.
Последиците от хакването могат да бъдат най-неприятни: загуба на съдържание или ресурс като цяло, песимизиране на резултатите от търсачките, загуба на аудитория поради надписа „Сайтът може да застраши сигурността на компютър или мобилно устройство“ и дори рискът да бъдете замесени в наказателно дело, ако са извършени незаконни действия на базата на вашия уеб ресурс.
Така че можем с увереност да кажем, че проблемите със сигурността засягат абсолютно всеки уеб администратор. И ако ги пренебрегнете, всички усилия за популяризиране на търсачката (а това са пари и ценно време) могат да отидат на вятъра за една нощ. Проблемът е много спешен, затова реших да започна поредица от статии, посветени на мрежовите заплахи и методите за справяне с тях. Популярната CMS система – Wordpress ще бъде разгледана в три броя.
Методи за защита на WordPress сайт
Един от най-примитивните методи за хакване е грубата сила. Буквално терминът се превежда като „груба сила“ и означава получаване на двойка вход / парола чрез грубо изброяване на възможните опции. Често брутфорсърите се опитват да улеснят живота си, като се възползват от грешки в настройките на двигателя и сървъра - това им помага например да разберат името на акаунта, което значително намалява броя на комбинациите. Става дума за елиминирането на тези уязвимости, както и за методите за борба с опитите за неоторизиран достъп, които ще бъдат обсъдени.
1. Използвайте уникален администраторски вход
По подразбиране системата предлага да създадете потребител с име администратор. Въпреки това, за да защитите своя WordPress сайт, най-добре е да използвате вход, състоящ се от набор от произволни букви и цифри. На жив ресурс името на администратора може да бъде променено без проблеми, като се използва един от двата метода:
Чрез административния панел. Отидете в секцията „Потребители“, щракнете върху бутона „Добавяне на нов“ и създайте акаунт. В полето „Роля“ изберете „Администратор“ и потвърдете операцията. След това влезте отново от името на новосъздадения акаунт, върнете се в секцията „Потребители“, изберете „admin“ и щракнете върху „Изтриване“. В прозореца, който се отваря, поставете радио бутона в позицията „Свързване на цялото съдържание“ и изберете нов администратор от падащия списък, след което щракнете върху „Потвърждаване на изтриването“.
... Използване на phpMyAdmin. Много по-лесно е да извършите същата процедура чрез контролния панел на базата данни. Изберете необходимата база данни, намерете таблицата wp_users, намерете реда „admin“ (ID = 1), щракнете върху „Промяна“ и въведете желаното име.
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’, ‘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>заповед разрешаване, отказ отказване от всички |
# Изберете файла със скрипт за оторизация:
В същото време би било хубаво да се погрижим за сигурността на самия htaccess. Строго погледнато, такава директива трябва да бъде изписана в основните настройки на хостинг, но предвид небрежността на някои доставчици, трябва да играете на сигурно:
Заменете желаното име вместо "вход". Остава да се генерира самата парола, както и да се криптира, защото съхраняването на такива данни в ясен текст е недопустим лукс. Има много услуги за това, но е по-добре сами да напишете необходимия скрипт. Това се прави по следния начин:
1) Създайте .php файл в бележника, например crypt.php
2) Въведете кода там, като замените паролата си вместо думата "Парола":
3) Запазете файла и го качете в главната директория
4) Следвайте връзката site_name.ru / crypt.php - хешът на паролата ще се появи на екрана
5) Запазете тази стойност във файл .htpasswd и я качете в основната директория и изтрийте crypt.php
Последният щрих е забраната за преглед на съдържанието на директорията на уеб ресурсите. Достатъчно е да добавите един ред към htaccess:
| Опции Всички - Индекси |
Опции Всички -Индекси
Това се прави, за да не могат хакерите да разберат кои файлове са в директориите на проекта. На много хостинг сайтове тази директива вече е включена в настройките на сървъра, но ако тази точка се пренебрегне, трябва да я регистрирате сами.
8. Инсталирайте captcha
Използването на captcha ще ви позволи да отрежете, ако не всички, то поне повечето от ботовете с груба сила, и в същото време. Директорията с приставки за защита на сайта на WordPress предлага много опции. В допълнение към свързването на собствено решение от Google, голям интерес представлява Captcha от BestWebSoft от смесен (графичен и текстов) тип, който се основава на математически операции. Независимостта на услугата, яснотата и приемливото ниво на сложност правят модула един от най-добрите.
Персонализирането не е голям проблем. Разделът "Основни" ви позволява да изберете къде да се показва captcha, както и да посочите заглавие и символ за маркиране на полетата, които са задължителни.
Разделът „Разширени“ предоставя възможността да създавате свои собствени съобщения за грешки, както и да активирате допълнителни пакети с изображения, за да направите живота още по-труден за ботовете.
Друга полезна функция е вграденият бял списък с 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 адреси със запетаи |
11. Деактивирайте грешките при оторизация
При грубо налагане на пароли, нападателят ще намери за много полезно да знае, че въведените данни са неправилни. Такива съобщения се показват при всеки неуспешен опит за влизане, а WordPress също отчита какво е въведено неправилно, потребителско име или парола. За да се отървете от тях, просто трябва да добавите само един ред към functions.php:
| add_filter ("login_errors", create_function ("$ a", "return null;")); |
add_filter ("login_errors", create_function ("$ a", "return null;"));
За да направите това, изберете "Външен вид" -> "Редактор" -> "Функции на темата" в административния панел. Необходимо е да напишете кода след отварящия таг
12. Използвайте защитена връзка.
За криптиране на трафика между компютъра на потребителя и уеб сървъра има протокол https, използването на който изключва възможността за прихващане на важни данни, в нашия случай идентификационни данни. За да го активирате, първо трябва да закупите SSL сертификат, който изпълнява две функции едновременно: удостоверяване на уеб ресурс и криптиране на предаваната информация. Можете да го получите в специализирани центрове или от редица регистратори на имена на домейни. За некомерсиални цели е напълно достатъчно да се сдобиете с безплатен сертификат за входно ниво (такива се предлага от компанията www.startssl.com). Що се отнася до процеса на инсталиране, като правило, той е описан подробно в раздела за помощ на хостера.
След като получите SSL сертификат, трябва да конфигурирате пренасочване на административната част на уеб ресурса към защитена връзка. В случая с WordPress това се прави с помощта на следната конструкция:
| < IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine On RewriteCond% (HTTPS) = off RewriteCond% (REQUEST_URI) = / wp-login. php RewriteRule (. *) https: |
Можете също така да наложите използването на SSL сертификати на ниво двигател. За да направите това, отворете файла wp-config.php и добавете след това
| define ("FORCE_SSL_ADMIN", вярно); |
define ("FORCE_SSL_ADMIN", вярно);
Освен това можете да настроите глобално пренасочване от http към https. За новите сайтове този подход е оптимален, като се има предвид, че Google насърчава сигурни проекти, като им дава известен приоритет в резултатите от търсенето:
| < IfModule mod_rewrite. c>Опции + FollowSymlinks RewriteEngine на RewriteCond% (HTTPS) = изключен RewriteRule ^ (. *) $ Https: //% (HTTP_HOST)% (REQUEST_URI) |
13. Блокирайте натрапниците
Ако се открие подозрителна активност от определени IP адреси, струва си да блокирате достъпа им до сайта. Това се прави по аналогия с предишния метод. Разликата е, че директивите са написани за проекта като цяло и ние изброяваме адресите на тези, които искаме да забраним:
Поръчайте Разрешаване, Отказване Разрешаване от всички Отказване от 127.0.0.1, 127.0.02 # Посочете нежелан IP
Методът е надежден, но неефективен. Първо, по някакъв начин е необходимо да се записват заявките на услугите за брутфорс и да се отделят от уважавани посетители. Второ, с масивна атака просто няма да можете да проследявате и въвеждате IP на хакери и ботове ръчно. Този метод е добър само ако администраторът има надежден черен списък с адреси.
В противен случай можете да използвате плъгин за защита на сайта на WordPress, наречен WP Cerber. Това решение е абсолютно безплатно, като същевременно предлага много впечатляващ набор от инструменти, предназначени да предотвратят хакване на CMS. Можете да го инсталирате директно от административния панел.
По подразбиране се предлагат доста разумни параметри. Броят на опитите обаче трябва да се увеличи до 5, за да се избегнат недоразумения.
В квадратчето срещу „Block IP for any wp-login.php request“ трябва да се постави отметка, ако промените администраторския адрес по описания по-горе начин.
За тези цели можете да използвате и собствения инструмент на WP Cerber:
Режимът на плъгин за защита на сайта на Цитаделата също не се нуждае от допълнителна конфигурация. Той е предназначен да "нафталира" проекта по време на масивна атака с груба сила. По-добре е да премахнете отметката от квадратчето до „Записване на опити за влизане във файл“ - това ще помогне за премахване на допълнителното натоварване на сървъра.
Разделът „Списъци за достъп“ се използва за създаване на „черен“ и „бял“ IP списък (ако имате статичен адрес, не забравяйте да го добавите към списъка с надеждни), а секцията „Инструменти“ ви позволява да импортирайте и експортирайте предварително направените настройки. Тези възможности обаче не изискват отделно разглеждане.
14. Преместете конфигурационния файл
Както разбрахме по-горе, wp-config.php съхранява такива критични данни като потребителско име и парола за достъп до MySQL, както и API ключове. Следващата стъпка изглежда е очевидна - защита на WordPress чрез htaccess чрез ограничаване на достъпа до файла:
| < Files wp- config. php>Поръчайте разреши, откажете Откажи от всички |
Има обаче и по-надежден метод. WordPress има много интересна функция, за която малко хора знаят. Двигателят позволява поставяне на конфигурационния файл едно ниво над главната директория.. php може да се премести в директорията на сайта. В този случай файлът ще стане напълно недостъпен през Интернет, докато информацията, съдържаща се в него, все още ще се чете от CMS.
15. Добавете проверка на REFERER
Добре доказан метод за защита на WordPress от спам също ще помогне, когато се изправите срещу атаки с груба сила. В крайна сметка грубото налагане на пароли в никакъв случай не е ръчна работа: за тези цели се използват специализирани програми. Това означава, че като активирате проверката на заглавки във входящи заявки, можете да отрежете ботове, които са дошли от нищото с празен HTTP REFERER:
| < IfModule mod_rewrite. c>RewriteEngine на RewriteCond% (REQUEST_METHOD) POST RewriteCond% (REQUEST_URI). (wp- коментари- публикация | wp- вход) \. php * RewriteCond% (HTTP_REFERER)!. * tekseo. su. * [ИЛИ] RewriteCond% (HTTP_USER_AGENT) ^ $ RewriteRule (. *) http: //% (REMOTE_ADDR) / $ 1 |
16. Защитете XML-RPC
От версия 3.5, възможността за деактивиране на протокола за отдалечено извикване на процедура XML-RPC изчезна от WordPress. По принцип е необходимо за взаимодействие с мобилни приложения, но не всеки има нужда от такава функционалност. В същото време xmlrpc.php се използва активно за извършване на DDoS атаки, като е ахилесовата пета на целия проект.
В допълнение, хакерите са помислили да използват XML-RPC за груба сила. Използването на метода wp.getUsersBlogs ви позволява да преглеждате идентификационни данни много по-бързо, отколкото да използвате формуляра за администратор. Тъй като много XML-RPC повиквания изискват оторизация, заявка като тази:
| < methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>админ < param>< value>< string> 12345 |
ще накара двигателя да ви каже дали предадената комбинация е правилна. За да се отървете от този бич, трябва напълно да деактивирате протокола. Това може да стане по няколко начина:
1) Като блокирате достъпа до файла xmlrpc.php чрез htaccess
изисквам_веднъж (ABSPATH. "wp-settings.php");
трябва да се регистрирате
функция remove_x_pingback ($ заглавки) (ненастроени ($ заглавки ["X-Pingback"]); връщане на $ заглавки;) 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, както и възможността за създаване на персонализиран файл. В последния случай той може също да бъде конфигуриран с потребителско име на регистрационния файл за грешки и персонализиран път на регистрационния файл за грешки. Това отваря широки възможности за системния администратор – например решението може да се използва заедно с fail2ban. Също така, не забравяйте да изберете подходящата часова зона в колоната Часова зона.
Персонализираният дневник може да се види директно от административния панел на страницата за преглед на персонализиран журнал:
Нека обобщим:
Изброените методи ще помогнат значително да повишите сигурността на вашия ресурс и да го защитите от ботове, грубо налагане, мрежови хулигани и практикуване на scriptkiddis. Всичко описано по-горе обаче е само върхът на айсберга. Нападателите имат много по-сложни методи в арсенала си. И в следващата статия ще говорим за това как да се предпазите от истински хакери, използвайки различни уязвимости на двигателя и сървърния софтуер. Както в този материал, в допълнение към общите "правила за хигиена" ще бъдат разгледани ключовите настройки на CMS, начините за промяна на кода, както и най-подходящите плъгини.
Що се отнася до сигурността на приложенията, важно е да се грижим не само за хардуера и операционната система, но и за писането на защитени скриптове. В тази статия ще научите как да запазите приложението си сигурно и по-малко уязвимо. По-долу е даден списък с мерки, които да ви помогнат да защитите приложението си от всички видове атаки:
- Проверка на входящите данни
- Защита срещу XSS атаки
- Защита срещу CSRF атаки
- Предотвратяване на SQL инжектиране
- Защита на файловата система
- Защита на данните за сесията
- Грешка при обработка
- Защита на включените файлове
Проверка на входящите данни
Когато проектирате приложението си, трябва да се стремите да го защитите от „лоши“ входящи данни. Правилото, което трябва да се спазва е нещо като: „Никога не вярвайте на това, което потребителят е въвел“. Въпреки че повечето потребители не са заплаха, винаги има възможност някой да иска да хакне вашия сайт, използвайки „лоши“ данни, въведени чрез формуляри или адресната лента. Ако винаги проверявате и филтрирате входящи данни, тогава имате голям шанс да напишете защитено приложение.
Винаги проверявайте данните си в PHP скриптове. Ако използвате JavaScript за валидиране на данни, нападателят може да го деактивира в браузъра си по всяко време. В този случай вашето приложение е изложено на риск. Никой не е против валидирането на JavaScript, но за добра защита трябва да проверите отново данните в PHP скриптовете.
Защита срещу XSS атаки
Скриптове между сайтове или XSS атака е атака, базирана на инжектиране на код в потенциално уязвими страници. Опасността е, че злонамерен код може да бъде въведен чрез формуляри и след това да се покаже в браузъра.
Да предположим, че вашият сайт има формуляр за въвеждане на коментари, които се показват веднага след добавяне. Нападателят може да въведе коментар, съдържащ JavaScript код. След подаване на формуляра данните се изпращат на сървъра и се въвеждат в базата данни. След това данните се извличат от базата данни и новият коментар се показва на HTML страницата, включително вградения JavaScript код. Може да пренасочи потребителя към някаква злонамерена страница или фишинг сайт.
За да защитите вашите приложения, стартирайте входящите данни чрез функцията strip_tags (), която ще премахне всички налични тагове. Когато показвате данни в браузър, използвайте функцията htmlentities ().
Защита срещу CSRF атаки
Следващият тип атака, който ще разгледаме, е CSRF атака или фалшифициране на междусайтови заявки. Нападателят използва различни трикове, за да получи поверителна информация или да сключи сделка без знанието на жертвата. Това се случва главно на лошо защитени сайтове, където бизнес логиката се основава на работата на GET заявките.
Най-общо казано, GET заявките са идемпотентни. Идемпотентността в този контекст означава, че една и съща страница може да бъде достъпна произволен брой пъти без никаква външна намеса. Ето защо GET заявките трябва да се използват само за получаване на достъп до информация, но в никакъв случай за извършване на различни видове транзакции.
Следният прост пример показва как незащитен сайт може да бъде обект на CSRF атака:
Да предположим, че Боб иска да извърши CSRF атака срещу Алис. Той формира специален url адрес и го изпрати на Алис по имейл:
Посетете моя уебсайт!
Ако Алис е оторизирана на уебсайта example.com и следва тази връзка, тогава 1000 $ ще бъдат прехвърлени от нейния акаунт към акаунта на Боб. Като алтернатива, Боб може да изпрати и изображение и да попълни "лошия" URL в атрибута src.
Браузърът няма да може да покаже това изображение, тъй като то не съществува, но заявката ще бъде направена без знанието и участието на Алис.
За да предотвратите този вид атаки, използвайте само POST заявки към процеси, предназначени да променят информацията в базата данни. Не използвайте $ _REQUEST. Използвайте $ _GET за обработка на GET параметри и $ _POST за извличане на POST параметри.
Като допълнителна мярка можете да генерирате уникален токен и да го прикачите към всяка POST заявка. Когато потребител влезе в системата, можете да генерирате произволен токен и да го запишете в сесията. Тъй като всички формуляри се показват на потребителя, този маркер трябва да бъде записан в скрито поле. Бизнес логиката на приложението трябва да предоставя функционалност, която ще проверява токена от формулярите и токена, съхранени в сесията.
Предотвратяване на SQL инжектиране
Трябва да използвате PDO, за да изпълнявате заявки към базата данни. С параметризирани заявки и подготвени изрази можете да смекчите заплахата от SQL инжекция.
Нека да разгледаме следния пример:
В горния код изпращаме заявка към метода за подготовка (), включваща посочените параметри:: име и: възраст. По този начин заявката е предварително компилирана за по-нататъшно заместване на данни. Когато се извика методът execute (), заявката е напълно оформена и изпълнена. Ако използвате тази техника, тогава всички опити на нападател да извърши SQL инжекция ще бъдат анулирани.
Защита на файловата система
Като отговорен разработчик, винаги трябва да пишете код, който не компрометира вашата файлова система. Нека разгледаме кода, който изпраща файл за изтегляне в зависимост от данните, предоставени от потребителя.
Този скрипт е много опасен, защото дава възможност за достъп до всяка директория, която е достъпна от файла със скрипта: директорията със сесии, системни папки и много други.
Защита на данните за сесията
По подразбиране цялата информация за сесията се записва във временната директория. Ако използвате споделен хостинг, някой освен вас може да напише скрипт и да чете данните за сесията. Затова внимавайте да съхранявате пароли или номера на кредитни карти в сесии.
Ако все още трябва да съхранявате такива данни в сесия, тогава криптирането е най-добрата мярка. Това не решава напълно проблема, тъй като криптираните данни не са 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. Всички естествени изключения трябва да бъдат обекти на класове или подкласове на Exception. Ако са изхвърлени изключения, те могат да се обработват в блока try/catch.
Защита на включените файлове
Често други файлове се зареждат в PHP скриптове, като свързване към базата данни и много други. Някои разработчици дават на тези файлове разширението .inc. PHP не анализира такива файлове по подразбиране. Ако се обърнете директно към тях, потребителят ще може да види текста на този файл. Ако хакерът успее да получи достъп до файла, съхраняващ връзката с данни към базата данни, по-късно той може да получи достъп до всички данни на вашето приложение. Затова винаги използвайте разширението .php за качени файлове и ги съхранявайте там, където няма директен потребителски достъп.
Резултат
Ако следвате изброените 8 правила, това значително ще подобри устойчивостта на вашето приложение към различни видове атаки. Не се доверявайте на данните, въведени от потребителите, защитете вашите файлове и база данни.
Нека помислим кой е хакер? Хакерът не е кракер! Хората често бъркат тези понятия. Хакерът е преди всичко човек с нестандартно мислене и това е неговата сила, така да се каже.
За да се противопоставите успешно на хакер, вие също трябва да се научите да мислите извън кутията. Както се казва, клин се избива от клин.
Днес ще ви предложа един много необичаен начин да се предпазите от атаки като php include. Разбира се, той не е подходящ за всеки. И ако честно, той предпазва не от самата атака, а от нейното откриване. Заинтригуван?
Как да намерите вкл...
Нека първо разберем как точно нападателят се опитва да намери уязвимост.
Изглежда така. Нападателят модифицира всички входящи параметри един по един, като предполага, че данните от тези параметри влизат във функцията за включване. Е, или ако по прост начин се опитва да "прикачи" файлове. И за да определи дали има уязвимост или не, той трябва да включи някакъв файл в целевата система (ако знае - има уязвимост, не - няма уязвимост).
Естествено, ако нападателят действа отвън, тогава той не знае структурата на местоположението на директориите и файловете и не може да прикачи никакъв файл, тъй като няма да знае пътя към него. Но има файлове, които винаги съществуват в системата и за които винаги има разрешения за четене. За Linux това е / etc / passwd, а за Windows нека бъде C: \ boot.ini. Но между другото Windows не ни интересува малко, така че по-нататък ще говорим за passwd
/ etc / passwd
Вероятно сте попадали на повече записи на формуляра във вашите регистрационни файлове:
Действие = .. / etc / passwd% 00
? действие = .. / .. / etc / passwd% 00
? действие = .. / .. / .. / etc / passwd% 00
? действие = .. / .. / .. / .. / etc / passwd% 00
? действие = .. / .. / .. / .. / .. / 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 include (е, или възможността за четене на произволни файлове, но ние не се интересуваме от това сега). Така че, ако един от вашите параметри не е обработен правилно и се окаже във функция включва (), тогава файлът / 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 :: /: / sbin / sh
bin: *: 2: 2 :: / usr / bin: / sbin / sh
sys: *: 3: 3 :: /:
adm: *: 4: 4 :: / var / adm: / sbin / sh
защитен потребител: *: 1001: 1001::/:
Е, в скрипта на приставката вече извършваме необходимите ви действия - забранете потребителя, блокирайте заявката, уведомете администратора.
В резултат на това имаме един вид капан, който може да защити вашия сайт от хакване.
Заключение
Да, напълно съм наясно, че всичко написано по-горе изглежда като глупост. И прекрасно разбирам, че никой няма да използва това на практика. Но не за това написах. Написах, за да покажа пример за нестандартен подход в областта на защитата.
Благодаря за вниманието =)
