Насколько безопасно использовать идентификаторы фрагментов для хранения личных данных в URL-адресах?

Мы знаем, что URL сам по себе не является безопасным способом передачи или хранения информации. Слишком много программ будут выполнять неожиданную обработку URL-адреса или даже отправлять его по сети, и, вообще говоря, URL-адрес не обрабатывается с большим вниманием к его конфиденциальности.

В прошлом мы видели биткойн-кошельки, например, которые полагались на сохранение URL-адреса в секрете, но они обнаружили, что существует слишком много способов, которыми URL-адрес (отправленный через Skype, по электронной почте или даже просто набрав в омнибар Google Chrome) будет храниться на удаленном сервере и, возможно, отображаться публично.

И поэтому я думал, что URL-адрес будет навсегда оставлен как средство для передачи любых личных данных ... несмотря на то, что он чрезвычайно удобен, за исключением того, что я видел несколько сайтов, которые используют фрагменты URL-адреса - часть URL-адреса после '# ' -- как своего рода "безопасное" хранилище. Я думаю, ожидается, что Google не будет анализировать фрагмент и не позволит ему отображаться в результатах поиска, поэтому данные не должны публиковаться.

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

Итак, я действительно хотел бы понять... Кто-нибудь может объяснить, какова модель безопасности для идентификаторов фрагментов?


person JeremyS    schedule 24.12.2013    source источник
comment
Я понятия не имею, о чем вы спрашиваете, вы говорите об якоре или вы говорите о параметрах GET   -  person Mr. Alien    schedule 24.12.2013
comment
Якорный текст, безусловно, может быть проиндексирован Google и отображаться в результатах поиска. Это очень важная стратегия SEO. Какая?   -  person Justin    schedule 24.12.2013
comment
Я говорю о компоненте URL, который идет после «#». Хорошо, по-видимому, это называется именованным якорем или также «идентификатором фрагмента». en.wikipedia.org/wiki/Fragment_identifier   -  person JeremyS    schedule 25.12.2013


Ответы (2)


Тайлер Клоуз и другие, разрабатывавшие архитектуру безопасности для Waterken, провели соответствующее исследование. Они используют неугадываемые строки во фрагментах URI в качестве веб-ключей:

Эта утечка URL-адреса с разрешением через заголовок Referer на практике представляет проблему только в том случае, если целевой хост гиперссылки отличается от хоста-источника и, следовательно, потенциально опасен. RFC 2616 предвидел опасность такой утечки информации и поэтому предоставил руководство по безопасности в разделе 15.1.3:

«Поскольку источником ссылки может быть личная информация или может раскрываться иной источник частной информации… Клиенты НЕ ДОЛЖНЫ включать поле заголовка Referer в (незащищенный) HTTP-запрос, если ссылающаяся страница была передана по защищенному протоколу».

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

Такое активное использование заголовка Referer представляло бы значительный барьер для реализации концепции веб-ключа, если бы не одно несвязанное, но довольно удачное требование, предъявляемое к использованию заголовка Referer. Раздел 14.36 RFC 2616, регулирующий использование заголовка Referer, гласит: «URI НЕ ДОЛЖЕН включать фрагмент». Тестирование развернутых веб-браузеров показало, что это требование обычно выполняется.

Помещение неопределенного ключа разрешения в сегмент фрагмента создает URL-адрес https, который выглядит так: <https://www.example.com/app/#mhbqcmmva5ja3>.

Получение представления

Размещение ключа в компоненте фрагмента URL предотвращает утечку через заголовок Referer, но также усложняет операцию разыменования, поскольку фрагмент также не отправляется в Request-URI HTTP-запроса. Эта сложность преодолевается с помощью двух краеугольных камней Web 2.0: JavaScript и XMLHttpRequest.


Итак, да, вы можете использовать идентификаторы фрагментов для хранения секретов, хотя эти секреты могут быть украдены и эксфильтрированы, если ваше приложение восприимчиво к XSS, и для идентификаторов фрагментов не существует эквивалента файлов cookie только для http.

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

person Mike Samuel    schedule 24.12.2013

Часть после # не более безопасна, чем любая другая часть URL. Единственное отличие состоит в том, что он МОЖЕТ быть исключен из журнала доступа к веб-серверу. Но веб-сервер не представляет угрозы.

Пока вы храните секрет либо в URL-адресе, либо где-то еще, где он может стать общедоступным, он небезопасен. Вот почему мы изобрели пароли, потому что они должны существовать только в головах людей.

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

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

person Audun Larsen    schedule 24.12.2013
comment
Что вы подразумеваете под «тегом привязки», например <a>? - person Gumbo; 25.12.2013
comment
@Gumbo Прости за это. Я, конечно, говорил о части после #. - person Audun Larsen; 25.12.2013
comment
Это будет известно как идентификатор фрагмента. - person Gumbo; 25.12.2013
comment
Фрагмент не отправляется на сервер. - person Mike Samuel; 25.12.2013
comment
Нет, но обычно вы хотите передать секрет серверу в какой-то момент. Так что сервер — это не тот, от кого вы хотите его защитить. - person Audun Larsen; 25.12.2013
comment
Секреты в идентификаторах фрагментов не хэшируются, не шифруются и не запутываются каким-либо образом. Это не означает, что они бесполезны, но ограничивает их использование. Но если просто вставка фрагмента в браузер раскрывает секрет, например. проиндексировав его Google, конечно, тогда он бесполезен. - person JeremyS; 25.12.2013
comment
«Часть после # не более безопасна, чем любая другая часть URL». Это неправильно. Как говорится в другом ответе, «URI НЕ ДОЛЖЕН включать фрагмент» в заголовке Referer. Поскольку он удаляется во время перехода (как в теории, так и на практике), он более безопасен, чем остальная часть URL. Использование слова «дебил» неконструктивно. - person fatal_error; 12.01.2019