Юхуу! Всем привет! Эта неделя будет неделью безопасности :) С вами на связи - @sergeybelove. Я наметил очень много тем, держитесь! (:

Я 2 года занимался безопасностью в американском стартапе (реклама для мобильных устройств) и 3 года работаю в @DSecRU / @erpscan.

В основном занимаюсь атакой, а не защитой. Писал на хабр (habrahabr.ru/users/belove/) и в @XakepRU. Выступаю на конференциях, в РФ и зарубежом

CodeFest (3 раза :3), РИТ++, CEE-SECR, FrontendConf, OWASP (RU & PL), Hack In Paris, ZeroNights и другие. Также одно время багхантил/баунтил

Находил уязвимости в VK, Telegram, Yandex, Google, CloudFlare, Badoo, Digital Ocean и у др. В общем, давайте к делу - конец прошлого года

Я как раз интересовался безопасностью фронта, около JS технологиями и платформами. Поэтому есть что сказать на эту тему.

Твит для ретвита: habrahabr.ru/company/dsec/b… -
статья про (Не)безопасный frontend. Здесь отразил большинство проблем безопасности фронта.

Конечно, основная проблема безопасности frontend - нарушение SOP. Но и с SOP не все так просто, он не всегда зависит от [scheme][host][port]

На эту тему был воркшоп на ZN 2013 - 2013.zeronights.org/includes/docs/… от @kkotowicz (сейчас в Google). Просто полистайте слайды, они самодостаточны.

Вкратце: в java applets хост не имеет значения (если ip1 = ip2), IE - порт не учитывается, cookies - могут ставить с поддомена на основной

Вот с куками как раз много подстав. Так, например, на гитхабе были cookie бомбы от @homakov (ставим большую куку, получаем client side DoS)

Или @i_bo0om использовал этот трюк на последнем PHDays bo0om.ru/telegram-love-… для эксплуатации уязвимости в веб-версии телеграмма

Я к чему - нельзя доверять поддомены кому попало. Иногда cookie injection довольно просто находится, когда он нужен, например для XSS.

Соответственно относимся к cookies недоверительно (при обращении из js) и санитайзим значения, если подставляем их в DOM.

Кстати, про термины! Санитайзим - обезопасиваем (энкод в html сущности), эскейпим - ставим \ перед нужными символами (кавычки как пример)

Фильтруем - значит не пропускаем (вообще) или вырезаем какую-то часть входящих данных. Поэтому при работе с юзер контентом мы санитайзим

(речь про XSS). Что пользователь ввел - то и должно получить на экране, но в "безопасном" виде, после санитайзинга. Ничего не режем.

В случае, если юзеру нужно дать HTML и тут же его подставить в DOM - используем github.com/cure53/DOMPuri… от @cure53berlin. Там все в доках.

Тут подсказывают, что с терминологией в ИБ - беда. Санитайзинг/эскейпинг/фильтрация, XSS - уязвимость/атака, и мн. др. Пропустим это)

Вообще, все, что привносит новый веб - и усложняет атаки (например, как CSP), но и расширяет attack surface, такие вещи как postMessage

Но остаются и "смешные" проблемы, например как с window.opener. Который работает по сей день(и даже в ФБ, хоть их shim и срежет при жалобах)

Демка на facebook - facebook.com/sergeybelove/p… (открывать в браузере, кликнуть, выполнит JS во вкладке с FB, origin изолирован)

Что-то ответов не так много. Как оно вообще?) Ни комментов, ни результатов клика по ссылке, только один дм) Стоит:

