Comments 5
> Но это совсем не решения, т.к. открывают дыру в безопасности сайта.
А какая дыра открывается, если отключить проверку токена для sessions#create? Я не могу с ходу придумать, почему этого делать нельзя. Для большей уверенности можно просто добавить проверку реферера.
А какая дыра открывается, если отключить проверку токена для sessions#create? Я не могу с ходу придумать, почему этого делать нельзя. Для большей уверенности можно просто добавить проверку реферера.
printercu, Tonkonozhenko, Chikey благодарю за комментарии.
Отвечу одним сообщением на ваши отзывы.
А какая дыра открывается, если отключить проверку токена для sessions#create? Я не могу с ходу придумать, почему этого делать нельзя.
Про XSS есть хорошая статья на хабре — habrahabr.ru/post/66057
Я в атаках не спец, но решил не отказываться от базовой проверки авторизованности запросов.
Чем я руководствовался при написании плагина?
Из этих требований для меня стало очевидным необходимость проверить домен с которого идет запрос (реферер), но перечислять внутри плагина текстом все наши домены через запятую — это уже не универсальный плагин.
Поэтому я решил добавить токен, который используется на обеих сторонах. Некий ключ для шифрования и расшифровки.
Это добавило универсальности коду, т.к. не нужно домены прописывать и исключило возможность копирования токена с целью использования его для отправки запросов с иных ресурсов.
Отвечу одним сообщением на ваши отзывы.
А какая дыра открывается, если отключить проверку токена для sessions#create? Я не могу с ходу придумать, почему этого делать нельзя.
Про XSS есть хорошая статья на хабре — habrahabr.ru/post/66057
Я в атаках не спец, но решил не отказываться от базовой проверки авторизованности запросов.
Чем я руководствовался при написании плагина?
- Нужно сделать возможность логиниться в Redmine со внешних сайтов.
Их может быть несколько, т.к. лэндингов у компании может быть несколько. - Если для авторизации POST-запросов придумали токен, значит стоит его все же сохранить.
- Это плагин для Redmine. Поэтому любой желающий может добавить себе и выполнить соответствующую настройку на стороне сайта.
Плагин подразумевает универсальность.
Из этих требований для меня стало очевидным необходимость проверить домен с которого идет запрос (реферер), но перечислять внутри плагина текстом все наши домены через запятую — это уже не универсальный плагин.
Поэтому я решил добавить токен, который используется на обеих сторонах. Некий ключ для шифрования и расшифровки.
Это добавило универсальности коду, т.к. не нужно домены прописывать и исключило возможность копирования токена с целью использования его для отправки запросов с иных ресурсов.
Такое решение бессмысленно. Как «работает» xss токен:
— токен лежит в сессии (зашифрованный в куках или редисе, например);
— вы отдаете его только пользователю с этой сессией (это ключевой момент);
— при запросах от этого пользователя вы проверяете, совпадает ли токен из запроса с токеном из сессии.
В вашей реализации токен для всех один. Злоумышленнику нужно его 1 раз узнать, и он может его использовать, пока вы конфиг не поменяете, размещая на своих сайтах формы. Реферер-то вы просто проверяете на совпадение с текстом в токене (читай: сейчас у вас токен ничего не защищает).
Для чего нужен токен: чтобы от имени пользователя не слали запросы с других сайтов. Например, на сайте злоумышленника кнопка «скачать без смс и регистрации» отправляет аяксом
Если же вы уберете проверку токена для входа, то всё, что сможет сделать злоумышленник — залогинить пользователя. По-моему, это не страшно.
Если нужно запретить логин со сторонних сайтов, то нужно
— либо часто обновлять токен и подписывать его. Для этого на всех сайтах надо логику подписи делать, это не сложно, но без нее никак.
— либо просто использовать белый список рефереров.
— токен лежит в сессии (зашифрованный в куках или редисе, например);
— вы отдаете его только пользователю с этой сессией (это ключевой момент);
— при запросах от этого пользователя вы проверяете, совпадает ли токен из запроса с токеном из сессии.
В вашей реализации токен для всех один. Злоумышленнику нужно его 1 раз узнать, и он может его использовать, пока вы конфиг не поменяете, размещая на своих сайтах формы. Реферер-то вы просто проверяете на совпадение с текстом в токене (читай: сейчас у вас токен ничего не защищает).
Для чего нужен токен: чтобы от имени пользователя не слали запросы с других сайтов. Например, на сайте злоумышленника кнопка «скачать без смс и регистрации» отправляет аяксом
POST http://your-domain/admin/destroy_all (ну или просто создания спам-поста от имени пользователя).Если же вы уберете проверку токена для входа, то всё, что сможет сделать злоумышленник — залогинить пользователя. По-моему, это не страшно.
Если нужно запретить логин со сторонних сайтов, то нужно
— либо часто обновлять токен и подписывать его. Для этого на всех сайтах надо логику подписи делать, это не сложно, но без нее никак.
— либо просто использовать белый список рефереров.
Sign up to leave a comment.
Авторизация в Redmine с другого сайта