Как стать автором
Обновить

Комментарии 19

Вы уже запостили баг в их трекер?
Нет пока :)
так не делают.
каким бы ни был глупым баг, сначала надо отрепортить, а потом писать в твиттер и на хабр.
желательно еще подождать пока его исправят, особенно если баг касается безопасности.
>> желательно еще подождать пока его исправят, особенно если баг касается безопасности.
Не желательно, а обязательно подождать пока его исправят.
отличный репорт!
Ваш пост похож на хвастовство… «Эй, смотрите, я нашел дыру в Kohana! Ха-ха». Почему нельзя просто исправить и сделать PullRequest?
Это конечно правильно, но то что этот парень здесь запостил — отдельная благодарность должна быть, нет?
Не вижу аргументов против, нету?
От обнародования этой ошибки пострадают люди. Достаточно понятно?
Люди чаще читают хабр, чем багтрекер коханы.
Моментально понял, где ошибка, как только зацепился глазом за preg_replace с флагом e.
Не понимаю, зачем использовать такой код, когда есть preg_replace_callback.
Grusho, это познавательно и очень интересно, но лучше спрятать топик до исправления бага.
Чтобы исправить надо изменить функцию site
c $path = preg_replace('~([^/]+)~e', 'rawurlencode("$1")', $path);
на $path = preg_replace('~([^/]+)~e', 'rawurlencode(\'$1\')', $path);
Еще в книге «PHP 5» Котеров советовал не использовать «е», а брать вместо него preg_replace_callback…
С дыркой вроде все ясно. А почему у вас возможны такие значения для param1? Все-таки первичный контроль УРЛы должны проходить еще при обработке роутов, используя заданные регекспы для сегментов адреса.
Вопрос закономерный. В некоторых ситуациях допускаем такую вольность. Согласен, возможно и зря, но, согласитесь, это не делает эту уязвимость более оправданной.
Подскажите, что это за программка которая сканировала?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.