How to become an author
Search
Write a publication
Pull to refresh

Comments 52

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

PS: На самом деле не очень понимаю, в чём, собственно, проблема. Что-то серьёзное с таким сделать сложно, ну а если для вас так критично не допустить подобного на своём ресурсе — решение элементарно, юзайте форму и POST…
Total votes 3: ↑2 and ↓1+1
Это не выход я считаю, пост форму можно подделать, на стороннем сайте.
И результат для пользователя будет такой же.
Total votes 2: ↑1 and ↓10
Ну это всё же не картинка, а форма. Ну и нужно проверять реферрер, видимо.
Total votes 1: ↑1 and ↓0+1
Я вижу только использование специально генерируемого ключа для каждого пользователя и его проверку при запросах разного рода.
Но это по моему немного не удобно.
This comment wasn’t rated yet0
Вы хотите переизобрести HTTPS? Или вы просто пока стесняетесь его использовать?
Total votes 2: ↑1 and ↓10
По-моему речь шла просто о добавлении рандомного кода в скрытом поле каждый раз да и всё.
Реализуется очень просто и сторонний запрос уже не пошлёшь. У меня в фреймворке просто отдельной опцией включается, ровно как и капча.
This comment wasn’t rated yet0
Чем тогда он отличается от session_id?
This comment wasn’t rated yet0
реферер можно тоже елементароно подделать :) а вообще проблема надуманна, как по мне
Total votes 3: ↑1 and ↓2-1
Что-то я тоже проблемы не увидел.
Total votes 1: ↑0 and ↓1-1
Это все потому, что не придерживаются REST
Total votes 7: ↑2 and ↓5-3
В том, что описывает технология когда нужно get, post, put и т.д., не раз уже писали.
Total votes 3: ↑1 and ↓2-1
пост тоже не спасает. об этом тоже не раз писали.
Total votes 1: ↑1 and ↓0+1
От всего нельзя спастись, всегда можно намутить, но get это самое просто, что нужно избегать в таких вещах.
Total votes 3: ↑1 and ↓2-1
если в лодке есть дырки — она утонет даже если ты заткнёшь ту, которую проще заткнуть.
Total votes 4: ↑3 and ↓1+2
>Последнее время мне очень интересна эта проблема
— хотите поговорить об этом?
Total votes 9: ↑2 and ↓7-5
Наверное это логично, раз я так написал.
Total votes 1: ↑1 and ↓0+1
Спасибо, теперь мне стало понятно, зачем действительно нужно использовать метод POST для запросов, изменяющих данные на сайтах, где юзеры могут тем или иным способом вставлять HTML (UGC, например).

Проверил все свои сайты.
This comment wasn’t rated yet0
UFO just landed and posted this here
UFO just landed and posted this here
x = random()
session[token] = x
a href='qwe.php?token=x'

if(session[token] != get[token])
exit
Total votes 4: ↑4 and ↓0+4
Наверное лучший вариант, но не очень красиво я считаю.

И если использовать именно Ваш вариант, например пользователю после какого то действия с сайтом, понадобится дать ссылку другу, то друг увидит пустую страницу.
This comment wasn’t rated yet0
Очевидно мы и добивается чтоб у друга ссылка не заработала )
Кстати, с POST тоже надо так делать, а то ведь могут и кнопочку волшебную подсунуть )
Total votes 2: ↑2 and ↓0+2
Вы уверены, что session_id безопасно использовать в качестве токена?
This comment wasn’t rated yet0
Всё просто. Нужно в критически важные ссылки добавлять логин пользователя (а на сервере сверять его, к примеру, с ID сессии). Ссылка для выхода будет выглядеть примерно так: www.site.com/user/%username%/logout/.
Total votes 1: ↑1 and ↓0+1
Ну так для конкретного юзера URL тоже можно сгенерить.
This comment wasn’t rated yet0
А если злоумышленник составит базу логинов или будет заранее знать нужных ему пользователей.
Это конечно мало вероятно, но все же я считаю, это не очень подходит.
Total votes 1: ↑1 and ↓0+1
Ну хорошо, тогда добавлять не логин, а сам ID сессии. Его, по идее, злоумышленник никак не сможет узнать.
Total votes 3: ↑2 and ↓1+1
ID сессии в GET — плохо, т.к. иногда можно увидеть его через referer.
This comment wasn’t rated yet0
В get-запросах стоит передавать то, что заставляет страницы выглядеть определённым образом, чтобы можно было добавлять в закладки. Всё остальное — дурной тон.

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

Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.
Total votes 4: ↑3 and ↓1+2
Добавлю в качестве примера, как у меня в текущем проекте происходит проверка перед выполнением действий на сайте в зоне для уже авторизированных пользователей:
1. Есть ли идентификатор пользователя в сессии пользователя (впихивается в $_SESSION при авторизации)?
2. Пришло ли с нашего сайта (по имени сервера)?
3. Пришло ли с того айпишника, с которым этот пользователь зашёл на сайт?
4. Не содержат ли передаваемые данные запрещённые символы?
5. [опционально, зависит от вида действия] Роль пользователя позволяет ему выполнять это действие?
This comment wasn’t rated yet0
По второму пункту, что будет если у пользователя запрещена передача referer'a?
Он не сможет попасть к Вам на сайт?
This comment wasn’t rated yet0
До этого сообщения об этом не задумывался, потому что с такими проблемами со стороны пользователя ни разу не сталкивался. В свободное время, наверное, погуглю на эту тему, возможно сделаю проверку по имени сервера желательной, но необязательной. Но, повторюсь, пока таких пользователей не встречал. Возможно, везло.
This comment wasn’t rated yet0
UFO just landed and posted this here
Да, сейчас бегло прочитал про фаерволлы, блокирующие рефереры. Пожалуй, действительно стоит сделать эту проверку необязательной. От греха.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Взломать можно абсолютно всё, это вопрос только времени и денег.

Не совсем понял, в чём суть вашего хака: я же говорю, проверяется корректность введённых данных, в частности по PCRE — пункт номер 4 в моём списке. К тому же, если вы уже авторизировались, то пробили защиту по сессиям и она, как первый уровень обороны уже более для вас не актуальна.
This comment wasn’t rated yet0
В get-запросах стоит передавать то, что заставляет страницы выглядеть определённым образом, чтобы можно было добавлять в закладки. Всё остальное — дурной тон.

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

Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.
Total votes 1: ↑1 and ↓0+1
Что-то хабрадвижок сглючил, прошу прощения за дубль.
This comment wasn’t rated yet0
Спасибо, но все же, какие методы используются для предотвращения этого, там не указанно.
This comment wasn’t rated yet0
решение простое как пробка — подписывать не только пользователя (кукой), но и выданную ему форму/ссылку (параметром).
кука периодически меняется, а к страницам подключается скрипт, который отслеживает её изменение и обновляет подписи форм/ссылок.
This comment wasn’t rated yet0
А Вам не кажется, что это больно сложное решение данной проблемы?
This comment wasn’t rated yet0
это _единственное_ решение
Total votes 2: ↑2 and ↓0+2
Не сложное, если заранее подумать об этом. В Django например это делается одной строчкой в settings.py
This comment wasn’t rated yet0
Приведите эту строчку пожалуйста
This comment wasn’t rated yet0
Основная и действующая идея кратко описана здесь. На основании ее строятся практически все защиты от CSRF.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr