Как безоружный обход искателя WebForms аутентификации и захват пользовательской сессии?

Вчера вечером клиент назвал, безумным, потому что у Google были кешированные версии информации личного сотрудника. Эта информация недоступна, если вы не авторизованы.

Они выполнили поиск Google для своего домена, например:

site:example.com

и заметил, что Googled просканировал и закрепил некоторые внутренние страницы.

Посмотрите на кешированные версии страниц:

Это кэш Google в https://example.com/(F (NSvQJ0SS3gYRJB4UUcDa1z7JWp7Qy7Kb76XGu8riAA1idys-nfR1mid8Qw7sZH0DYcL64GGiB6FK_TLBy3yr0KnARauyjjDL3Wdf1QcS-ivVwWrq-htW_qIeViQlz6CHtm0faD8qVOmAzdArbgngDfMMSg_N4u45UysZxTnL3d6mCX7pe2Ezj0F21g4w9VP57ZlXQ_6Rf-HhK8kMBxEdtlrEm2gBwBhOCcf_f71GdkI1))/ViewTransaction.aspx? TransactionNumber = 12345. Это снимок страницы, как он появился 15 сентября 2013 00:07:22 GMT

Меня смутил длинный URL. Вместо:

https://example.com/ViewTransaction.aspx?transactionNumber=12345

была вставлена длинная строка:

https://example.com/[...snip...]/ViewTransaction.aspx?transactionNumber=12345

Мне потребовалось несколько минут, чтобы помнить: это может быть признаком ASP.net "без cookie-сессий". Если ваш браузер не поддерживает Set-Cookie, веб-сайт будет вставлять cookie в URL-адрес.

Кроме того, наш сайт не использует это.

И даже если на нашем сайте были автоматически обнаружены файлы cookie, и Google удалось уговорить веб-сервер передать ему сеанс в URL-адресе, как он взял на себя другой сеанс пользователя?

Да, Google не вредоносный бот захватил сеанс

Сайт просканирован ботами в течение многих лет. И это прошлое 29 мая ничем не отличалось.

Обычно Google запускает обход, проверяя файл robots.txt (у нас его нет). Но никто не может ничего готовить на сайте (в том числе robots.txt) без предварительной аутентификации, поэтому он терпит неудачу:

Time      Uri                      Port  User Name         Status
========  =======================  ====  ================  ======
1:33:04   GET /robots.txt          80                      302    ;not authenticated, see /Account/Login.aspx
1:33:04   GET /Account/Login.aspx  80                      302    ;use https plesae
1:33:04   GET /Account/Login.aspx  443                     200    ;go ahead, try to login

Все это время Google искал файл robots.txt. Это никогда не было. Затем он возвращается, чтобы попытаться выполнить сканирование корня:

Time      Uri                      Port  User Name         Status
========  =======================  ====  ================  ======
1:33:04   GET /                    80                      302    ;not authenticated, see /Account/Login.aspx
1:33:04   GET /Account/Login.aspx  80                      302    ;use https plesae
1:33:04   GET /Account/Login.aspx  443                     200    ;go ahead, try to login

И еще одна проверка robots.txt на защищенном сайте:

Time      Uri                      Port  User Name         Status
========  =======================  ====  ================  ======
1:33:04   GET /robots.txt          443                     302    ;not authenticated, see /Account/Login.aspx
1:33:04   GET /Account/Login.aspx  443                     200    ;go ahead, try to login

И затем таблица стилей на странице входа:

Time      Uri                      Port  User Name         Status
========  =======================  ====  ================  ======
1:33:04   GET /Styles/Site.css     443                     200

И как работает каждый обход из GoogleBot, msnbot и BingBot. Роботы, логин, безопасность, логин. Никогда не получайте нигде, потому что он не может пройти мимо Аутентификация WebForms. И все хорошо с миром.

До одного дня; из ниоткуда

До одного дня появляется GoogleBot с файлом сессии в руке!

Time      Uri                        Port  User Name            Status
========  =========================  ====  ===================  ======
1:49:21   GET /                      443   [email protected]  200    ;they showed up logged in!
1:57:35   GET /ControlPanel.aspx     443   [email protected]  200    ;now they're crawling that user stuff!
1:57:35   GET /Defautl.aspx          443   [email protected]  200    ;back to the homepage
2:07:21   GET /ViewTransaction.aspx  443   [email protected]  200    ;and here comes the private information

Пользователь, [email protected] не был зарегистрирован в течение дня. (Я надеялся, что IIS предоставил один и тот же идентификатор сеанса двум одновременным посетителям, разделенным повторной обработкой приложения). И наш сайт (web.config) не настроен для включения cookie без сеанса. И сервер (machine.config) не настроен для включения cookie без сеанса.

Итак:

