Стрим про безопасность web-приложений
В комментариях и чатах к предыдущим стримам часто попадалось предложение о том, что было бы интересно посмотреть или послушать что-нибудь на тему безопасной разработки web-приложений. Как про написание безопасного кода, так и про защиту сетей, виртуальных машин и контейнеров.
Эта тема теперь особенно актуальна ввиду ужесточения ответственности за утечки персональных данных и за несоблюдение требований законов к хранению и защите этих данных. Помимо этого, если мы активно разрабатываем и публикуем приложения в Docker-контейнерах, то сразу возникает необходимость разобраться с защитой этих контейнеров и сетей между ними.
По этим просьбам проведём наш очередной большой ламповый стрим на один или два вечера про безопасность web-приложений и сопутствующей инфраструктуры.
На стриме проведём исследование разных видов атак. Обсудим с примерами написание безопасного программного кода на бэкенде и во фронтенде. Разберём хеширование и шифрование данных. Защитим HTML-формы от подлога и API от перебора. Сделаем невозможным внедрение постороннего JavaScript через фильтрацию и через политики безопасности браузеров. Дополнительно защитим аутентификацию по OAuth2. Разберёмся с защитой инфраструктуры в Linux нативно и в Docker-контейнерах. Подберём нструменты для проведения аудита и поиска уязвимостей. Организуем для своего проекта соблюдение технических требований к обработке персональных данных, резервному копированию и мониторингу по закону №152-ФЗ.
Так что до встречи в эфире и в записи!
Оплатить стрим можно самому российской или иностранной картой или попросить работодателя оплатить от имени компании.
Для скидки можете сначала оформить в кабинете или от работодателя безлимитную подписку на наши полезные скринкасты про разработку. Вместо разовой оплаты там теперь заработала подписка с автоплатежами и для иностранных карт.
А потом или сейчас приобрести участие в трансляции и получить запись можно там же в кабинете или здесь:
Это всё очень хорошо и очень интересно ) НО! Когда будет шестой скринкаст по взаимодействию объектов (поля и свойства)? Когда будет продолжение серии "Устройство HTTP-фреймворка"? Наконец, когда будет продолжение по аукциону на Slim, особенно сильно интересует "Брокер очередей" и следующие за ним три темы. Когда??! )
Дико плюсую!
Поддерживаю :)
Присоединяюсь к вопросу, когда будет продолжение основных скринкастов?
Плюсую!
Да, действительно, когда мы уже закончим несчастный аукцион?
Согласен, хочется продолжение скринкастов.
Да уж, даже планы по аукциону не озвучивается ..
Если забросили, то лучше уже озвучить честно. Но то что было - бомба!
Стрим обещает быть огненным. Везде все про python, про php есть, но мало. И в целом на тему безопасности в разработке, как мне кажется, всегда собираешь по крупицам информацию. Например собрать список небезопасных атрибутов в html, которые надо эскейпить особым образом, не так как обычные атрибуты, можно запыхаться!
Чтобы не быть голословным, вот мой список, которым я пользуюсь для этих дел:
Атрибут - href
В тегах: a, area, base, link, svg.image
Атрибут - codebase
В тегах: applet, object,
Атрибут - cite
В тегах: blockquote, del, ins, q
Атрибут - background
В тегах: body
Атрибут - action
В тегах: form
Атрибут - longdesc
В тегах: frame, iframe, img
Атрибут - src
В тегах: frame, iframe, img, input, script, audio, embed, source, track, video
Атрибут - profile
В тегах: head
Атрибут - usemap
В тегах: img, input, object
Атрибут - classid
В тегах: object
Атрибут - data
В тегах: object
Атрибут - formaction
В тегах: button, input
Атрибут - icon
В тегах: command
Атрибут - manifest
В тегах: html
Атрибут - poster
В тегах: video
Атрибут - srcset
В тегах: img, source
Атрибут - archive
В тегах: object, applet
5 лет уже делаем аукцион, эта серия скринкастов скоро превратится в мастер-класс о том как попасть в "Производственный ад"
К слову, может имеет смысл вернуться к формату старых мастер-классов? Как это было в случае с сериями по Yii, Laravel и Symfony. А то перфекционизм это конечно хорошо, но как итог, оно в ущерб количеству информации в итоге идёт. Что, как видим, в итоге и сказывается на продолжительности разработки аукциона.
Ну вот не знаю, может какое голосование устроить, чтобы было понимание, какой формат лучше. Как вариант.
Это вам кажется, что было быстрее и больше. Если проследите историю постов на сайте, то:
Если считать только время проведения мастер-классов, то:
Это только время проведения. До этого перед каждым было по полгода подготовки структуры и кода.
То есть и в старых форматах мастер-классы готовились и выпускались всего по одному в год. И даже в таком режиме там оставалось много недоделанного и вообще не рассматривались деплой и смежные темы.
И по времени если всё сложить, то за 4 года суммарно получилось всего 53 стрима на 200 часов сырого эфира со всем мусором без монтажа. С монтажём бы из них осталось всего 100 часов.
А новом формате уже опубликовано 133 скринкаста с монтажём и проведено 6 стримов.
По количеству информации в старых мастер-классах есть только программирование PHP-проекта, но вообще нет ничего про деплой, CI/CD, бэкапы, аутентификацию API, фронтенд, линтеры, типизацию, работу серверов, HTTP, разные уровни тестирования и прочих вещей, которые нужны в процессе разработки.
Да я как бы только за то, чтобы рассматривали все смежные вещи, такие как деплой, фронтенд и прочее. Просто если сравнивать с частотой, с какой уроки выкладывались в начале разработки аукциона и с какой сейчас - это прям бросается в глаза. Вот и предположил, что возможно дело в том, что такой формат требует больших затрат и как следствие процесс идёт более тяжко. Но если дело не в этом, то мой совет вернуться к старому формату не к месту оказался)
Нам нравятся ваши скринкасты, и от этого жажда мучает нас еще больше. :)
Рассмотрите на стриме ситуацию, когда у вас сайт с рассылкой, "злой дядька" покупает БД майлов и начинает их регистрировать у вас. У вас требуется подтверждение регистрации по майлу.В БД дядьки, среди прочих, оказываются майлы спам ловушек , и вот вас уже банят почтовики (почтовые сервера в блэк листе). Разберите, пожалуйста, подобный сценарий, а то в роли злого дядьки может быть любой школьник без технических знаний. Спасибо.
Или войти через: