Использование поддоменов печенья с mod_auth_openidc

Так у меня есть подстановочный хост на Apache сервере с помощью mod_auth_openidc соответствующих биты моего Apache конфигурации являются:Использование поддоменов печенья с mod_auth_openidc

<VirtualHost *:443> 
ServerAlias *.sub.mydomain.com 
OIDCRedirectURI https://sub.mydomain.com/oauth2callback 
OIDCCookieDomain sub.mydomain.com

Есть что-нибудь, что бы запретить пользователь аутентификации с обув. sub.mydomain.com, а затем аутентифицироваться с помощью bar.myomain.com без необходимости повторного входа в систему?

источник

2015-10-09 Severun

В качестве последующего вопроса, если у меня есть два отдельных файла конфигурации, которые не используют подстановочные домены, что помешало бы кому-то пройти проверку подлинности с помощью foo.mydomain.com, а затем изменить имя хоста в заголовке на bar.mydomain.com и отправка тех же значений cookie на новый хост? Поскольку они являются виртуальными хостами на одном сервере, и оба они поддерживаются одним и тем же хранилищем сеансов, будут ли они работать как вектор атаки? – Severun

ОК. Я настраиваю тестовую конфигурацию и ответ на исходный вопрос, да, после аутентификации с указанной конфигурацией вы аутентифицированы для любого хоста на .midomain.com. Вопрос в моем втором комментарии еще не разрешен. Если я изменю домен cookie и домен в своем заголовке для запроса, смогу ли я получить доступ к различным доменам на одном хосте? – Severun

Нет, это работает после того, как файл cookie сессии установлен на sub.domain.com и как таковой получен на foo.sub.mydomain.com, а также bar.sub.mydomain.com.

То, что вы описали в комментарии, на самом деле не является атакой, поскольку оно является одним и тем же пользователем в одном браузере. Пример эквивалента того, что упоминалось выше, за исключением обработки вручную в браузере ... Было бы проблемой, что вы могли бы как-то украсть файл cookie у другого пользователя, но опять же, это будет атака, не относящаяся к mod_auth_openidc, и невозможно предположить все работает по https, и в браузере нет вредоносной программы.

Если вам действительно нужно разделение, вы можете разделить его на виртуальные хосты и запустить другую конфигурацию mod_auth_openidc на каждом хосте. Затем cookie Apache не будет использоваться повторно для двух хостов. Конечно, оба хоста все равно будут перенаправляться на OP для аутентификации, и там может существовать сеанс SSO + cookie, который неявно связывает эти два сеанса.

источник

2015-10-09 17:50:05

Короче говоря, я пытался получить один конфигурационный файл apache для поддержки нескольких виртуальных хостов. То, что я хочу предотвратить, - это тот, кто входит в систему с foo.sub.mydomain.com от доступа к bar.sub.mydomain.com. Я пытался сделать это с помощью одного виртуального хоста apache config. Я попробовал OIDCRedirectURI https: // $ {HTTP_HOST}/oauth2callback, и я также попробовал просто/oauth2callback, надеясь, что он будет атаковать хозяина на фронте, но ни один из них не работал. Кажется, я должен быть явным с параметром OIDCRedirectURI. – Severun

re: вектор атаки, что я постулирую, пользователь входит в систему foo и получает файл cookie mod_auth_openidc. У него нет доступа к бару, но он получает доступ, изменяя файл cookie, который он получил от foo, чтобы выглядеть так, как будто он появился из бара, затем передает тот же идентификатор сеанса и бар в качестве имени хоста запроса. Вопрос: mod_auth_openidc связывает cookie с хостом на стороне сервера/сеанса или же он просто ищет идентификатор сеанса независимо от того, на каком хосте используется куки? Или есть еще одна особенность https cookie или CSRF, которая мешает этому? – Severun

в одной конфигурации apache, вы должны ограничить доступ к бару, используя соответствующие инструкции 'Требование № : '. Если только пользователи из определенного OP A имеют доступ к «бару», а другие - нет, вы должны использовать 'Требовать требование iss: A' –

Использование поддоменов печенья с mod_auth_openidc

ответ

Смежные вопросы