Как Google получил хэндл без сеанса?
Как Google получил ahold действительного файла cookie без сеанса?
Как Google задерживал действительный файл cookie без сеанса, принадлежащий другому пользователю?

Совсем недавно, как 1 октября (4 дня назад), GoogleBot все еще показывался, куки файлы в руке, регистрировались в качестве этого пользователя, обходили, кэшировали и публиковали некоторые свои личные данные.

Как ~~Google~~ не вредоносный веб-искатель обходит аутентификацию WebForms?

IIS7, Windows Server 2008 R2, один сервер.

Теория

Сервер не настроен на предоставление cookieless сессий. Но игнорируя этот факт, как Google может обходить аутентификацию?

GoogleBot создает веб-сайт и пытается использовать произвольные имена пользователей и пароли (маловероятно, что в журналах нет попыток входа в систему)
GoogleBot решил вставить случайный cookieless-сеанс в строку url, и это совпадало с сеансом существующего пользователя (маловероятно)
Пользователю удалось выяснить, как сделать веб-сайт IIS возвратом cookieless-url (вряд ли), а затем вставить этот URL-адрес на другой веб-сайт (вряд ли), где Google обнаружил cookieless-url и выполнил сканирование
Пользователь работает через мобильный прокси (а это не так). Прокси-сервер не поддерживает файлы cookie, поэтому IIS создает сеанс cookieless. Тот (к примеру, Opera Mobile) был взломан (не вероятно), и все кэшированные ссылки размещены на форуме хакеров. GoogleBot просканировал форум хакеров и начал следить за всеми ссылками; включая наш [email protected] cookieless url сеанса.
У пользователя есть вирус, которому удается уговорить любые веб-серверы IIS, чтобы передать файл cookieless. Затем этот вирус возвращается в штаб-квартиру. URL-адреса отправляются на общедоступный ресурс, который сканирует GoogleBot. GoogleBot затем появляется на нашем сервере с файлом cookieless.

Никто из них не правдоподобен.

Как ~~Google~~ нехитрый веб-искатель обходит проверку WebForms и захватывает существующий сеанс пользователя?

Что вы спрашиваете?

Я даже не знаю, как веб-сайт ASP.net, который не настроен на предоставление cookieless-сессий, может выдавать cookieless сеанс. Возможно ли обратное преобразование идентификатора сеанса на основе файлов cookie в идентификатор сеанса на основе cookieless? Я мог бы процитировать соответствующий раздел <sessionState> web.config и machine.config, и показать, что не существует

<sessionState cookieless="true">

Как веб-сервер решил, что браузер не поддерживает файлы cookie? Я попытался заблокировать файлы cookie в Chrome, и мне никогда не давали идентификатор сеанса cookie-less. Могу ли я имитировать браузер, который не поддерживает файлы cookie, чтобы убедиться, что мой сервер не выдал cookieless сессий?

Определяет ли сервер cookieless сеансы с помощью строки User-Agent? Если это так, я могу установить Internet Explorer с поддельным UA.

Идентифицирует ли идентификатор сеанса в ASP.net исключительно cookie? Может ли кто-либо из любого IP-адреса с помощью cookie-url получить доступ к этой сессии? Не учитывает ли ASP.net, по умолчанию, также?

Если ASP.net делает связывание IP-адреса с сеансом, не означает ли это, что сеанс не мог возникнуть у сотрудника на своем домашнем компьютере? Потому что тогда, когда искатель GoogleBot попытался использовать его с IP-адреса Google, он не сработал?

Были ли какие-либо экземпляры в любом месте (помимо того, что я связал) ASP.net, выдавая cookieless-сессии, когда он не настроен? Есть ли проблема с Microsoft Connect?

Известно ли, что проверка подлинности в Web-Forms имеет проблемы и не должна использоваться для обеспечения безопасности?

Чтение бонусов

qaru.site/info/309648/...

Изменить. Удалено имя ~~Google~~ бота, который обошел привилегию, поскольку люди - штаны с задержкой головы; путайте ~~Google~~ имя искателя для чего-то другого. Я использую ~~Google~~ имя искателя в качестве напоминания о том, что это был не вредоносный веб-искатель, который смог просканировать его в другой сеанс WebForm пользователя. Это можно сравнить с вредоносным искателем, пытающимся проникнуть в другой сеанс пользователя. Ничто не похоже на педант, чтобы выявить обострение.

Ответ 1

Хотя вопрос в основном ссылается на идентификаторы сеанса, длина идентификатора показалась мне необычной.

Существует не менее двух типов операций cookie/cookieless, которые могут изменять строку запроса, чтобы включить идентификатор.

Бескидные сессии
Знаки аутентификации без cookie файлов

Они полностью независимы друг от друга (насколько я могу судить).

Состояние сеанса

