Архив метки: bash

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов

Добавить комментарий

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов. Форматирование постов в MAX долгое время оставалось для меня весьма мучительной задачей. Судите сами: текстовую разметку (markdown) MAX пока не поддерживает, доступ к API для постинга пока есть только у юрлиц. Конечно, уже есть сервисы, предоставляющие услуги постинга (фактически обёртки над API), но они все какие-то мутные и просят денег буквально за каждый пост. Бесплатных ботов-конвертеров, аналогичных ТГ-шным пока нет. И чего с этим делать? Каждый раз форматировать пост ручками, используя редактор постов в приложении MAX? Ну, такое себе. Но решение, оказывается, всё время было рядом и было очень простым.

Всё началось с того, что я заметил: в веб-версии MAX форматированный текст можно копировать и вставлять без потери форматирования. 👀 А это значит, что веб-приложение MAX кладёт текст в буфер в форматированном виде. Что в свою очередь значит, что форматированный текст в таком же виде можно положить в буфер самостоятельно. 😉 Оказалось, что в Linux это можно сделать буквально вот так с помощью xclip:

cat post.html | xclip -selection clipboard -t text/html

Как-то специально заморачиваться с html не нужно. Если там используются простые теги (a, b, i, br) - всё работает. 🙂 Форматированный текст копируется в буфер и его достаточно вставить в веб-интерфейс MAX. 😇

Важно: это работает именно с веб-клиентом! Десктопный клиент хранит форматированный текст в буфере несколько иначе и там нужно больше танцев с бубном, чтобы достичь +- того же результата. Поэтому лучше работать именно с веб-клиентом.

А что если нам наоборот нужно копировать посты из MAX с сохранением форматирования? Это может быть полезно, если мы изначально пишем посты в MAX, а потом хотим выложить их куда-то ещё с сохранением форматирования. Всё аналогично. Копируем форматированный текст поста в веб-клиенте MAX и читаем буфер (в Linux) с помощью того же xclip:

xclip -selection clipboard -t text/html -o

Но есть проблема, что html-код там навороченный. Чтобы упростить его до простых тегов (a, b, i, br), я навайбкодил скриптик. В том же проекте доступны bash-обвязки, которыми я пользуюсь: HTML2MaxBuffer.sh, MaxBuffer2HTML.sh, show_all_buffers.sh.

Пользуйтесь и рекомендуйте друзьям, которым это может быть актуально.

Прожектор по ИБ, выпуск №15 (09.12.2023): Нейролингвистические атаки на ИИ

Добавить комментарий

Прожектор по ИБ, выпуск №15 (09.12.2023): Нейролингвистические атаки на ИИ

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

00:00 Здороваемся и смотрим статистику по прошлому эпизоду
01:56 Про конференцию Код ИБ Итоги 2023
08:14 Фишинговая атака на админов WordPress и настоящая RCE
13:39 У NVD превратятся в тыкву фиды и API 1.0, что делать?
17:36 Нейролингвистические атаки на ИИ и автоматическая конвертация BASH в Python
26:00 Стратегия развития области связи
34:17 Премия Киберпросвет
38:59 Прощание от Mr.X

Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python

1 комментарий

Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python

Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python. Bash-скрипт был примитивный: скачать zip-архив с XML-выгрузкой из БДУ ФСТЭК, распаковать, поискать уязвимости, которые были добавлены в этом году. Я такое накидываю быстро и на автомате. Расплачиваюсь за это последующим рутинным переписыванием на Python. 😕 Автоматизированную же трансляцию толком не сделаешь - слишком много утилит и их особенностей. Или сделаешь? 😏

На удачу забил этот bash-скрипт в сервис с комментарием "rewrite in python" и железяка практически справилась. 🤩 Скачала архив по урлу, распаковала, циклически прошлась по файлу и поискала то, что нужно. Было только несколько минорных ошибок. Magic. 🪄

Продолжу эксперименты с чем-то посложнее, с кучей sed-ов и awk. Но похоже, что будет можно по кайфу фигачить парсеры на Bash-е и влегкую превращать это потом в приличный Python. 😊 Если не прямо сейчас, то в обозримом будущем.

Что делать со "слепыми пятнами" в базах знаний Vulnerability Management решений?

2 комментария

Что делать со "слепыми пятнами" в базах знаний Vulnerability Management решений? 🤔 В прошлый раз показали, что VM решения могут детектировать не все уязвимости. Это данность. Что можно предложить VM-вендорам, чтобы эта ситуация начала меняться к лучшему.

1. Чтобы бороться, с проблемой нужно для начала её измерить. А для этого нужно понимать для каких продуктов VM-решение может детектировать уязвимости. Rapid7 поддерживает такой список. А как насчёт других VM-вендоров? Также было бы неплохо, чтобы во время аудита VM-решение подсвечивало продукты, которые были обнаружены, но детектов уязвимостей для них нет. Если это будет наглядно видно, клиент сможет выбирать как реагировать: пушить VM-вендора, чтобы добавляли поддержку; подобрать дополнительный специализированный сканер уязвимостей; отказаться от использования продуктов, для которых не работают детекты уязвимостей; принять риски.

2. Не можете детектировать сами, но хотите быть единственным решением для Vulnerability Management в организации? Тогда будьте любезны дать возможность заводить уязвимости в вашем решении, продетектированные, например, другим специализированным сканером уязвимостей. Технически это означает необходимость добавить возможность заводить уязвимости и редактировать списки активов, где они детектируются, через API.

3. Неплохо бы дать возможность пользователям управлять скриптами для кастомных детектов непосредственно внутри VM-решения. В какой-то степени это уже реализуется в некоторых VM-решениях через возможность добавления собственных детектов на специализированных языках (OVAL, NASL, Nmap scripting language). Но добавлять детекты с помощью более привычных, мощных и универсальных инструментов (Bash, Python) было бы гораздо предпочтительнее. Одну такую реализацию рассмотрим в следующий раз.