OWASP Cheat Sheets

Еще одна важная вещь, которую миру подарила организация OWASP, - серия OWASP Cheat Sheets. Эта штука, вероятно, многим разработчикам будет удобнее ASVS, т.к. дает более прикладную информацию, но это скорее следствие того, что область применения у читщитов немного другая - если ASVS критически важен на этапе дизайна приложения, то читщиты - это уже про реализацию. Но маппинг одного на другое есть - чтобы было проще ориентироваться.

Про что есть шпаргалки?
- разделы, посвященные тому, как правильно организовать безопасность для конкретных технологий (например, разделы про Java, Laravel, .NET, NodeJS, отдельно про GraphQL и многое другое).
- разделы, посвященные скорее DevOps части разработки (CI/CD Security, Docker Security, Network Segmentation...).
- разделы, посвященные реализации конкретных фич, которые часто встречаются и имеют список типичных ошибок, которые допускаются при реализации (File Upload, мэнеджмент сессий, работа с XML и многое другое).
- вообще совершенно классные разделы, посвященные в целом тому, как организовать менеджмент секретов, проводить моделирование угроз, тестировать аутентификацию и даже осуществлять виртуальный патчинг.

Именно на основе этих документов можно очень быстро дополнить свой список для Code Review требованиями по Security части. Предлагаю ознакомиться с этим документом и выбрать для себя те вещи, которые касаются Ваших продуктов.

зацените слоган)

Typosquatting в go-пакетах: атаки на linux и macos

Всем привет, вчера вечером опубликовали статью, на которую стоит обратить внимание go-разработчикам (а для общего понимания атаки и остальным тоже можно).

Исследователи из socket.dev обнаружили развернутую атаку на Go экосистемы. Опубликованные злоумышленниками пакеты при запуске распаковывают малварь, которая по общему своему составу похожа на стандартные подходы к доставке зловредов разными APT. По всей видимости, атака направлена на разработчиков в финансовом секторе. Будьте осторожны.

Плохие секреты. Поиграем?

У OWASP есть еще и игры. Предлагаю познакомиться с одной из них - wrong secrets project.

Эта игра знакомит Вас с тем, где и по каким причинам могут прятаться захардкоженные пароли. Хотя разработчики и так знают это, правда?)

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

https://www.wrongsecrets.com/

Хотите задачку? Есть следующий ниже код (Node.js). Что нужно отправить в параметр token, чтобы этот код напечатал true?

Что эта таска делает в канале про application security? а она связана с одной очень специфичной уязвимостью, которая возникает в случае, если на бэке используется Node.js. Если у Вас есть идеи, что нужно сделать, пишите в комментарии (ну или в личку). А на следующей неделе расскажу подробнее про саму уязвимость и почему она возникает.

const SOMEOBJECT = {}

app.get("/validateToken", (req, res) => {
 if (req.header('token')){
  const token = Buffer.from(req.header('token'), 'base64')
  if (SOMEOBJECT[token] && token){
   return res.send("true");
  }
 }
 return res.send("false");
});

В начале недели я скидывала таск, который успешно был решен. Пришло время рассказать, какое отношение он имеет к безопасности.

Специфичная для JavaScript, уязвимость, о которой пойдет речь, называется Prototype Pollution. В этом языке каждый объект имеет специальное поле, по которому можно получить доступ к его прототипу. Для этого можно обратиться к имени __proto__, которое по сути можно использовать как сеттер и геттер для прототипа объекта. И хотя это обычно считается плохим подходом, в целом, в JavaScript можно изменять прототип не только для пользовательских, но и для встроенных типов.

Prototype pollution - уязвимость JavaScript, которая позволяет атакующему добавить нужные ему свойства в глобально определенные прототипы, которые могут быть унаследованы пользовательскими объектами. Проще говоря, мы можем переопределить структуру, лежащую в основе объектов.

Сама уязвимость в чистом виде встречается и эксплуатируется редко, зато может оказаться важным звеном в цепочке атаки. Классный гайд о том, когда она возникает и как именно эксплуатируется, есть здесь. И если Вы работаете с JS, то ознакомиться с ним было бы очень здорово, потому что при плохом стечении обстоятельств, она может даже дать RCE (в первой ссылке ниже пример именно такой).
Тем более что такие уязвимости в большом количестве обнаруживались в самых разных JS библиотеках (Blitz.js с крутым разбором ) и как минимум уже в трех популярных плагинах в этом году: canvg, vue l18n , intlify

Всех поздравляю с наступающим праздником! Желаю тепла, любви и здоровья! а по заявке одного из подписчиков, предлагаю еще и флаг найти)

Два повода обновиться - уязвимости 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 просто будет пропущен, а проверка аутентификации\авторизации пользователя по определенным путям перестанет работать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не совсем про уязвимости, но хочу поделиться игрой от 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/

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

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

@RequestMapping("/spel")
public class SpelInjectionController {

    @GetMapping("/evaluate")
    public String evaluate(@RequestParam String id) {
        ExpressionParser parser = new SpelExpressionParser();
        StandardEvaluationContext context = new StandardEvaluationContext();
        context.setVariable("runtime", Runtime.getRuntime());

        Object result = parser.parseExpression(id).getValue(context);
        return "Result: " + result;
    }
}

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

Spring Expressions Language (SpEL) Injection

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

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

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

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

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

In a wilderness

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

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

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

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

Про инъекции

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

rm file1 file2 dir1 dir2 -rf

, а если включить 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 , где я буду выступать с докладом про то, как случается в жизни - хотели исправить уязвимость, а вышло, что сделали другую. Беда🤷‍♀️
И если вы будете на конфе, буду очень рада вас видеть)

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

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

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

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

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

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

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

Всем привет! пришла пятница и обещанный таск, который CTF-ерам покажется нереально тривиальным, а остальным может открыть что-то новое. Just have fun.
А я напоминаю, что сегодня мы можем встретиться на конфе appsecfest.kz , меня можно будет найти (теоретически) возле большого зеленого животного.

Попалась статья по принципу многое-в-одном-месте про JWT. Но скорее про логику использования, в том числе, с точки зрения безопасности, чем про саму реализацию. Начинающим разработчикам очень рекомендую, не начинающим - в целом, тоже может быть полезно.

https://www.permit.io/blog/how-to-use-jwts-for-authorization-best-practices-and-common-mistakes