Безопасность от неясности: как насчет URL?

Question

Прежде всего, вопрос с наивной точки зрения:

У меня есть веб-приложение с URL-адресом к продукту, подобному Products?id=123.Допустим, у меня есть страница администрирования, доступная с Products?id=123&editable=true.

Если я считаю, что никто никогда не будет пытаться включить параметр editable, и, таким образом, не нужно никакого дополнительного механизма безопасности для защитына этой странице это защита от неясности , и это не очень хорошая идея, верно?

-

В моей реальной задаче проблема немного более тонкая: есть лиОпасно ли позволять кому-либо знать URL моей администрации?например, работая с XSL, я хотел бы написать:

<xsl:if test="/webAlbums/mode/@admin">
    (compute edit link)
</xsl:if>

но не будет ли потенциальному злоумышленнику легче найти слабость в «важных» страницах?

Answer 1

Безопасность через неизвестность - это совсем не безопасность.Не рассчитывайте на это.

Вы должны создать систему аутентификации, которая не позволяет людям использовать страницу администратора при реальной безопасности.

Что касается людей, знающих ваши админские URL-адреса, то все должно быть в порядке:Пока ваша страница администратора защищена и конфиденциальные данные не отображаются в URL (например, внутреннее представление типа данных, внутренний идентификатор некоторых данных и т. д.).

Answer 2

Даниэль Мисслер дает еще один элемент ответа в своем блоге, тот, который я имел в виду, когда писал вопрос, но не мог сформулировать:

• Непрозрачность как слой делает систему с уже хорошей защитой более трудной для цели, что улучшает ее общее состояние безопасности.
• Безопасность через непрозрачность означает, что после попадания в цель система будет беззащитна, т. Е. Вся ее безопасность обеспечивается секретностью.

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

Если взломщики не знают, где находится дверь, они с меньшей вероятностью попытаются ее взломать!

Это то, что он делает, изменяя свой порт SSHd на 24, сканер портов найдет сервер SSH, но автоматические сценарии грубой силы будут использовать только стандартный.

Результаты? после выходных 18 000 атакуют на порт 22 и 5 на порт 24 (он разрешил открыть оба порта, чтобы разрешить сравнение).

Answer 3

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

• Как и любая другая аутентификацияЕсли вы обращаетесь к странице администратора без HTTPS, запрос страницы (содержащий действительный «пароль») отправляется в открытом виде.

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

• Как и во всех паролях, если секретный URL-адрес достаточно прост, существует разумная вероятность, что он можетбыть грубым.Что-то вроде &editable=true не кажется мне таким безопасным.

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

Answer 4

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

Чтобы это работало, вам нужно убедиться, что часть URL так же сложно угадать, как и надежный пароль. Неважно, где вы его включаете, если страница не может быть отредактирована, если эта часть не верна.

Небезопасный пример:

Products?id=123&editable=true

Безопасные примеры:

Products?id=123&editable=true&edit-token=GgSkJSb6pvNT
Products?id=123&edit=GgSkJSb6pvNT
edit/GgSkJSb6pvNT/Products?id=123
GgSkJSb6pvNT/Products?id=123