Порабощение на практике

В этом цикле статей о сфере информационных технологий в общем и технологиях Интернет в частности автор уже не раз упоминал, что это не дружелюбная песочница с куличиками, а поле битвы информационной войны не на жизнь а насмерть, и что Интернет существует не для пользователей, а для крохотной горстки баснословно богатых монополистов и их друзей в гос-структурах. Это находит выражение не только в правилах и практиках поведения владельцев и администраторов различных ресурсов, но и на более фундаментальном уровне: в самих технологических решениях, лежащих в основе Интернет. Прежде в статьях цикла рассматривались файлы «куки» и другие явления. В этот раз будет рассмотрена т.н. маршрутизация, в какой-то момент получившая широкое распространение в Интернет-приложениях.

Маршрутизация — это такое поведение приложения и браузера, при котором поведение приложения полностью определяется путём в адресной строке. Даже если приложение состоит из разрозненных файлов, как в случае с языками вроде PHP, Python, Perl и т.д., их имена не используются для подачи и обработки запросов и не отображаются в ней. Казалось бы, что не так с практикой соотнесения пути в адресной строке с сущностями и их обработчиками в приложении? Для разработчика — всё замечательно! Он получает в своё распоряжение стандартный способ обработки запросов. Для пользователя в принципе ничего не изменилось, и ему всё равно. Но всё же есть одна категория лиц, которых не спросили, и интересы которых оказались нарушены: это владельцы ресурсов, устанавливающие Интернет-приложения и использующие их в своей коммерческой, общественной, государственной или иной деятельности.

Дело в том, что приложения, использующие технологию и принцип маршрутизации, больше не подчиняются воле владельца или администратора. Они выполняют лишь волю разработчика. Как так? В т.н. приложениях, высокомерно названных «устаревшими» этими же разработчиками, которые не использовали маршрутизацию, именно владелец или администратор контролировал доступ к частям приложения. Он мог запретить или разрешить его для всех или для отдельных пользователей при помощи конфигурационных файлов безопасности своего веб-сервера. На практике это работает так: в определённой папке администратор в соответствии со своими соображениями, политикой безопасности или другими правилами создаёт файл, в котором разрешает или запрещает доступ по адресам пользователей.

Почему это важно? Потому что не все приложения одинаково полезны, и в них встречаются недочёты, которые разработчики или не хотят устранять вообще или не торопятся. Также может возникнуть масса других причин для администратора ресурса управлять доступом. Маршрутизация лишает его такой возможности, потому что за маршрутом нет физического пути из папок на сервере, в которых можно было бы разместить файлы конфигурации безопасности. А это в свою очередь важно, потому что ПО не совершенно, особенно бесплатное с открытым кодом, и для начала существуют уязвимости, которые, может быть, придётся в аварийном режиме устранять владельцам ресурсов, пока разработчики мычат да телятся. Технология маршрутизации лишила владельцев и администраторов такой возможности.

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

Да, эта технология без сомнения гениальна! Её придумал настоящий гений. С её помощью можно выразить одним путём в адресной строке правила обработки запросов в приложении. Вот только об интересах потребителя ПО никто не подумал или подумал, но усмехнулся и молча продолжил её внедрять. Прежде для их соблюдения им достаточно было создать простой текстовый файл в определённой папке, а теперь для этого требуется модифицировать исходный код приложения. Стоимость этих двух мероприятий несопоставимая: первое почти ничего не стоит и находится полностью в ведении потребителя, тогда как второе скорее всего будет ему не по карману и находится в ведении разработчика.

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

В следующий раз, когда пресса будет ныть по поводу очередного взлома какого-нибудь Интернет-приложения, вспомните эту статью и усмехнитесь про себя. Все технологии, приёмы, меры, практики и правила обеспечения безопасности уже давно существуют. Если их настойчиво и продуманно применять, то приложения станут неуязвимыми ко взлому. Если это не происходит, значит, это кому-то очень нужно. При желании несложно определить, кто принял и одобрил то или иное небезопасное решение. Осталось только вывести их на плац.