Мир сегодня с "Юрий Подоляка"

Труха⚡️Україна

Паглядзець

Николаевский Ванёк

Паглядзець

Мир сегодня с "Юрий Подоляка"

Паглядзець

Труха⚡️Україна

Паглядзець

Николаевский Ванёк

Паглядзець

Ко(д)тики и безопасность

Канал о безопасной разработке для программистов и не только.

Рэйтынг TGlist

ТыпПублічны

Вертыфікацыя

Не вертыфікаваны

Надзейнасць

Не надзейны

Размяшчэнне

МоваІншая

Дата стварэння каналаСіч 20, 2022

Дадана ў TGlist

Квіт 19, 2025

Я ўладальнік канала

Гісторыя змяненняў

Прыкрепленая група

Ко(д)тики и безопасность Chat

Статыстыка Тэлеграм-канала Ко(д)тики и безопасность

Падрабязней

Падпісчыкаў

253

24 гадз.

20.9%Тыдзень

143130%Месяц

143130%

Індэкс цытавання

200

Згадкі2Рэпостаў на каналах0Згадкі на каналах2

Сярэдняе ахоп 1 паста

125

12 гадз.1250%24 гадз.1250%48 гадз.2020%

Узаемадзеянне (ER)

4%

Рэпостаў2Каментары0Рэакцыі3

Узаемадзеянне па ахопу (ERR)

49.8%

24 гадз.0%Тыдзень

78.83%Месяц0%

Ахоп 1 рэкламнага паста

125

1 гадз.00%1 – 4 гадз.00%4 - 24 гадз.00%

Падрабязней

Падключыце нашага бота да канала і даведайцеся пол аўдыторыі гэтага канала.

Усяго пастоў за 24 гадзіны

0

Дынаміка

Апошнія публікацыі ў групе "Ко(д)тики и безопасность"

Усе пасты

21.04.202515:24

я тут случайно выяснила, что у Semgrep есть своя академия: https://academy.semgrep.dev/

Формат видео мне обычно не заходит. Текст читать проще, да и примеров хочется именно кодом, а не на словах. Но этот курс ведет Tanya Janca (https://shehackspurple.ca/), а она весьма экспертна и харизматична. По итогу мне понравился мини-курс про безопасность API для разработчиков - может, и вам пригодится.

И два оффтоп вопроса к алматинцам:
1. Как к вам одеваться, если вылетать завтра? Вроде прогноз показывает, что тепло, но люди говорят обратное
2. Подъемник на Кок-Тобе работает, не знаете?)

Пераслаў з:

Сертификат безопасности

19.04.202512:24

⚡️KazInfoSec - подборка личных TG-каналов казахстанского ИБ-комьюнити 💭

https://t.me/addlist/kI9Bkz-4Bs41ZmRi

18.04.202511:49

Попалась хорошая статья про то, как вкатиться в код ревью по безопасности.

С этим делом какая проблема: когда спрашивают, с чего начать учиться на аппсека, я всегда отвечаю, что с написания кода. Но будем честны, в отрасли такая нехватка аппсеков, что требовать "в совершенстве владеть каким-то языком программирования" - слегка оверкилл. А фразу "написание кода" зачастую понимают именно так - большой промышленный опыт с глубоким знанием всех конструкций и особенностей. А это задачка, так-то, даже для разработчика нетривиальная, да и не всегда необходимая. Поэтому, возможно, есть смысл сперва посмотреть подобные статьи и адаптировать все эти рекомендации под себя. Ведь было бы желание.

В статье, кстати, есть ссылка на репо автора с примерами кода. Для начинающего аппсека или разработчика, который хочет безопаснее, самое то.

https://medium.com/@dub-flow/how-to-get-started-with-secure-code-review-89bcf2eb7ec4

18.04.202505:41

Про инъекции

Всем привет! в прошлом посте вы видели небольшой таск про то, как работают вайлдкарды (например, *) и как коварен может быть баш, если их использовать неосмотрительно. Причем в таске мы рассмотрели историю про то, что файл с названием "-rf" при вызове команды "rm *" может привести к неожиданному поведению. Так, для интерпретатора команда в таком раскладе превратится в

, а если включить strace, то увидим картину ниже.

И дело даже не в вайлдкардах, а в самих командах, которые могут принимать инструкции через флаги, но при этом обрабатывать имена файлов именно так, как это делает rm на скриншоте - есть "-" в начале? считаем это флагом!

И таких команд довольно много (навскидку: rsync, который вообще может принят команды на выполнение, zip и tar c интересными флагами -Т, scp и его флаг -oProxyCommand... кто хакеры его знает, что еще.) А самое забавное, что такая эксплуатация будет попадать под понятие инъекции, особенно если у пользователя есть вохможность каким-то образом повлиять на имена файлов в директориях, где запускаются какие-то ваши скрипты.

