MS SQL + Telegram =?

[El_Kraken_Feliz]

Делал примерно такое же, больше всего убивает максимальная ширина, так что больше всего времени я потратил на алгоритмы разбиения по сообщениям и нормализацию строк, забавно, что у Вас примерно такой же подход, только я ещё с переносами строк заморочался :)
А так удобный, но опасный инструмент получился, решил на уровне кода запретить запросы с словами drop и выборку без ограничений.

А то можно написать что-то типа select * from table и привет :)

[gleberof]

Класс. Идеи отличные. Присоединишься к проекту?

[whunter]

С точки зрения удобства — вероятно полезный инструмент, но с точки зрения безопасности — вы создали точку входа к критическим данным. Как мишень для таргетированной атаки — слишком заморочено, но как массовый поиск на наличие доступа вполне годится. Ваш подход имеет право на жизнь, но ваши задачи вполне могли бы покрыть шелл-скрипты с тем же эффектом, но при этом вы не дали бы дополнительный доступ извне. Если ввести в ваш бот дополнительные и достаточные меры защиты — простота и комфорт, ради которого он существует — сведется к тому же SSH доступу, только через бот, что сведет на нет его смысл. Сделки между простотой, комфортом и безопасностью — довольно отчаянный шаг в случае доступа к важным данным. Не говорю, что сделанное вами — плохо, но говорю, что к подобным инструментам стоит пододходить с большой осторожностью. Если угодно — с удовольствием подискутирую на эту тему.

[t0rr]

Очень правильное замечание!
Добавлю свои 5 копеек в сторону митигации рисков.

Входящие запросы. Система (в данной реализации) работает по принципу поллинга, т.е. не получает обновления, а сама ходит за ними к API Telegram. Соответственно, чтобы получить доступ к подмене сообщений, нужно подменить api.telegram.org. Если злоумышленник делает вам подмену DNS — тут не о ботах надо переживать :)

Доступ к «злодеяниям». Фильтрацию команд можно нужно настроить исходя из критичности данных. Как выше писал El_Kraken_Feliz, пользователь данного решения вправе закрыть возможность что-то сломать (как минимум самому). Код открыт, можно докручивать его как угодно.

Доступ к чату. Если управление происходит из группового чата, закройте возможность пользователям добавлять людей в группу. Также стоит помнить, что владелец группы может сделать её публичной или назначить ссылку для входа.

Доступ к аккаунту владельца. Telegram (как и любой другой мессенджер) достаточно уязвим со стороны клиента. Это НАИБОЛЕЕ уязвимое место в описанной выше системе.
Минимальные меры предосторожности:
— двухфакторная аутентификация (добавьте пароль в настройках Telegram)
— шифрование устройства (доступ к tdata чреват утечкой переписок)

Если что-то забыл — дополняйте :)

[gleberof]

Спасибо. Все правильно и по теме. Учтем кое-что.

[whunter]

Пожалуй добавлю. Как я говорил выше, для таргетированной атаки, при должных мерах безопасности — довольно муторно. Но. Давайте допустим что сервер с таким ПО не один, и не десять. Один поставил, настроил, забыл, уволился, итп — простые человеческие факторы. @botfather прекрасно отдаст контроль любому, кто представится подходящим номером телефона, а номера периодически меняют пополняя пул свободных для оператора. Таким образом арендовав скажем условные 1000 номеров за условные 30 копеек, можно простым брутом пощупать их на предмет подобного доступа.

[t0rr]

Этот риск значительно уменьшается двухфакторкой. Достаточно поставить годный пароль.
Если твой номер телефона перестанет быть актуальным и уйдёт в пул — новый владелец (в нашем случае — злоумышленник) не сможет зайти в аккаунт. Долго брутить придётся :)

[El_Kraken_Feliz]

Я у себя сделал отдельный allowlist по учётке телеграмм, плюс сами скрипты выполняются от имени пользователя sql, который имеет ограниченные права в самой бд. Так нет проблем с групповыми чатами — бот получает ид пользователя из чата и сразу отпинывает неугодных

[whunter]

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

[t0rr]

Так а что даст номер, если пароля к аккаунту нет?

Пример:
Берём Васю Пупкина на работу.
У него есть номер +х-ххх-ххх-хх-хх
Вася ставит в Telegram пароль qwerty12345
Вася меняет номер и не переносит туда свой телеграм
Васин номер попадает в продажу
Кевин покупает номер Васи за 30 копеек
Кевин открывает Telegram: «Введите пароль»
Если Кевин не подберёт пароль, то доступ к аккаунту он не получит.

[El_Kraken_Feliz]

Тут самый главный фактор утечки — украденный телефон, и там не только сообщения через чатик можно отправлять. По сути доступ к боту и бота к данным бд должны быть жёстко регламентированны
Есть вариант, что бот будет запускать только какие-то заранее подготовленные скрипты с какими-то параметрами, а пользователь только выбирает что ему надо, а не пишет запросы.

[whunter]

Есть также алтернативный фактор при котором оператор сливает длительно неиспользуемый номер. Решаемо теоритически элементарным PIN-кодом или контрольными вопросами, но здесь появляется дополнительная задача по возможности и методам его восстановления при появлении такой необходимости, причем так, чтобы это было безотносительно «симки».

[El_Kraken_Feliz]

учётка телеграм — это не только номер, номера как раз может и не быть

[whunter]

Я говорю про возможные векторы атаки, а не про то что в каком-то конкретно взятом случае это прокатит. В любом случае давать доступ к базе, упрощенно говоря, стороннему сервису — значительный риск, и дополнительные пути для злоумышленника

[gleberof]

В стеке технологий c MS SQL — как то не принят SSH и bash скрипты.

У нас инструмент для личного пользования. Бот настраиваеться на один чат при конфигурации. Из других ничего обрабатывать не будет.

Код в репо открыт — можно посмотреть как работает.

[vagon333]

В Jobs.sql вы создаете SQL Job.
Можно избежать.
Использую на любых редакциях SQL (включая Express, на котором вырезан SQL Job), решение через sp_procoption.
Типа:

EXEC sp_procoption @ProcName = N'spSys_AutoExecuteTasks'
    , @OptionName = 'startup'   
    , @OptionValue = 'on';  

[gleberof]

О спасибо! Но sp_procoption это разовый запуск на старте SQL. А у нам нужно регулярное выполнение. Вдобавок sp_procoption требует размещения процедуры в master — это как-то жестко.