Уязвимост на PHP и защита от инжектиране на PHP. Правила за безопасно програмиране на PHP

Всички ние, по един или друг начин, бихме искали да сме сигурни, че никой не може да хакне нашия уебсайт или блог. Но уви, реалността е, че всяка система е уязвима, без значение колко силна би била защитена. Всичко зависи само от ресурсите и упоритостта на един крадец ... Хм ... Нещо ме дръпна в грешната посока ... Нека считаме това за предисловие =)

Не толкова отдавна писах за това как. Но да речем, че сте взели готов CMS и не знаете как се изпълнява изтеглянето там и просто направете цялата защита. Разбира се, особено любознателните и компетентни разработчици ще проучат кода на тази CMS, преди да я поставят на сайта си. Но какво да кажем за тези, които нямат толкова много време?

Е, или да кажем, че сте един от тези, които вярват, че сигурността и правилна настройкасървъра не е излишен? Ако е така, добре дошли под кат.

Не, в статията няма да намерите някакъв супер дупер плъгин, който филтрира всички данни, които трябва да бъдат включени във всички файлове. Идеята ми е да използвам директивата auto_prepend_fileи изграждане на списък с разрешени файлове ... Но като цяло, прочетете сами ...

Тази идея седи в главата ми дълго време, но най-накрая се хванах за нея, въпреки че тук няма нищо сложно и успях да внедря тази система и да напиша статия =)

Принцип на действие

Както казах по-горе, системата се основава на действието на директивата auto_prepend_file V php.ini. Тя отговаря за инсталирането на скрипта, който ще бъде изпълнен ПРЕДИ да бъде изпълнен основният.

Например отворихте index.php и преди неговото изпълнение, файлът, посочен в auto_prepend_file. Основното е, че в този скрипт можем да контролираме по-нататъшна работадруги скриптове. Грубо казано, продължете да работите и изпълнете искания скрипт или излезте веднага ( умирам()).

Например ситуацията - нападател е качил shell на вашия сайт чрез някакъв вид уязвимост и се опитва да го отвори в браузър. И вместо черупката му, без причина, му се дава, ето такава грешка:

Нещо подобно би ме вкарало в ступор...

За да работи системата ми, имам нужда от списък с разрешени файлове, достъпът до файлове, които не са в този списък, ще бъде блокиран.

(Не знам дали тази диаграма е необходима, изглежда, че така или иначе всичко трябва да е ясно ...)

Разбира се, съставянето на такъв списък ръчно не е благородно нещо, така че стигнах до извода, че има смисъл да внедря така наречения "режим на обучение". Режимът, при който всички извиквания към всички скриптове автоматично ще бъдат добавени към списъка с разрешени файлове.

Какво дава? Можете да стартирате тази система в режим на обучение и да продължите да използвате вашия сайт. Докато го използвате, вашата база данни ще се попълва с онези страници, които използвате (съжалявам за играта на думи). И да кажем след месец - друг списъкът ви ще съдържа всички файлове, които са свързани с вашия сайт (до който сте имали директен достъп).

И имайте предвид, че списъкът ще съдържа само онези файлове, с които ще работите директно. Обичайният среден двигател на сайта има куп включени файлове (с класове, функции, библиотеки, модули и т.н.), тези файлове няма да бъдат включени в този списък и достъпът до тях ще бъде блокиран в бъдеще на нивото на нашия защита (разбира се, средните двигатели имат защита от директно стартиране, но изведнъж някъде тази защита е пропусната).

Какво можем да направим

Тъй като това е концепция, не знаем колко.

  • Блокиране на неоторизирани скриптове (всъщност основната функция). Но отново, това е конфигурируемо, не можете да блокирате връзката, а само да уведомите администратора по имейл
  • Уведомяване за нелегитимни искания до администратора по имейл (кратък отчет или пълен отчет, последният включва заглавки на пакети и данни POST заявкаако има такива)
  • Можете да посочите IP на администратора, който ще има достъп до всякакви скриптове, т.е. тази систематова няма да бъде засегнато (тези IP адреси няма да участват в режим на обучение). Например, няма нужда да затваряте .htaccessсофтуер като PhpMyAdmin, SupexDumper и други системни помощни програми.
  • Между другото, IP адресите поддържат прости маски =)
  • Напълно коментиран код и подробно описание на всяка конфигурационна директива
  • Ха какво още...

Настройка

Сега за това как да вградите тази защита във вашия сайт...