Прежде, чем читать дальше, давайте попробуем ответить для себя на вопрос: а во что вообще можно делать инъекции или про какие типы инъекций вы слышали?

- SQL (а также ORM инъекции, потому что вообще-то ORM тоже надо уметь правильно готовить. Сюда же Hibernate инъекции, LinQ инъекции и многое другое)
- инъекции Javascript и прочие XSS (кстати, в html тоже можно инжектить. И в css. И даже использовать это в атаках)
- инъекции кода - чаще всего реализуются через какой-нибудь рендеринг шаблонов или через локальное подключение файлов (include и еще с десяток методов в php, да и java server pages тоже сюда попадают), или через некорректную десериализацию.
- инъекции OS, не очень удачное название, но речь идет как раз о тех случаях, когда вы можете заставить приложение выполнить или модифицировать какие-то команды баша, как в нашем примере. Или еще чего системное.
- инъекции промтов

я думаю, что стопудово что-то упустила. Если вспомните что-то еще или если интересны разборы конкретных сценариев - пишите в комментариях.

А пока объявлю, что следующий таск в канале появится в пятницу. А также - что в пятницу проходит appsecfest.kz , где я буду выступать с докладом про то, как случается в жизни - хотели исправить уязвимость, а вышло, что сделали другую. Беда🤷‍♀️
И если вы будете на конфе, буду очень рада вас видеть)

11.04.202510:39

In a wilderness

У нас были таски на разных языках программирования. Сегодня хочу предложить задачку которая требует знания только bash. Ну и некоторых особенностей его команд, а также линуксовых директорий.

Расклад примерно такой, как на прикрепленной картинке. Вы находитесь в директории, в которой есть непустые сабдиректории и есть несколько файлов. Вопрос: какое действие или команду надо выполнить, чтобы выполненная после нее инструкция "rm *" удалила не только файлы, но и директории с вложенными в них файлами?

Примечательно, что та вещь, о которой идет речь в таске, сработает практически на всех *nix-based системах, но на некоторых запросит согласие пользователя, а на некоторых - нет.

Ответы "удалить заранее" или "переопределить rm" не подходят. Если будет нужна подсказка, дам ее сегодня вечером :)

07.04.202504:58

Spring Expressions Language (SpEL) Injection

Обещанный комментарий к пятничному (одному из самых непопулярных 😒 ) посту.

Приведенный в нем фрагмент кода содержит уязвимость типа SpEL инъекция, которая, как и все инъекции, возникает из-за некорректной работы с пользовательским вводом. В частности, если мы позволяем параметрам, на которые может повлиять пользователь, проинтерпретироваться как SpEL выражение, то пользователь может пробросить нагрузку вида T(java.lang.Runtime).getRuntime().exec('mkdir pwnd') , которая как раз приведет к выполнению команды на бэке приложения.

И вроде бы всегда очевидно, что пользовательский ввод исполнять\интерпретировать нельзя. Однако очень рекомендуется проверить свой код по следующим ключевым словам:
SpelExpressionParser, EvaluationContext, parseExpression, @Value("#{ }") или #{ }, ${}, T().

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

Проблема в том, что такая уязвимость случается гораздо чаще, чем может показаться. Началось все еще в 2016, когда вышла cve-2016-4977 - уязвимость, затронувшая массово Spring приложения, и позволявшая исполнять произвольный пользовательский код через один из параметров вью Whitelabel Error Page. И до конца 2024 года число CVE, присвоенных уязвимостям типа SpEL, составляет около 20 штук(это только в продуктах семества Spring, а не в коде использующих его продуктов). Последняя была опубликована в 2024 году, но одна из более интересных, и более критичных, разумеется, это CVE-2022-22980 , оцененная в 9.8

04.04.202504:18

Пятница - снова хорошее время, чтобы порешать таски.

На этот раз таск очень простой. Если Вы знакомы со Spring Boot 🙂 Ответом на задание будет строка, которая приведет к созданию на сервере, где запущен этот код, директории pwnd. А в понедельник я расскажу, как в 2016-2020 годах массово кошмарили приложения Spring Boot из-за аналогичной уязвимости, но и по сегодняшний день такая уязвимость - совершенно не редкость.

А если эта задача кажется Вам слишком легкой, то попробуйте создать нагрузку в случае, если мы уберем строку context.setVariable("runtime", Runtime.getRuntime()) и пример сразу станет жизненнее;

02.04.202516:41

Тут недавно люди говорили, что любят читать код после работы 🙂

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

https://quiz.pvs-studio.com/en/java/tutorial/

А еще у них есть очень крутые разборы уязвимостей, периодически почитываю, бывает интересно (например, https://pvs-studio.com/en/blog/posts/java/1190/ прям хороша)

UPD для шарпа у них тоже есть https://pvs-studio.com/en/blog/quest/csharp/

01.04.202509:24

Второй пост за день))

