Как предотвратить взлом, если пользователи изменяют переменные html/javascript на стороне клиента?

Используя простой инструмент, такой как FireBug, любой пользователь может изменить параметры javascript на стороне клиента. Если кто-то найдет время и изучит ваше приложение некоторое время, они смогут узнать, как изменить параметры JS, что приведет к взлому вашего сайта.

Например, простой пользователь может удалить объекты, которые они видят, но им не разрешено изменять. Я знаю, что хороший разработчик должен проверять все на стороне сервера, но это означает больше накладных расходов, сначала вы должны делать проверки с данными из БД, чтобы проверить запрос. Это занимает много времени, для каждого действия кто-то должен его проверять, и может сделать это только путем получения необходимых данных из БД.

Что бы вы сделали, чтобы минимизировать взлом в этом случае?

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

Насколько хорошо звучит ваше решение выше?

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

Ответ 1

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

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

Ответ 2

Все, что на стороне клиента может быть подделано. Если вы используете какой-либо секретный ключ + подпись параметра, ваш алгоритм подписи должен быть достаточно случайным/безопасным, чтобы он не мог быть обратным инженером.

Накладные расходы, созданные с добавлением сложности на стороне клиента, лучше потратить на правильную проверку на стороне сервера.

Ответ 3

Что бы вы сделали, чтобы минимизировать взлом в этом случае?

Вы не можете работать с использованием методов проверки на стороне сервера.

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

И как вы используете секретный ключ, если клиент не видит его? Как вы уже упоминали ранее, пользователь легко может манипулировать вашим javascript, а также он может читать все в javascript, секретный ключ тоже!

Вы не можете скрыть что-либо в JavaScript, единственное, что вы можете сделать, это скрыть вещи в JavaScript и надеяться, что никто не попытается выяснить, что вы пытаетесь скрыть.

Ответ 4

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

Все, даже ваш исходный код javascript виден клиенту и может быть изменен ими, это не так.

Ответ 5

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

Ответ 6

Вы, конечно же, не можете скрыть что-либо на стороне клиента, поэтому нет смысла пытаться это сделать.

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

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

Ответ 7

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

Появляется сообщение "У вас нет разрешения на удаление этой задачи".

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

Мы очень серьезно относимся к безопасности, и все это реализовано на стороне сервера, поскольку, как говорит Jens F, мы не можем отвечать на безопасность на стороне клиента.

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