Ко(д)тики и безопасность
رفتن به کانال در Telegram
Канал о безопасной разработке для программистов и не только.
نمایش بیشتر305
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+37 روز
+330 روز
در حال بارگیری داده...
جذب مشترکین
ژوئن '25
ژوئن '25
+305
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 17 ژوئن | 0 | |||
| 16 ژوئن | +3 |
پستهای کانال
Что нового в OWASP ASVS 5.0
Если вы забыли, что это, то можно почитать вот тут
В мае вышел новый релиз OWASP ASVS (самый большой за последние пять лет). И, как мне кажется, новая версия стала гораздо удобнее для разработчиков.
Но самое первое, что бросается в глаза, это изменения в области уровней защищенности. Если коротко, ASVS предлагает пачки контролей, соответствующие уровням L1, L2, L3, где L1 - базовая безопасность, а L3 - продвинутый уровень, соответствующий высокой зрелости продукта. Каждый уровень описывается своим набором требований\контролей, которые применяются к коду и, если все требования выполнены, можно считать, что мы соответствуем какому-то уровню.
Так вот. В старой версии ASVS 4.0.3 для соответствия уровню L1 нужно было выполнить 131 условие. В новой - всего 70. И несмотря на кажущееся противоречие (вроде как время идет, средний уровень зрелости должен расти), этот шаг весьма оправдан и является следствием жарких дискуссий. И здесь важно понимать, что высокое количество правил уровня L1, по всей видимости, являлось одной из причин того, что компании, начиная работать с ASVS, либо не доводили до соответствия первому уровню, либо в принципе бросали всю эту затею (все чаще думаю о том, что с безопасностью надо как с аллергеном - сперва малыми дозами, чтобы не вызывало сразу прям отторжения)
А еще все ожидали от этой версии правил работы с продуктами, использующими LLM, и не дождались. Авторы решили, что это заслуживает отдельного стандарта - и вот он .
А вот из реально прикольного - совсем новый раздел про пост-квантовую криптографию и сокращение длины минимально необходимого пароля (прикиньте! но там хитрая формулировка. Раньше было про "минимальную" длину пароля в 12 символов, сейчас стало "минимальная" - 8, а вот рекомендованная - 15. Но вообще, конечно, все уже присматриваются к историям без паролей).
В общем, новый документ ёмче, в нем меньше дублирования, убрано явно устаревшее и неактуальное и складывается ощущение, что новый документ еще больше адпатирован под разработчиков, а не под безопасников. И это не может не радовать.
| 2 |  ну и старый добрый мемчик, чтобы веселее читалось | 185 |
| 3 | Про атаки на разработчиков
Вчера с одной из команд говорили про социальную инженерию на разработчиков. Вспомнились кейсы, которые периодически активно обсуждаются в сети - когда на фейковом собеседовании человека просят скачать код с какого-то репозитория и на этом живом коде якобы провести сессию лайф-коддинга, чтобы убедиться в его навыках. Проблема начинается в тот момент, когда проект запускается в IDE и обфусцированный фрагмент одной из библиотек обращается к контрольному центру, чтобы скачать... RAT-файл, ратник, или remote access tool. Иными словами - программку, которая позволит выполнить на ПК жертвы определенные действия. В простом варианте атаки, на самом деле, не нужен даже ратник, потому что у нас и так выполняется код и какие-то доступы у него все равно будут.
И тут важный момент - а как защищаться? Можно поделить защиты на два аспекта.
1. Человек.
Это социальная инженерия, как ни крути. Поэтому то, насколько критично человек относится своим действиям, все еще остается важным. Зачастую разработчики и другие IT специалисты более расслабленно воспринимают стандартные правила кибергигиены, и злоумышленники этим пользуются.
2. Процессы и инструменты.
Докер-образы, плагины для IDE и браузеров, библиотеки в ZIP-архивах... как много всего может попасть к нам из непроверенных источников. Иногда по необходимости, иногда просто из любопытства. И все это нужно воспринимать как потенциально вредоносное, иными словами - ограничивать возможности, запускать все недоверенное в изолированных средах, перепроверять, что все это пришло из официальных источников.
И если говорить именно про эту атаку, то не стоит забывать, что IDE тоже пытается вас защитить (хоть полноценный сендбоксинг в ней и не возможен). Так, для плагинов механизм доверия в большинстве случаев реализован через подписывание, а для проектов есть Workspace Trust / Safe Mode, которые призваны ограничить возможности запускаемого кода, если он пришел из стороннего источника. | 165 |
| 4 |  просишь копилота подтюнить текст. Он тебе в ответ: а давай запилим инфографику! ну, давай...
пост не имеет смысловой нагрузки | 141 |
| 5 | +1 index.js | 244 |
| 6 | +1 index.php | 218 |
| 7 | Критическая уязвимость в Node.js библиотеке (и новая таска!)
Пару дней назад вышла критическая (CVE-2025-47949, CVSS 9.9) уязвимость в библиотеке samlify (Node.js). Это библиотека, реализующая аутентификацию в рамках интеграции с SAML SSO системами. И уязвимость, разумеется, позволяет злоумышленнику аутентифицироваться под кем-то другим, если у него есть хотя бы один валидный ответ на SAML-запрос. Поэтому если вы используете эту версию библиотеки, рекомендую как можно скорее обновиться до версии 2.10.0. Понравился комментарий в коде исправления:
// something has gone seriously wrong if we are still here
А пока предлагаю решить задачку на этом языке (ну и заодно ее полный аналог на PHP, если он вам ближе). Задачка с библиотекой не связана, вообще никак. И с уязвимостью в ней. Но это уже подсказка 🙂
Вопрос следующий - каким запросом я могу получить всех пользователей, что за уязвимость присутствует в коде и позволяет это сделать, и, главное, как это исправить?
На всякий случай:
Node.js код можно запустить с express (`node index.js`, поднимется на порту 8000)
PHP код - php -S localhost:8000 (ну или любой незанятый порт на ваш вкус)
P.S. странное чувство - предлагать людям добровольно скачать файлики с кодом и запустить их. | 227 |
| 8 | https://www.codereviewlab.com/ - а это шикарно, товарищи. Таски небанальные, надо поискать, подумать. В день доступен один таск в бесплатной подписке, да и платная в целом меньше 5000 тенге в месяц. Если кто ищет платформу для своей команды - рекомендую | 229 |
| 9 | Немного про Keycloak'и
Keycloak - кажется, одно из самых популярных у нас в Казахстане опенсорсных IAM (Identity and Access Management) решений. По крайней мере, мне попадался часто и при пентестах, и в процессе разработки. Но как и любой другой инструмент, он требует осторожности при настройке, а так же имеет ряд своих архитектурных особенностей, которые требуют пристального внимания, чтобы случайно не сделать ваш инстанс и связанное с ним приложение уязвимыми к разного вида атакам. Это тот случай, когда просто поддерживать актуальную версию совсем недостаточно.
Поэтому хочу поделитсья парой ссылок про него.
1. Разумеется, официальная дока про то, как делать безопасно в приложениях и сервисах: https://www.keycloak.org/docs/25.0.6/securing_apps/index.html
2. Официальная дока про то, как конфигурировать: https://www.keycloak.org/docs/25.0.6/server_admin/index.html#mitigating_security_threats
3. И, собственно, про то, как вас будут ломать (а мы же все понимаем, что будут):
часть 1 - https://csacyber.com/blog/pentesting-keycloak-part-1-identifying-misconfiguration-using-risk-management-tools
часть 2 - https://csacyber.com/blog/pentesting-keycloak-part-2
Вот тут важный момент: дока не самая свежая, но по части разведки (сбора информации о том, как ваше приложение использует keycloak) и основных косяков конфигурации все равно будет актуальна. Важно не забывать, что за последние пару лет еще вышла пачка CVE.
4. Про то, что IAM по-своему сложно бороться с гонками: https://www.cyberark.com/resources/threat-research-blog/you-cant-always-win-racing-the-keycloak | 271 |
| 10 | Попалась статья по принципу многое-в-одном-месте про JWT. Но скорее про логику использования, в том числе, с точки зрения безопасности, чем про саму реализацию. Начинающим разработчикам очень рекомендую, не начинающим - в целом, тоже может быть полезно.
https://www.permit.io/blog/how-to-use-jwts-for-authorization-best-practices-and-common-mistakes | 285 |
| 11 | Всем привет! пришла пятница и обещанный таск, который CTF-ерам покажется нереально тривиальным, а остальным может открыть что-то новое. Just have fun.
А я напоминаю, что сегодня мы можем встретиться на конфе appsecfest.kz , меня можно будет найти (теоретически) возле большого зеленого животного. | 352 |
| 12 | я тут случайно выяснила, что у Semgrep есть своя академия: https://academy.semgrep.dev/
Формат видео мне обычно не заходит. Текст читать проще, да и примеров хочется именно кодом, а не на словах. Но этот курс ведет Tanya Janca (https://shehackspurple.ca/), а она весьма экспертна и харизматична. По итогу мне понравился мини-курс про безопасность API для разработчиков - может, и вам пригодится.
И два оффтоп вопроса к алматинцам:
1. Как к вам одеваться, если вылетать завтра? Вроде прогноз показывает, что тепло, но люди говорят обратное
2. Подъемник на Кок-Тобе работает, не знаете?) | 534 |
| 13 | ⚡️KazInfoSec - подборка личных TG-каналов казахстанского ИБ-комьюнити 💭
https://t.me/addlist/kI9Bkz-4Bs41ZmRi | 161 |
| 14 | Попалась хорошая статья про то, как вкатиться в код ревью по безопасности.
С этим делом какая проблема: когда спрашивают, с чего начать учиться на аппсека, я всегда отвечаю, что с написания кода. Но будем честны, в отрасли такая нехватка аппсеков, что требовать "в совершенстве владеть каким-то языком программирования" - слегка оверкилл. А фразу "написание кода" зачастую понимают именно так - большой промышленный опыт с глубоким знанием всех конструкций и особенностей. А это задачка, так-то, даже для разработчика нетривиальная, да и не всегда необходимая. Поэтому, возможно, есть смысл сперва посмотреть подобные статьи и адаптировать все эти рекомендации под себя. Ведь было бы желание.
В статье, кстати, есть ссылка на репо автора с примерами кода. Для начинающего аппсека или разработчика, который хочет безопаснее, самое то.
https://medium.com/@dub-flow/how-to-get-started-with-secure-code-review-89bcf2eb7ec4 | 358 |
| 15 | Про инъекции
Всем привет! в прошлом посте вы видели небольшой таск про то, как работают вайлдкарды (например, *) и как коварен может быть баш, если их использовать неосмотрительно. Причем в таске мы рассмотрели историю про то, что файл с названием "-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 , где я буду выступать с докладом про то, как случается в жизни - хотели исправить уязвимость, а вышло, что сделали другую. Беда🤷♀️
И если вы будете на конфе, буду очень рада вас видеть) | 798 |
| 16 |  In a wilderness
У нас были таски на разных языках программирования. Сегодня хочу предложить задачку которая требует знания только bash. Ну и некоторых особенностей его команд, а также линуксовых директорий.
Расклад примерно такой, как на прикрепленной картинке. Вы находитесь в директории, в которой есть непустые сабдиректории и есть несколько файлов. Вопрос: какое действие или команду надо выполнить, чтобы выполненная после нее инструкция "rm *" удалила не только файлы, но и директории с вложенными в них файлами?
Примечательно, что та вещь, о которой идет речь в таске, сработает практически на всех *nix-based системах, но на некоторых запросит согласие пользователя, а на некоторых - нет.
Ответы "удалить заранее" или "переопределить rm" не подходят. Если будет нужна подсказка, дам ее сегодня вечером :) | 228 |
| 17 | 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 | 230 |
| 18 | Пятница - снова хорошее время, чтобы порешать таски.
На этот раз таск очень простой. Если Вы знакомы со 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()) и пример сразу станет жизненнее; | 208 |
| 19 | Тут недавно люди говорили, что любят читать код после работы 🙂
не совсем про уязвимости, но хочу поделиться игрой от 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/ | 194 |
| 20 | Второй пост за день))
25 апреля пройдет конференция AppSecFest, https://appsecfest.kz/
Я еще ни разу не попадала на нее, хотя очень хотела с первого года проведения. И вот теперь подалась с докладом. Поговорим о том, как мутируют баги (кстати, не только уязвимости). Приходите, буду очень рада видеть!
А еще - ребята продлили CFP до 7 апреля, и если вам есть, чем поделиться с коммьюнити разработчиков и AppSec/DevSecOps инженеров, то это очень хорошая площадка для этого! | 179 |
