Безопасно ли хранить файлы cookie в базе данных?

Если я использую механизировать, я могу, например, создать новый профиль Google Analytics для веб-сайта. Я делаю это, программно заполняя форму входа и сохраняя файлы cookie в базе данных. Затем, по крайней мере, до истечения срока действия файла cookie, я могу получить доступ к панели администратора аналитики без повторного ввода имени пользователя и пароля.

Предполагая, что вы не можете создать новый профиль аналитики каким-либо другим способом (с помощью OpenAuth или чего-либо подобного, я не думаю, что он работает для фактического создания нового профиля Google Analytics, API Analytics предназначен для просмотра данных, но мне нужно создать новый профиль аналитики), плохо ли хранить куки в базе данных?

Если я сохраню файл cookie в базе данных, это позволит очень легко программно войти в Google Analytics, и пользователю даже не придется заходить в браузер (возможно, в приложении есть функция, которая говорит: «Пользователь, вы можете запланировать хук, который создает новый профиль аналитики для каждого нового домена, который вы создаете, просто введите свои учетные данные один раз, и мы будем держать вас в безопасности»). В противном случае мне придется продолжать передавать электронные письма и пароли, что кажется еще хуже.

Так безопасно ли хранить куки в базе данных?


passwords security storage session cookies
person Lance Pollard    schedule 20.04.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Прежде всего, это ошибочный подход, потому что аутентифицированный сеанс в конечном итоге истечет, и ваше соединение с Google будет разорвано. Кроме того, вы должны использовать API Google Analytics.

Однако СОХРАНЕНИЕ ИДЕНТИФИКАТОРА СЕССИИ В БАЗЕ ДАННЫХ НЕЗАЩИЩЕНО.

Это не признанная уязвимость, по крайней мере, я не знаю. Но это намного упрощает атаку на ваше приложение. Внедрение SQL-кода очень распространено, и вы должны спроектировать свое приложение так, чтобы ограничить воздействие, создаваемое любой конкретной уязвимостью. Вот почему пароли хешируются, потому что это задерживает злоумышленника от получения полной компрометации. Хранение идентификатора сеанса, который можно использовать немедленно, делает уязвимость SQL Injection против вашего приложения более серьезной.

Я не уверен, на какой платформе вы работаете, но я предполагаю, что вы используете Linux, потому что вы заботитесь о безопасности :). Я рекомендую хранить имя пользователя/пароль в файле. Вы должны настроить права доступа к файлу, такие как chmod 700 file_name, и убедиться, что файл принадлежит вашему веб-серверу: chown apache:apache file_name. Если вы используете MySQL, убедитесь, что вы удалили file_priv (права доступа к файлам) из учетной записи пользователя приложения ruby. Файловые привилегии действительно неприятны, потому что они позволяют злоумышленнику читать и записывать файлы через sql-инъекцию.

person rook    schedule 20.04.2010
comment
плюс 1 - никогда не хранить идентификатор сеанса в базе данных - это ярлык для захвата учетной записи. - person rook; 26.05.2016