За да направите това, имате нужда от достъп до файла php.ini

  1. Първо изтеглете самия скрипт: PrependSecuritySystem
  2. Разопаковайте съдържанието на архива (data.txt и main.php) в някоя папка на сървъра, за предпочитане в папка, която не е достъпна от мрежата (не е необходимо, защото ще работи във всяка, има смисъл да премахнете сценарий далеч от очите на кракера)
  3. Отворете файла main.php и редактирайте настройките. Необходимо е да смените ip адреса и имейла на администратора. Останалите настройки зависят от вас.
  4. Задайте разрешения за разопаковани файлове. Под niks е желателно да смените собственика и на двата файла, различни от потребителя, под който работи уеб сървъра. За файл main.phpнеобходимо е да деактивирате записа за всички. За файл data.txtтрябва да зададете разрешения за четене и писане за всички (това е временно, за периода на обучение)
  5. Ние отваряме php.iniи въведете следното:
    auto_prepend_file=[път към разопакования main.php файл]
  6. СЪС този моментзапочва системно обучение. Изчакваме определено време, достатъчно според вас за пълното обучение на тази система.
  7. В края на обучението отворете файла main.phpи редактирайте константата PSS_STATUS_BLOCK, задайте стойността му на вярно, запазете
  8. Променете разрешенията за файла data.txt. Забраняваме редактирането даден файлза всички.
  9. Сега системата е преминала в режим на блокиране на неоторизирани скриптове

Твърде много стъпки, разбира се, но ми се струва, че дори дете може да се справи.

Ако трябва да преквалифицирате системата (от нулата или да я допълните), тогава трябва да:

  1. Разрешаване на запис във файла data.txt
  2. Изчистване на съдържанието на data.txt (САМО ако трябва да преквалифицирате системата от нулата)
  3. Редактиране на константа PSS_STATUS_BLOCKвъв файл main.phpкато зададете стойността му на невярно
  4. Ние се преквалифицираме...
  5. В края на преквалификацията редактираме константата PSS_STATUS_BLOCKзадаване на стойността му обратно на вярно
  6. Ние забраняваме писането на файла data.txt

Е, сега за тъжното

Няма да прикривам, а сега ще говоря за недостатъците.

  • Може би основният недостатък, в сравнение с който всички останали избледняват, е, че тази система може да бъде заобиколена. Питате: как е? Всичко е много просто, директивно auto_prepend_fileможе да се посочи и в .htaccess. И ако подходите трезво, тогава ако нападателят внезапно е успял да напълни черупката, тогава със сигурност той ще може да напълни своята .htaccessв който може да деактивира оригиналната директива.
    Това работи само под апаш, но например под nginxтози трик няма да работи (nginx няма .htaccess файлове). НО! Под Nginx обикновено можете да качвате .
  • Нападателят може да редактира „разрешен“ скрипт, ако има валидни права за това, и нашата система, за съжаление, не може да направи нищо по въпроса. Освен ако не трябва да зададете правилните разрешения за всички изпълними файлове
  • Освен PHP има всякакви perl, cgi и прочее...тази система не работи с тях.
  • Допълнително натоварване. Но vrtyali това натоварване ще бъде забележимо.

Ето защо изглежда, че такава оригинална система не може да се нарече идеална. Но е доста подходящо като проста превантивна мярка, която ще спре не най-упоритите упорити крадци. Най-малкото, тази система ще може да отнеме време на нападателя да извърши атака. Например, системата ще уведоми администратора за опит за хакване, като по този начин ще му даде възможност да поправи уязвимостта, докато нападателят разбере причината за неуспехите си.

Заключение

Все пак, както и да е, това е концепция, може би можете да измислите нещо по-добро въз основа на нея. Или може би моята система ще ви подхожда.

Според мен разумна защита не се случва много. От вас зависи да използвате нещо подобно или не на вашите сайтове.

уф. Е, написах, почти целия ден го нямаше. Извинете ме, ако го описах малко хаотично. Като цяло задайте въпросите си в коментарите, ще се опитам да отговоря.

PS: въпреки че кодирах възможно най-адекватно, скриптът може да има грешки. Тествано на win/apache/php 5.2 - всичко беше наред.

Лозунгът "Сигурността не е шега работа" може да се намери на летищата по целия свят. Всеки един и същ лозунг Системен администратортрябваше да е закотвен до моя PHP сървър. И всеки, който се свързва към сървър, разположен в Интернет, трябва да вземе подходящи мерки за сигурност или рискува да загуби данни и дори пари, защото злонамерени хакери софтуермогат да причинят щети с помощта на клавиатурата на своя компютър.

