Стрим про безопасность WEB-приложений

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

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

По этим просьбам провели наш очередной большой ламповый стрим на один или два вечера про безопасность web-приложений и сопутствующей инфраструктуры.

На стриме провели исследование разных видов атак. Обсудили с примерами написание безопасного программного кода на бэкенде и во фронтенде. Разобрали хеширование и шифрование данных. Защитили HTML-формы от подлога и API от перебора. Сделаели невозможным внедрение постороннего JavaScript через фильтрацию и через политики безопасности браузеров. Дополнительно защитили аутентификацию по OAuth2. Разобрались с защитой инфраструктуры в Linux нативно и в Docker-контейнерах. Подобрали нструменты для проведения аудита и поиска уязвимостей. Организовали для своего проекта соблюдение технических требований к обработке персональных данных, резервному копированию и мониторингу по закону №152-ФЗ.

В первой части обсудили векторы атак и общеполезные принципы:

и поговорили про варианты вторжения через разные сети:

Что получилось:

  • 00:00:00 - Приветствие
  • 00:03:17 - Что будет на стриме
  • 00:04:43 - Отказ от ответственности
  • 00:05:39 - Из чего складывается безопасность
  • 00:09:18 - Пример с подменой цены в магазине
  • 00:16:26 - Ответственность в оффлайне и онлайне
  • 00:18:03 - Атаки без взлома и DoS
  • 00:21:08 - Цели атак со взломом
  • 00:21:56 - Кража и утечки данных
  • 00:23:07 - Утечки паролей и польза менеджеры паролей
  • 00:24:55 - Порча и подмена данных
  • 00:25:45 - Кража исходного кода проекта
  • 00:27:22 - Разные схемы мошенничества
  • 00:27:54 - Использование чужой репутации
  • 00:31:04 - Шпионы и майнеры
  • 00:32:49 - Использование как узел в ботоферме
  • 00:37:10 - Узел для взлома других ресурсов
  • 00:50:42 - Анонимный узел для других взломов
  • 00:53:34 - Сотрудники и социальная инженерия
  • 01:00:05 - Защита от кражи исходного кода
  • 01:05:08 - Закон 152 ФЗ о персональных данных
  • 01:06:17 - Категории персональных данных и степени защиты
  • 01:09:24 - Какие данные собирать и для чего
  • 01:14:55 - Где храним и куда передаём
  • 01:18:50 - Организация удаления и восстановления
  • 01:19:36 - Безопасное хранение и журнал ключей
  • 01:21:03 - Технические способы удаления по запросу
  • 01:33:20 - Уведомление о компрометации
  • 01:36:30 - Вынесение мониторинга и бэкапов на отдельную машину
  • 01:41:47 - Ограничение доступа к бэкапам
  • 01:49:50 - Закрытие портов от внешнего доступа
  • 02:03:29 - Смена порта SSH и доступ по ключу
  • 02:12:33 - Каталог CVE уязвимостей NVD
  • 02:22:07 - Перерыв
  • 02:39:50 - Блокирование профиля вместо удаления
  • 02:42:35 - Можно ли парсить открытые данные
  • 02:44:42 - Уточнение про iptables
  • 02:47:26 - Карточки товаров не являются персональными данными
  • 02:49:57 - Про редактор кода в WordPress
  • 02:53:33 - Работа в Linux и Docker не от root
  • 02:59:22 - Защита файлов от записи с chown и chmod
  • 03:11:44 - Использование неофициальных Docker-образов
  • 03:14:54 - Использование secrets для настройки паролей
  • 03:16:38 - Блокировка через iptables внутри Docker-контейнера
  • 03:23:02 - Защита от перебора SSH через Fail2Ban
  • 03:25:36 - Email-оповещение о входе на сервер
  • 03:32:23 - Аудит уязвимостей Docker-контейнеров c Trivy
  • 03:38:32 - Деплой в Docker Swarm через сертификаты
  • 03:48:40 - Уязвимости образа WordPress
  • 03:53:15 - Как откатывать сервисы без compose-файла
  • 03:57:16 - Сокрытие версии Nginx
  • 04:01:21 - Сокрытие версии PHP-FPM
  • 04:02:35 - Исправление пути в FCGI
  • 04:05:54 - Сокрытие ошибок приложения для продакшена
  • 04:13:35 - Частые уязвимости проектов на Apache-хостинге
  • 04:29:50 - Вынос кода из папки public
  • 04:31:41 - Смотрим чужие файлы .env в Google
  • 04:38:10 - Защита PHP-файлов от прямого открытия
  • 04:45:55 - Риск индексации ссылок на документы
  • 04:50:36 - Что будет дальше

