LINUX.ORG.RU
Форум — Web-development  

Гайавата через раз детектит CSRF

 


0

1

Здравствуйте.

Такая проблема. Браузер отправляет POST-запрос на CGI-приложение. Запрос доходит до CGI стабильно через раз. А тот раз, когда не доходит, возвращается «400 Bad request» и стандартная серверная html-страничка. В логах эти запросы детектятся как CSRF.

Подскажите, что в этом запросе может быть CSRF-ного?

POST /coolmaster/set/name HTTP/1.1
Host: 192.168.88.100:9090
Connection: keep-alive
Content-Length: 15
Pragma: no-cache
Cache-Control: no-cache
Origin: http://192.168.88.100:9090
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
DNT: 1
Referer: http://192.168.88.100:9090/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

Тело запроса: 

[666,«Satan H»]

★★★★★

Последнее исправление: makoven (всего исправлений: 2)

Не вижу в запросе CSRF-токена.
Покажи «годный» запрос.

Гайавата

Ловить CSRF - роль веб-приложения, а не сервера. Отменить, уже просветился.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

Реализации могут быть разные, но проблема CSRF может проявляться как правило там, где нет привязки сессии к IP

anonymous
()
Ответ на: комментарий от thesis

Точно такой же, один в один. При первом запросе браузер получает 200 OK, при втором - 400. Третий - 200, четвертый - 400. И так далее

makoven ★★★★★
() автор топика
Ответ на: комментарий от r_asian

Это не я, это хром. Я вообще не добавляю заголовки. Только вызываю методы open и send у XMLHttpRequest

makoven ★★★★★
() автор топика
Ответ на: комментарий от makoven

Этот заголовок используется для организации кроссдоменных запросов

Покажи js-код, которым ты такое формируешь

r_asian ★☆☆
()
Ответ на: комментарий от r_asian

Кусочек из функции:

this.xhr = new XMLHttpRequest();
data = JSON.stringify(data);
this.xhr.open("POST", url);
this.xhr.send(data);

Твои размышления про Origin заставили посмотреть в конфиг сервера. Там в качестве Host был прописан 192.168.88.100. Исправил на 192.168.88.100:9090 - ошибка перестала появляться. Спасибо.

Правда не совсем понимаю почему такое поведение

makoven ★★★★★
() автор топика
Ответ на: комментарий от r_asian

Правильно я понимаю, что при загрузке index.html браузер сообщает серверу, что он 192.168.88.100:9090. Сервер отвечает, что он 192.168.88.100 (без номера порта). Браузер делает вывод, что это другой домен и отправляет все запросы как CORS?

makoven ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Реализации могут быть разные, но проблема CSRF может проявляться как правило там, где нет привязки сессии к IP

нет.

обычно проблема CSRF возникает в том случае когда вёбразработчик не знает что такое CSRF :-) ..

и (в частности) привязка сессии к IP — не решает проблему CSRF *СОВЕРШЕННО_НИ_КАК* (даже на чуть-чуть!) ! то есть твоё предложение, товарищ Аноним, это канонический пример человека, который не зная что такое CSRF, всё равно какбы пытается его тщетно избежать :-) ..

makoven ★★ (07.07.2015 13:31:05)> Я не знаю что такое сессии, но куки вообще никакие не используются, если ты об этом

а! ну если нет куков (и нет localStorage, и нет прочих подобных сущостей, которые запоминали бы хоть-что-то на строне клиента) — то значит и CSRF возникнуть не может!

то есть на HelloWorld не возникают CSRF , даже если вёббразработчик (который делал HelloWorld) не знает что такое CSRF :-)

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 7)
Ответ на: комментарий от user_id_68054

Я погуглил. Теперь я знаю что такое сессии

http://postimg.org/image/g349yu5hd/

Мне кажется, что ты знаешь что-то дельное по теме, кроме осуждений )

makoven ★★★★★
() автор топика
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

Мне кажется, что ты знаешь что-то дельное по теме, кроме осуждений )

знаю и уже высказал!

знание о том что привязка по IP не спасает.

а вообще:

Там в качестве Host был прописан 192.168.88.100. Исправил на 192.168.88.100:9090 - ошибка перестала появляться. Спасибо.

что я после этого ещё могу ответить? :-)

user_id_68054 ★★★★★
()
Ответ на: комментарий от makoven

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

(возможно баг?)

наверно GET-запросы проходят без дополнительного контроля? а POST-запросы проверяются на предмет CSRF?

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

Врятли баг. Скорее я что-то недоглядел. Плохо когда нет понимания картины целиком.

makoven ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

Да, GET все проходят. В опции Hostname нет «*». Значит, как я понимаю, сервер должен отвергать все кросс-запросы.

В конфиге включена опция:

PreventCSRF = yes|no
Prevent Cross-site Request Forgery by ignoring all cookies sent by a browser when following an external link to this website. This setting can cause problems for users who use tools to hide/remove the Referer HTTP header string while browsing. Please note that this protection is not 100% safe. 
Default = no, example: PreventCSRF = yes
makoven ★★★★★
() автор топика
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

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

На самом деле CSRF это надуманный тупизм для тех, кто считает, что хорошо ориентируется в этих вопросах.

Мне кажется было бы гораздо полезнее для всех, разобраться что под CSRF здесь понимается.

Моя точка зрения такова: CSRF это банальная подмена запроса. Если сервер не проверяет откуда запрос - то решето.

Как сервер проверит? - кукисы, сертификат (https), IP (здравствуй кооперативный интернет и виртуальный пользователь), UA + Browser Env, referer (крайне ненадежно и легко подделать), шифрованные пакеты.

В итоге кроме сертификата, остальное весьма спорно.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Web-development