Вы сами в курсе, к чему эта картинка тут :( pic.twitter.com/kF6V8SeRJT

Но вернемся к нашей теме. Или это хорошее трололо, или так и есть - ровно поровну народ хочет и простых вещей и хардкора. Начнем со сложного

Задача: найти значение, которое при клике на "Render" приведет к DOM XSS (например, выполнится alert). URL таска - sergeybelove.ru/exploits/dom_x…

Решение точно есть для браузера Сhrome (чекнул на версии 51). Там только нативный JS. Ведь это аккаунт разработчиков фронтенда!

Вы можете найти вектора в интернетах. Но более интересно понимание решения (оно и простое, и сложное). Твитьте скрины с вектором и алертом

Эту задачу оставлю до утра (пишите хотя бы, если пробовали решать), а завтра на повестке - "JS, вышедший далеко за рамки фронтенда".

Т.е. по факту - обойти санитайзер, у которого есть белый список (в котором нет <script> или onerror/onload событий, для onerror=alert(1) )

Видно, что первый таск идет сложно. Пока мы не перешли к новой теме - закидываю таск попроще - sergeybelove.ru/exploits/task2 (задача - найти XSS)

Я не писал код для второго таска (и не добавлял сам уязвимостей). Я просто загуглил - codemag.com/article/1301091, взял весь код и развернул.

К слову, сколько уязвимостей допущено копипастом по первым ссылкам из гугла (stackoverflow - тоже идёт в счет). И это еще не server side.

Уверен, с этим таском у вас должно все получится. Ваш ответ - ссылка в reply, перейдя по которой у меня выскочит alert(1) на моем домене :)

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

К слову - именно такая навигация (как в таске №2) использовалась в Drupal долгое время (в админке). И точно также была уязвима к DOM XSS

XSS - это когда мы можем внедрить произвольный JS. Как пример - внедрить надо alert(1)

@jsunderhood Шикарный баг/фича C***! К сожалению сам не додумался, нагуглил. Спасибо!

Если вы нашли ТУ самую статью, откуда код для таска, то да, оттуда работать не должно )

Поздравляю @eShreder, @PanyaKor и @naxel_ с решением второго таска! И как факт - вы нашли уязвимость в коде, который в топе выдача гугла )

@jsunderhood <form onclick="alert('1');" style="position:absolute;margin:0;width:100px;height:100px;"><input name="attributes"></form>

И @an4ger с решением первого! Атака называется DOM clobbering. Пэйлоад можно было найти здесь - github.com/Microsoft/JSan…

Вкратце - атака на разбор DOM, реализуется за счет использования зарезервированных имен. thespanner.co.uk/2013/05/16/dom… owasp.org/images/a/ae/Ad…

И конечно же slideshare.net/x00mario/in-th… от @0x6D6172696F. Атака мала известна, включая специалистов по web sec. Но 42% просили что-то сложное!

@an4ger @jsunderhood черт! круто. почитал ссылки. так сразу работает <form><img onerror="alert(1)" src=""><img name="childNodes"></form>

Не теряйте, я точно расскажу о всем, о чем еще запланировал :) А пока новый челлендж, добейтесь alert(1) везде! escape.alf.nu

. @jsunderhood время 01:30: мы вызывали alert как могли! (упоролся) pic.twitter.com/tExx5Xy8ll

Наконец-то могу вернуться к твиттеру (надолго), давайте продолжим тему безопасности. Ранее мы познакомились с уязвимостями фронтенда (хабр)

Что SOP - штука гибкая, код из гайдов - м.б. с уязвимостями и есть разные, интересные сложки атаки на разбор DOM.

Многие попробовали себя в качестве пентестеров (поискать DOM XSS) и у некоторых это вышло, отрадно! Едем к следующей теме.

JS - язык настоящего и будущего и я действительно так считаю. Фронт, бэк, SmartTV, машины (multimedia), десктопные скрипты (win/linux)

расширения для браузеров и мн. другое, все на JS. Из этого я также занимался безопасностью расширений и виджетов и приложений для SmartTV

И эта наша следующая тема. По факту мы имеем тот же JS только с расширенным API (доступ к железку, датчикам, файловой системе и т.п.)

Естественно можно выстрелить себе в ногу при разработке и допустить уязвимость. Только тут импакт уже в разы больше -

мы уже за стандартной песочницей браузера. Начнем с расширений, дело было давно (в 2013) и было интересно. Чтобы не скучали, закину видос :)

Я пользовался расширением Any.DO и при поиске уязвимостей в gmail внезапно нашел в нём xD Demo - youtube.com/watch?v=5Nr-ta…

По факту мы имеем обычную DOM XSS, но в контексте расширения, которое может слать XHR запросы на любые домены(спрашиваются при установке, *)

