Я никогда не оставляю бэкдоры в своей системе, но из любопытства мне было интересно, оставил ли я секретный URL-адрес, например /x 52d23r, который позволил обойти какую-то безопасность, и это было только для моего личного использования - это было бы каким-то образом обнаруженным третьей стороной, не получая от меня информацию?
Например, секретные порты могут быть отсканированы и отпечатаны в порту, но может ли быть такая же тактика для секретных URL-адресов?
Исходный ответ: Безопасность через скрытность - это то, что должно быть никогда.
Я хотел бы расширить это, поскольку я вижу, что по-прежнему делается какой-то аргумент, что секретный URL-адрес не отличается от пароля. Я бы очень не согласился с этим сравнением. Секретный URL-адрес и пароль do разделяют одну аналогичную характеристику: они известны одному или нескольким конкретным людям/людям. Вот где заканчивается сходство.
Сила паролей
Создание пароля из серии случайных слов делает пароль очень сильным и очень трудным для угадывания или грубой силы.
Пароль должен быть связан с именем пользователя, что также может повысить безопасность, если имя пользователя не является обычным явлением.
Комбинации имени пользователя и пароля не статически отображаются на экране и не сохраняются нигде в браузере (если вы не решили, что ваш браузер "сохранит" ваши учетные данные).
Пароли могут быть изменены в случае нарушения без необходимости изменения точки входа в систему.
Хорошие системы паролей не хранят их в текстовом формате в файловой системе.
Слабость секретного URL
Если используется в режиме "Инкогнито", "Private" и т.д., URL-адрес будет сохранен в вашей локальной истории/кеше.
URL-адреса отображаются в окне браузера и могут быть привязаны к блуждающим глазам.
Если секретный URL-адрес взломан, вы должны его изменить и уведомить любого пользователя.
URL-адрес существует в виде обычного текста на сервере где-то, будь то реальный каталог/файлы или как переписывать (однако переписать можно было бы на гораздо более высоком уровне).
Все остальное, что @Mike Кларк упомянул в его ответе.
Что это действительно происходит:
Секретные URL-адреса занимаются защитой только через неясность. Что это.
Пароли могут быть скрыты по определению, но дополнительные усилия, меры предосторожности и защищенные пароли добавляет уровень безопасности поверх всего. Другими словами, пароли являются многоуровневыми и практикуют безопасность с помощью других средств в дополнение к безвестности. Это, в свою очередь, делает их лучшим выбором, чем простой скрытый URL.
Рекомендация: Используйте как "секретный" URL-адрес, так и очень сильную комбинацию имени пользователя и пароля. Не полагайтесь на JUST "секретный" URL.
Никогда не практикуйте безопасность, используя неизвестность как единственную гарантию.
Причина использования "секретного URL" обычно небезопасна не потому, что это "безопасность через безвестность". В теории информации секретный URL-адрес не отличается от пароля или закрытого ключа. Являются ли пароли и частные ключи плохой практикой, потому что они "безопасность через неясность"? Нет.
Итак, какая разница между труднодоступным URL и труднодоступным паролем?
Разница заключается в множестве небезопасных мест и способах сохранения, отображения и передачи URL-адресов. Примеры:
HTTPS может защитить некоторые из них, но не все из них (элементы, отмеченные *, не защищены от использования HTTPS.)
В сильно контролируемой среде труднодоступные URL-адреса могут быть безопасными. Но при использовании обычных веб-браузеров, веб-серверов и веб-фреймвордов трудно полагаться на труднодоступные URL-адреса, если не существует другой возможности (и даже тогда вы должны тщательно рассмотреть).
Это не безопасно.
Для HTTP-трафика ваш секретный URL-адрес будет эффективно публиковаться, как только вы его используете. Без какой-либо защиты паролем прослушиватель вашего сетевого трафика мог видеть URL-адрес, который вы отправляете, а затем на той же странице.
Не хорошая идея, потому что:
Я бы сказал, если вы будете осторожны, они могут быть в безопасности. Наибольшая дыра в безопасности будет использовать люди. Это будет непреднамеренно распространено или опубликовано где-нибудь, что Google проиндексирует его. Создайте для этого и используйте его соответствующим образом - например, в документе Google "Кто-нибудь с этой ссылкой".
Используйте HTTPS
Останавливает отправку URL-адреса в виде открытого текста
Не устанавливает заголовки заголовков, если они нажимают ссылку HTTP
Если пользователи обращаются к вашему секретному URL через HTTP, предупредите их и немедленно измените его
не защищенность через неясность - непонимание нормального использования фразы.
"Система, основанная на неясность может иметь теоретические или фактические уязвимости безопасности, но его владельцы или дизайнеры считают, что недостатки неизвестны, и что нападавшие вряд ли найдут их".
В отличие от этого вы открываете о внедрении и дизайне.
Я не вижу, что это менее безопасно, чем средний пароль при использовании с длинным секретным URL (всего 64 символа? 2000 - domain_length?), в комбинация с tar-ямой.
Я планирую использовать его в приложении, где я чувствую, что люди будут ценить простоту выше безопасности.
Waterken веб-сервер - это веб-платформа, разработанная людьми безопасности в исследованиях HP вокруг секретных (в частности, криптографически неописуемых) URL-адресов.
Приложения, построенные на нем, имеют в результате некоторые очень интересные свойства безопасности.
Сделано правильно, криптографически сильные секретные URL-адреса могут обеспечить высокий уровень безопасности.
ACLs Не - это документ из команды waterken по архитектуре безопасности.
Сравнение предлагаемой защиты с решением на основе возможностей для сценария компиляции и снова предполагая Unix-подобную систему: URL-адрес похож на фи lename; и неописуемый токен подобен файлу дескриптор, аппроксимирующий неприступность способности с неустранимостью. Допустимая страница из фондовые брокеры на веб-сайте сначала открывают покупку акций ресурс, получающий неописуемый секрет. Браузер затем использует этот неописуемый секрет для записи в акции ресурс покупки.
было бы каким-то образом обнаружено третьей стороной, не получая от меня информацию? Например, секретные порты могут быть отсканированы и отпечатаны в порту, но может ли быть та же самая тактика для секретных URL-адресов?
Да. Вы думаете об угрозе, когда человек сидит за компьютером, набрав URL-адрес в своем браузере. Реальность такова, что злоумышленники используют автоматизированные программы, которые выполняют разведку в системах и используют эту информацию для совершения различных атак. Попытка случайных URL-адресов имеет мало стоимости для автоматической системы, чем может генерировать сотни HTTP-запросов в секунду. Во-вторых, как отметили другие, как только вы используете URL-адрес, он больше не секрет. Эти автоматизированные программы прослушивают интернет-трафик и собирают URL-адреса для покупок. Тот факт, что только вы знаете URL, означает, что ни один другой человек не может разглашать его значение. Это не мешает техническим средствам разглашать значение.
Это на самом деле довольно разумная идея, если вы используете большой и произвольно сгенерированный URL-адрес. есть много систем, которые действительно работают так уже. например, в документах google, вы можете создать ссылку, которая может редактировать любой документ с этой ссылкой. Это достаточно долго, что вы никогда не сможете догадаться об этой ссылке. Кроме того, пароль reset ссылки в основном это, за исключением того, что они (надеюсь) используются только один раз. (см. ниже)
Вам нужно убедиться, что секрет не просочился. Это означает использование https, не протоколирование доступа или возврат секретности в других вызовах api.
Тем не менее, как отмечают многие вышеперечисленные комментаторы, URL-адрес содержит всевозможные небезопасные места на вашем компьютере, но если у противника есть доступ к вашему компьютеру, вы уже ввернуты. Довольно типично предположить, что ваше конечное пользовательское устройство безопасно.
Кроме того, любой секрет - это только секрет, обратно пропорциональный тому, как много людей это знают. Возможно, возникает соблазн поделиться ссылкой с другими людьми, которые нуждаются в доступе. Лучше система может заставить каждый URL работать один раз, но добавить cookie в браузер пользователя, который является фактическим токеном. В принципе, точно так же, как поток пароля reset flow/email, за исключением паролей.