Комментарии 33
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Пусть бы лучше новички совершали эту ошибку почаще чем оставляли все как есть…
И кстати по-моему что-то кроме цифр передавать через гет просто некрасиво :)
И кстати по-моему что-то кроме цифр передавать через гет просто некрасиво :)
НЛО прилетело и опубликовало эту надпись здесь
Так я не же не говорил что это «неправильно» :) По-моему урл, который видит пользователь (чаще всего видит) должен быть коротким, читаемым и в идеале вбиваемым вручную.
PS А фразу «то, что не изменяет данные, передается гетом» это как следует понимать? :) post изменяет данные во время передачи, гетом нужно передавать только то, что никогда не изменяется (зачем только тогда это передавать непонятно) или о чем это вообще?
PS А фразу «то, что не изменяет данные, передается гетом» это как следует понимать? :) post изменяет данные во время передачи, гетом нужно передавать только то, что никогда не изменяется (зачем только тогда это передавать непонятно) или о чем это вообще?
Пример ?page=upload или ?page=add_post вот что имел ввиду OnYourLips сверху. Но суть уязвимости не в методе передачи, а в обработке данных.
НЛО прилетело и опубликовало эту надпись здесь
Главное в жизни веб девелопера не знание спецификаций. Их тоже конечно нужно знать, но без здравого смысла и умения выражать свои мысли все будет намного печальней. Вы внимательно перечитайте свои сообщения и поставьте себя на место начинающего разработчика — он же застрелится от бессилия в попытках вникнуть в поток сознания в разговорах типа нашего с вами? :)
что-то кроме цифр передавать через гет просто некрасиво
Гетом вообще передвать не красиво. В этом плане мне нравится подход в джанге — параметры являются частью урл — boobs.com/posts/1234/
Не работал с Джанго до сих пор (к сожалению), но не думаю, что в ней что-то иначе. Параметры «являющиеся частью url» (GET, кстати, тоже являются) — это все еще get-параметры, просто ловко завуалированные с помощью рерайтов.
Причем тут подход в джанге. То что вы написали есть во многих фреймворках и на самом деле 1234 будет передано в гет запросе примерно так: boobs.com?post=1234
НЛО прилетело и опубликовало эту надпись здесь
Давайте прежде чем рекомендовать будем понимать как parh трансформируется в запрос:
позволю себе привести часть руководства одного из фреймворков основанных на MVC:
— … и понятно за счет использования формата path, который исключает использование строки запроса и включает все GET-параметры в информационную часть адреса URL:
/post/read/id/100
в результате чего запрос будет содержать два GET параметра:
route=post/read и id=100
— Привел пример не для развития холиваров, а для того чтобы минусущим. стоит вначале посмотреть как в итоге будет выглядеть запрос к серверу, прежде чем утверждать что там нет ГЕТ параметров.
ps: если не убедил, давайте останемся каждый при своем мнении, чтобы не развивать срач в комментах
позволю себе привести часть руководства одного из фреймворков основанных на MVC:
— … и понятно за счет использования формата path, который исключает использование строки запроса и включает все GET-параметры в информационную часть адреса URL:
/post/read/id/100
в результате чего запрос будет содержать два GET параметра:
route=post/read и id=100
— Привел пример не для развития холиваров, а для того чтобы минусущим. стоит вначале посмотреть как в итоге будет выглядеть запрос к серверу, прежде чем утверждать что там нет ГЕТ параметров.
ps: если не убедил, давайте останемся каждый при своем мнении, чтобы не развивать срач в комментах
НЛО прилетело и опубликовало эту надпись здесь
Смотря как реализована обработка урла, на примере DLE вы получите масив, в случае с WP нет.
НЛО прилетело и опубликовало эту надпись здесь
А причем здесь роутинг? Я написал kAIST только то, что PHP НИКАКИМ образом не завязан на URL.
>> Так делать не принято уже лет десять и ни один нормальный фреймворк этого не позволяет.
Не может фреймворк этого не позволять, потому как это на веб-сервере определяется. Откуда ваш фреймворк берет строку URL для разбора в роутере? Наверняка, из $_SERVER['PATH_INFO']. Никто не мешает нам на веб-сервере PATH_INFO переименовать хоть в VASYA_PUPKIN.
>> Так делать не принято уже лет десять и ни один нормальный фреймворк этого не позволяет.
Не может фреймворк этого не позволять, потому как это на веб-сервере определяется. Откуда ваш фреймворк берет строку URL для разбора в роутере? Наверняка, из $_SERVER['PATH_INFO']. Никто не мешает нам на веб-сервере PATH_INFO переименовать хоть в VASYA_PUPKIN.
Как бы вам объяснить. Django, как и любое другое wsgi приложение работает немного не так, как php скрипты. А если быть точнее — совсем не так.
Приложению передаётся path, и никаких рерайтов! Приложение обрабатывает ВСЕ запросы, и уже решает что с ними делать.
Приложению передаётся path, и никаких рерайтов! Приложение обрабатывает ВСЕ запросы, и уже решает что с ними делать.
>> Приложению передаётся path, и никаких рерайтов
В PHP так же вообще-то
В PHP так же вообще-то
Насколько я знаю, там несколько иной подход:
Либо путями «рулит файловая система» ( /news/index.php ), или (и) скрипту передается параметры, которые предварительно обрабатываются rewrite engine, как раз так как и писали выше — было /news/18, стало для скрипта /news?d=18.
При работе с wsgi нужно очень постараться чтоб написать в стиле ?type=news&id=18, а вот в php наоборот, нужно приложить усилия, чтоб так не писать.
Либо путями «рулит файловая система» ( /news/index.php ), или (и) скрипту передается параметры, которые предварительно обрабатываются rewrite engine, как раз так как и писали выше — было /news/18, стало для скрипта /news?d=18.
При работе с wsgi нужно очень постараться чтоб написать в стиле ?type=news&id=18, а вот в php наоборот, нужно приложить усилия, чтоб так не писать.
Может быть в апаче это так и было, но в связке nginx+php-fpm все не так. Рерайты никакие не нужны. Nginx берет URL и по нему прописывает параметры fast_cgi_params (какой скрипт вызвать, какие заголовки проставить, что в QUERY_STRING передать, что в PATH_INFO) и дальше отдает запрос на FastCGI. Последнему глубоко по барабану, какой там был URL, он смотрит только в fast_cgi_params. Соответственно нарисовать nginx-ом в fast_cgi_params можно все, что душе угодно.
Если был введен /news/index.php, на самом деле может быть вызван хоть какой скрипт, да хоть pdf-файл можно отдать без участия PHP, если был введен /news?id=18, то это совершенно не означает, что в скрипте будет параметр $_GET['id']. Опять же как захочет веб-сервер (левая нога разработчика).
Если был введен /news/index.php, на самом деле может быть вызван хоть какой скрипт, да хоть pdf-файл можно отдать без участия PHP, если был введен /news?id=18, то это совершенно не означает, что в скрипте будет параметр $_GET['id']. Опять же как захочет веб-сервер (левая нога разработчика).
На web-сервер придёт запрос "/post/read/id/100". Приложению web-сервер передаст "/post/read/id/100". А приложение уже распарсит строку по установленым правилам и передаст значения в нужный контроллер.
ps: не убедили.
ps: не убедили.
Ну а награду то хоть выписали? :)
Ответ автора в его блоге — No, eBay doesn't pay.
это печально, хорошо что не как тут.
Да, лучше просто не получить награды, чем не только не получить награды, но и получить иск за багхантинг. Кстати именно поэтому я как-то вообще отстранился от попыток искать дырки, какая-то лотерея, либо наградят, либо по башке настучат, причем в зависиомсти от левой пятки. Правда это больше относится к СНГ-шным конторам.
Патч же 24го был, а не 19го.
Они хоть «спасибо» перечислили?))
ЗЫ… А… Этож перевод…
ЗЫ… А… Этож перевод…
Интересен объём базы.
У них даже во фронте баги. Вот об одном писал. К слову, так и не устранили ;)
eBay один из немногих больших сайтов которые по безопасности застряли в 90-х. В отличии от купленного ими продукта пейпала, который платит за баги
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SQL Injection для eBay