Во второй части рассмотрели практику с программным кодом:

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

Что показали в коде:

  • 00:00:00 - Приветствие
  • 00:01:23 - Что сегодня будет
  • 00:03:45 - XSS и ручное экранирование при рендере HTML
  • 00:17:55 - Использование шаблонизаторов с автоматическим экранированием
  • 00:22:28 - Разрешение использования HTML-тегов в тексте
  • 00:30:46 - Риски обхода самописных парсеров
  • 00:34:15 - Библиотека HTMLPurifier
  • 00:57:51 - Внедрение лога
  • 01:05:48 - Польза типизации при десериализации запроса
  • 01:10:43 - Пользовательская валидация и инвариант бизнес-логики
  • 01:20:28 - Риски нестрогих проверок с приведения типов
  • 01:30:56 - Некорректные проверки регулярными выражениями
  • 01:35:52 - Опасность условий с !preg_match
  • 01:50:52 - Десериализация в произвольный класс
  • 02:18:29 - Опасность передачи путей файлов
  • 02:25:03 - Ограничение операций через белый список
  • 02:30:02 - Сокрытие ошибок приложения в продакшене
  • 02:34:21 - Запуск всего в контейнерах
  • 02:44:13 - Отключение автоскриптов пакетных менеджеров
  • 02:48:21 - Отключение опасных функций
  • 02:51:35 - Безопасное хэширование паролей
  • 03:08:39 - Разница хэширования и шифрования
  • 03:14:01 - Подпись для гарантии оригинальности данных
  • 03:21:15 - Приватный и публичный ключ
  • 03:26:15 - Подпись JWT токенов
  • 03:30:26 - Электронная подпись в документообороте
  • 03:33:09 - Подписываем приватным ключом, а шифруем публичным
  • 03:37:45 - Шифрование бэкапов базы данных
  • 03:42:37 - Важность сложных паролей
  • 03:50:48 - Пропуск ограничения доступа контроллера
  • 04:00:05 - Опасность ссылок с target _blank
  • 04:14:46 - Ограничение попыток подбора токенов подтверждения
  • 04:23:01 - Капча для ограничения числа SMS
  • 04:29:17 - Rate Limit для форм
  • 04:44:46 - Защита форм от CSRF
  • 05:07:20 - Взлом через SQL Injection
  • 05:32:08 - Использование iframe для ClickJacking
  • 05:37:51 - Использование HTTPS
  • 05:39:40 - Ограничение сторонних скриптов через CSP
  • 05:42:02 - Запрет сторонних браузерных запросов через CORS
  • 05:52:56 - Хранение OAuth токена восстановления в Cookies
  • 06:15:25 - Отзыв refresh_token при повторном запросе
  • 06:18:45 - Аудит composer-пакетов
  • 06:24:31 - Поиск уязвимостей с SQLMap
  • 06:28:01 - Дополнительные параметры для Cookies
  • 06:33:31 - Загрузка пользовательских файлов
  • 06:44:24 - Временные ссылки для скачивания
  • 06:46:20 - Сканирование уязвимостей сайта с OWASP ZAP
  • 06:56:27 - Подведение итогов
  • 07:04:18 - Куда задавать вопросы

Оплатить можно самому российской или иностранной картой или попросить работодателя оплатить от имени компании.

Для скидки можете сначала оформить в кабинете или от работодателя безлимитную подписку на наши полезные скринкасты про разработку. А потом или сейчас получить запись можно там же в кабинете или здесь:

Дмитрий Елисеев
elisdn.ru
Комментарии (23)
Александр

Это всё очень хорошо и очень интересно ) НО! Когда будет шестой скринкаст по взаимодействию объектов (поля и свойства)? Когда будет продолжение серии "Устройство HTTP-фреймворка"? Наконец, когда будет продолжение по аукциону на Slim, особенно сильно интересует "Брокер очередей" и следующие за ним три темы. Когда??! )

Ответить
Evgenii

Дико плюсую!

Ответить
Сергей

Поддерживаю :)

Ответить
Алексей

Присоединяюсь к вопросу, когда будет продолжение основных скринкастов?

Ответить
Сергей

Плюсую!

Ответить
Васёк

Да, действительно, когда мы уже закончим несчастный аукцион?

Ответить
Александр

Согласен, хочется продолжение скринкастов.

Ответить
Владимир Перепеченко

Да уж, даже планы по аукциону не озвучивается ..

Ответить
Владимир Перепеченко

Если забросили, то лучше уже озвучить честно. Но то что было - бомба!

Ответить
Григорий

Стрим обещает быть огненным. Везде все про python, про php есть, но мало. И в целом на тему безопасности в разработке, как мне кажется, всегда собираешь по крупицам информацию. Например собрать список небезопасных атрибутов в html, которые надо эскейпить особым образом, не так как обычные атрибуты, можно запыхаться!

Ответить
Григорий

Чтобы не быть голословным, вот мой список, которым я пользуюсь для этих дел:

АтрибутВ тегах
hrefa, area, base, link, svg, image
codebaseapplet, object
citeblockquote, del, ins, q
backgroundbody
actionform
longdescframe, iframe, img
srcframe, iframe, img, input, script, audio, embed, source, track, video
profilehead
usemapimg, input, object
classidobject
dataobject
formactionbutton, input
iconcommand
manifesthtml
postervideo
srcsetimg, source
archiveobject, applet
Ответить
разве эти теги framework-и внутри своего ядра не экранируют?

разве эти теги framework-и внутри своего ядра не экранируют?

Ответить
Васёк

5 лет уже делаем аукцион, эта серия скринкастов скоро превратится в мастер-класс о том как попасть в "Производственный ад"

Ответить
Максим

К слову, может имеет смысл вернуться к формату старых мастер-классов? Как это было в случае с сериями по Yii, Laravel и Symfony. А то перфекционизм это конечно хорошо, но как итог, оно в ущерб количеству информации в итоге идёт. Что, как видим, в итоге и сказывается на продолжительности разработки аукциона.

Ну вот не знаю, может какое голосование устроить, чтобы было понимание, какой формат лучше. Как вариант.

Ответить
Дмитрий Елисеев

К слову, может имеет смысл вернуться к формату старых мастер-классов? Как это было в случае с сериями по Yii, Laravel и Symfony. А то перфекционизм это конечно хорошо, но как итог, оно в ущерб количеству информации в итоге идёт.

Это вам кажется, что было быстрее и больше. Если проследите историю постов на сайте, то:

  • В 2018 году серия про PSR-фреймворк из 7 стримов по 4-5 часов готовилась и шла 10 месяцев.

Если считать только время проведения мастер-классов, то:

  • В 2016 году серия Неделя ООП из 7 стримов по 5 часов два раза в неделю шла почти месяц.
  • В 2017 году серия по Yii из в 11 стримов по 5 часов через день шла месяц.
  • В 2018 году серия по Laravel из в 13 стримов по 4 часа через день шла месяц.
  • В 2019 году серия по Symfony из 15 стримов по 3 часа раз в неделю шла три месяца.

Это только время проведения. До этого перед каждым было по полгода подготовки структуры и кода.

То есть и в старых форматах мастер-классы готовились и выпускались всего по одному в год. И даже в таком режиме там оставалось много недоделанного и вообще не рассматривались деплой и смежные темы.

И по времени если всё сложить, то за 4 года суммарно получилось всего 53 стрима на 200 часов сырого эфира со всем мусором без монтажа. С монтажом бы из них осталось всего 100 часов.

А новом формате уже опубликовано 133 скринкаста с монтажём и проведено 6 стримов.

А то перфекционизм это конечно хорошо, но как итог, оно в ущерб количеству информации в итоге идёт.

По количеству информации в старых мастер-классах есть только программирование PHP-проекта, но вообще нет ничего про деплой, CI/CD, бэкапы, аутентификацию API, фронтенд, линтеры, типизацию, работу серверов, HTTP, разные уровни тестирования и прочих вещей, которые нужны в процессе разработки.

Ответить
Максим

Да я как бы только за то, чтобы рассматривали все смежные вещи, такие как деплой, фронтенд и прочее. Просто если сравнивать с частотой, с какой уроки выкладывались в начале разработки аукциона и с какой сейчас - это прям бросается в глаза. Вот и предположил, что возможно дело в том, что такой формат требует больших затрат и как следствие процесс идёт более тяжко. Но если дело не в этом, то мой совет вернуться к старому формату не к месту оказался)

Ответить
Ruslan

Нам нравятся ваши скринкасты, и от этого жажда мучает нас еще больше. :)

Ответить
Евгений

Думаю, тут ещё вопрос финансов. У людей списывается по 500 руб. в месяц, а новых роликов-то уже сколько месяцев нет. Ладно бы ещё стримы были бесплатными для плательщиков, так нет, они тоже денег стоят, ещё и немаленьких.

Ответить
разве эти теги framework-и внутри своего ядра не экранируют?

А были ли или будут CI/CD?

Ответить
Ruslan

Рассмотрите на стриме ситуацию, когда у вас сайт с рассылкой, "злой дядька" покупает БД майлов и начинает их регистрировать у вас. У вас требуется подтверждение регистрации по майлу. В БД дядьки, среди прочих, оказываются майлы спам ловушек, и вот вас уже банят почтовики (почтовые сервера в блэк листе).

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

Спасибо.

Ответить
Максим (@myks92)

Здравствуйте, Дмитрий. Тема очень интересная, особенно если ещё охватывать законодательную часть.

Какие есть предложения по стриму:

  1. Как уже и написано в статье - это всё что касается ПД. Как хранить, как шифровать и дешифровать в очередях, что нужно размещать на сайте, что делать в сервисах/микросервисах, когда человек пришел с отзывом о согласии персональных данных ну и так далее.
  2. Инструменты для различных проверок безопасности. Например, composer audit
  3. Инструменты, позволяющие определять, что сайт пытаются взломать. Сюда же можно рассмотреть и другие различные атаки, в том числе через массовую регистрацию.

Вероятно Вы это уже учли в подготовке стрима, но решил ещё поделиться.

Вижу много людей, которые ждут определенные темы и возмущены тем, что не получают их. Например, тема RabbitMQ. Когда-то вы говорили, что deworker.pro будет развиваться так, как хотят большинство. Стрим по безопасности дело полезное, но может быть стоит прислушаться? Практически под каждым скринкастом я вижу сообщения про RabbitMQ. С одной стороны вы рассмотрели эту тему на стриме. Кто-то её понял. Но видимо не все) По этой части могу внести предложение выкладывать темы и стримы по голосованию. За что больше голосуют - ту тему и готовить. Так и сообществу будет интересно, и вам. Рассмотрите такой вариант)

Дополнительно хочу внести предложение чтобы ваш сайт deworker.pro стал публичным в плане кодовой базы и скринкастов. Аукцион интересный, но сложность его заключается в том, что его надо специально разрабатывать. Тратить на это много времени, а между делом ещё и успевать поддерживать в актуальном состоянии deworker.pro. Вам было бы проще черпать идеи от сообщества, писать код и останется только это всё снимать. Вполне возможно, что на этой почве кто-то мог бы помогать вам в разработке deworker.pro кодовой базы. Готовить какую-то фичу, а вам только снять видео. Захотел побыстрее чтобы вышло видео - сделай пул реквест) Я не знаю, возможно ли это, но стоит подумать. Вы также иногда в своих видео показываете код не аукциона, а именно deworker.pro. Особенно вам было бы проще делать простые вещи - вроде обновления на PHP 8.4 и других зависимостей. А так эта большая работа вам предстоит и в аукционе и в deworker.pro.

Спасибо вам за ваше терпение и ваш труд!)

Ответить
Arunas

Спасибо, Дмитрий, за Ваше отношение и усилия по передаче опыта и знаний. Счастливого Нового Года и праздников Вам!

Ответить
Рус

Дмитрий, тоже жду выпуски основных вещей. И мне кажется ваша проблема, что вам надо освоить ещё один навык - делегирование, работа в команде. Один человек на монтаже, один эксперт, который поможет с материалом, подачей, структурой выпусков. Да придется делиться, да есть риски. Но в итоге можно прийти к качественно новому результату. Возможно уже есть люди, которые хорошо разбираются в каких-то вопросах и могли бы за вас раскрыть какую-то тему, доделать скринкасты, которые уже висят не один год. Дерзайте, удачи!

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Yandex
MailRu
GitHub
Google