Как защитить AJAX-запрос?

Question

[lil_web]

У меня есть две страницы: список людей для пользователя и администратора. Пользователь только просматривает список, администратор добавляет людей через форму без перезагрузки страницы.

Страница админа защищена паролем (допустим), но я нашёл уязвимость. Пользователь может открыть script.js, узнать, как админ добавляет людей, и с помощью веб-консоли замусорить базу данных.

Как защититься от этого?

Answer 1

[dollar]

Обычно происходит так:
1) У админа есть пароль. У пользователя, кстати, тоже должен быть.
2) Админ вводит пароль на сайте и в замен получает токен (т.е. какой-то ключ). Получить он может его как угодно - напрямую через POST-запрос из формы, либо через ajax. Но суть такая, что в запросе пароль, а в ответе токен (ключ).
3) Далее этот токен админ использует везде на сайте для доступа к своим админстким функциям. То есть в каждом ajax-запросе присутствует этот токен. Он становится частью сессии. Вообще в php даже есть свои сессии со своим ключом, так что их тоже можно использовать.
4) Через какое-то время, либо после нажатия кнопки "выход", токен устаревает и больше не работает (нужно снова вводить пароль).

Так что ответ на вопрос: нужно посылать токен в каждом ajax-запросе, это и будет защита.

Comments

[ZakkMalin]

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

[dollar]

ZakkMalin, с точки зрения перехвата https соединения - никак.

А с точки зрения перехвата сессии разными способами - пароль остается защищенным. То есть если пользователь отошел, потом подошел хакер и вынул из памяти пароль и узнал его, то у хакера будет пароль. А если там только токен, то пароль хакер знать не будет. Он сможет скопировать только сессию.

Защита сессии - отдельная тема. Но вкратце скажу. Вместе с токеном передаётся условно номер (потому что на самом деле еще один токен) текущего запроса. То есть если после запроса 10 следует запрос 50 или 5, то это явно попытка перенести сессию на другое устройство.

Кроме того, при использовании токена появляются всякие приятные штуки типа параллельных сессий. Например, если пользователь работает с двух компов и на одном сменил пароль, то вторая сессия не дропнется. Точнее, это на усмотрение разработчика. Или какая-нибудь кнопка типа "выйти со всех устройств" и т.д.

Ну и по-хорошему пароль не нужно передавать вообще. RC4 и всё такое. Просто я не стал усложнять, т.к. автору (судя по вопросу) нужен простой ответ для начала.

[ZakkMalin]

dollar, спасибо за хороший, понятный, и развёрнутый комментарий

[ZakkMalin]

dollar, я реально всё понял с первого раза, чем по гуглению помойки-гугла

[ZakkMalin]

dollar, у вас есть сайт или блоги с собственными статьями?

[lil_web]

dollar, спасибо за ответ! Я добавил на страницу обработчика условный оператор:

if (password_verify($ini[admin][password], $_COOKIE['admin'])) {}

А до этого, когда пользователь вводит правильный пароль для админки, пароль хешируется и сохраняется в куке admin.

Насколько это хорошая и безопасная практика? Как сделать лучше?

Answer 2

[entermix]

Как защититься от этого?

Вы не поверите, но нужно прикрутить авторизацию...

Comments

[lil_web]

Что вы имеете в виду?

[entermix]

lil_web, https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D...

[lil_web]

entermix, я же написал:

Страница админа защищена паролем (допустим)

.

[DanKud]

lil_web, ну так а каким образом к странице получит доступ злоумышленник не зная пароля и не имея куков администратора? В чем конкретно заключается найденная вами уязвимость?

[xmoonlight]

lil_web, почитай мой ответ и сделай так, чтобы ни при каких обстоятельствах данные запроса с сервера не были доступны не авторизованному пользователю!

Answer 3

[xmoonlight]

Как защититься от этого?

Варианта 2:
1. Либо Вы делаете недоступным контент
2. Либо - запрос.
(PS: что одно и то же...)