Сигурност на PHP заявки и скриптове
Съдържание:
Въведение в сигурността на PHP:
Хиляди хора по света търгуват чрез хакване на уебсайтове и цели мрежи. Така си изкарват хляба. В тази статия ще ви научим как да заобиколите най-популярните методи за хакване на PHP. Няма нищо перфектно на света, включително перфектната защита на PHP кода. Въпреки това можете да защитите себе си и сайта си добре, като използвате стандартните настройки и техники засигурност.
Често допускани грешки
Грешки като тази са често срещани на уебсайтове: Предупреждение: Използване на недефинирана константа LOCAL_SERVER — предполага се „LOCAL_SERVER“ в /web/includes/page-definitions.php на ред 13
Това е една от стандартните PHP грешки, която е не само грозна за окото на потребителя, но и потенциално вредна засигурността на сайта. Такива грешки в кода трябва да бъдат уловени и сортирани.
Функцията error_reporting ни позволява да решим кои грешки искаме да видим. По принцип е достатъчно просто да изключите показването на всички грешки (error_reporting(0)), но не трябва да правите това, защото ние просто искаме да виждаме грешки в php кода, които вредят на сигурността.
Константата за всички php грешки е E_ALL. PHP 5 въведе константата E_STRICT, за да посочи строги забележки относно кода. Разбира се, желателно е да ги видите, но те не са включени в E_ALL, така че ще използваме числената стойност error_reporting(8191), която включва всичко до нови PHP 6 грешки.
Забележка: error_reporting(E_ALL E_STRICT) не е подходящо, защото тогава PHP 4 ще се оплаква, че не знае какво е E_STRICT. С цифрова стойност няма да има проблеми.
Добавяме проверка за DEBUG - константа, зададена в конфигурацията, и използвайки set_error_handler, ще хващаме грешки ввече работеща услуга. Между другото, вашият репортер за грешки трябва да върне true, в противен случай PHP ще изведе стандартна грешка.
директива register_globals
Преди версия 4.2.0 директивата register_globals беше активирана по подразбиране в PHP. Това доведе до факта, че мнозина са свикнали с факта, че ако е във формуляра, тогава в PHP кода можете да проверите дали ($username == 'admin')…
Това обаче е потенциална дупка в сигурността, водеща до много хакове. Следователно променливите POST, GET и COOKIE трябва да бъдат достъпни чрез суперглобалните $_POST, $_GET, $_COOKIE. Много хора го намериха за твърде трудно, така че командата import_request_variables стана популярна, връщайки всичко към нормалното.
Друг проблем с register_globals:
SQL инжектиране и сигурност на заявките
Сред начинаещите програмисти в php тази конструкция е популярна:
Тя не е в безопасност. Ако потребителят въведе ‘ ИЛИ `username` = ‘admin’ вместо парола, системата ще го въведе като администратор. Горният пример, разбира се, е елементарен. Но ако не решите проблема глобално, винаги можете да пропуснете някоя заявка, предмет на SQL инжекция.
- премахнете наклонени черти от цялата входяща информация, ако има такава.
- цялата информация, постъпваща в SQL заявката, се филтрира от функцията mysql_real_escape_string, специално създадена за тази цел (или аналог за друга база данни).
Създаваме функция за филтриране (mysql_real_escape_string е дълъг и е свързан с формата на проверка. И ако трябва да промените филтъра?)
и го използвайте навсякъде. Веднага след като някои динамични данни бъдат изпратени на SQL, ние незабавно използваме цитат:
Проверка на данни
Съветвам ви да проверявате всичко, което потребителят въвежда, тъй като за нас всеки потребител може да бъденападател. Опитайте се да не филтрирате, а да валидирате. С други думи, създайте не черен списък, а бял списък. Вместо
Има няколко команди, с които трябва да се работи много внимателно. Това са include, require, readfile, eval, ", system, exec, create_function, dir, fopen и други подобни. Проверете всичко три пъти, ако ги използвате. В крайна сметка, ако използват данни, които могат да дойдат от потребителя, бъдете сигурни, че някой със сигурност ще ги използва.
Това парче е опасно. Ако нападателят въведе „../../../../../etc/passwd%00“, той ще получи паролата и ще бъде щастлив. Ти не си.