Можно ли использовать случайные URL-адреса вместо паролей? [закрыто]

12

Считается ли это «безопасным» для использования URL, созданного из случайных символов, как это?

http://example.com/EU3uc654/Photos

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

Я настроил файл .htaccess, просто чтобы заметить, что нажатие на http://user:pass@url/ссылки не работает с некоторыми браузерами / почтовыми клиентами, вызывает диалоговые окна и предупреждающие сообщения, которые сбивают с толку моих пользователей, не слишком разбирающихся в компьютерах.

web-server authentication password password-protected тушеное мясо
источник
Нет. Вы можете использовать это, но не в качестве единственного или основного механизма аутентификации.
Эндрю Смит
1
Я пробовал это в качестве эксперимента много раз, и каждый раз ссылки попадают в поисковые системы. Я не знаю как, но я знаю, что это происходит.
Дэвид Шварц
Возможно, вы захотите настроить SSL для прекращения предупреждений, вы можете получить бесплатные сертификаты от Startsl.com, и SSL больше не требует больших вычислительных ресурсов (если его правильно настроить).
Юбер Карио
Этот вопрос является классическим «неконструктивным» примером. Мы не знаем, насколько вы цените безопасность ваших фотографий. Единственный способ сообщить о важности безопасности - это методология авторизации, которую вы используете для защиты доступа к этим изображениям. То, что вы получили, это «аргументы дебатов» в форме «ответов». Но ни один из них не является полным обзором современных аспектов безопасности и технических последствий. Вам следует ознакомиться с методами безопасности, предоставляемыми вашей платформой, и оценить ценность каждого из них для вашей ситуации; если у вас есть дополнительные вопросы после того, как вы это сделали, то спросите еще раз.
Крис С

Ответы:

17

«Хорошо» или нет, зависит от того, насколько чувствительны изображения.

Если вы не используете SSL, URL-адреса, HTML и сами изображения будут кэшироваться на компьютерах вашего пользователя. Это может протечь, но я считаю это маловероятным.

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

Правильная аутентификация, такая как HTTP-аутентификация или переменная POST, не должна кэшироваться таким образом или передаваться на какой-либо родительский веб-сайт.

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

Ladadadada
источник
+1 за упоминание панелей инструментов браузера.
Юбер Карио
23

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

user9517
источник
10
Разве все пароли не являются безопасностью через неизвестность?
Уинстон Эверт
4
@WinstonEwert: Сами пароли не имеют ничего общего с безопасностью через неясность, которая связана с секретностью проектирования / реализации. Например, в случае базовой аутентификации Apache его дизайн / реализация полностью открыта для всеобщего обозрения.
user9517
10
ерунда - все это безопасность через мрак. Все дело в том, что для этого вам понадобится информация, которая вряд ли будет угадываема. Фраза «Безопасность через неизвестность» чрезмерно злоупотребляет. Случайный фрагмент URL в точности эквивалентен введению «пароля» в URL. Единственный вопрос - кто может это видеть, и ответ, который я добавил в своем комментарии, - «промежуточные прокси, плюс это http, так что любой, кто может прослушивать»
Брон Гондвана
1
Одна ошибка (или возврат к конфигурации по умолчанию) в конфигурации Apache, и ваши каталоги показывают индексы со всеми файлами и каталогами на ладони, а не с паролями.
Юбер Карио
4
Вы говорите, что безопасность через неясность «связана с секретностью проектирования / реализации». Но ясно, что случайные URL не связаны с секретностью дизайна / реализации. Таким образом, случайные URL-адреса, какими бы ни были их недостатки, не могут быть классифицированы как безопасность из-за неизвестности.
Уинстон Эверт
6

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

И, конечно же, следите за случайностью вашего генератора.

Я предполагаю, что вы не ищете здесь сверхвысокую безопасность.

Брон Гондвана
источник
Если кто-то опубликует URL, ничто не помешает ему опубликовать пароль. Аутентификация по знаниям как фактор всегда может быть «обманута» вот так.
Мануэль Фо
@ManuelFaux: Конечно, если это намеренно. Но это также может быть случайным. Например, он может использовать инструмент, который проверяет URL-адреса, которые он посещает, чтобы узнать, были ли они объявлены вредоносными. Инструменты знают, что пароли должны храниться в секрете. Они знают, что параметры в URL могут быть чувствительными. Но они не знают, что делают пути в URL. (Например, http referer .)
Дэвид Шварц
5

Загадочный URL удобен для одноразовых загрузок, но не обеспечивает реальной защиты. Вы должны знать, что не все боты соблюдают файл robots.txt, поэтому, если на вашем сайте есть какая-либо ссылка, ведущая на замаскированную папку, она будет проиндексирована некоторыми поисковыми системами, и как только она начнется, обратного пути не будет.

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

Джон Гарденье
источник
5

Я хотел бы добавить еще один, возможно, более пугающий взгляд на запутанные URL, как в этом примере. Даже если ваш URL не передан случайно, он может быть отправлен поисковым системам:

  • Интернет-провайдер посетителя. Посещения по протоколу HTTP собираются, обрабатываются на основе данных и иногда даже напрямую продаются сторонним поставщикам услуг Интернета.
  • Облачное хранилище посетителей. Существует ряд сервисов, которые хранят закладки и историю для бесплатной синхронизации между установками браузера. Если они предварительно не зашифруют данные, как это делает Mozilla, то могут подразумеваться те же методы добычи данных.

YMMV.

Коркман
источник
о да - или просто с помощью плагина браузера, который ищет похожие сайты или позволяет пользователям делиться заметками о странице
Брон Гондвана
2

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

Я просто сделал, чтобы URL каждого пользователя содержал метку времени истечения и MD5 их электронной почты.

ТАК URL выглядит так:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

С учетом вышесказанного, если пользователь введет адрес электронной почты user@gmail.com до 30 июля, он будет хорош.

Не совсем военного уровня безопасности, но сделал работу.

Дэйв Э
источник
0

Это разделяет ту же уязвимость, что и сохранение sessionID в URL. Кто-то может случайно скопировать и вставить ссылку на других, забыть цензурировать ее на скриншоте или позволить кому-то искать ее, поскольку она не помечена звездочкой, как пароли.

Кроме того, если какой-либо контент защищен паролем, войдя в систему, Вы знаете, что это секрет. Если вы получите ссылку, вы можете легко забыть ее.

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

Я думаю, это не плохо, если это просто изображения. Но если это какие-то изображения, которыми вы бы действительно, на самом деле не хотели делиться;) тогда я предлагаю вам использовать более длинное случайное слово, больше похожее на одно из представленных dave.

РЕДАКТИРОВАТЬ: Добавить? DO_NOT_SHARE_THIS_LINK к URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos?DO_NOT_SHARE_THIS_LINK

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

Маркус фон Броади
источник
На самом деле это намного хуже, чем идентификаторы сессий, потому что сессии истекает через некоторое время. Поисковые системы, извлекающие идентификатор сеанса, вошедшего в систему, обычно в конечном итоге представляют неработающую ссылку / не вошли в сеанс в результатах. Или, если серверу все равно, он может синхронизировать сеанс многих пользователей, и когда один из них входит в систему, они все делают это. В любом случае, не так плохо, как постоянно авторизованный URL :-)
korkman
Конечно, это еще хуже, и вы также можете запомнить IP-адрес в сеансе, так как сначала вам нужно войти в систему, чтобы получить sessid в URL, а затем вы можете уничтожить сеанс, если IP-адрес изменился.
Маркус фон Броади