Да

Да

Какие же? :)

В настройках хрома и HSTS удалить vk.com

так победимъ

Какие же? :)

chrome://net-internals/#hsts

Мне приходится так делать самому порой

Речь идет об атаке с подменой dns

в самом низу - Delete domain security policies

дальше думаю разберёшься, @rollly

Речь идет об атаке с подменой dns

можно телепортнуться в 2011, там хстса нет в хроме

можно телепортнуться в 2011, там хстса нет в хроме

А где телепорт взять?

Привет, поднял DNS сервак, поставил на него vestacp панель, создал домен vk.com, сгенерировал самопальный сертификат, запустил dnschef, в браузере Firefox можно просто добавить в исключение или же пропустить предупреждение, но в браузере Chrome не дает этого сделать HSTS

vk скорее всего в листе hstspreload.org

vk скорее всего в листе hstspreload.org

Тоже верно Но я повторю - я делаю delete домена Но он подсосётся скорее всего потом опять оттуда

vk скорее всего в листе hstspreload.org

Там все популярные сайты с hsts

Там все популярные сайты с hsts

Раньше атака была, когда переводили время больше, чем действует срок жизни hsts, но вроде уже давно фиксед

Тоже верно Но я повторю - я делаю delete домена Но он подсосётся скорее всего потом опять оттуда

Я говорю про подмену dns, пользователь должен посетить сайт, никаких других манипуляций не должен делать

Я говорю про подмену dns, пользователь должен посетить сайт, никаких других манипуляций не должен делать

Про последнее я как-то не догадался, прости

Надо поглядеть как берётся инфа с hstspreload.org

Раньше атака была, когда переводили время больше, чем действует срок жизни hsts, но вроде уже давно фиксед

Тут недалеко, в 2014 https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf

Надо поглядеть как берётся инфа с hstspreload.org

Зашито в браузере

Раньше атака была, когда переводили время больше, чем действует срок жизни hsts, но вроде уже давно фиксед

там 1 или 2 года действует

Зашито в браузере

+

там 1 или 2 года действует

Смотря как поставишь (обычно на год)

В лисе такого нету

Надо поглядеть как берётся инфа с hstspreload.org

тупо заблокировать этот адрес нельзя? )

Зашито в браузере

Это вряд ли меня остановит конечно ;)

в общем варианты есть и в прошлом, и в будущем

Это вряд ли меня остановит конечно ;)

Слышал о махинациях с доменами

тупо заблокировать этот адрес нельзя? )

Я бы глянул и гляну в общем-то как оно подсасывается, митмнул домен и отдавал бы исключая нужные хосты

либо багу искать

Слышал о махинациях с доменами

Это вопрос? ;)

Я тут кстати как-то пропалил непонятный серт вкшный

Это вопрос? ;)

нет, с одним парнем общался, да и он расплывчато описывал

Я понял Глянь серт ВК сам такой отдаёт иногда

на внутряк похоже

Так и есть

Нужен сертификат для домена vk.com :D

Но вылезает где-то наружу Могу только хосты позже сказать, надо только сохранённую сессию Чарлза найти

Его не получить

с какого нить рассинхроненного бекенда в балансировке течет

Что-то вроде того, да

Нужен сертификат для домена vk.com :D

А ты просто бери "выше" ) Сделай как когда-то сделал нескажукто серт для *.itunes.apple.com и Root CA его выдавшего (in-appstore.com)

если б я не был ленивым, я бы простучал с хостнеймом www.vk тот хост, который отдавал серт, или много много раз морду, вдруг что еще расскажет а то и покажет

Но ты ленивый, да?)

@rollly больше вконтактиком интересуется, ему наверное интересней

@rollly больше вконтактиком интересуется, ему наверное интересней

Нет, меня интересует сама атака, контакт чисто для примера взял, так как на других сайтах тоже используется hsts

Речь идет о google,mail.ru, yandex

Вот была атака недавно