Сегмент без cooki позволяет серверу получать данные состояния сеанса на основе уникального идентификатора в URL-адресе и уникального идентификатора в cookie файле. Обычно это считается прекрасной практикой, хотя ASP.Net повторно использует идентификаторы сеансов, что делает его более склонным к попыткам фиксации сеанса (отдельная тема, но стоит знать).

Идентифицирует ли идентификатор сеанса в ASP.net исключительно cookie? Можно любой, с любого IP, с файлом cookie-url, получает доступ к этой сессии? Есть ли ASP.net не по умолчанию также учитывает?

Идентификатор сеанса - это все, что требуется.

Общие сведения о безопасности сеанса

Аутентификация форм

В зависимости от длины примерных данных, я предполагаю, что ваш URL действительно содержит значение проверки подлинности, а не идентификатор сеанса. Исходный код предполагает, что режим cookieless не является чем-то, что вы должны явно включить.

/// <summary>ASP.NET determines whether to use cookies based on
/// <see cref="T:System.Web.HttpBrowserCapabilities" /> setting. 
/// If the setting indicates that the browser or device supports cookies, 
/// cookies are used; otherwise, an identifier is used in the query string.</summary>
UseDeviceProfile

Вот как делается определение:

// System.Web.Security.CookielessHelperClass
internal static bool UseCookieless( HttpContext context, bool doRedirect, HttpCookieMode cookieMode )
{
    switch( cookieMode )
    {
        case HttpCookieMode.UseUri:
            return true;
        case HttpCookieMode.UseCookies:
            return false;
        case HttpCookieMode.AutoDetect:
            {
                // omitted for length
                return false;
            }
        case HttpCookieMode.UseDeviceProfile:
            if( context == null )
            {
                context = HttpContext.Current;
            }
            return context != null && ( !context.Request.Browser.Cookies || !context.Request.Browser.SupportsRedirectWithCookie );
        default:
            return false;
    }
}

Угадайте, что такое по умолчанию? HttpCookieMode.UseDeviceProfile. ASP.Net поддерживает список устройств и возможностей. Этот список, как правило, очень плох; для пример, IE11 дает ложное положительное значение для того, чтобы быть браузером нисходящего потока наравне с Netscape 4.

Причины

Я думаю, что объяснение Джина очень вероятно; Google нашел URL-адрес от некоторого действия пользователя и выполнил его сканирование.

Совершенно очевидно, что бот Google считается не поддерживающим файлы cookie. Но это не объясняет происхождение URL-адреса, т.е. Какое действие пользователя привело к тому, что Google увидел URL-адрес с уже ID-идентификатором? Простым объяснением может быть пользователь с браузером, который, как считалось, не поддерживает файлы cookie. В зависимости от браузера все остальное может выглядеть хорошо для пользователя.

Время, т.е. продолжительность действия кажется длинным, хотя я не знаю, как долго действительны билеты на аутентификацию и при каких обстоятельствах они могут быть возобновлены. Это вполне возможно, что ASP.Net продолжает переиздавать/продлевать билеты, как это было бы делать для постоянно действующего пользователя.

Возможные решения

Я делаю здесь много предположений, но если я прав:

Во-первых, воспроизведите поведение в вашей среде.

Явно отключить cookieless поведение с помощью HttpCookieMode.UseCookies.

web.config

 <authentication mode="Forms">
    <forms loginUrl="~/Account/Login.aspx" name=".ASPXFORMSAUTH" timeout="26297438"
           cookieless="UseCookies" />
 </authentication>

В то время как это должно устранить поведение, вы можете исследовать расширение модуля HTTP проверки подлинности форм и добавление дополнительной проверки (или, по крайней мере, протоколирования/диагностики).

Ответ 2

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

Откажитесь от идеи, что ваш сайт настроен не на кодирование информации о сеансе в URI. С очень высокой вероятностью он сделал это. Либо вы ошибаетесь в настройке, либо, скорее всего, там есть ошибка, из-за которой это произошло.

Это оставляет основной вопрос: как Google получил URI сеанса?

Вы ничего не сказали о клиентской базе. Вот догадка:

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

Существуют и другие аналогичные способы, с помощью которых клиент, чей клиент создал URI, может непреднамеренно передать его Google. Документ Google Диска. Размещение Google Plus. И т.д.

Google не может быть злым, но, тем не менее, он везде. Их соглашение об использовании позволяет им перемещать ссылки по границам продукта, в этом случае почта (и т.д.) Для поиска.

Реальный вопрос, о котором вы должны думать, - это то, почему ваш сайт не защищен от подделки подпроса. Люди Rails объясняют это довольно красиво. Механизм Rails protect_from_forgery предотвратил бы возникшую проблему.

Связанный с этим вопрос заключается в том, почему закодированный cookie (по-видимому) никогда не истекает. Это должно быть легко сделать, чтобы сеансы содержали временные метки, чтобы сделать это.