Для того, чтобы вызвать php-info() надо сделать скрипт с этим вызовом.
Если будет скрипт — он не вызовется
Для вставки кода в существующий скрипт, надо зайти на ftp, и это сложно. надо знать пароль. Иначе надо знать, как скрипт называется и переходим к пункту 1
Если будет утащен весь сайт, то опять нужно либо по ftp заходить, либо см. первый пункт. И в любом случае придется очень долго разбираться в алгоритмах шифрования
Про ENV — это не моя идея, а создателей WP. Я за свой метод стою.
Обсуждение как-то само свелось к обсуждению пункта 1. Бежать от хостера просто, если вы не участвовали в партнерке и не накопили в ней кучу бабла. И еще если вы уверены, чтоследующий хостер будет на много лучше.
Для того, чтобы изменить существующий скрипт, надо знать его имя. Перечитайте статью, у меня нет index.php.
Понял. Вариант близок к тому, что я предлагаю. Не уверен, правда, что можно хоть что-то прохардкодить на публичном хостинге от имени рута. Если только админов попросить? Но у админов есть супер-отговорка: «Мы такого не делаем. Извините за беспокойство».
Я не очень хорошо себе представляю, как вскрываются хостинги. Все мои сведенья почерпнуты из интернетов. Я же не могу спрашивать у админов хостинга о том, как их вскрыли? Правда? С вероятностью 100% я буду послан.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл, я узнаю об этом в течение 10 минут. Если будет попытка запуска подозрительного скрипта, он не запустится, а я узнаю об этом еще быстрее.
Если злоумышленник укачает мой сайт, он очень долго не сможет расшифровать данные по доступу к базе. Я успею их поменять.
Так что я не совсем затрудняю доступ. Скорее я увеличиваю шанс того, что я вовремя его поймаю за хвост.
Если злоумышленник зайдет на мой сайт по фтп, скачает весь сайт, то ему потребуется довольно много времени, чтобы получить сведенья по доступу к базе данных. Я успею заменить все пароли к тому времени.
Если он зайдет от моего имени в мою админку на хостинге, тогда да. все пропало и можно уже ничего не обсуждать.
Но мне кажется, что не нужно успокаивать себя тем, что если кому-то надо вас взломать — вас взломают. Надо все равно попытаться злоумышленнику помешать. Мы все знаем, что умрем когда-нибудь. Но ведь живем зачем-то… сайты делаем… и все такое…
Кстати, я не предлагал бороться с проблемой выставлением жестких прав. Я всегда думал, что это так или иначе надо делать. Есть много чего в документациях на эту тему. Я эту тему просто не рассматривал.
Понял. К своему стыду у меня нет ни одного локального проекта в этой кодировке. А делать специально неохота. Но есть удобные онлайн сервисы. И некоторые даже работают.
Это как? Покажите пример, а то не совсем понятно что вы предлагаете. Если вы делаете вызов mysql_connect(..., decrypt($crypted_password), ...), то что мешает злоумышленнику сделать вызов print(decrypt($crypted_password))? Алгоритм шифрования лежит рядом, шифрование обратимое, не знаю над чем можно зависнуть на пару часов в данном случае.
Схема следующая.
Есть файл php в котором лежит заранее зашифрованные сведенья. Это строка бинарная, поэтому я ее кодирую base64. Строка зашифрованных сведений оформлена в качестве константы.
Первый же скрипт, которому нужна база расшифровывает эту строку. Ключ лежит в секретном месте. Сам ключ перед использованием меняется. К нему добавляются так называемые отпечатки пальцев (секретные). Добавили отпечатки, взяли md5 какое-то количество раз и вот то, что получилось используем в виде ключа. Для шифрования XOR-ом хорошо бы иметь ключ такой-же длины как и данные. Ну мы не лыком шиты и придумываем что-нибудь, чтобы получить ключ нужной длины. Смысл в том, что нельзя взять просто ключ, который лежит, но который надо найти. Его еще трансформировать надо правильно.
Данные расшифровываются и кладутся в глобальную сферу. Ну и все другие методы, которые лезут в базу данных, используют сведенья из глобалов.
Вот вкраце так.
Да! Поскольку зашифровать вручную практически невозможно (слишком трудно) у меня есть локальный скрипт, который делает это быстро и надежно.
В целом, когда вы используете shared хостинг, то заведомо не можете защитить себя от взлома хостера. Ведь ничего не мешает злоумышленнику добавить к вашему .htaccess строчку со своим «php_value auto_prepend_file». Такой вариант рассматривали?
Я продолжаю работать и совершенствовать свои подходы. Для того, чтобы уберечь .htaccess от прямого редактирования, нужно, на мой взгляд, использовать стандартные средства защиты ftp.
Просто так файл config.php прочитать не получится, веб сервер же не отдаёт его в открытом виде. Ну а если злоумышленник нашёл уязвимость типа чтение произвольных файлов, то зачем ему угадывать имя конфига, если почти наверняка точка входа index.php (или иная, описанная в .htaccess), и одной из первых строк будет инклуд файла с конфигом?
Проблема именно в том, что у вас на хостинге оказывается чужой скрипт. Прямо в корневой папке. И этот скрипт работает у вас на сайте от имени владельца, что есть делает все, что угодно! И бывает так, что это не ваша вина, не уязвимость сайта или кода. Советую ознакомиться со статьей по второй ссылке из подвала (детективная история). Там все описано в красках.
На счет примера я, возможно, сделаю отдельную статью, если у уважаемого сообщества возникнет интерес к теме.
Как я и говорил, система логирования и сбора плохих ури дает развеселые результаты!
Будьте осторожны! Некоторые мои регулярно клиенты держат подобные зипы в корневых папках. Причем именно те, кто сидит на выделенных серверах и кому места на этих серверах девать реально некуда!
Да! Так и есть!
Для того, чтобы изменить существующий скрипт, надо знать его имя. Перечитайте статью, у меня нет index.php.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл, я узнаю об этом в течение 10 минут. Если будет попытка запуска подозрительного скрипта, он не запустится, а я узнаю об этом еще быстрее.
Если злоумышленник укачает мой сайт, он очень долго не сможет расшифровать данные по доступу к базе. Я успею их поменять.
Так что я не совсем затрудняю доступ. Скорее я увеличиваю шанс того, что я вовремя его поймаю за хвост.
Если он зайдет от моего имени в мою админку на хостинге, тогда да. все пропало и можно уже ничего не обсуждать.
Но мне кажется, что не нужно успокаивать себя тем, что если кому-то надо вас взломать — вас взломают. Надо все равно попытаться злоумышленнику помешать. Мы все знаем, что умрем когда-нибудь. Но ведь живем зачем-то… сайты делаем… и все такое…
Кстати, я не предлагал бороться с проблемой выставлением жестких прав. Я всегда думал, что это так или иначе надо делать. Есть много чего в документациях на эту тему. Я эту тему просто не рассматривал.
Я не очень знаком с разделом рутирования хостингов. Возможно, администрация как-то все же защищается от настолько явных дыр.
Схема следующая.
Есть файл php в котором лежит заранее зашифрованные сведенья. Это строка бинарная, поэтому я ее кодирую base64. Строка зашифрованных сведений оформлена в качестве константы.
Первый же скрипт, которому нужна база расшифровывает эту строку. Ключ лежит в секретном месте. Сам ключ перед использованием меняется. К нему добавляются так называемые отпечатки пальцев (секретные). Добавили отпечатки, взяли md5 какое-то количество раз и вот то, что получилось используем в виде ключа. Для шифрования XOR-ом хорошо бы иметь ключ такой-же длины как и данные. Ну мы не лыком шиты и придумываем что-нибудь, чтобы получить ключ нужной длины. Смысл в том, что нельзя взять просто ключ, который лежит, но который надо найти. Его еще трансформировать надо правильно.
Данные расшифровываются и кладутся в глобальную сферу. Ну и все другие методы, которые лезут в базу данных, используют сведенья из глобалов.
Вот вкраце так.
Да! Поскольку зашифровать вручную практически невозможно (слишком трудно) у меня есть локальный скрипт, который делает это быстро и надежно.
Я продолжаю работать и совершенствовать свои подходы. Для того, чтобы уберечь .htaccess от прямого редактирования, нужно, на мой взгляд, использовать стандартные средства защиты ftp.
Проблема именно в том, что у вас на хостинге оказывается чужой скрипт. Прямо в корневой папке. И этот скрипт работает у вас на сайте от имени владельца, что есть делает все, что угодно! И бывает так, что это не ваша вина, не уязвимость сайта или кода. Советую ознакомиться со статьей по второй ссылке из подвала (детективная история). Там все описано в красках.
На счет примера я, возможно, сделаю отдельную статью, если у уважаемого сообщества возникнет интерес к теме.
Хотел добавить. Только вчера я просматривал результаты очередной атаки на свой сайт. Знаете что хотели утянуть?
/index.zip
/files.zip
/htdocs.zip
/file.zip
/www.zip
/belkin-labs.zip
Как я и говорил, система логирования и сбора плохих ури дает развеселые результаты!
Будьте осторожны! Некоторые мои регулярно клиенты держат подобные зипы в корневых папках. Причем именно те, кто сидит на выделенных серверах и кому места на этих серверах девать реально некуда!