https://www.reddit.com/r/MyEtherWallet/comments/8eloo9/official_statement_regarding_dns_spoofing_of/

Ты конечно не первооткрыватель идей, но... Я позже тебе скажу про hstspreload.org всё же Не смотря на то, что он "вшит" в браузер

https://www.reddit.com/r/MyEtherWallet/comments/8eloo9/official_statement_regarding_dns_spoofing_of/

там в той атаке все как то тупенько сделано, и ссл не подменяли

самоподписанный серт торчал вроде бы

https://www.reddit.com/r/MyEtherWallet/comments/8eloo9/official_statement_regarding_dns_spoofing_of/

Кстати, Rolly Пересобери свой Хром) https://bugs.chromium.org/p/chromium/issues/detail?id=467486

самоподписанный серт торчал вроде бы

Да, но опять же, в лисе я спокойно могу пропустить Алерт о сертификате, hsts не мешает, а хром препятствует

Вы лучше скажите мне вот что ;) Я тут на выходных будучи на веселе дропнул одним свайпом и одним тачем весь свой Saved Messages в телеге) Конечно всё восстанавливаемо, но такое.... Есть собственно бэкап структуры файлов и самой папки tdata, но как-то только, разумеется, я выхожу в онлайн - с сервака приходит инфа клиенту о размере map (или что там точнее) и все файлы локально само собой убиваются, поскольку инфы о них на серваке нету. Нужен некий оффлайновый бэкапер, я вот 3 проекта сейчас с гитхаба склонировал, буду изучать могут ли они...

Вы лучше скажите мне вот что ;) Я тут на выходных будучи на веселе дропнул одним свайпом и одним тачем весь свой Saved Messages в телеге) Конечно всё восстанавливаемо, но такое.... Есть собственно бэкап структуры файлов и самой папки tdata, но как-то только, разумеется, я выхожу в онлайн - с сервака приходит инфа клиенту о размере map (или что там точнее) и все файлы локально само собой убиваются, поскольку инфы о них на серваке нету. Нужен некий оффлайновый бэкапер, я вот 3 проекта сейчас с гитхаба склонировал, буду изучать могут ли они...

заведи клиента без доступа в сеть с сохраненной базой, дерни текст из клиента если подтянет локальную базу, потом выйди в сеть и пульни в saved messages заново

http://www.ntp.org/ntpfaq/NTP-s-algo-crypt.htm

http://www.ntp.org/ntpfaq/NTP-s-algo-crypt.htm

Да я за NTP упомянул, но протупил за сообщение Bo0om'a в котором упоминается что это вроде бы уже пофиксили

только не понятно, в HSTS относительное или абсолютное время на макс время. Надо когда-то этот вопросик изучить.

заведи клиента без доступа в сеть с сохраненной базой, дерни текст из клиента если подтянет локальную базу, потом выйди в сеть и пульни в saved messages заново

А ты не вкурсе, да? ;) Клиент не покажет тебе мессаги при запуске, если сети нет

@i_bo0om в свете последних постов в "кавычке": насколько адекватно сейчас вообще полагаться на Content-Type в вопросе защиты от CSRF? Когда-то в обсуждениях баги хрома с разрешенной посылкой cross-origin запросов с любым content-type (опять же, через beacon), некотрые ребята на полном серьёзе выступали за "оставить так", preflight слишком "жирно" слать. Мол, это же beacons, они для минимизации отправок.

https://bugs.chromium.org/p/chromium/issues/detail?id=490015#c10 Читаешь и не по себе становится. //Потом к адекватному поведению с preflight-запросом привели, конечно, но всё равно.

@i_bo0om в свете последних постов в "кавычке": насколько адекватно сейчас вообще полагаться на Content-Type в вопросе защиты от CSRF? Когда-то в обсуждениях баги хрома с разрешенной посылкой cross-origin запросов с любым content-type (опять же, через beacon), некотрые ребята на полном серьёзе выступали за "оставить так", preflight слишком "жирно" слать. Мол, это же beacons, они для минимизации отправок.

