Как защитить GAE серверную логику вычислений? - PullRequest
Новая
       6

Как защитить GAE серверную логику вычислений?

1 голос
/ 10 февраля 2012

Допустим, у меня есть 100 полей в HTML-форме. Когда все поля заполнены, некоторая оценка вычисляется и показывается пользователю (скажем, значение оценки от 0 до 3000).

Когда пользователь изменяет значение в каком-либо поле, мы показываем ему диапазон значений (0-1000, 1001-2000, 2001-3000), без подробной оценки. Но после нажатия кнопки «Отправить» отображается точный счет.

Теперь мне нужно защитить логику - поэтому пользователи не должны понимать, как каждое поле влияет на оценку. Кроме того, пользователи не должны иметь возможность использовать какую-либо программу, чтобы «поиграть» со значениями и посмотреть, как меняется оценка.

Я думаю о следующем подходе:

  1. использовать сеансы;
  2. сохранить на стороне сервера текущее значение оценки;
  3. при изменении значения в одном поле отправьте запрос на сервер с измененным именем поля и новым значением;
  4. на стороне сервера проверить, когда был отправлен предыдущий запрос, если разница во времени слишком мала, отклонить запрос;
  5. сервер отвечает с новым диапазоном и сохраняет новое значение;
  6. при нажатии кнопки Отправить сервер отвечает серверным значением оценки (не пересчитывайте его, принимайте как есть). Не отвечайте на это слишком часто.

Есть ли другие (лучшие) подходы?

Ответы [ 2 ]

1 голос
/ 11 февраля 2012

Для клиента:

  1. Отправка данных полей на сервер и запрос на подсчет очков.
  2. Установите ограничение для вашего клиента, чтобы сервер мог дождаться ответа на запрос, отправленный на шаге 1, прежде чем отправлять новый.
  3. Когда ответ от сервера вернулся, проверьте значения в полях, если есть какие-либо изменения по сравнению с прошлым разом, когда вы были на шаге № 1, повторите шаг № 1. Если нет, проверьте поля и перейдите к шагу # 1 при обнаружении каких-либо изменений.

Теперь для сервера:

  1. Когда приходит запрос на перерасчет, рассчитайте новый счет, но затем добавьте искусственную задержку перед отправкой результата расчета клиенту. (например, поспать 1000 мс перед отправкой ответа клиенту)

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

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

1 голос
/ 11 февраля 2012

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

  • использовать файл cookie «enabler» (или установить флаг сеанса), когда пользователь отображает форму и проверяет наличие этого конкретного файла cookie или флага, прежде чем передать ответ. Снимите флажок после получения ответа и не разрешайте отправлять сообщения тем, кто уже отправил
  • рандомизировать имена полей и проверить на стороне сервера, имеют ли поля правильные случайные имена
  • использовать куки для проверки, если пользователь уже отправил форму (легко победить)
  • проверка агента пользователя по отношению к популярным библиотекам HTTP (и не разрешать людям отправлять формы с ними)
  • отслеживать, если один и тот же IP-адрес делает много заявок - неточно, но может указывать на что-то подозрительное

Это первые идеи, которые приходят мне в голову. Скорее всего, будут другие проницательные комментарии с другими.

...