Разработчикът на сайта, загрижен за проблемите на сигурността, е длъжен постоянно да повтаря: „Не се доверявайте на мрежата“. Ако се притеснявате за защитата на вашия сайт, повторете тази поговорка, докато кодирате бъдещи страници на вашия сайт. Всяка информация, предадена на сървъра по мрежата (било то URL адрес, данни от HTML формиили данни, идващи през някой друг мрежов порт) трябва да се считат за потенциално опасни. Тази статия предлага няколко метода за защита на входящата информация. Необходимо е не само да се прилагат тези методи, но и да се обърне внимание на определено времеза да открие други потенциални опасности и да намери начини за предотвратяването им.

Второто основно правило за създаване на защитен сайт е: „Минимизиране на щетите“. Какво се случва, ако програмата, която пишете, която смятате за доста надеждна, всъщност се окаже уязвима? Дори само да остана вътре пълна сигурност, ограничават щетите, които нападателят може да причини, използвайки тази уязвимост.

Когато посетителите дойдат на вашия сайт, те се надяват, че сайтът съдържа валидна информация, която няма да навреди на тях или техните компютри, и че предоставената от тях информация ще бъде обработена правилно. За посетителя винаги съществува известен риск от нарушаване на защитата при взаимодействие с всеки сайт, независимо дали е развлекателен, информационен или сайт за електронна търговия. Отговорност на дизайнера на сайта е да защити посетителите от подобни рискове. Това означава, че трябва не само да съхранявате сигурно информацията, предоставена от посетителите на вашия сървър, но и да вземете мерки за защита на информацията, предоставена по време на предаването й от компютрите на посетителите към вашия сървър.

Но всички тези съображения не трябва да пречат на вашите намерения, като например да направите сайта си за електронна търговия онлайн.

Възможни атаки

Свързването на сървър към интернет може да се сравни с отварянето на магазин на оживена улица. Бихте искали да имате много посетители, но без да вземете предпазни мерки, може да откриете, че не обикновени посетители, а много нежелани гости ще се възползват от вашето невнимание.

Обикновено хакериобадете се на тези, които биха били по-правилни да се обадят крадци с взлом софтуерна защита . В компютърната общност кракерите за сигурност са специалисти, които, използвайки късмета или уменията си, преодоляват защитата. компютърни системии причиняват щети. А хакерите са програмисти, които могат майсторски да пишат програми и са в състояние не само да разбират сложен код, но и да пишат сами ефективен (и често недостъпен за външни лица) код на много езици. За един програмист титлата хакер е чест, а титлата софтуерен кракер изглежда означава, че нейният собственик трябва да следи бележките за търсене.

Без да осъзнават колко унизително е заглавието софтуерен кракер, много начинаещи програмисти тръгват по този път, като прибягват до инструменти и скриптове, които намират в мрежата. Такива начинаещи кракери се наричат ​​script-kiddies или по нашенски coolhackers. Тези хора често дори не знаят какво правят. Обикновено тази категория нападатели стои зад примитивни атаки като компрометиране на сайт, XSS и SQL инжектиране.

Компрометиране на сайта и XSS атаки

Компромисите на сайтове, които по-често са неприятни, отколкото действително вредни, са доста често срещани, тъй като много сайтове предоставят възможност на кракер за сигурност да обяви на света, че е успял в целта си. Понякога един уеб браузър сам по себе си е достатъчен, за да компрометира лошо проектиран уебсайт. Помислете например за следната програма:

Страница с проста форма за добавяне на коментари ".$row["текст"].""; } } ?> Основи на PHP



Тази програма внедрява система за коментари в много примитивна форма (ако сте чели моето ръководство за PHP от самото начало, може да не сте запознати с операциите с бази данни; ако е така, препоръчвам ви да се върнете към тази статия, след като прочетете съответния материал за MySQL).

Четейки този код, опитен програмист започва да се чувства несигурен (запомнете - "Не вярвайте на мрежата"). Такава програма приема данни от формуляри, които се очаква да съдържат текста на коментар. Този текст се присвоява на променливата $comment и се съхранява в базата данни за показване на бъдещи посетители. Ако въведените данни са това, което очакваме, тогава няма да има проблеми.

Сега се поставете за момент на мястото на coolhacker и си представете какво би се случило, ако входът съдържаше HTML тагове. Това проста програмаще вмъкне механично такива дескриптори в генерираната страница и тази изкривена страница ще бъде разгърната в браузърите на други посетители вместо нормалната. Един дескриптор, който може да бъде особено опасен от гледна точка на сигурността на данните, е дескрипторът

Зареждане...
Връх