25 апреля пройдет конференция AppSecFest, https://appsecfest.kz/

Я еще ни разу не попадала на нее, хотя очень хотела с первого года проведения. И вот теперь подалась с докладом. Поговорим о том, как мутируют баги (кстати, не только уязвимости). Приходите, буду очень рада видеть!

А еще - ребята продлили CFP до 7 апреля, и если вам есть, чем поделиться с коммьюнити разработчиков и AppSec/DevSecOps инженеров, то это очень хорошая площадка для этого!

01.04.202503:43

Что все-таки случилось с томкатом?

Тут недавно ИБ сообщество встало на уши из-за CVE-2025-24813 - уязвимости с RCE в Apache Tomcat, которая, по всей видимости, должна очень легко эксплуатироваться (ну конечно, сериализация, что же еще).

Честно сказать, я тоже сперва напряглась и даже напрягла друзей (отдельное спасибо Саше за помощь), но оказалось, что в общем паника не особо стоила выеденного яйца, несмотря на 9.8 CVSS.

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

https://digitaldefenders.substack.com/p/cve-2025-24813-one-guard-lies-one

31.03.202505:38

Анализ зависимостей в go

Не знаю, есть ли тут go-разработчики, но штука крутая, хочется рассказать всем.

Композиционный анализ, или анализ того, становится ли ваш продукт уязвимым из-за использования сторонних библиотек - штука крайне сложная, потому что ложно-позитивные срабатывания в инструментах этого класса по определению являются нормой. Например, совсем недавно вышла статья про критическую уязвимость в Apache Tomcat, но при ближайшем анализе оказалось, что уязвимость действительно серьезная, но сработает только в очень узком классе случаев и при специфических настройках. И так с уязвимостями в сторонних компонентах практически всегда - может быть уязвим какой-то один метод, к которому ваш код вообще не обращается. А может быть как в случае с log4j - практически наверняка уязвимость сработает.

Дальше всех в решении этого вопроса, на мой взгляд, продвинулись разработчики языка go, которые не просто выпустили нативный для языка инструмент govulncheck, но еще и поддерживают свою собственную базу уязвимостей. А главной особенностью инструмента можно считать тот факт, что практически всегда в ходе анализа проверяется не просто факт наличия уязвимой зависимости, но еще и прослеживается, а действительно ли ваш код обращается к уязвимому функционалу. Такой анализ существенно снижает количество ложно-позитивных срабатываний. Да, безусловно, у инструмента еще есть белые пятна, на которых все работет неидеально, но их значительно меньше, чем у любого другого SCA в применении к go.

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

26.03.202503:48

Два повода обновиться - уязвимости Ingress Nginx и Next.js фреймворка

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

☄️ Первая мне особенно понравилась тем, что она служит отличным примером для OWASP Top-10 A04:2021 Insecure Design, когда контроль безопасности должен был быть продуман и не был. В Ingress NGINX Controller for Kubernetes была обнаружена целая пачка критических уязвимостей, которые могут привести к удаленному исполнению кода и в целом к полному захвату кластера. Уязвимость возникла из-за того, как адмишн контроллер обрабатывает входящие ингресс объекты. По умолчанию, этот контроллер доступен из сети без аутентификации, что делает его очень заманчивым для атакующего, позволяя ему инжектить произвольные ингресс объекты (содержащие директивы конфигураций, т.е. исполнять код). В ходе работы с этой уязвимостью исследователи нашли еще пять, а также разнесли первый патч, представленный командой kubernetes, потому что не всегда быстрые патчи реально устраняют проблему. Примечательно, что все пять критических уязвимостей были опубликованы командой Wiz, не так давно купленной Гуглом за 32 миллиарда долларов. Наличными.

CVSS 9.8, наличие и эксплуатабельность были подтверждены для 43% облачных платформ. Есить смысл проверить у себя, ведь по дефолту настройки уязвимые (правда, надеюсь, с сетевой доступностью все не так просто). Даже самые крутые команды могут допускать промахи, которые не ловятся никакими инструментами.

☄️ Вторая уязвимость затронула фреймворк Next.js и его работу с middleware. Возникает она из-за некорректной обработки заголовка x-middleware-subrequest. В частности, функция runMiddleware проверяет значение этого хэдера, чтобы определить, следует ли выполнять middleware. Злоумышленник может сфабриковать запрос, добавив этот заголовок с определенными значениями (например, pages/_middleware или middleware) и тогда middleware просто будет пропущен, а проверка аутентификации\авторизации пользователя по определенным путям перестанет работать.

В обоих случаях основная рекомендация - обновиться. Есть митигации, но это дело временное.