Разделяй и властвуй: как мы реализовывали разделение сессий на портале Mail.Ru

Правильно сделать так, чтобы код, который обслуживает запросы пользователей, и код, который производит авторизацию запросов и работает с эккаунтами пользователями были изолированы друг от друга. Изоляция может быть в рамках одной машины, если это небольшой проект — разнести его по разным виртуальным хостам, системным эккаунтам, возможно, виртуальным машинам. В случае двух сильно удаленных хостов с негарантируемой связью это единственный вариант. Если проект большой — то чем больше уровней изоляции — тем лучше — т.е. желательно разносить не просто по разным виртуальным хостам, системным эккаунтам — но и по разным физическим машинам и сегментам сети.

Если вопрос о том, как безопасно связать 2 сервера — то ответ: через VPN.

куку просто надо подписывать одним ключем, который секретно храниться на двух серверах. Посмотрите как это реализовано в asp.net «из коробки» msdn.microsoft.com/en-us/library/ff649308.aspx
Ну и проверять пришедшую куку перед какой-то с ней работой естественно.

vk.com действительно самый посещаемый сайт рунета, но не портал. Mail.Ru это не только главная страница или почта — это несколько сотен проектов. Месячная аудитория портала Mail.Ru – 59 млн. Для сравнения: ВКонтакте, — 52,1 млн (TNS, все население России в возрасте от 12 до 64 лет, март 2014 г.) и он только третий.

Я подумал, что Mail.Ru в какой-то момент был самым посещаемым сайтом рунета.

Очень правильный вопрос, спасибо.

Принудительный HTTPS (перенаправление + HTTP Strict Transport Security) обязательно нужен на критичных проектах, но он не отменяет необходимости реализовывать разделение сессий, потому что:

• Без разделения сессий компрометация одного из проектов приведет к компрометации всех проектов. В качестве примера можно привести Heartblead. Несколько проектов у нас были поддвержены этой атаке. По счастью, почту и центр авторизации «пронесло». Это как раз тот случай, когда нас спасло разделение сессий, т.к. компрометация второстепенных проектов не привела к компрометации учетных записей пользователей и почты.
• Если у кук нет флажка HTTPOnly, то XSS приводит к угону сессии, наличие https никак не влияет на это
• HTTP Strict Transport Security работает не во всех браузерах + не работает, когда пользователь долго не заходил на сайт.
  Если у куки нет флажка Secure, то MitM все равно может угнать куку, заставив пользователя посетить незащищенный сайт, т.к. в запросе на незащищенный сайт кука будет присутствовать. Принудительный HTTPS в данном случае тоже не спасет.

Т.е. надо использовать И принудительный https И разделение сессий.

Зависит от проекта.
Там, где отдается много аудио/видео/больших картинок, будут очень большие накладные расходы на шифрование.
Как на серверах, так и на клиентах (а особенно на мобильных клиентах).
Т.е. вылезают проблемы из другой области.

Деталей реализации не знаю, но гугл совершенно точно использует разделение сессий по поддоменам.

Это почти тот же интересный и правильный вопрос, что обсуждался чуть выше, про то, что не проще ли внедрить принудительный https. Таким образом vk.com решается проблему относительно безопасного использования сессионных кук на небезопасном сайте без поддержки . Это в общем-то костыль, решение не надежно — если у вас в интернет-кафе отснифили привязанную к IP куку, то пока вы сидите в кафе и даже когда вы из кафе уходите, у похитителя остается доступ к сайту вместе с вашим прошлым IP адресом. Конечно, через некоторое время эта сессия проэкспайрится, но до тех пор ваш эккаунт доступен.
В почте Mail.Ru эта проблема решается именно путем принудительного https и HSTS, что гораздо надежней. vk.com уже внедряет https на добровольной основе и, надеюсь, в итоге придет к тому же решению с принудительным https + HSTS.

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

Если по пунктам:
1й — не получится из-за X-Frame-Options на главной странице.
2й — shell of the future не обходит ограничения HTTPOnly, это реверс-шел на JS и имеет доступ только к тому, к чему имеет доступ JS. JS не имеет доступа к HTTPOnly кукам. Кроме того, загрузить внешний скрипт на наших основных проектов может быть немного сложно из-за CSP (Content Security Policy).
3й — НО, даже если полуилось загрузить скрипт и даже если бы скрипт имел доступ к кукам на главной странице, для того, чтобы получить доступ к сессии электронной почты, не достаточно куки с главной страницы, это как раз заслуга разделения сессий. Чтобы получить доступ к электронной почте, XSS должен быть именно в электронной почте.

И кстати, у нас есть программа поиска уязвимостей, за XSS в почте мы платим около $500, присоединяйтесь.

Да совершенно верно. Выше обсуждался вариант, который еще более похож на Kerberos, когда клиент получает подписанную куку.

Можно и curl, но на самом деле проще даже без курла — именно проксированием запроса (+служебные заголовки, например для передачи информации о клиенте, токена авторизации проекта и т.п.) и ответа — например балансировщиком или на reverse proxy. Центр авторизации в таком случае отвечает и за валидацию токена и за то, чтобы он был одноразовым. Это позволяет избежать лишнего дублирующего кода в проектах.

Как вариант, можно подписывать токен, но тогда логику проверки придется реализовывать в каждом проекте.