Безопасный Код

Безопасное программирование — необходимость, которую необходимо соблюдать всегда, будь то десктопное или веб-приложение. Цель написания статьи — это желание поделиться с разработчиками своими мыслями и опытом по безопасности, которые стараюсь соблюдать при разработке.

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

При разработке, мы (разработчики) часто пользуемся интернетом для быстрого поиска информации для решения задач. Мы часто копируем чужой код, как говорится «зачем придумывать велосипед?» или «тяп ляп и в production». Узнали себя? Значит читаем дальше. Часто ли вы видите на веб-сайте скрипты, не принадлежащие ему? Для более быстрой разработки, программисты используют уже готовые решения и это неплохо. НО! Многие забывают проверять этот самый код на безопасность/баги, из-за чего могут пострадать пользователи вашего приложения и неважно, десктопное оно или веб. Возьмем пример (рис.1).

Рис.1 импортирование скрипта<br />
Рис.1 импортирование скрипта

И так мы видим типичный случай, когда программист использует популярную библиотеку на сайте. Этот скрипт из библиотеки всем известного фреймворка jquery и импортируется он напрямую (тянется с сайта). Это значит, что работа скрипта может быть изменена без ведома администратора/разработчика сайта. То, что можно сделать с сайтом злоумышленник или любой другой кто хочет как-то навредить, ограничивается лишь функционалом языка JavaScript. Например, закинуть скрипт с Beef Framework и переворачивать ваши ярлыки, или устроить хранимый xss прямо на главной странице, с последующим получением рут доступа к серверу где хранится весь код, а там уже и БД для авторизации оказалась, и история вашего браузера (и объясняй потом маме, зачем ты пытался скачать видеокарту и как словил «блокировщик» в виде порнобаннера). Чтобы безопасно импортировать скрипты достаточно установить библиотеку себе на устройство и уже без риска удаленного изменения кода использовать framework и все его возможности. Возможность изменения кода во framework’е остается только при обновлении библиотек, поэтому тщательно проверяйте то что вы обновляете. Импортирование технологий из других сайтов может плохо отразиться на работе вашего сайта, а то и вовсе привести к компрометации данных. Даже если библиотека/сервис/приложение вызывает у вас доверие, это не означает того, что оно безопасно и не может быть взломано/скомпрометировано. Возьмем в пример Twitter. 15 июля 2020 года были взломаны аккаунты популярных и влиятельных людей (Илон Маск, Билл Гейтс и др.). Доступ к этим аккаунтам был получен через администрацию сайта. Данный пример отлично подходит для нашего случая, т.к. через администрацию этого framework можно получить доступ к любому приложению, которое использует данную библиотеку напрямую или обновляет его не глядя, что именно обновляет.

Не уходя далеко от темы почему важно проверять обновления даже известных frameworks. В 2022 году, разработчик программного обеспечения Брэндон Миллер загрузил в формате открытого кода пакеты peacenotwar и oneday-test, они были замечены на Github’e и на NPM. Изначально они были написаны для политического протеста по сами понимаете какой ситуации. При запуске, данные пакеты загружали на рабочий стол своих жертв, установивших их, призывы к миру. Также, стоит упомянуть, что в последний версии популярной библиотеки node-ipc, которая также сопровождается RIAEvangelist, Миллером были загружены не менее разрушительные пайлоды, с целью деструктива всех данных и/или перезапись файлов пользователей. Этот «зловред» получает внешний IP-адрес хоста, на котором был запущен, проверяет пул полученного адреса, в последствие чего, удаляет данные пользователей, если они находятся в России и/или Беларуси. Импортирование библиотек напрямую может быть не только во фронте, но и в бекэнде. Поэтому тщательно проверяйте обновления и чужой код, если собираетесь его использовать.

Второе, чем хотелось бы поделиться, это использование iframe. При использовании этой технологии, можно вставлять кусок чужой страницы к себе на страницу. Например, вы хотите вставить себе на страницу в какой-либо блок html видео с «youtube.com». Вы простым движением пальцев, вставляете в iframe это видео, и оно отлично отображается. А если поместить уязвимый код в тег iframe? Ответ простой и банальный, вы поместите уязвимый код к себе на сайт, после чего, через этот самый код можно атаковать ваше приложение. Также, опасность этого тега в том, что, как и в вышеупомянутом примере, кусок кода, который помещен в тег iframe может изменяться без ведома администратора/разработчика, т.е. этот код изменяется на входном сайте и соответственно меняется и у вас. Риски остаются такими же, как и в примере со скриптами. Даже если поместить iframe в тег noscript, то остается риск дефейса (если простыми словами, то случай, когда меняется содержимое html страницы и соответственно, его вывод). Поэтому прежде чем использовать чужой код у себя на странице, стоит подумать несколько раз. Возможно переписать или хотя бы скопировать код в данном случае будет надежнее, пусть и займет у вас немного больше времени.

Обычно в конце подводят итоги (aka заключение/умная мысль/краткий пересказ). Проверяйте чужой код, если вы хотите его забрать себе или как-то использовать, ведь даже самая маленькая его часть может нанести вред пользователям или стать причиной взлома вашего приложения, и повторюсь в который раз, неважно десктоп это или веб. Даже если библиотека/сервис/приложение и т.д. вызывает у вас сто процентное доверие, провейте код на наличие уязвимостей, багов, подвергайте сомнению его безопасность, или «швейцарскую» работоспособность. Только не превращайтесь в безумца параноика, который не доверяет никому и ничему. Доверяй, но проверяй, везде нужен баланс. Однако стоит вспомнить русскую пословицу «хочешь сделать-сделай сам». Надеюсь кому-то помог, спасибо.

11
Начать дискуссию