многие слышали про такие вещи, как php-инъекция, sql-инъекция, xss, которые объединяет одно общее название — уязвимости. кто-то не только слышал, но даже сталкивался с этим. самое обидное, что это, как правило, недосмотр программиста. но в некоторых случаях уязвимость основана на принципе работы скрипта (точнее, работы не так, как того ожидалось разработчиком). что же делать, чтобы эти уязвимости не появлялись?
далее идёт первая часть статьи, посвящённая php-инъекциям
php-инъекция
как правило, возникает чаще всего у начинающих программистов. допустим, есть раздел из 10 статей. не мудрствуя лукаво, программист пишет скрипт articles.php, который просто подгружает файл по имени, переданном в параметрах.
$file = 'articles/' . $_GET['file'];
echo file_get_contents($file);
вроде бы всё довольно логично. но что будет, если передать скрипту такое значение:
http://site.ru/articles.php?file=../articles.php
в этом случае перед злоумышленником предстанет полный код файла articles.php. и хорошо, если веб-сервер настроен корректно и у php нет доступа к системным файлам. иначе можно будет если и не распрощаться с сервером, то рассчитывать на трояны точно.
поэтому всегда и все переменные, пришедшие от пользователя, требуют обработки. если было решено передавать в параметрах полный путь к файлу, то в скрипте обязательно нужно сделать проверку на то, что запрашивается разрешённый файл. в данном примере лучше вообще запретить слэши и точки, оставив лишь буквы латинского алфавита, цифры и небольшой набор символов-разделителей. например, так:
$file = 'articles/' . preg_replace('![^a-z0-9_-]!i', '', $_GET['file']) . '.txt';
if (file_exists($file)) {
echo file_get_contents($file);
} else {
echo 'Ошибка. Статьи не существует';
}
после этого имена файлов следует составлять только из допустимых символов: буквы латинского алфавита, цифры и символы _ и -.
краткий итог:
1. никаким данным, пришедшим от пользователя, доверять нельзя. это могут переменные из $_GET, $_POST, $_COOKIE, $_REQUEST, а также из $_SERVER с ключами, начинающимися с HTTP_*. использовать их в «ключевых местах» (работе с файлами, запросах в бд, выводе в браузер и т. п.) можно только после предварительной фильтрации/проверки;
2. при формировании структуры навигации (в примере выше — по статьям), использовать минимально возможный достаточный набор символов. если статьи пронумерованы и лежат в отдельной папке, проще передавать скрипту только число (номер статьи), который будет легко обезопасить с помощью кода:
$file = (int) $_GET['file'];
— здесь принудительно преобразуется тип к целому.

днём интернета

шоколадкой для работы мозга

коробочкой ароматного чая для бодрости

продлением хостинга на +1 месяц
Мой сервер тестировал один знакомы программист. Сказал, что уязвимости есть, но ими воспользоваться могут только очень опытные хакеры. Так что радуюсь пока, может и пронесет.
Самостоятельно мне во всем этом не разобраться. А нанимать денег нет.
Для эксплуатирования некоторых уязвимостей могут существовать эксплойты. Тут уж любой школьник-двоечник напакостить сможет.
А что понимать под фразой «свой сервер», собственный VPS/VDS, или сервер реально?
Ну до таких высот не доросли. Мой — значит тот где лежит сайт. Вроде бы запрет по ip хорошо закрывает основные «дыры».
Понятно
Только хостер не даст кому-то исправлять системные конфиги. Хорошо, если пофиксит указанные баги.
Запрет по IP-адресу закрывает админку (ты об этом?) от доступа к файлам, расположенным в wp-admin. Но могут быть уязвимости и вне этой директории, и тогда, в зависимости от серверных настроек, можно получить доступ ко всем соседям.
Опасные вы люди, программисты ;) Одни делают хорошо, другие ищут лазейки.
Об этом и речь, что уязвимости еще остались, но достаточно сложные для школьников. И этому рада.
А чего сразу программисты? Мы ж добрейшей дыши люди, сеем разумное и вечное.
Очень хорошо, если никто воспользоваться не сможет. Пусть так и останется
Аминь
Безопасности всем нам! Спасибо за интересный пост.
Надежда, спасибо за развитие темы