GET запросы

[PingWin]

использовать формы и POST-запросы? :)

PS: На самом деле не очень понимаю, в чём, собственно, проблема. Что-то серьёзное с таким сделать сложно, ну а если для вас так критично не допустить подобного на своём ресурсе — решение элементарно, юзайте форму и POST…

[ScorpLeX]

Это не выход я считаю, пост форму можно подделать, на стороннем сайте.
И результат для пользователя будет такой же.

[Q2W]

Ну это всё же не картинка, а форма. Ну и нужно проверять реферрер, видимо.

[ScorpLeX]

Я вижу только использование специально генерируемого ключа для каждого пользователя и его проверку при запросах разного рода.
Но это по моему немного не удобно.

[seraph]

Вы хотите переизобрести HTTPS? Или вы просто пока стесняетесь его использовать?

[Danilka]

По-моему речь шла просто о добавлении рандомного кода в скрытом поле каждый раз да и всё.
Реализуется очень просто и сторонний запрос уже не пошлёшь. У меня в фреймворке просто отдельной опцией включается, ровно как и капча.

[seraph]

Чем тогда он отличается от session_id?

[mayhem]

реферер можно тоже елементароно подделать :) а вообще проблема надуманна, как по мне

[Ueasley]

Что-то я тоже проблемы не увидел.

[jeje]

Это все потому, что не придерживаются REST

[tenshi]

а он тут причём?

[jeje]

В том, что описывает технология когда нужно get, post, put и т.д., не раз уже писали.

[tenshi]

пост тоже не спасает. об этом тоже не раз писали.

[jeje]

От всего нельзя спастись, всегда можно намутить, но get это самое просто, что нужно избегать в таких вещах.

[tenshi]

если в лодке есть дырки — она утонет даже если ты заткнёшь ту, которую проще заткнуть.

[VDG]

>Последнее время мне очень интересна эта проблема
— хотите поговорить об этом?

[ScorpLeX]

Наверное это логично, раз я так написал.

[Q2W]

Спасибо, теперь мне стало понятно, зачем действительно нужно использовать метод POST для запросов, изменяющих данные на сайтах, где юзеры могут тем или иным способом вставлять HTML (UGC, например).

Проверил все свои сайты.

[tenshi]

безтолку

[pixxxel]

x = random()
session[token] = x
a href='qwe.php?token=x'

if(session[token] != get[token])
exit

[ScorpLeX]

Наверное лучший вариант, но не очень красиво я считаю.

И если использовать именно Ваш вариант, например пользователю после какого то действия с сайтом, понадобится дать ссылку другу, то друг увидит пустую страницу.

[pixxxel]

Очевидно мы и добивается чтоб у друга ссылка не заработала )
Кстати, с POST тоже надо так делать, а то ведь могут и кнопочку волшебную подсунуть )

[tenshi]

php.net/session_id

[pixxxel]

Вы уверены, что session_id безопасно использовать в качестве токена?

[tenshi]

угу

[AztEK]

Всё просто. Нужно в критически важные ссылки добавлять логин пользователя (а на сервере сверять его, к примеру, с ID сессии). Ссылка для выхода будет выглядеть примерно так: www.site.com/user/%username%/logout/.

[Q2W]

Ну так для конкретного юзера URL тоже можно сгенерить.

[ScorpLeX]

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

[AztEK]

Ну хорошо, тогда добавлять не логин, а сам ID сессии. Его, по идее, злоумышленник никак не сможет узнать.

[sergey_novikov]

ID сессии в GET — плохо, т.к. иногда можно увидеть его через referer.

[seraph]

В get-запросах стоит передавать то, что заставляет страницы выглядеть определённым образом, чтобы можно было добавлять в закладки. Всё остальное — дурной тон.

GET-запрос легко исправить, тупо изменив его в строке браузера. POST-запрос подделать сложнее, но тоже реально. Но есть механизм сессий. Но есть сниферы. И тут приходит шифрование и HTTPS. И тут злоумышленник тратится или на суперкомпьютер, чтобы поломать ключ, или на паяльник и билет до жертвы, чтобы оказать него желаемое воздействие.

Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.

[seraph]

Добавлю в качестве примера, как у меня в текущем проекте происходит проверка перед выполнением действий на сайте в зоне для уже авторизированных пользователей:
1. Есть ли идентификатор пользователя в сессии пользователя (впихивается в $_SESSION при авторизации)?
2. Пришло ли с нашего сайта (по имени сервера)?
3. Пришло ли с того айпишника, с которым этот пользователь зашёл на сайт?
4. Не содержат ли передаваемые данные запрещённые символы?
5. [опционально, зависит от вида действия] Роль пользователя позволяет ему выполнять это действие?

[ScorpLeX]

По второму пункту, что будет если у пользователя запрещена передача referer'a?
Он не сможет попасть к Вам на сайт?

[seraph]

До этого сообщения об этом не задумывался, потому что с такими проблемами со стороны пользователя ни разу не сталкивался. В свободное время, наверное, погуглю на эту тему, возможно сделаю проверку по имени сервера желательной, но необязательной. Но, повторюсь, пока таких пользователей не встречал. Возможно, везло.

[seraph]

Да, сейчас бегло прочитал про фаерволлы, блокирующие рефереры. Пожалуй, действительно стоит сделать эту проверку необязательной. От греха.

[seraph]

Взломать можно абсолютно всё, это вопрос только времени и денег.

Не совсем понял, в чём суть вашего хака: я же говорю, проверяется корректность введённых данных, в частности по PCRE — пункт номер 4 в моём списке. К тому же, если вы уже авторизировались, то пробили защиту по сессиям и она, как первый уровень обороны уже более для вас не актуальна.

[seraph]

В get-запросах стоит передавать то, что заставляет страницы выглядеть определённым образом, чтобы можно было добавлять в закладки. Всё остальное — дурной тон.

GET-запрос легко исправить, тупо изменив его в строке браузера. POST-запрос подделать сложнее, но тоже реально. Но есть механизм сессий. Но есть сниферы. И тут приходит шифрование и HTTPS. И тут злоумышленник тратится или на суперкомпьютер, чтобы поломать ключ, или на паяльник и билет до жертвы, чтобы оказать него желаемое воздействие.

Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.

[seraph]

Что-то хабрадвижок сглючил, прошу прощения за дубль.

[VEnis]

Интересующая Вас тема называется «Cross-site request forgery». Получить дополнительную информацию о ней можно здесь (на англ.) и здесь (на русском).

[ScorpLeX]

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

[tenshi]

решение простое как пробка — подписывать не только пользователя (кукой), но и выданную ему форму/ссылку (параметром).
кука периодически меняется, а к страницам подключается скрипт, который отслеживает её изменение и обновляет подписи форм/ссылок.

[ScorpLeX]

А Вам не кажется, что это больно сложное решение данной проблемы?

[tenshi]

это _единственное_ решение

[TimTowdy]

Не сложное, если заранее подумать об этом. В Django например это делается одной строчкой в settings.py

[imagick]

Аналогично и в symfony.

[glader]

Приведите эту строчку пожалуйста

[VEnis]

Основная и действующая идея кратко описана здесь. На основании ее строятся практически все защиты от CSRF.

[kolpeex]

Это называется CSRF.