IT

🔐 Что такое LDAP Injection? Мы уже разобрали, что такое LDAP и зачем он нужен в Active Directory. Но что произойдёт, если приложение неправильно обрабатывает пользовательский ввод при обращении к LDAP? В этом случае может возникнуть LDAP Injection.

📌 LDAP Injection — это уязвимость, при которой злоумышленник изменяет LDAP-запрос, отправляемый приложением, чтобы получить несанкционированный доступ к данным или изменить логику поиска.

По своей идее она очень похожа на SQL Injection. Только вместо SQL-запросов атакуется LDAP. Представим, что приложение формирует запрос так:

(&(uid=user)(password=123456))

Если пользовательский ввод не фильтруется должным образом, злоумышленник может изменить структуру запроса и повлиять на результат поиска. 💀 Чем это опасно? При успешной эксплуатации LDAP Injection можно: — обойти аутентификацию; — получить информацию о пользователях; — перечислить группы и объекты Active Directory; — извлечь внутренние данные каталога. Всё зависит от того, какие права имеет учётная запись, от имени которой приложение обращается к LDAP. 🧠 Почему это встречается реже, чем SQL Injection? Потому что далеко не каждое приложение работает напрямую с LDAP. Но корпоративные порталы, системы авторизации, внутренние веб-приложения и некоторые VPN-шлюзы довольно часто используют LDAP для проверки пользователей. И если разработчики не экранируют специальные символы, появляется риск LDAP Injection. 🛡 Как защититься? Основные рекомендации: — использовать параметризованные LDAP-запросы; — экранировать специальные символы; — не собирать запросы простой конкатенацией строк; — выдавать приложению минимально необходимые права на чтение LDAP.

📌 LDAP Injection встречается значительно реже SQL Injection, но в корпоративной инфраструктуре последствия могут быть очень серьёзными, особенно если приложение имеет широкий доступ к Active Directory.

#infra #ad #ldap #ldapinjection #websecurity

Технологии цифровой защиты С ростом цифровых рисков компании всё чаще задумываются о надёжной защите своих данных и систем. Вот ключевые инструменты кибербезопасности: 🔹 Антивирусные программы — находят и блокируют вредоносное ПО до того, как оно причинит ущерб. 🔹 Межсетевые экраны (фаерволы) — контролируют входящий и исходящий трафик, защищая от внешних атак. 🔹 Системы обнаружения вторжений (IDS) — отслеживают нетипичную активность в сети и помогают выявить попытки взлома. 🔹 DLP-системы — предотвращают утечку конфиденциальной информации, ограничивая передачу важных данных. 🔹 Криптографические методы — шифруют информацию, делая её бесполезной для злоумышленников. 🔹 SIEM-решения — в реальном времени собирают и анализируют данные о безопасности, помогая оперативно реагировать на угрозы. Чтобы защита была действительно эффективной, стоит использовать комбинацию этих решений и регулярно обновлять инфраструктуру. Фаундер | Бизнес и Стартапы

Мы опубликовали тезис о киберэкономике, то есть новой экономической системе в программируемом и высокоавтоматизированном мире - человечество зажато между двумя экспонентами: технологии порождают новые риски вплоть до киберрабства и вымирания, но они же дают инструменты кибернетической саморегуляции - чтобы выживать, системы обязаны расширяться. капитализм это лучший самооптимизирующийся механизм экспансии, где цена работает как децентрализованный сигнал для баланса спроса и предложения - у экспансии встроенный трейд-офф риска и роста: чем быстрее рост, тем больше новых рисков: от долговых циклов и концентрации богатства до киберрабства владельцами ИИ - киберрабство - риск того, что техномонополии с рефлексивно самоулучшающимся ИИ применят накопленную власть за пределами бизнеса. оно уже здесь: телефон следит за вами, лента формирует убеждения, ИИ-ассистент работает на того кто больше платит - причиной являются человеческие ограничения в наблюдении, анализе, координации и действии - самое сильное из них - это проблема координации, порождающая невозможность коллективного действия. теория игр гарантирует, что индивидуально рациональное поведение даёт устойчиво худший коллективный исход - ИИ снимает эти ограничения: агенты ищут, рассуждают, коммуницируют и исполняют лучше людей. эпоха ограниченной рациональности позади. - смарт-контракты закрывают барьер доверия и гарантий исполнения обязательств: любые два агента, человек или ИИ, заключают сложные контракты без центральной юрисдикции - три рычага ускорения кибернетики: — регулирование через технологию (интерпретируемость ИИ, evals, верифицируемый аудит, полицентричное управление) — переход от экономики внимания к экономике намерений (агент читает интент, находит контрагентов, договаривается и исполняет) — ИИ-генерация рыночных механизмов на лету, где координация становится программируемой - развилка сегодня: смириться с киберрабством и дать рефлексивному технологическому риску привести к вымиранию или ускорить кибернетику, свести новые риски к нулю и сойтись к кибернетической экономике

