Вопрос о безопасности AJAX, пожалуйста, задавайте вопросы - PullRequest
4 голосов
/ 24 марта 2011

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

Я знаю, что javascript можно легко взломать, а также прочитать здесь http://www.acunetix.com/websitesecurity/ajax.htm что AJAX не так безопасен, как казалось бы.Они утверждают, что «поскольку XML-HTTP-запросы функционируют с использованием того же протокола, что и все остальные в Интернете (HTTP), технически говоря, веб-приложения на основе AJAX уязвимы к тем же методологиям взлома, что и« обычные »приложения».

Поэтому я не хочу, чтобы червь просто продолжал выполнять запросы на добавление в друзья через мою функцию AJAX, и кто-то подписывался на сайте, и у него было 14 миллионов запросов на добавление в друзья.Это также проблема с несколькими другими сценариями AJAX, которые я запускаю на сайте.Вопрос, который у меня есть, заключается в том, что я должен оставить все на стороне сервера.Я использую php, поэтому каждый запрос на добавление в друзья должен быть просто перезагрузкой страницы, насколько я хотел бы избежать такой вещи?Пожалуйста, любая помощь будет принята с благодарностью.

Ответы [ 5 ]

5 голосов
/ 24 марта 2011

Если у вас есть проблемы с безопасностью, они не уникальны для ajax, но есть простые способы усложнить работу.

1) Как говорит Диодей - абсолютно не позволяйте людям пользоваться вашими услугами без их аутентификации через сеанс. То же, что и любая другая страница на веб-сайте, требующая входа в систему.

2) усложнить захват сеанса, внедрив информацию о клиенте в ключ сеанса (cookie) и проверив ее на сервере, например, IP-адрес, версия браузера. Это все еще можно подделать, хотя.

3) Если конкретный сеанс делает более x запросов за определенный период времени (например, 10 в минуту), выйдите из системы и заблокируйте их на час. Установите более высокий предел, чтобы запретить их, пока не будет восстановлено администратором. Каждый раз, когда это происходит, отправляйте по электронной почте код, чтобы знать, есть ли у вас проблемы.

4) Если вы действительно обеспокоены, используйте SSL. Это действительно единственный способ полностью предотвратить перехват сеанса (кроме реализации собственного механизма шифрования личного ключа для данных сеанса).

5) Если вы не используете SSL, вы не можете остановить возможность перехвата сеанса, но вы МОЖЕТЕ защитить пароли своего пользователя от легкого отслеживания. При аутентификации сделайте следующее:

  • Клиентский скрипт запрашивает соль с сервера (случайная строка)
  • Сервер отправляет соль клиенту и запоминает его во время сеанса
  • Клиент хэширует пароль, используя Sha-256 , например, с солью, и аутентифицируется с помощью своего имени пользователя и хешированного пароля. Сервер хэширует пароль, связанный с пользователем на своем конце, используя ту же соль, и проверяет подлинность, если он совпадает с хэшем, отправленным клиентом. Сервер забывает соль, которую он использовал один раз.

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

На самом деле перехват сеансов не так уж и распространен, хотя громкой реализацией, конечно же, является Facebook через Wi-Fi. Если кто-то использует плагин Firefox для взлома вашей социальной сети, вы должны быть в восторге, потому что знаете, что сделали это.

1 голос
/ 24 марта 2011

Это не проблемы, специфичные для AJAX. Все это сводится к проверке и дезинфекции ваших данных. Я предполагаю, что пользователи должны зарегистрироваться / войти, прежде чем они смогут добавлять друзей (в конце концов, как еще вы будете отслеживать, кто с кем дружит?), Поэтому вот некоторые очевидные моменты, которые следует учитывать:

  • Добавьте CAPTCHA или аналогичный процесс регистрации, чтобы сократить количество пользователей ботов. reCAPTCHA в наши дни является отраслевым стандартом (и его очень легко настроить).
  • При обработке вызова AJAX убедитесь, что пользователю разрешено делать то, что он делает (т.е. вошел ли он в систему, активировал ли он свою учетную запись и т. Д.)
  • При обработке запроса на добавление в друзья игнорируйте дубликаты. Иногда люди намеренно игнорируют запросы друзей, и, вероятно, они не хотят получать приглашение снова, когда приглашающий начинает терять терпение.
  • Найдите способ отследить подозрительное поведение. Если за последние две секунды пользователь отправил 50 запросов на добавление в друзья, скорее всего, это может быть бот. Временно заблокируйте учетную запись и попросите человека проверить это. Также может быть хорошей идеей скрыть запросы друзей от заблокированных пользователей.

Есть намного больше, но они должны начать вас.

0 голосов
/ 24 марта 2011

Там действительно нет такой вещи, как AJAX.Термин AJAX является общим описанием способа организации вещей.Так называемый запрос «AJAX» - это просто HTTP GET или PUT.

0 голосов
/ 24 марта 2011

Я не уверен, что полностью понимаю, потому что, если какой-то червь или что-то еще отправляло запросы AJAX, почему этот же червь не может делать запросы не-ajax?

В любом случае вам обязательно нужно пройти проверку на стороне сервера, чтобы убедиться, что запрос действителен. Хотите ли вы иметь некоторую проверку относительно количества запросов на добавление в друзья, которые вы можете сделать, не зависит от того, используете ли вы ajax или нет.

0 голосов
/ 24 марта 2011

Установить cookie для входа в систему на клиенте. Отправьте значение cookie с помощью запроса ajax и подтвердите его на сервере.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...