Итак, доброе время суток. Как-то немного я вижу здесь статей по изучению технической части некоторых сайтов, и постараюсь это исправить.
Сегодня мы будем изучать поискового гиганта : google. Но к сожалению не его поисковую машину, а просто систему авторизации, и способы угнать сессию пользователя.
Видимо многие сталкивались с тем, что вроде бы и куки пользователя угнали - а зайти в аккаунт не можем? Вот сейчас мы и увидим почему это случается.
Давайте рассмотрим как проходит авторизация и зайдем на accounts.google.com
Видим обычное поле логина, но нас инетресует другое : при входе на гугл, мы получаем куки GAPS и GALX. Заметим что при совершении любых действий они меняются и со старыми куками мы получаем сообщение о том что нам надо их очистить ( вот собственно и ответ почему мы не можем воспользоваться куками со стилера, их надо удалять у пользователя, чтобы холдер их не мог ими воспользоваться раньше нас).
Ещё довольно таки интересный момент есть в авторизации ( информация к людям, которые хотят побрутить web версию ) - будьте крайне внимательны к запросу на /signin/challenge/sl/password - они в параметрах передают cookie ( соответственно они вполне могут тянуть куку из js + гугл крайне чувствителен к http Referer
Ну да ладно - допустим мы авторизовались, получили в хедерах код 302 и нам предложили восстановить доступ к аккаунту - потому что мы зашли как-то слишком в другом месте. На этом этапе можно уже грабить mail+pass и спокойно сваливать, однако нас же интересует полный доступ к аккаунту и этим мы ограничиваться не будем.
Если нам предложили восстановить доступ к аккаунту - значит нам не передали самые важные куки SID, LSID, HSID, SSID, APISID, SAPISID, ACCOUNT_CHOOSER и NID ( это вроде по желанию ). Без этих куков нас постоянно будут просить восстановить доступ к аккаунту и к email мы доступа не получим.
Получаются эти куки любым предложенным путем ( ответить на секретный вопрос, или ввести город, из которого обычно заходишь ). Я выбрал способ по городу - потому что имея ip жертвы можно определить город - а значит и получить такой долгожданный доступ к аккаунту.
Кстати - api ключа к google maps там не введен - поэтому запись в консоли, которую вы увидите об отсутствии ключа - вполне нормальное явление. И да - если у вас в window.location.href находиться какое-то другое значение ( отличное от гугловского ) - вам вернут ошибочку и заблокируют окно ввода. Разблокируется она парой нажатий в Element Inspector конечно - но юзер же не будет этого делать
Итак - восстановили мы доступ, получили долгожданные куки - и вот оно счастье? Не совсем. Для работы почты требуется ещё 1-а кука : OSID. Но она впринципе ставиться автоматически через редиректы гугла. Кстати насчет редиректов - давайте составим списочек где мы и что получаем ( и как пройти квест по получению всех куков пользователя )
1) заходим на accounts.google.com и нас кидает на /ServiceLogin?passive=1209600&continue=https%3A%2F%2Faccounts.google.com%2FManageAccount&followup=https%3A%2F%2Faccounts.google.com%2FManageAccount
( заметим что в запросе у нас видно откуда мы пришли )
2) очень важный момент - на странице в рантайме подгружается ( у вас аргументы будут другими ) и вроде как добавляет некоторые input в форму, которую отправляем дальше.
3) После прохода промежуточного этапа, когда мы посылаем данные на accounts.google.com/AccountLoginInfo ( или accounts.google.com/AccountLoginInfoXhr в зависимости от ващего браузера ) ( где нам кстати обновляют куку GAPS ), мы сможем наконецто послать данные на авторизацию на /signin/challenge/sl/password ( данные улетают чистым текстом, так что если вы организовали mitm - то самое время тащить данные )
4) Здесь может быть несколько вариантов - либо нам сразу выдали все куки ( значит вы зашли с ip жертвы ), либо поменяли только GAPS и ждут от вас ответа.
5) в зависимости от того как вы восстанавливаете доступ вам потребуются разные запросы. Так как я рассматривал только по городу то я получил все куки после ответа на запрос в /signin/challenge/ll/5
6) после этого серии редиректов вида /CheckCookie и /accounts/SetSID (название куки, которую надо установить ), и наконеццто редирект на страницу, которая затребовала авторизации в гугле.
После всех этих этапов можно спокойно у пользователя удалять куки и сваливать. Кука OSID будет выставляться по вашим скомунизженным кукам. Главное чтобы холдер не имел к ним больше доступа. Иначе в 1 прекрасный день вы увидите сообщение что они просрочены ( хотя срок их не вышел ).
Могу дать впринципе листинг запросов и ответов, но это лучше 1 раз попробовать самому.
Во время изучения использовались только chromium и firefox ( у него прекрасный сетевой отладчик, который наглядно показывает какие куки были переданы на удаленную сторону, а какие приняты с сервера, что chromium например при ssl соединении не показывает ).
Сегодня мы будем изучать поискового гиганта : google. Но к сожалению не его поисковую машину, а просто систему авторизации, и способы угнать сессию пользователя.
Видимо многие сталкивались с тем, что вроде бы и куки пользователя угнали - а зайти в аккаунт не можем? Вот сейчас мы и увидим почему это случается.
Давайте рассмотрим как проходит авторизация и зайдем на accounts.google.com
Видим обычное поле логина, но нас инетресует другое : при входе на гугл, мы получаем куки GAPS и GALX. Заметим что при совершении любых действий они меняются и со старыми куками мы получаем сообщение о том что нам надо их очистить ( вот собственно и ответ почему мы не можем воспользоваться куками со стилера, их надо удалять у пользователя, чтобы холдер их не мог ими воспользоваться раньше нас).
Ещё довольно таки интересный момент есть в авторизации ( информация к людям, которые хотят побрутить web версию ) - будьте крайне внимательны к запросу на /signin/challenge/sl/password - они в параметрах передают cookie ( соответственно они вполне могут тянуть куку из js + гугл крайне чувствителен к http Referer
Ну да ладно - допустим мы авторизовались, получили в хедерах код 302 и нам предложили восстановить доступ к аккаунту - потому что мы зашли как-то слишком в другом месте. На этом этапе можно уже грабить mail+pass и спокойно сваливать, однако нас же интересует полный доступ к аккаунту и этим мы ограничиваться не будем.
Если нам предложили восстановить доступ к аккаунту - значит нам не передали самые важные куки SID, LSID, HSID, SSID, APISID, SAPISID, ACCOUNT_CHOOSER и NID ( это вроде по желанию ). Без этих куков нас постоянно будут просить восстановить доступ к аккаунту и к email мы доступа не получим.
Получаются эти куки любым предложенным путем ( ответить на секретный вопрос, или ввести город, из которого обычно заходишь ). Я выбрал способ по городу - потому что имея ip жертвы можно определить город - а значит и получить такой долгожданный доступ к аккаунту.
Кстати - api ключа к google maps там не введен - поэтому запись в консоли, которую вы увидите об отсутствии ключа - вполне нормальное явление. И да - если у вас в window.location.href находиться какое-то другое значение ( отличное от гугловского ) - вам вернут ошибочку и заблокируют окно ввода. Разблокируется она парой нажатий в Element Inspector конечно - но юзер же не будет этого делать
Итак - восстановили мы доступ, получили долгожданные куки - и вот оно счастье? Не совсем. Для работы почты требуется ещё 1-а кука : OSID. Но она впринципе ставиться автоматически через редиректы гугла. Кстати насчет редиректов - давайте составим списочек где мы и что получаем ( и как пройти квест по получению всех куков пользователя )
1) заходим на accounts.google.com и нас кидает на /ServiceLogin?passive=1209600&continue=https%3A%2F%2Faccounts.google.com%2FManageAccount&followup=https%3A%2F%2Faccounts.google.com%2FManageAccount
( заметим что в запросе у нас видно откуда мы пришли )
2) очень важный момент - на странице в рантайме подгружается ( у вас аргументы будут другими ) и вроде как добавляет некоторые input в форму, которую отправляем дальше.
3) После прохода промежуточного этапа, когда мы посылаем данные на accounts.google.com/AccountLoginInfo ( или accounts.google.com/AccountLoginInfoXhr в зависимости от ващего браузера ) ( где нам кстати обновляют куку GAPS ), мы сможем наконецто послать данные на авторизацию на /signin/challenge/sl/password ( данные улетают чистым текстом, так что если вы организовали mitm - то самое время тащить данные )
4) Здесь может быть несколько вариантов - либо нам сразу выдали все куки ( значит вы зашли с ip жертвы ), либо поменяли только GAPS и ждут от вас ответа.
5) в зависимости от того как вы восстанавливаете доступ вам потребуются разные запросы. Так как я рассматривал только по городу то я получил все куки после ответа на запрос в /signin/challenge/ll/5
6) после этого серии редиректов вида /CheckCookie и /accounts/SetSID (название куки, которую надо установить ), и наконеццто редирект на страницу, которая затребовала авторизации в гугле.
После всех этих этапов можно спокойно у пользователя удалять куки и сваливать. Кука OSID будет выставляться по вашим скомунизженным кукам. Главное чтобы холдер не имел к ним больше доступа. Иначе в 1 прекрасный день вы увидите сообщение что они просрочены ( хотя срок их не вышел ).
Могу дать впринципе листинг запросов и ответов, но это лучше 1 раз попробовать самому.
Во время изучения использовались только chromium и firefox ( у него прекрасный сетевой отладчик, который наглядно показывает какие куки были переданы на удаленную сторону, а какие приняты с сервера, что chromium например при ssl соединении не показывает ).