Но здесь просто full SOP bypass (см. видео). А может быть и выполнение команд ОС (у юзера), статья - blog.kotowicz.net/2012/09/owning…

Поэтому, если вы разрабатываете расширения, смотрите в сторону тех же багов фронта / запрашивайте корректные права и будьте параноиком

SmartTV. С этой темой я выступал на последнем ZeroNights и баги описал в статье - habrahabr.ru/company/dsec/b…

Тут важно понимать, SmartTV - они очень разные и на разных ОС (от кастомных сборок до Tizen и тупо - просто Android'а).

В случае со SmartTV от Samsung - у них своя ОС на базе linux (2008-2014) и Tizen (тоже linux) для новых моделей. Приложения пишутся на JS.

По факту - это SPA + доп API. И в случае приложений для 2008-2014 у вас НЕТ ВОЗМОЖНОСТИ БЕЗОПАСНО хранить данные (OAuth токены, например)

Любое приложение при помощи XHR + схемы file:/// может стащить файл другого приложения, где лежат "секретные" данные. А сколько людей ставят

себе виджеты от "Васяна", в которых вполне может быть подобный бэкдор. Tizen так в руки и не попал, но мне говорили, что фиксили это

Но идем дальше. Я пошел искать настоящие уязвимости. В реальности угрозу несут только DOM XSS (нашел - получил доступ к файловой системе)

И инфолики. Например, в официальном приложении для FB от Samsung я нашел захардкоженные учетки для тестов :) работающие

Идем дальше. АВ-ТО-МО-БИЛЬ! И до сюда добрался JS, как пример спека - w3.org/2012/11/web-an…

В рамках данной твиттер-сессии мы не будем вплотную рассматривать этот вопрос, но вкратце: есть API до всяких мультимедиа штук

Но ограничения, как обычно, вводит сам производитель. Мы будем пристально следить за этой темой :)

Очень многое зависит от того, в какую песочницу поместит JS производитель. Неудачная реализация со SmartTV 2008-2014 яркий тому пример.

Но это не освобождает разработчиков от ответственности за код :) Так что будьте в тренде, думайте о безопасности.

Едем дальше, я бы хотел написать про пентесты (анализ защищенности). Формально, бывают разных типов: [white|gray|black]box

Зависит от того, что заказчик предоставляет - всё (исходники и т.п.), дает часть (учетки, что-то еще) и тупо ничего. Например, только url

Отдельно выделим анализ кода (как работу). Ведь исходники могут просто помогать при пентесте, а можно детально анализировать только их.

В последнее время есть тенденция на whitebox и анализ кода. Понимание, что лучше найти дыры до инцидентов - это круто.

А вообще - должна быть дружба между security & developers. Если вы, как разработчики сами имеете сомнения в каком-то функционале - обратите

на него внимание пентестером. Можно что-то говорить спортивность, но пентест на заказ - это ограниченное время и невозможно посмотреть всё.

За определенное время специалистами с таким-то опытом найдутся такие-то уязвимости. Поэтому нет ничего страшного что-нибудь подсказать.

Ладно, будут про пентесты вопросы - пишите :) Возможно, это не так интересно. Поэтому перейдем к вопросу про ... багбаунти! Это так модно :)

(и я догнал тему 4го дня из своего плана). Про это все 1000 раз слышали, когда можно получить деньги за найденные уязвимости.

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

Но чаще всего такое подчищено. В РФ довольно много программ, включая Яндекс, Mail.ru, VK, Badoo и Qiwi.

Среднюю сумму, которую можно получить (за "типичные" баги) - от 5 до 25 тысяч рублей. Критичные - от 30 до ~150

Часть программ управляются тупо через почту, но большая вынесена на площадки - hackerone.com / bugcrowd.com

Там смотрим у кого открыта бб программа, репортим через них же тикет, в случае аппрува - получаем деньги на PayPal. Расценки указны.

Обычно out of scope - флаги для Cookies, security headers (HSTS/XFO/etc), self-xss и подобные штуки. Но если найдете импакт - то платят.

Так, что-то я уже тут много написал, сделаю перерыв :) почитайте ленту, будут вопросы - пишите, поотвечаю и пойдем дальше.