Из чего состоит «сделать» Представьте, что на работе вас попросили добавить поддержку нового способа оплаты через Яндекс.Сплит. Если вы взялись это сделать, вот, что от вас ждут: Сначала вы очень хорошо подумаете и разберетесь в задаче. Куда добавить? Какие ограничения? Как это выглядело бы для клиентов? Затем вы очень хорошо подумаете о решении. Как это будет работать под капотом? Какие есть еще варианты? Что есть из готового, а что нужно и стоит писать самим? Какие требования и ограничения? Потом вы очень хорошо подумаете о краевых случаях. Какие они? Что с ними делать? На что можно забить? Какие не дадут запуститься? Тут вы еще и об ошибках подумаете. Скажем, что делать, если вебхук от Сплита пришел, когда мы лежали? А что делать, если Сплит вовремя не ответил, когда пытались создать заказ? Ретрай? Сколько раз, с какой паузой? Затем подумаете о данных. Что нам надо хранить, в каком виде? Это будет jsonb или нам вообще не нужен список товаров? А если решим расширить существующую модель заказов, как ее смигрировать? Что мы пока не знаем о данных и их хранении? Потом прикинете, как это все проверять. Какие тесты и для чего нужны? Что проверим автоматом, а что вручную? Есть ли у Сплита песочница, как в ней потыкаться? Потом придумаете, как запускать. Сразу всем? Втихаря на 10%? А за чем следить? Потом придумаете «анонс». Как и кому мы об этом рассказываем? Какие слова и термины используем, на что напираем? Что нашим клиентам от того, что у нас появился Сплит? Наконец начнете все это программировать. Возможно, сами, возможно, ллмкой. Проверите то, что получается. Что-то проверите автоматическими тестами, что-то руками, что-то агентом. Главное сейчас — убедиться, что оно готово к пуску. Затем ревью и пара-тройка раундов исправлений. Наконец смержите все в мастер и выкатите в прод. Еще раз убедитесь, что все работает. Не протыкал — не сделал. Если пуск затрагивает коллег, расскажете им об этом. Убедитесь, что не осталось хвостов. Если что-то нужно перепроверить через месяц-два, добавите задачку в календарь или агента. Поздравляю, теперь вы официально сделали задачу. P. S. Конечно, этот список меняется от компании к компании и от разработчика к разработчику. Если вы соло-предприниматель, все на вас. Если вы в бигтехе, анонсы писать не будете, но придется помудохаться с безопасниками. Если вы джун, от вас мало что ждут, но надеются, что вы со временем сможете закрывать весь список. Если вы сеньор, вы и сами все это знаете и регулярно делаете.

Кто-то только что переписал 40 лет PostgreSQL с нуля на Rust. И он уже проходит 100% официальных тестов Postgres. Проект называется pgrust. Это не форк, а полная реализация с нуля, которая уже проходит все 46 066 запросов из официального тестового набора PostgreSQL 18.3. Postgres разрабатывается уже 40 лет, и некоторые архитектурные решения из 80-х до сих пор приводят к сбоям: - один поток на соединение, фактически отдельный OS-процесс на пользователя - 350+ параметров настройки, которыми нужно управлять вручную - один только VACUUM стал причиной тысяч инцидентов pgrust выбрасывает всё это и начинает заново. Что уже работает: - проходит 96% regression suite PostgreSQL - psql подключается из коробки, есть совместимость с wire protocol - query planner, buffer cache, storage engine, B-tree индексы - JSON/JSONB, window functions, foreign keys, EXPLAIN ANALYZE, regex - тот же движок компилируется в WebAssembly и запускается прямо в браузере на pgrust.com 100% open source. https://github.com/malisper/pgrust