Chrome Instant Invald URL, вызывающие блокировку сайта

Question

Мой веб-сайт использует непонятные случайные URL-адреса для обеспечения безопасности конфиденциальных документов.Например, URL может быть http://example.com/<random 20-char string>.URL не связаны ни с какими другими страницами, имеют теги META, чтобы отказаться от сканирования поисковой системой, и имеют короткие сроки действия.Для обеспечения безопасности верхнего уровня некоторые URL-адреса также защищены приглашением для входа в систему, но многие просто защищены скрытым URL-адресом.Мы решили, что это приемлемый уровень безопасности.

У нас реализован механизм блокировки, при котором IP-адрес будет заблокирован на некоторый период времени после нескольких попыток ввода недействительных URL-адресов, чтобы не допускать перебора URL-адресов методом перебора..

Однако в Google Chrome есть функция «Мгновенная» (включена в «Параметры» -> «Основные» -> Поиск), которая будет выполнять предварительную выборку URL-адресов по мере их ввода в адресную строку.Это быстро вызывает блокировку, так как он пытается получить кучу недопустимых URL-адресов, и к тому времени, когда пользователь завершит работу, ему больше не будет разрешено попыток.

• Есть ли способ отказатьсяиз этой функции или игнорировать HTTP-запросы, исходящие от нее?
• Или этот механизм блокировки просто глуп и раздражает пользователей без какой-либо существенной защиты?

(По правде говоря, яЯ не совсем понимаю, насколько это полезная функция для Chrome. Для результатов поиска может быть интересно посмотреть, что Google предлагает при вводе текста, но какова вероятность того, что подмножество вашего предполагаемого URL приведет к созданию значимой страницы?если эта функция включена, все, что я получаю, это куча 404 ошибок, пока я не закончу печатать.)

Answer 1

Не комментируя цель, я столкнулся с подобной проблемой (нежелательная загрузка страниц из Chrome Instant) и обнаружил, что Google действительно позволяет избежать этой проблемы :

Когда Google Chrome отправляет запрос на сервер вашего сайта, он отправляет следующий заголовок:

X-Purpose: preview

Определите это и верните код состояния HTTP 403 («Запрещено»).

Answer 2

Или этот механизм блокировки просто глуп и раздражает пользователей без какой-либо существенной защиты?

Вы потенциально попали туда по гвоздю: безопасность через неизвестность - это не безопасность.

Вместо того, чтобы пытаться «препятствовать угадыванию», используйте URL-адреса, которые на самом деле трудно угадать: очевидный пример - использование криптографически безопасного ГСЧ для генерации «случайной строки из 20 символов». Если вы используете base64url (или аналогичный base64-безопасный base64), вы получите 64 ^ 20 = 2 ^ 6 ^ 20 = 2 ^ 120 бит. Не совсем 128 (или 160 или 256) бит, так что вы можете сделать его длиннее, если хотите, но также учтите, что ожидаемая стоимость полосы пропускания для правильного предположения будет огромной, так что вам не нужно беспокоиться, пока вы счет за пропускную способность становится огромным.

Существует несколько дополнительных способов защиты ссылок:

• Использование HTTPS для снижения вероятности перехвата (они все равно будут незашифрованы между SMTP-серверами, если вы отправите ссылки по электронной почте)
• Не ссылайтесь ни на что, или, если вы делаете, ссылку через перенаправление HTTPS (в последний раз я проверял, многие веб-браузеры по-прежнему будут отправлять Referer:, пропуская "безопасный" URL, который вы просматривали ранее). В качестве альтернативы можно указать, чтобы при начальной загрузке был установлен неузнаваемый файл cookie сеанса secure и перенаправлен на новый URL-адрес, действительный только для этого файла cookie сеанса.

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

• Служить только после задержки. Каждый раз, когда вы отправляете документ или HTTP 404, увеличивайте задержку для этого IP. Вероятно, существует простой алгоритм асимптотического приближения к пределу скорости, но он должен быть более «прощающим» для первых нескольких запросов.
• Для каждого IP-адреса разрешается только один запрос за раз. Получив запрос, верните HTTP 5xx для любых существующих запросов (я забыл, какой из них «слишком высокая нагрузка на сервер»).

Даже если начальные задержки экспоненциально увеличиваются (то есть 1 с, 2 с, 4 с), «текущая» задержка не будет намного больше, чем время, необходимое для ввода всего URL. Если для ввода случайного URL-адреса вам потребуется 10 секунд, то еще 16 секунд для его загрузки не так уж и плохи.

Имейте в виду, что тот, кто хочет обойти ограничения на основе IP-адреса, может просто арендовать (часть полосы пропускания) ботнет.

---

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