Ping! Совсем сложно оказалось на неделе со временем, но за ночь дострочу мысли, идеи, советы и мнения.

Одна из тем, которую хотел затронуть - последние громкие взломы больших компаний. haveibeenpwned.com/PwnedWebsites

И, даавйте исключим из списка "дампы" mail.ru / yandex / etc, они пришли одной волной и были в результате фишинга / слива ботнета, факт

А вот у некоторых действильно слили базу :) И мое мнение, что просто есть проблема в подходе: выстраивать защиту - значить защищаться.

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

Но что толку от них без правильной настройки? А чтобы правильно настроить - надо их проатаковать. Давайте на примерах. Вот корп. фаирволлы

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

Перекидывать данные наружу, да что там - прокидывать шеллы (при социалке удобно). Например, можно через wiki.skullsecurity.org/Dnscat

А внутри сети? С ARP спуфингом научились бороться. Но проводить mitm можно по-разному, и github.com/SpiderLabs/Res… очень помогает в этом

(помните, все тулзы привожу только, конечно же, для ознакомления и в учебных целях)

Снаружи, обычно, тоже находится путь. Кстати, чтобы чекать банальные штуки я как-то запилил сканер - sergeybelove.ru/one-button-sca… (в одну кнопку)

Тупо вбивайте урл и он делает разные проверки. Обязательно расширю ему базу. Как-то этот сканер нашел реальные баги на wikipedia/yahoo :)

Будут еще утечки, будут сливать базы и не станет "тише", имхо. Чтобы снизить риски - никогда не надо строить защиту без нападения (на себя)

В качестве примера такого тру подхода, в котором я принимал участие - это компания Qiwi. Статья от @isox_xx - journal.ib-bank.ru/post/413

Тру - я конечно же имел ввиду строить защиту, "нападать" на нее, строить дальше, снова "нападать". Сложно придумать лучше.

Кстати, в целом тусовка ИБ (практиков) не очень большая. Это две больших конфы - @phdays и @ZeroNights и небольшие комюнити по городам.

DCG группы (найди в своем городе - defcon.org/html/defcon-gr…), OWASP встречи (Москва), митапы в mail.ru (Москва)

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

Поэтому, если надумаете изучать сферу - всегда велком, очень много возможностей, встреч, статей, материалов с конференций и т.п.

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

Будет хорошо, если будете вникать глубже - например JSONP leaks / CORS / и т.п., что я приводил в статье на Хабре.

Вообще, это большая проблема, что когда собеседуют разработчиков НЕ ЗАДАЮТ вопросов по безопасности. Никаких.

Старший разработчик / тимлид точно может сам понять все базовые атаки. Спрашивайте при приеме на работу / понимаете уровень

Знаете уровень - будете ставить задачи с этим учетом. Если плохо понимает человек CORS/JSONP/Referer - значит стоит быть аккуратным :)

Вообще, обычно тут проблемы другие. Если делать безопасно - то это дороже / больше сроки / неудобно юзерам. Поэтому должен быть баланс.

Картинка к теме. Минимальные затраты уже сразу дают резкий рост. С верхним пределом сложно, панацеи нет. pic.twitter.com/k9fHc6iX06

Из чеклиста, что еще оставалось: JS в Security. Например, в reverse engineering - habrahabr.ru/company/dsec/b… (от @evdokimovds )

А также подходит для малвари (скорее в целом - скриптовые языки). Тот же powershell - куча возможностей и не палится антивирусами.

Кстати, все хотел закинуть статью, как через JSONP
serviceWorkers получить постоянную XSS :)
c0nradsc0rner.wordpress.com/2016/06/17/xss…

Подводя итоги хочу сказать, что если вы пропустили мимо тему безопасности, она все равно вас настигнет. Как тот экзамен, который надо сдать.

Поэтому не откладывайте её каждый раз подальше, например как ту кучу непрочитанных закладок в браузере, которые у каждого есть.

Все твиты/ссылки за неделю можно будет найти здесь - jsunderhood.ru/sergeybelove/. Возникнут вопросы - всегда пишите на почту или в твиттер.

Я рад, что была такая необычная возможность поделиться чем-то полезным с сообществом разработчиков. Будьте в безопасности и пока!