LINUX.ORG.RU

суть механизма проверки csrf-токена со стороны сервера

 


0

1

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

1. допустим, сайт сделан на основе какого-нибудь популярного mvc-фреймворка. в таких фреймворках обычно есть режим shell. то есть в командной строке можно запустить этот режим и из командной же строки выполнять действия типа создания пользователей, запросов к БД и т.д.

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

3. если сайт сделан и выложен в сеть, то например 10 пользователей с разных компьютеров могут зайти на сайт через браузер, вбив с адресную строку http://www.site_address.ru . после этого на стороне сервера откроется 10 командных строк в режиме shell(то есть создастся 10 сред окружения). и далее всё взаимодействие с сайтом для конкретного пользователя будет происходить через его персональный shell(то есть фреймворк все действия преобразует в команды для shell и выполняет их)

4. в фреймворке обычно уже есть механизм для генерации и проверки csrf-токенов. работает он следующим образом:

5. персональный shell после получения запроса от браузера пользователя на отрисовку странички с формой отправляет кроме всего прочего csrf-токен(в html это будет поле типа hidden)

6. при этом персональный shell пользователя где-то у себя запоминает отосланный csrf-токен. для определённости, скажем, помещает его в СВОЮ глобальную область

7. пользователь заполняет форму и отправляет её. а персональный shell пользователя берёт запомненное значение токена и проверяет с тем, токеном, который получен в результате отправки формы пользователем

8. если эти значения совпадают, то shell считает, что данные полученные из формы можно обрабатывать(например осуществить перевод денег)

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



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

«shell» в описании — какая-то лишняя сущность. Как у человека, никогда не сталкивавшегося с MVC фреймворками, которые в наборе поставляют оный, тут уже у меня вопрос вида «правильно ли я понял...». Суть CSRF и методы решения, к слову, хорошо описаны в рамках проекта OWASP:

Schmuck
()
Ответ на: комментарий от prozaik

Эта командная строка предназначена для разработчика и запускается исключительно по его инициативе. В процессе работы сайта никаких шеллов не создаётся. Как правило, сайты работают по stateless-схеме. Максимум под «шеллом» можно понимать пользовательскую сессию, но это просто некий набор данных. В исключительном случае, для чатов или в играх может создаваться некий подпроцесс.

Ещё раз прочитай про протокол HTTP, а про CSRF-токены можешь прочитать здесь: https://habrahabr.ru/post/318748/

static_lab ★★★★★
()

Суть CSRF в моем понимании, это проверка возможности выполнения действия в рамках «пространства» авторизованного пользователя...

Например, «от имени» пользователя есть риск (без особых) выполнить модификации учетных данных другого пользователя. Здесь возможны варианты.

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

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

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

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

простым программистам лучше не задумываться

напротив, но другое дело модель черного ящика: вход, выход, что внутри неизвестно. Это полезно.

Да и решать за программистов это брать на себя лишнюю обязанность, ответственность. Это просто неразумно.

Канал, это также как и в метро например чередование станций и доступности связи ... Об этом полезно помнить ...

Сессия это сеанс, может обслуживаться и одним процессом и пулом. Веб-сессия слабо связана с процессом и соответственно сессионные переменные живут вне процессов.

Вообще стандартное время ответа сервера 10 минут.

Тут важно осознавать популярный барьер для неосиляторов, что web stateless по своей сути.

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