Леонид Каганов: дневник

Чтобы ваш блог тоже дублировался в канал Telegram (как в ЖЖ, Фейсбук, ВКонтакт, Твиттер, Инстаграм) надо обновить движок с lleo.me/dnevnik и дописать в «редактор переменных» — «autopost» строку вида:

telegram template.telegram lleodnevnik 284151432:AAEZ5fjLlBPU3noQp3eRtc25m6bDkmSsCf4

Где template.telegram — имя шаблона «редактор переменных»->«template.telegram».
lleodnevnik — название вашего канала

остаток строки — API-ключ к вашему Telegram-боту, которому вы дали админские права делать посты в вашем канале. Канал и бота надо соответственно создать. Как это сделать — подробно описано во всех инструкциях к Telegram.

Напоминаю, что мой движок в плане постинга зеркал — единственный в мире трансляционный движок, который позволяет не только постить, но удалять и автоматически заменять пост во всех соцсетях при внесении изменений (исправлении опечаток) в оригинальную публикацию.

А вот постинг фоток в Яндекс-фотки я советую убрать из списка «autopost»: в ближайшее время Яндекс собирается это сервис отключать. Как он будет устроен в новой версии, мы точно не знаем, но фотки на Яндексе, даже если будут загружаться, станут недоступны по внешней ссылке.

Также я освоил написание Telegram-ботов, это вообще оказалось не сложно. При этом нашел две интересные фичи, связанные с безопасностью. Во-первых, оказывается, что большинство Telegram-ботов построены на callback-схеме (она ведь самая удобная), но никак не защищены от прямого захода по https любого постороннего человека. По крайней мере, в документации Telegram ни слова о советах по такой защите. Напротив: советуют тестировать и отлаживать своего бота прямой засылкой данных по https. Обычно в трехстороннем протоколе используется сложная авторизация — callback приносит не данные, а лишь тикет, с которым твой сервер должен сам сбегать именно на сайт.com и тогда только получить данные. Здесь же данные летят напрямую, и злоумышленнику никто не мешает ходить к вам и изображать поток данных. Ну, положим, в своем движке я сделал проверку на IP от Telegram. Но ведь Telegram-боты — это сегодня огромное поле деятельности, в том числе и для бизнеса. И строят на них не только игрушки и дурацкие фокусы типа «спроси про погоду или курс доллара и мы тут же пришлем ответ», но системы работы с клиентами, базы коммерческих заказов и всё такое. Причем, я сильно подозреваю, что разработчики берут для работы с API стандартные фреймфорки и библиотеки (полистал я их, это конечно позор, потому что там необходимого кода на 20 строчек от силы), а у этих библиотек, вполне возможно, callback-скрипт лежит на сайтах по стандартным адресам. И есть у меня подозрение, что в этом случае можно выяснить сервер нахождения бота, тупо вломиться со стороны и, как минимум, заказать пиццу или такси в час ночи всем сотрудникам вашей компании...

Другая интересная штука по проблеме IP связана с CloudFlare. Кто не в курсе — http://cloudflare.com бесплатно дает не только защиту от атак, кэширование и маскировку реального IP, но https-доступ. Поэтому за ним уже полмира сидит, и мой сайт lleo.me тоже. В реальности посетитель ходит на lleo.me через IP CloudFlare (в том числе по https), а тот в роли честного man-in-the-middle быстро связывается с моим сайтом по http и выдает посетителю результат как бы от себя. Для посетителя это незаметно. Всё бы прекрасно, но возникает вопрос: а как мне на своем сайте определить IP посетителя? Реальный REMOTE_ADDR, который я вижу со стороны своего сервера, — это IP CloudFlare, причем он ещё и бывает разный. Реальный IP посетителя CloudFlare мне сообщает сам, устанавливая дополнительные переменные HTTP_X_FORWARDED_FOR и HTTP_CF_CONNECTING_IP. В принципе, я их могу тупо брать, но проблема здесь та же: любой хакер может узнать реальный адрес моего сервера и отправиться туда в обход CloudFlare, подделав в этих переменных любой IP. Если ты на своем сайте делаешь что-то, завязанное на конкретные IP (какой-нибудь там админский доступ или прием данных от доверенных источников), то тупая замена REMOTE_ADDR на HTTP_X_FORWARDED_FOR после переезда за CloudFlare может обернуться большой дырой в безопасности. Выход — например, проверять, соответствует ли REMOTE_ADDR диапазону адресов CloudFlare. Но это задача трудно реализуемая, потому что у этого долбанного CloudFlare немыслимая куча самых разношерстных адресов. Вот только для примера я поставил ловилку и насобирал в логах за пару минут такие диапазоны:

CloudFlare: 108.162.192.0 — 108.162.255.255
CloudFlare: 141.101.77.0 — 141.101.77.255
CloudFlare: 141.101.96.0 — 141.101.103.255
CloudFlare: 141.101.104.0 — 141.101.111.255
CloudFlare: 162.158.0.0 — 162.159.255.255
CloudFlare: 172.64.0.0 — 172.71.255.255
CloudFlare: 173.245.48.0 — 173.245.63.255
CloudFlare: 198.41.128.0 — 198.41.255.255

PS: Говорят, у CloudFlare есть «ссылка актуальных адресов» https://www.cloudflare.com/ips-v4 Но переводить их в человеческий формат и оперативно сравнивать с имеющимся REMOTE_ADDR — то еще удовольствие на PHP.