Лучшая практика для «скрытого» JavaScript HTTP-запроса?

Question

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

Мы создаем службу HTML5, на которую зачисляются пользователи (Награда за общение в игровой социальной сети) за выполнение серии предложений.Большинство из этих предложений - просмотр видеообъявлений.У нас уже есть реализация этого, построенная на Flash, но для HTML5 я сталкиваюсь с немного большим количеством вопросов о том, как сделать запрос на вызовы для проверки законно просматриваемых видеообъявлений.В интерфейсе Flash у нас есть серия HTTP-запросов, которые выполняет SWF, некоторые при запуске воспроизведения видео, в середине и в конце, каждый из этих запросов связан друг с другом, то есть ответ одноготребуется при следующем запросе и т. д. Большая часть логики «скрыть» этот «алгоритм» слегка скрыта в двоичном файле SWF, и он в значительной степени служит его цели.

Однако для HTML5 мы должны полагатьсяв мире видим JavaScript и эта «скрытая» логика широко открыта.Итак, я полагаю, что это призыв к предложениям о том, как обычно обрабатываются эти случаи, чтобы квалифицированный специалист не мог (так легко) получить к нему доступ и использовать сервис для программного зачисления.Запутывание JavaScript кажется чем-то, что может помочь, но никоим образом не защищает полностью.

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

Answer 1

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

Существует несколько точек атаки на такую ​​систему.

1. Проверьте JavaScript, чтобы найти обработчик событий и вызовите их через Firebug или другой инструмент.
2. Проверьте все ключи из своего кода и сгенерируйте HTTP-запросы без участия браузера.
3. Запустите код в браузере для программной генерации событий.
4. Используйте сторонний инструмент, который используется браузером для генерации кликов.

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

Answer 2

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

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

Экономически выгода.