Реальные истории Web безопасности
HTML-код
- Опубликовано: 4 окт 2024
- Попробовать анализатор PVS-Studio: pvs-studio.ru/...
Мой тест PVS-Studio: • Поиск ошибок кода с по...
Поддержать меня на Бусти и получить доступ к доп контенту: boosty.to/mflenov
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.info
Телеграм: t.me/mflenov
X: x.com/flenov
Инстаграм: / mflenov
Мой просто блог blo.moe
О, лайфстори про ИБ. Всегда интересно.
Похоже на полезную интеграцию ) но историю классная. Спасибо!
Надеюсь полезная, я с PVS работаю уже не первый раз, потому что мне нравится их продукт.
Строгие код-гайды и качественные тесты, в том числе по безопасности, во время разработки помогут избежать многих проблем.
Миша, respect!
Только нубам нужна безопасность! Реальные кодеры делают код настолько забагованным, что хакеры просто плюют на взламывание этой кучи рандомного кода! :D
Бывает такое
Попытались найти логику и зависимости плюнули и пошли ломать интерпрайз :)))
😂
Ждем видео "Что программист должен знать о безопасности?" :)
Для безопасника о безопасности нужно знать всё. Для хакера о безопасности достаточно знать одну вещь, которая будет не закрыта на стороне безопасности.
@@programisli есть-же подмножество пунктов авторизации, аутентификации, sql инекций, обновлений сторонних зависимостей и связанные с этим вещей) BTW привет из Ростова)
@@programisli Истина, Михаильчик !!!!
12:24 "программисты должны думать, это не так сложно" 🤣
У меня на бусти много видео по безопасности. 10 часов просмотра и не будешь совершать самые популярные ошибки
Привет! Если уж говорить что нашли "виноватого", то "виноваты" прежде всего те, кто пропустил этот код в прод. К процессу код ревью подошли спустя рукава. Вот и закономерный результат.
Там не было ревью, потому что торопились. Но блин, это был уже где-то 2017-й год и SQL инъекцию уже позорно допускать.
@@programisli Значит виноват тот, кто построил такой процесс разработки. Спешка не может быть оправданием слабых процессов
А программист то НЕ ВИНОВАТ! Я смотрю Егора Бугаенко, он прямо говорит, программист не виноват, если мы закоммитили этот код! Значит наша система тестов пропустила его, значит мы(компания) его одобрили. Надо было лучше писать систему тестов.
Смотря о каких тестах ты говоришь, если это unit тесты, то их пишет сам программист. А если это отсутствие статического анализатора кода, то да, сами виноваты, что не используют
@@programisli нет, те тесты которые пишет программист никуда не годятся. Я говорю лишь о тестах, которые должен выполнять любой заказчик при приёмке стороннего кода. Хотя по идее все эти тесты должны составлять единую систему. И во вторых у меня есть такое подозрение, что мы говорим о пхп коде, который и создал ваш программист, в таком случае получается получение проблем безопасности будет происходить с каждой новой страницей. Я уже больше 15 лет не разрабатываю веб, но уже тогда применял комплексные фильтры на входе, когда все запросы пользователей сначала фильтруются на безопасность, и только потом передаются в серверный код.
Заказчик и менеджмент часто даже не думают о безопасности: их доходы от неё не зависят. Все начинают бегать и суетиться только когда петух известно куда клюнет (дырой реально кто-то воспользуется). Однажды помню, известил руководство, что у нас единый пермишен на скачивание файлов и, зная идентификатор, можно качать файлы других пользователей. Проблеме поставили приоритет "Забить х.." и продолжили пилить фичи.
:)))
Продаем 4 воды, 3 воды отменяем, списываются 4 воды.
"Проблема не массовая, забей" :))
Кодеры протестировали свой код, интеграторы настроили в серверной винде автологон с правами администратора :))
Бывает такое
Думал, интерсное что... А оказалась партнёрка пивиэс😂
Это партнёрка, но истории же жизненные и реальные. Большую часть видео занимают реальные истории.
Подскажите пожалуста, безопасно ли "where" ( для БД) , принимать с наружи, а запрос будет результат конкатации с этим where. Спасибо
Любая конкатенация в запросе с данными снаружи опасна. Я на бусти показывал примеры взломов
может, проблема в 5 баксовых программерах ? пословица про дешевую рыбка таки права ?
Так автор про это и говорит, что косяк в дешевой раб силе в конечном итоге привел к фейлу дедлайна
@@nikitiki524 не, автор говорит, что 5-баксовых они не перстанут заказывать, но последние должны работать хорошо и за 5 баксов
Проблема и в образовании программистов и в отсутствии проверок. Лучше если программисты будут более продвинутыми и для самозащиты использовать анализаторы и вообще тестировать как можно раньше
@@programisli мне кажется, структурно. Всегда провал в менеджменте. Если используется дешевый кодер, он не должен писать критически важный участок кода в сжатые сроки.
Если на рекламную компанию потратили деньги, должны понимать, что есть риски дедлайнов. Выгорит, профит. Не выгорит, значит списываем затраты на рекламу без криков "все пропало и что теперь делать" :)
Если компания небольшая, имеет ли смысл заморачиваться безопасностью? Грубо говоря, скорее всего никто не будет пытаться ломать - можно так рассуждать?))
Надёжность кода, отказоустойчивость, восстановление после сбоев - это другое дело, это всегда важно...
Отказывайтесь от ООП и сайт будет, на сервере, работать в разы быстрее !
Так ООП используют сейчас на минимуме, уже никто не использует наследованные.
@@programisli я от него отказался давно
На каких языках писали сайт?
C#
@@programisli бэк c#, фронт Javascript?
Первый
Мож специально?