Стрим про безопасность 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 - Куда задавать вопросы
Оплатить можно самому российской или иностранной картой или попросить работодателя оплатить от имени компании.
Для скидки можете сначала оформить в кабинете или от работодателя безлимитную подписку на наши полезные скринкасты про разработку. А потом или сейчас получить запись можно там же в кабинете или здесь:
Это всё очень хорошо и очень интересно ) НО! Когда будет шестой скринкаст по взаимодействию объектов (поля и свойства)? Когда будет продолжение серии "Устройство HTTP-фреймворка"? Наконец, когда будет продолжение по аукциону на Slim, особенно сильно интересует "Брокер очередей" и следующие за ним три темы. Когда??! )
Дико плюсую!
Поддерживаю :)
Присоединяюсь к вопросу, когда будет продолжение основных скринкастов?
Плюсую!
Да, действительно, когда мы уже закончим несчастный аукцион?
Согласен, хочется продолжение скринкастов.
Да уж, даже планы по аукциону не озвучивается ..
Если забросили, то лучше уже озвучить честно. Но то что было - бомба!
Стрим обещает быть огненным. Везде все про python, про php есть, но мало. И в целом на тему безопасности в разработке, как мне кажется, всегда собираешь по крупицам информацию. Например собрать список небезопасных атрибутов в html, которые надо эскейпить особым образом, не так как обычные атрибуты, можно запыхаться!
Чтобы не быть голословным, вот мой список, которым я пользуюсь для этих дел:
разве эти теги framework-и внутри своего ядра не экранируют?
5 лет уже делаем аукцион, эта серия скринкастов скоро превратится в мастер-класс о том как попасть в "Производственный ад"
К слову, может имеет смысл вернуться к формату старых мастер-классов? Как это было в случае с сериями по Yii, Laravel и Symfony. А то перфекционизм это конечно хорошо, но как итог, оно в ущерб количеству информации в итоге идёт. Что, как видим, в итоге и сказывается на продолжительности разработки аукциона.
Ну вот не знаю, может какое голосование устроить, чтобы было понимание, какой формат лучше. Как вариант.
Это вам кажется, что было быстрее и больше. Если проследите историю постов на сайте, то:
Если считать только время проведения мастер-классов, то:
Это только время проведения. До этого перед каждым было по полгода подготовки структуры и кода.
То есть и в старых форматах мастер-классы готовились и выпускались всего по одному в год. И даже в таком режиме там оставалось много недоделанного и вообще не рассматривались деплой и смежные темы.
И по времени если всё сложить, то за 4 года суммарно получилось всего 53 стрима на 200 часов сырого эфира со всем мусором без монтажа. С монтажом бы из них осталось всего 100 часов.
А новом формате уже опубликовано 133 скринкаста с монтажём и проведено 6 стримов.
По количеству информации в старых мастер-классах есть только программирование PHP-проекта, но вообще нет ничего про деплой, CI/CD, бэкапы, аутентификацию API, фронтенд, линтеры, типизацию, работу серверов, HTTP, разные уровни тестирования и прочих вещей, которые нужны в процессе разработки.
Да я как бы только за то, чтобы рассматривали все смежные вещи, такие как деплой, фронтенд и прочее. Просто если сравнивать с частотой, с какой уроки выкладывались в начале разработки аукциона и с какой сейчас - это прям бросается в глаза. Вот и предположил, что возможно дело в том, что такой формат требует больших затрат и как следствие процесс идёт более тяжко. Но если дело не в этом, то мой совет вернуться к старому формату не к месту оказался)
Нам нравятся ваши скринкасты, и от этого жажда мучает нас еще больше. :)
Думаю, тут ещё вопрос финансов. У людей списывается по 500 руб. в месяц, а новых роликов-то уже сколько месяцев нет. Ладно бы ещё стримы были бесплатными для плательщиков, так нет, они тоже денег стоят, ещё и немаленьких.
А были ли или будут CI/CD?
Рассмотрите на стриме ситуацию, когда у вас сайт с рассылкой, "злой дядька" покупает БД майлов и начинает их регистрировать у вас. У вас требуется подтверждение регистрации по майлу. В БД дядьки, среди прочих, оказываются майлы спам ловушек, и вот вас уже банят почтовики (почтовые сервера в блэк листе).
Разберите, пожалуйста, подобный сценарий, а то в роли злого дядьки может быть любой школьник без технических знаний.
Спасибо.
Здравствуйте, Дмитрий. Тема очень интересная, особенно если ещё охватывать законодательную часть.
Какие есть предложения по стриму:
Вероятно Вы это уже учли в подготовке стрима, но решил ещё поделиться.
Вижу много людей, которые ждут определенные темы и возмущены тем, что не получают их. Например, тема RabbitMQ. Когда-то вы говорили, что deworker.pro будет развиваться так, как хотят большинство. Стрим по безопасности дело полезное, но может быть стоит прислушаться? Практически под каждым скринкастом я вижу сообщения про RabbitMQ. С одной стороны вы рассмотрели эту тему на стриме. Кто-то её понял. Но видимо не все) По этой части могу внести предложение выкладывать темы и стримы по голосованию. За что больше голосуют - ту тему и готовить. Так и сообществу будет интересно, и вам. Рассмотрите такой вариант)
Дополнительно хочу внести предложение чтобы ваш сайт deworker.pro стал публичным в плане кодовой базы и скринкастов. Аукцион интересный, но сложность его заключается в том, что его надо специально разрабатывать. Тратить на это много времени, а между делом ещё и успевать поддерживать в актуальном состоянии deworker.pro. Вам было бы проще черпать идеи от сообщества, писать код и останется только это всё снимать. Вполне возможно, что на этой почве кто-то мог бы помогать вам в разработке deworker.pro кодовой базы. Готовить какую-то фичу, а вам только снять видео. Захотел побыстрее чтобы вышло видео - сделай пул реквест) Я не знаю, возможно ли это, но стоит подумать. Вы также иногда в своих видео показываете код не аукциона, а именно deworker.pro. Особенно вам было бы проще делать простые вещи - вроде обновления на PHP 8.4 и других зависимостей. А так эта большая работа вам предстоит и в аукционе и в deworker.pro.
Спасибо вам за ваше терпение и ваш труд!)
Спасибо, Дмитрий, за Ваше отношение и усилия по передаче опыта и знаний. Счастливого Нового Года и праздников Вам!
Дмитрий, тоже жду выпуски основных вещей. И мне кажется ваша проблема, что вам надо освоить ещё один навык - делегирование, работа в команде. Один человек на монтаже, один эксперт, который поможет с материалом, подачей, структурой выпусков. Да придется делиться, да есть риски. Но в итоге можно прийти к качественно новому результату. Возможно уже есть люди, которые хорошо разбираются в каких-то вопросах и могли бы за вас раскрыть какую-то тему, доделать скринкасты, которые уже висят не один год. Дерзайте, удачи!
Или войти через: