- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
function tuc1($mensaje)
{
if (ereg("^[a-zA-Z0-9\-_ ]{1,255}$", $mensaje))
{
return $mensaje;
}else{
echo "Сука тебе пиздец мразь,айпи записан менты уже едут.А пока пшел нахуй отсюда.";
include('footer.php');
exit();
}
}
$stana=trim(htmlentities(stripslashes(tuc1($_GET["p"]))));
Follow us!
https://translate.google.com/#es/ru/mensaje
ноль деленный на 3 ноля = треть ноля
учи алгем
À la guerre comma à la guerre
Когда твой друг в крови,
Будь рядом до конца.
http://www.youtube.com/watch?v=BDLkGBH38gs
Да, grep тут не поможет.
Ну не так уж и глупо. Логи со всеми параметрами не раз помогали в разборе полётов. Правда писал я их не апачем.
> Во-вторых, небезопасно.
Ну у меня в одном json-сервисе параметры, содержащие "password", логируются как ********. А какие еще могут быть уязвимости помимо засветки паролей в логе и засирания диска?
Пост-переменные это не только пароли. Это ещё и ценный мех.
Для разбора полётов стоит подумать о чём-то более естественном. xdebug, тащемта, если сервер отладочный.
В плане же рассматриваемого вопроса, журналировать все переменные только для того, чтобы узнать, почему хакер ввёл русскую букву или апостроф - ад угара.
Ну зависит от нагрузки и ответственности тащемта.
В данном случае json rpc демон, работающий на правах бога-из-машины. Умеет запиливать/выносить юзеров, дропать базы и т.п. Вызывается он совсем не часто. А вот если забагует - очень хотелось бы знать, когда и почему. Поэтому там все запросы/ответы полностью логируются.
> это не стопроцентно надёжно
В моем случае - сойдет. На крайний случай лог можно писать на удаленную машинку, которой можно доверять, или хотя бы дать права только на append.
ПОЦОНЫ НЕ ПРИНИМАЙТЕ ТАКИЕ GETЫ У МИНЯ ТАК ХОСТИНГ УМЕР МУSQL РАЗВАЛИЛАСЬ ПИШУ С ПХП