Как Google Analytics предотвращает транспортный спуфинг
Мы хотим встроить сервис стиля ajax во многие наши веб-сайты каждый с уникальным ключом API. Проблема, которую я вижу, состоит в том, что, потому что ключ API хранится в JavaScript, регистрируют пользователя, мог потенциально взять ключ, имитировать http ссылающийся домен и выполнить миллионы запросов к API под тем ключом API.
Таким образом, я задаюсь вопросом, как Google предотвращает спуфинг Аналитики? Поскольку это использует почти ту же идею.
Я также открыт для других идей, по существу вот процесс.
SiteA-> Пользователь <-> Ajax <-> SiteB
РЕДАКТИРОВАНИЕ - является там каким-либо способом защитить API от того, чтобы быть злоупотребленным при вызове его через ajax?
2 ответа
Я не верю, что существуют какие-либо такие меры защиты. Спуфинг трафика - серьезная проблема для других сервисов Google, таких как Adwords. Например, злонамеренный человек, который делает ставки на AdWords, может генерировать много ложных кликов по объявлениям своего конкурента, чтобы увеличить свои рекламные расходы и, следовательно, цену акций Google. Верно и обратное: люди будут генерировать поддельные клики на своем сайте, чтобы получить дополнительные деньги от рекламы PayPer Click на своем сайте.
В конце концов, хакер может без особых трудностей собрать список из 10 000+ анонимных прокси-серверов, и с этим мало что можно сделать. Хакер также может использовать ботнет, размер некоторых из которых составляет миллионы. Трафик, генерируемый ботнетом, может выглядеть как легитимные машины с законным файлом cookie Google, поскольку они были захвачены.
Многие прокси-серверы и подключенные машины перечислены в черных списках в реальном времени (RBL), например, в http://www.spamhaus.org , и многие действительные IP-адреса также включены в эти списки. список. Существуют также прокси-серверы, которые нельзя использовать для рассылки спама, но могут использоваться для мошенничества с кликами, и поэтому их не будет в этом списке.
Предположительно, я бы сказал, что ключ - это половина пары открытого и закрытого ключей, которая (каким-то образом) включает URL-адрес в качестве хеша. Таким образом, ключ будет работать, а обращения будут регистрироваться только в том случае, если запрос относится к URL-адресу, для которого был сгенерирован ключ. Вы не можете подделать запрос, потому что, если вы это сделаете, он перейдет на неправильный URL-адрес, и ничего не произойдет.