Я за минимизацию рисков. Проверка referer если он будет всегда, content-type, origin. Но я скрипткидди.

только не понятно, в HSTS относительное или абсолютное время на макс время. Надо когда-то этот вопросик изучить.

Так же как и кэшируемые файлы скорее всего

Буквально несолько дней назад видел ресурс, который не обращает внимание на тип контента (но парсит json).

Что скажете про такой вариант?

Ребята, нормально же, что для ajax-приложухи прямо вот так выставляю наружу ручку /newtoken? Для получения CSRF-токена, отправкой спец. запроса прямо из js. Сам токен прилетает/отправляется в заголовке. Живет токен в LocalStorage (он синхронный, соответственно, нет проблем с многовкладочностью). Вроде как всё хрошо: не нужно перезагуржать страничку, токены можно очень быстро и просто ротировать. Для SPA очень удобно.

Просто сам факт наличия ручки "дай мне токен" смотрится немного дико. С другой стороны, если по старинке прикладывать прямо в теле страницы токен к формочкам, то ситуация та же: можешь получить данные странички => получаешь токен. Только токен ещё и светится в разметке (привет CSSI, привет dangling markup).

Ребята, нормально же, что для ajax-приложухи прямо вот так выставляю наружу ручку /newtoken? Для получения CSRF-токена, отправкой спец. запроса прямо из js. Сам токен прилетает/отправляется в заголовке. Живет токен в LocalStorage (он синхронный, соответственно, нет проблем с многовкладочностью). Вроде как всё хрошо: не нужно перезагуржать страничку, токены можно очень быстро и просто ротировать. Для SPA очень удобно.

Обычная практика. Токен-то надо где-то брать.

С точки зрения атакующего даже разницы нет. Есть xss - забрал ее из ручки или из тела страницы.

Ну, XSS-то понятно, но хотя бы CSSI переживать разный там. Как во всяких http://innerht.ml/challenges/token/

Там волнует не сколько уход токена каким-то волшебным образом, а сам факт того, что запрос (при каких-то условиях) можно слать. И портить жизнь добропорядочным гражданам, инвалидируя их токены на некоторое время. И веб-приложуха будет вечно перезапрашивать, перезапрашивать их... А люди ругаться, что "тормозит и лагает".

Там ведь токен на все запросы spa-приложухи один, просто с ротацией по таймауту.

Ну подожди, это уже за какую-то архитектуру рассказываешь.

Кейс какой? Вот SPA, вот ручка берет токен из json и ходит с ним.

Где риск / в чем импакт?)

Не уловил идею про "тормозит"

Угу. И ходит часто и много. И в ответах на запросы токен только проверяется. Если он неверный, приходит ответ, мол, ошибка, а-та-та, нельзя. А токен просто при открытии окна (и дальше, раз в определенное время) перезапрашивается. Если кто-то будет запрашивать новый токен (инвалидируя таким образом старый) вместо пользователя, у пользователя будут сыпаться "плохие" запросы. Да, конечно, после плохого запроса автоматом перезапросится токен, но это медленнее + сообщения об ошибках придется выпиливать все из фронта. :)

//Так-то уже решено.

Именно поэтому в итоге токен внутри содержит подписанное время жизни и не инвалидируется при запросе нового (если текущий ещё не протух).

Ну ооочень привязываешься к конкретной реализации.

Да, пожалуй. Просто сам кейс подпорчен. Ещё неделю назад думал, что Content-Type - это вообще святое.

У кого-то токен в заголовке ходит и один на сессию. У кого-то на группу действий один токен. Есть одноразывые, да, которым можно убивать текущие. Но никто этого делать, конечно же, не будет.

Сейчас хардварщики придут и нас выгонят

Спасибо на том, что читать запрос нельзя с нестандартным content-type. :)