2012-02-20 3 views
2

У меня есть следующий вызов ajax, который проверяет, является ли пользователь платным членом, если да, он выполняет определенные функции соответственно. Это работает, но я беспокоюсь о безопасности. Что делать, если кто-то изменяет этот код ajax в консоли, заставляя #button успешно выполнять функции без необходимости делать какие-либо сообщения. Могу ли я предотвратить это, продолжая использовать jQuery ajax.jQuery ajax security

$('#button').click(function() { 
    $.ajax({ 
     url:'checkplan', 
     type:'POST', 
     success:function(data){ 
      if(data == 'paid') 
       //grant access and run some functions 
    } 
}) 
+0

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

+0

FYI, эта строка кода '$ ('# button'). On (function() {' нуждается в событии (предположим, что вы имели в виду клик), чтобы это было так: '$ ('# button'). On (' click_, function() {'. – jfriend00

+0

@jfriend, это была опечатка. Я исправил ее. – Pinkie

ответ

2

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

Аналогичным образом, только «скрывающая» разметка не собирается сокращать ее для вас, поэтому display:none; не выполнит ничего в обеспечении безопасности вашего сайта.

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

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

Update

В случае, если вы упоминаете, где вы оказываете диалог JQuery UI, пока кнопки указывают на функциональность Тхата проверяет на стороне сервера, что пользователь, который он утверждает, что то, вы «безопасны» (хотя это не самый чистый код на земле); что вы действительно должны делать, это отображать эти кнопки на основе того, имеет ли пользователь требуемые учетные данные.

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

+0

Оставьте свой комментарий к ответу jfriend выше. – Pinkie

+0

Я только что обновил ответ на этот комментарий. – bevacqua

+0

Отсутствие средств управления на стороне клиента не обеспечивает необходимую безопасность, поскольку URL-адреса/формы могут быть проверены, а затем изготовлены клиентом-изгоем. Проверка на токен аутентификации должна быть реализована на сервере. Эта проблема не может быть решена в клиенте. Обычно функционирующий клиент может предлагать чистый пользовательский интерфейс на основе точного состояния, но он не может обеспечить безопасность. – jfriend00

3

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

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

Многие API-интерфейсы REST имеют метод входа, который возвращает идентификатор сеанса, а для всех других запросов API требуется этот идентификатор сеанса. Затем сервер проверяет этот идентификатор сеанса на каждом запросе, чтобы проверить, действительно ли он действителен для входа в систему и что он по-прежнему действителен (идентификаторы сессии обычно хороши только в течение некоторого периода времени, если не используются регулярно).

Многие веб-приложения используют куки-файлы для того, чтобы все будущие просмотры страниц и представления форм могли представить серверу, что они вошли в систему и прошли проверку подлинности должным образом из-за наличия соответствующего идентификатора sessionID в файле cookie.

+0

Есть ли способ скрыть функции успеха, если пользователь не является платным членом – Pinkie

+0

@Pinkie - вы спрашиваете, как вы спрятаны/показать элементы DOM? – jfriend00

+1

@ Pinkie вы не понимаете, как это работает. Вы никогда не сможете защитить себя от манипуляций со стороны JavaScript. Вот почему вам нужно убедиться, что * сервер * ничего не показывает пользователям, которые не вошли в систему. –

1

Если вы выполняете проверки безопасности, такие как эта клиентская сторона, нет ничего, что могло бы заставить клиентов либо изменить URL-адрес Ajax (чтобы вернуть «платный»), либо просто обойти свой JavaScript с помощью своего отладчика, чтобы делать то, что они хотят, переходя к вашему разделу «// доступ и запуск некоторых функций».

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

Never trust clients.

изменить ответ jfriend00 лучше :).