Оригинал: https://www.amliesolutions.com/bubble/10-bubble-security-tips/
Один из самых частых вопросов, которые мы слышим от клиентов это: "Насколько же безопасен Bubble?". В этой статье постараемся разобраться с этим и сделать ваше Bubble приложение максимально безопасным для ваших пользователей.
Большинство приложений, которые мы используем каждый день, переместились с вашего компьютера в облако. Мы больше не храним наши контакты, рецепты, страницы дневников, проекты, задачи и журналы тренировок в файлах, а используем для этого отдельные сервисы или решения, которые оптимизированы для производительности, времени безотказной работы и безопасности.
По мере того, как развиваются технологии, мы начинаем видеть следующее: отсутствие кода делает разработку приложений настолько простой, что все больше и больше людей отказываются от готового программного обеспечения и вместо этого разрабатывают свои собственные инструменты. .
Это имеет смысл — зачем выбирать универсальный инструмент, когда можно создать его по той же или более низкой цене?
Хотя платформы без кода, такие как Bubble.io, достаточно просты в освоении, все еще остается вопрос, который задают многие новые пользователи: насколько безопасны данные, которыми управляет мое приложение?
Естественно, вопрос сводится к выбору фреймворка: безопасна ли Bubble как платформа? Короткий ответ: да , Bubble обладает отличной защитой, которую наследует ваше приложение (вы можете прочитать наше подробное руководство по безопасности Bubble ). , если вам интересно).
Но чтобы по-настоящему понять, что такое безопасность Bubble, нам нужно погрузиться немного глубже. Являются ли языки JavaScript, Python, PHP и Ruby безопасными? Большинство скажет, что вопрос не имеет смысла. Сам по себе язык не является безопасным , но позволяет создавать безопасные приложения, если вы скомпонуете правильные строки кода. В конце концов, безопасность зависит от разработчика.
Платформы без кода, такие как Bubble, в некоторой степени следуют той же логике. Он не будет настраивать безопасность вашего приложения для вас, но предоставит вам расширенный набор инструментов, чтобы сделать это самостоятельно. Ключевое различие между кодированием и отсутствием кода заключается в том, что первое требует от разработчика изучения сложных передовых методов для обеспечения безопасности данных, в то время как такие платформы, как Bubble, имеют в вашем распоряжении надежный набор функций безопасности. Важные решения принимаются от вашего имени, программное обеспечение постоянно обновляется с помощью последних обновлений безопасности, а сам Bubble полагается на другие сервисы, такие как Amazon и Cloudflare, для безопасного размещения и резервного копирования огромных объемов данных.
Тем не менее, сравнение с традиционным программированием имеет смысл: Bubble сочетает в себе гибкость и безопасность. Если бы платформа была слишком безопасной по умолчанию, она была бы слишком жесткой, чтобы позволить создание такого широкого спектра различных приложений. Чтобы предоставить вам как разработчику гибкость, вам разрешено устанавливать небезопасные приложения. Bubble предлагает мощные инструменты, чтобы избежать этого, но не заставляет вас их использовать.
Таким образом, мы можем сделать вывод, что даже если кривая обучения без кода намного мягче, это не означает, что кривой обучения нет . Bubble дает вам инструменты, но вы как разработчик должны использовать их правильно.
Спланируйте безопасность своего приложения на Bubble изначально
Первый пункт очевиден, но до сих пор часто упускается из виду. Создание приложений и структурирование вашей базы данных в визуальном редакторе Bubble может быть невероятно интересным и приятным занятием, но если вы сразу же приступите к созданию без планирования, вы обязательно сделаете ошибки, на исправление которых может уйти много времени.
Так что же означает планирование?
Планирование сводится к знанию того, какие вопросы вам нужно задать о вашем собственном приложении:
- Какими данными будет управлять мое приложение? Это конфиденциально? Общественные? Большинство приложений находятся где-то посередине: некоторые данные (например, статьи в газете или продукты в магазине электронной коммерции) должны быть общедоступными, в то время как другие виды (контактная информация пользователя и история покупок) должны оставаться строго конфиденциальными. Некоторые данные изменяются по мере прохождения через систему: сообщение в блоге может быть закрытым, пока оно является черновиком, но общедоступным после публикации.
- Чем мои страницы отличаются с точки зрения безопасности? Одна страница (например, ваша главная страница) может быть общедоступной, но другая (само приложение или панель управления) требует, чтобы пользователь вошел в систему, чтобы увидеть ее.
- Какие пользователи будут у моего приложения? Вы можете думать о пользователях, имеющих разные роли , и эти роли имеют разные разрешения. Некоторые роли существуют по умолчанию (например, пользователи вошли в систему или нет), в то время как другие настраиваются разработчиком (например, администраторы).
Мы вернемся к некоторым из этих вопросов позже в статье. А пока обратите внимание на самый важный момент: планирование необходимо для настройки безопасных приложений.
Защитите свою учетную запись Bubble
Задумывались ли вы о том, насколько безопасна ваша учетная запись Bubble? Если нет, сделайте это сейчас. Доступ к вашей учетной записи Bubble — это самая важная дыра в безопасности, которую вам нужно закрыть. Подумайте об этом — любой, у кого есть доступ, может внести любые изменения в любую версию (тестовую или рабочую) любого из ваших приложений. Это пугающая перспектива, которая заслуживает тщательного анализа, особенно если вы работаете с клиентами.
Итак, что это значит?
- Используйте безопасный пароль (длинная криптографически случайная строка)
- . Я настоятельно рекомендую использовать хранилище паролей, например www.1password.com. , для создания надежных паролей и их безопасного хранения.
- Используйте двухфакторную аутентификацию. Это значительно повышает безопасность вашей учетной записи.
Установите одинаковую политику для своей команды и клиентов
Цепь настолько прочна, насколько прочно ее самое слабое звено. Если вы уверены, что ваша собственная учетная запись теперь в безопасности, имейте в виду, что она должна распространяться на каждого члена вашей команды. Установите четкую, понятную политику безопасности и применяйте ее, чтобы вы могли быть уверены, что ни один злоумышленник не сможет использовать одно слабое звено.
Если ваши клиенты в какой-то момент имеют или будут иметь доступ к приложению самостоятельно, предположите, что они не знают о важности безопасности в целом. Будьте серьезным фрилансером/агентством и хорошим консультантом и сообщите им о важности надежной политики безопасности учетной записи и о том, какие именно последствия могут быть, если злоумышленник получит доступ.
Установите четкую и систематизированную политику сотрудничества
Функция Collaborator невероятно полезна. Это позволяет вам привлечь фрилансера, коуча, клиента или заинтересованного лица и предоставить им прямой доступ к редактору. Но, как и ваша учетная запись, она сопряжена с очевидными угрозами безопасности. Уровень доступа, который вы предоставляете соавтору, должен основываться на четкой политике, и эта политика должна основываться на одном простом правиле:
Ни один соавтор никогда не должен иметь доступ ни на один байт больше, чем ему нужно для решения вашей проблемы.
Давайте посмотрим, что это означает на практике:
- Никогда не предоставляйте своим соавторам права администратора, если для этого нет особой причины.
- редко есть _ требуется доступ к активной версии вашего приложения
- Доступ для записи в базу данных может быть, но не по умолчанию .
- Подумайте о журналах/запросах: дадут ли они вашему сотруднику доступ к личной информации?
Возьмите за привычку предоставлять соавторам минимальный уровень доступа, который, как вы знаете, им необходим, а затем предоставлять дополнительные разрешения, если возникает необходимость.
Наконец, самая большая уязвимость с соавторами обычно заключается не в том , чтобы добавить их, а в том, что они остаются рядом . Сделайте свою политику безопасности такой, чтобы знать, когда снова удалять соавторов. При необходимости используйте систему задач или события календаря.
Следите за настройками своего приложения, чтобы обеспечить безопасность Bubble.
Теперь, когда ваша учетная запись защищена и у вас есть контроль над соавторами, пришло время взглянуть на настройки самого приложения.
Самая основная часть безопасности вашего приложения устанавливается на вкладке « Настройки » редактора Bubble. Давайте быстро пробежимся по наиболее важным потенциальным уязвимостям.
- Установите права доступа к редактору для частного приложения .
- Установите для параметра Ограничить доступ к этому приложению в режиме запуска с именем пользователя и паролем значение « Да » , чтобы приложение оставалось между вами и тем, у кого должен быть доступ.
- Измените имя пользователя и пароль по умолчанию
- Если вы подключились к домену, всегда включайте шифрование SSL
- Отключите функции API, которые вы не используете, и не включайте какие-либо типы данных в API данных, к которым вы не хотите предоставлять доступ.
Выполнив все основные настройки приложения, давайте взглянем на сторону разработки .
Поймите разницу между клиентской и серверной частью
Эти два термина говорят сами за себя, но, поскольку они оказывают огромное влияние на безопасность приложений, давайте рассмотрим их значение, чтобы избежать недоразумений.
Ваше приложение состоит из двух географически разделенных частей: клиента (то есть устройства пользователя) и сервера (компьютера, на котором хранится ваше приложение). Все, что происходит на устройстве пользователя, описывается как происходящее на стороне клиента, а все, что происходит на сервере, происходит на стороне сервера .
Короче говоря, все, что происходит на стороне сервера, считается безопасным, а все, что происходит на стороне клиента, считается небезопасным . Почему? Ну, потому что все, что происходит на клиенте, контролируется клиентом. Это означает, что им можно манипулировать: хакер может взять любой фрагмент данных или процесс и внести в него изменения, поскольку все это находится на его ноутбуке.
Следуя этому ходу мыслей, вы можете спросить: значит ли это, что вся моя страница небезопасна? И ответ, в принципе, да . Все, что достигает устройства пользователя, потенциально небезопасно, в том числе все, что видно и не видно на вашей странице.
Подождите… разве это не делает все мое приложение небезопасным? Нет — имейте в виду, что все, что находится на сервере , совершенно безопасно. Хитрость заключается в том, чтобы предотвратить попадание информации, к которой у пользователя не должно быть доступа, на устройство пользователя. Вот почему мы используем правила конфиденциальности для защиты базы данных; потому что это гарантирует, что часть информации из базы данных никогда не достигнет устройства, если пользователь не аутентифицировался и не авторизован для доступа к ней. Мы вернемся к этому позже.
Другие данные, которые достигают страницы
Чтобы приложение заработало, в браузер нужно загрузить множество вещей. Изображения, шрифты, видео — все это необходимо передать с сервера клиенту, чтобы использовать для чего угодно.
Но это не все. Движок Bubble разделен на две части: одна находится на сервере и выполняет всю работу, связанную с базой данных. Другой — это файл, сохраненный на устройстве пользователя. Эти двое постоянно общаются, чтобы убедиться, что все работает. Например, когда ваш пользователь нажимает кнопку, механизм на устройстве отправляет команду механизму на сервере, чтобы сообщить ему, что делать.
А о чем мы договаривались раньше? Что все, что попадает на страницу, небезопасно. Что это значит в данном случае? Bubble, конечно, продукт без кода , но сам Bubble написан в коде: JavaScript, если быть точным. Это означает, что движок, который находится на устройстве пользователя, представляет собой файл javascript, полностью читаемый любым, кто загружает его, открывая ваше приложение. Это не проблема само по себе, но есть несколько вещей, о которых вы должны знать. Этот код содержит много информации о вашем приложении, о которой вы можете не знать:
- Названия всех страниц
- Имена всех элементов и рабочих процессов
- Данные и имена инициализации API-коннектора
- Все наборы опций и их содержимое
- Имена всех ваших типов данных, полей и значений по умолчанию
- Названия стилей и информация
Это не все , что содержится в файле Javascript; вы можете найти файл с помощью инструментов разработчика Chrome и проверить его, если хотите. Вы можете ознакомиться с нашим руководством по инструментам разработчика Bubble и Chrome , если хотите узнать больше.
Научитесь использовать правила конфиденциальности
Правила конфиденциальности определяют, к каким данным в вашей базе данных разрешен доступ одному конкретному пользователю. Например, одно правило конфиденциальности может указать Bubble, что только один тип пользователей (зарегистрированные пользователи) может загружать один тип данных (рецепты еды). Другой может сделать так, чтобы один Пользователь мог загружать только те рецепты блюд, которые он сам создал.
На сервере применяются правила конфиденциальности , что означает, что данные хранятся в полной безопасности, поскольку они никогда не покидают зашифрованный жесткий диск облака Amazon AWS. Они также применяются во всем приложении, что означает, что если вы настроите их один раз, они будут применяться везде.
Правила конфиденциальности — это основа безопасности вашего приложения, и нельзя сказать яснее, чем это: без них ваши данные не в безопасности. Чтобы узнать о них больше, вы можете ознакомиться с нашим бесплатным подробным руководством по правилам конфиденциальности Bubble .
Использование условий на стороне сервера в рабочих процессах
Ваше приложение состоит из рабочих процессов и действий: это механизмы, которые поддерживают работу вашего приложения. Они сообщают Bubble, что делать, когда пользователь взаимодействует с элементами на странице, например, сохранять что-то в базе данных или переходить на другую страницу.
Чтобы остановить выполнение рабочих процессов и действий, если не выполняются определенные требования, мы используем условия . Это способы указать Bubble запускать это действие только в том случае, если это условие истинно.
Bubble должен быть в состоянии подтвердить условие на сервере , чтобы быть безопасным. Другими словами, условие не может полагаться исключительно на то, что происходит на странице, но в оптимальном случае должно иметь возможность проверять данные, хранящиеся в базе данных. Почему? Потому что страница небезопасна: ею может манипулировать опытный хакер. С другой стороны, база данных хранится в надежно зашифрованном виде вдали от досягаемости хакера.
Что это означает на практике? Проверка того, виден элемент или нет , происходит на странице. Проверка того, является ли текущий пользователь администратором, происходит на сервере. Логика последнего заключается в том, что условие опирается на информацию, хранящуюся в базе данных. Мы знаем, что целостность базы данных постоянна и что информация зашифрована, поэтому мы можем доверить Bubble проверку этой информации в месте, недоступном для хакера.
Всегда полагайтесь на данные, которые можно проверить в базе данных для условий, которые должны быть безопасными.
Настройте чеклист развертывания
Момент, когда вы развертываете свое приложение, — это когда вы наиболее уязвимы. Это точка, с которой ваши живые пользователи увидят все изменения, внесенные вами с момента последнего развертывания. Большинство разработчиков не следят за всеми изменениями, которые они вносят между циклами развертывания. Это вполне понятно: без кода работать так быстро, документирование всего в документе или инструменте управления проектами часто занимает больше времени, чем сама работа.
Мы можем быть отличными разработчиками, но мы также и люди: мы что-то упускаем и забываем. Вот почему так важен хороший контрольный список. Держите его в рабочем состоянии и редактируйте по мере необходимости.
Следующий список ни в коем случае не является исчерпывающим, так как все проекты разные. Но это дает вам представление о том, как может выглядеть контрольный список:
- Тщательно протестируйте все новые функции
- Дважды проверьте правила конфиденциальности
- Протестируйте приложение под разными типами пользователей (вошедшие в систему/не вошедшие в систему/разные роли пользователей).
- Удалите тестовые страницы
- Удалите пользователей-сотрудников приложения
- Запустите App Optimizer
- Удалите данные инициализации из коннектора API
Настройте политику, настройте ее по мере необходимости и никогда не пропускайте ее. Поспешное развертывание, открывающее уязвимость в системе безопасности, может иметь последствия, которые намного перевешивают важность быстрого запуска функций.
Использовать autobinding
Когда вы вносите изменения в свою базу данных на основе ввода пользователя, эти изменения можно внести двумя способами: вы можете сохранить их с помощью действий или сохранить с помощью autobinding . autobinding означает, что всякий раз, когда поле ввода теряет фокус, Bubble сохраняет его содержимое в базе данных.
Автоматическая привязка более безопасна, чем действия? Технически нет. Но у них есть преимущество в том, что они уменьшают общую зону риска ошибок со стороны разработчиков. Позволь мне объяснить:
Любое действие, которое вносит изменения в базу данных, может быть защищено таким условием , как Только при входе текущего пользователя . Это безопасно? Да. Bubble проверит это на сервере, прежде чем позволит завершить действие.
Но это условие нужно будет настроить для каждого действия, которое вносит эти изменения. Разработчик может забыть об этом одним действием. Случайно изменить его. Случайно удалить. Это обеспечивает большую область ошибок, поскольку разработчику нужно отслеживать больше рабочих процессов. Это также означает, что если ваши правила безопасности изменятся, это изменение необходимо будет внести в ряд различных действий, что опять же приведет к человеческой ошибке.
Чем отличается autobinding? Им можно управлять с помощью правил конфиденциальности. Это означает, что вам нужно установить правила только в одном месте, и они будут применяться ко всему вашему приложению. Это быстрее, дает меньше места для ошибок и, в конечном счете, более безопасно (даже если оба метода обеспечивают одинаковую техническую безопасность).
Означает ли это, что вы всегда должны выполнять autobinding и никогда не использовать действия? Нет, имейте в виду, что безопасность — не единственная ваша забота. Существует множество сценариев, в которых кнопка «Сохранить», прикрепленная к рабочему процессу, является лучшим вариантом с точки зрения UX. Но, зная последствия для безопасности, вы можете в каждом случае принимать взвешенное решение, чтобы сбалансировать масштаб безопасности и UX.
Настройте редиректы на стороне сервера
Всякий раз, когда пользователь пытается получить доступ к странице, на которую ему не должно быть разрешено, вы используете перенаправление, чтобы удалить его с этой страницы. Например, если пользователь платформы управления проектами пытается получить доступ к своей информационной панели, не войдя в систему, вы обычно направляете его на страницу входа.
Возможно, вы не знаете, что на самом деле существует два вида перенаправлений: на стороне сервера и на стороне клиента. И, как обычно, то, что происходит на сервере, более безопасно.
Перенаправления на стороне сервера
На практике перенаправления на стороне сервера означают, что когда пользователь пытается получить доступ к определенной странице, сервер блокирует доступ и отправляет пользователя на другую страницу до того, как страница успеет загрузить один байт. Это означает, что никакая информация о странице никогда не отправляется в браузер и все время надежно хранится на сервере.
Перенаправления на стороне клиента
Перенаправления на стороне клиента происходят на устройстве пользователя. На практике Bubble запускает в браузере фрагмент кода Javascript, который указывает браузеру открыть другую страницу. Следствием этого является то, что страница должна быть загружена, чтобы это произошло, открывая злоумышленнику возможность остановить этот процесс или получить доступ ко всем данным, которые были отправлены в браузер во время загрузки.
Чтобы было ясно: используя правила конфиденциальности, ваша страница уже должна быть защищена. Там не должно быть личной информации, которую мог бы найти любой хакер, даже если страница загружается.
Но безопасность заключается в том, чтобы сделать все как можно сложнее для хакера. Доступ к странице может дать им некоторую информацию, которую они могут использовать для чего-то другого. Это также дает вам еще один уровень безопасности, если вы совершите ошибку, например, неверную настройку правила конфиденциальности. Так что давайте вообще их не пускать.
Что их разделяет? Bubble в основном будет пытаться выполнить перенаправление на стороне сервера всякий раз, когда это возможно (это также метод с наименьшими затратами с точки зрения производительности). Но иногда страница настроена так, что для перенаправления требуется, чтобы страница была загружена, прежде чем ее можно будет выполнить. Это зависит от того, как вы настроили действие для начала. Простой рабочий процесс, подобный показанному ниже, почти всегда выполняется на стороне сервера:
Но если вы выберете другой тип события или начнете добавлять более сложные условия в рабочий процесс, Bubble может быть вынужден загрузить страницу, прежде чем он сможет определить, запускать ли рабочий процесс.
Как определить тип перенаправления вашей страницы
То, как страница перенаправляется, определяется в протоколе HTTP, который является линией связи между браузером и сервером. Успешно выполненная переадресация на стороне сервера будет иметь код состояния 302 , что означает, что сервер сообщает браузеру, что страница временно перемещена.
Если вы получите ответ 200 , это означает, что страница не перенаправлялась. 200 на самом деле не означает перенаправление на стороне клиента: это означает, что страница была успешно загружена. А потом его перенаправили, независимо от кода состояния. Вы можете проверить свою страницу с помощью средства проверки статуса , такого как 301 Redirect Checker от SureOak.
Проектирование для безопасности Bubble
Безопасность касается не только технических аспектов вашего приложения. Это также означает, что вам нужно подумать о том, как устроено ваше приложение.
Например, почему пароли не отображаются на экране, а просто заменяются звездочками типа ****? Ответ, конечно, очевиден: разработчики давно поняли, что пользователей нужно защищать от самих себя. Компьютеры, планшеты и телефоны используются в самых разных местах: в офисе, в парке, в аэропорту и в местном Starbucks. Если бы пароли отображались в виде обычного текста, каждый год миллионы паролей были бы украдены просто хакерами, заглядывающими через плечо пользователя, когда тот его вводит.
Это решение, конечно, принимается за вас. Но задумывались ли вы когда-нибудь о том, как другие дизайнерские решения могут повлиять на безопасность?
- Что именно вы показываете на экране, как только пользователь вошел в систему?
- Вы раскрываете личную информацию? Если ваше приложение обрабатывает конфиденциальные данные, подумайте, что именно вы отображаете через секунду после того, как пользователь вошел в систему. Подумайте о том, чтобы позволить пользователю выбирать , отображать информацию или нет, например, потребовав еще один щелчок мыши.
- Есть ли в вашем приложении информация, требующая дополнительной защиты?
- Если вы храните конфиденциальную информацию, такую как номер социального страхования или ключ API, вы можете попросить пользователя войти в систему еще раз, чтобы доказать, что он тот, за кого себя выдает. Еще раз проверьте пароль, чтобы избежать утечки данных, потому что пользователь отошел от экрана на несколько минут.
- Должен ли пользователь выйти из системы через некоторое время?
- По умолчанию пользователи будут входить в систему в течение некоторого времени (12 месяцев) после входа в систему. Если ваше приложение обрабатывает конфиденциальные данные, вы можете принудительно сократить время выхода из системы.
Это всего лишь несколько примеров проектирования с учетом конфиденциальности. Если ваше приложение имеет тысячи или даже миллионы пользователей с течением времени, предположите, что они будут подвергать свои ноутбуки и телефоны всевозможным рискованным ситуациям. Будьте хорошим разработчиком и закройте для них это окно.
Вывод
Безопасность Bubble — зависит от вас как разработчика. Вам разрешено настраивать приложения, которые вообще не являются безопасными — вот что дает вам гибкость. Это означает не то, что Bubble небезопасен, а то, что ваша работа как разработчика — узнать как можно больше о потенциальных проблемах безопасности, чтобы вы могли принимать обоснованные решения при разработке отличных приложений.
Парадокс в том, что трудно знать то, чего ты не знаешь. Вот почему так важно искать информацию, спрашивать опытных экспертов и общаться с командой Bubble, чтобы выявить эти недостатки. Не расстраивайся из-за этого. В этой жизни нет ни одной вещи, которую я знал до того, как узнал. Вот что такое обучение.