PHP Сигурност Част 1

В една серия от постове озаглавени „PHP Сигурност“ смятам да споделям различни методи за да подсигурите вашите онлайн приложения. Надявам се те да бъдат полезни както за начинаещи така и за напреднали програмисти, занимаващи се с PHP.

В тази част ще поговря за include на файлове. Всъщност include, require, require_once са невероятни функции на PHP и са изключителни за обекто-ориентирания метод на създаване на сайтове и проложения, а и не само. Масовата практика е файловете, които инклудвате да са с разширение .inc, макар че съм срещал и .inc.php и .php или файл името да започва с долна черта (пример __header.php). В интерес на истината няма голямо значение какво е разширението. Ако желаете може да бъде .vafla-borovec. Обикновено това се прави за удобсто и семантика. Но големия проблем в случая е, че .inc файловете не се изпълняват като скрипт на момента и могат да бъдат видяни като чист текст. Да речем че имате файл с връзка към базата ви данни наречен db.inc. При положение, че не сте подсигурили този файл е вдиим и много лесно ще бъдете хакнати.

Има различни методи за справяне с този проблем. Нека започнем с най-важния и може би най-сигурния от тях. Файловете, които съдържат пароли и важни данни, които не искате да бъдат обект на наблюдение от потребителите може да ги сложите извън вашия сървър. По-просто казано извън public_html директорията, която е достъпна по един или по друг начин е достъпна за всички ваши посетители. Тази практика е често срещана и е изключително добра, аз лично я ползвам и я препоръчвам на всички програмисти. За още по-добра защита е възможно да криптирате файла, така че той да не бъде семантичен с просто око, това е подсигуряване, в случай, че все пак уеб сървърът ви бъде хакнат по някакъв начин. Наскоро хакер успях да хакне сайта на Phpbb форума и се оказа, че те държат файловете с паролите си съвсем чисти. Много грешна практика, особено за проект с толкова големи мащаби. Предполагам са си взели полука и ще поправят тази грешка в сигурността си.

Друг вариант за справяне с проблема е ако забраните достъпа на роботите на търсачките до директориите с важните ви файлове, така че те да няма начин да излязат по някакъв начин в индекса на търсачките. Пример за това:

Създавате файл robots.txt, който се намира в главната директория на уеб сървъра.

User-agent: *
Disallow: /inc/
Disallow: /admin/

Това ще ограничи по-голямата част от роботите, но не всички. Имайте едно на ум, че все още има роботи, които не възприемат този файл и го игнорират индексирайки всичко, което намерят за добре.

Още един вариант е в тези важни за вас директории съдържащи ценни и секретни файлове да сложете нулев индекс. Какво представлява този нулев индекс, ами много просто – това е файл index.php, който блокира  достъпа до директорията. Пример за това давам веднага <?php header(‘Location: /404.php’); exit(); ?>. Важното в случая е, че се имитира, че директорията не съществува и препраща към 404 страницата на вашия уеб сайт. Добра практика е след като изпратите потребителя на друго място да използвате exit() функцията, която спира изпълняването на скрипта по-надолу. В случая това не е необходимо, защото няма какво друго да се изпълни, но е добър навик да свикнете да го ползвате.

Можете да блокирате директния достъп до файловете и по още няколко методи. Например с дефинирането на константа или променлива в файлът, който ще извиква функцията include и да проверявате за нея в файлът, който се инклудва. Например:

Главен файл:

$myinclude = TRUE;

Файл, който бива инклуднат:

if (!$myinclude) exit(„direct access not permitted“);

Последния вариант, за който се сещам в момента е с малко ровичкане в .htaccess. Добавяте следните полета:

<FilesMatch „\.(inc)$“>
Order deny,allow
Deny from all
</FilesMatch>

Така всичко би трябвало да бъде наред. Това са основните методи за защита. Аз лично препоръчвам да ги комбинирате, като по този начин се очаква, че ще бъдете максимално защитени. Надявам, се статията да е била полезна и да сте научили нови практики, които да ви научат да правите по-защитени PHP кодове. Вярвам, че ще успея да намирам време по-често да обновявам тази рубрика за PHP защита, защото както знаем, това е един от най-важните аспекти в програмирането.

Дискусия