Годы поддержки плагина WordPress научили меня плохой привычке. Клиент отправляет вам сломанную серийную крупную крупную крупную крупную крупную крупную крупную крупную крупную в то время, так что вы вставляете его в первый онлайн-унсериализатор, который дает вам Google. я делал это долгое время, не задумываясь об этом - до того дня, пока не посмотрел, что только что вставил I'd. Это был клиент и#39;s wp_options экспортный Он содержал их пароль SMTP, ключ API MailChimp и лицензионный ключ. Все это только что было отправлено на сервер, о котором я ничего не знал, которым управляет кто-то, кого я не мог назвать, в стране, о которой я не мог догадаться.
Насколько я знаю, ничего плохого не произошло. Это's тревожная часть - у меня нет возможности узнать. Там's нет уведомления для "ваша вставка вошла в журнал." Данные либо находились в ком-то's, либо обращались к журналам, либо это было't, и я' никогда не узнаю, что.
Этот инцидент является большой частью того, почему Toolz.dev работает так, как он работает Каждый из 50 инструментов на сайте обрабатывает ваш ввод в вашем браузере. Not & quot;мы обещаем, что удалим его после обработки & quot; - он никогда не передается в первую очередь.Это руководство объясняет разницу между этими двумя архитектурами, почему это имеет большее значение для разработчиков, чем для почти кого-либо еще, и как проверить инструмент & #39;s утверждает себя примерно за 30 секунд. И, поскольку я в конечном итоге вставил эту каплю клиента где-то безопасно, PHP несериализатор Это заменило мою дурную привычку.
TL;DR: Серверные инструменты передают ваш ввод кому-то другому's машина, где он может быть зарегистрирован, сохранен, взломан или совместно используется - и вы можете't проверить что-либо из этого. клиентские инструменты отправляют вам код и обрабатывают все локально; проверка занимает одну проверку вкладки DevTools Network. Для чего-либо, содержащего учетные данные - JWT,
wp-configзначения, строки соединений, ответы API - используйте инструменты на стороне клиента, такие как Форматтер JSON, JWT декодер, Форматтер SQL, и Валидатор YAML, йо- все на Toolz.dev Запускается в браузере.
Что на самом деле происходит, когда вы вставляете онлайн-инструмент?
Существует ровно две архитектуры, и каждый онлайн-инструмент использует одну из них.
Серверная сторона: Ваш вход переходит из вашего браузера на сервер инструмента, там обрабатывается, и результат возвращается обратно. Пять шагов, и ваши данные существуют в чужой инфраструктуре в течение трех из них.
Your browser → network → their server → network → your browser
(input) (transit) (processing, (transit) (result)
logging?,
retention?)
Клиентская сторона: ваш браузер загружает инструмент's JavaScript один раз, и тогда все - ввод, обработка, вывод - происходит на вкладке на вашем компьютере Единственное, что когда-либо пересекало сеть, это код.
Their server → your browser
(code) (input + processing + result, all local)
Различие звучит академично, пока вы не перечислите, что может случиться с данными на сервере, который вы делаете 't control.It может приземлиться в журналах доступа и журналах приложений.It может быть захвачен трекерами ошибок, как Sentry, которые snapshot request контекст, когда что-то бросает.It может быть сохранен в резервных копиях долго после оператора & quot;deleted& quot; it.It может быть прочитан любым сотрудником с доступом к журналу.It может быть сметен в брешь.And с несколькими & quot;free tool& quot; операторы, это может быть фактический продукт - монетизированный через аналитику или продаваемый как обучающие данные.
Ни один из них не требует злобы. Большую часть этого сделают только конфигурация ведения журнала по умолчанию. Оператор того несериализатора, который я использовал, вероятно, никогда не смотрел на пароль SMTP моего клиента. Но «вероятно» — это не официальная защита.
Почему это более важно для разработчиков, чем для кого-либо еще?
Из-за того, что мы вставляем. Средний пользователь вставляет абзац текста в счетчик слов. Пасты разработчика:
Ответы API с помощью токенов Live. Вы 'отлаживаете интеграцию, копируете весь ответ - включены заголовки - и форматируете его для чтения. Это Authorization: Bearer ... Заголовок просто пошел туда, где живет форматтер. Гитгард Состояние секретов исследования обнаружили около 12,8 миллионов секретов, раскрытых в публичных GitHub-коммитах только в 2023 году. Никто не публикует эквивалентные номера для онлайн-инструментов, потому что, в отличие от GitHub, операторы инструментов ' журналы aren't публично сканируются. Это's не успокаивает - это означает, что поверхность утечки невидима.
юсти Веб-токен JSON закодирован по принципу base64url, а не зашифрован - RFC 7519 явно об этом. Полезная нагрузка каждого токена, который вы вставляете в декодер на стороне сервера, передает идентификатор пользователя, электронную почту, роли и срок действия. Если токен все еще действителен, вы потенциально передали учетные данные рабочей сессии. расшифровать их локально с помощью JWT декодер вместо этого.
SQL с реальными данными в нем. Запрос, который вы форматируете, имеет WHERE email = '[email protected]' в нем и имена таблиц нарисуют всю вашу схему. выше Форматтер SQL Сохраняет это на вашей вкладке.
конфигурационные файлы. wp-config.php значения, .env Содержание, манифесты Kubernetes, database.yml- конфигурация - это место, где живут учетные данные. I've проверил файлы YAML, содержащие все секреты моего приложения Laravel. Это и #39;s паста, которую вы хотите пройти через клиентскую сторону Валидатор YAML, не публикация формы.
Сериализованные данные WordPress. Мое личное падение, согласно вступлению. WordPress хранит параметры и метаданные в виде последовательно сериализованных строк PHP, а их отладка означает их бессериализацию - the PHP несериализатор Делает это без данных вашего клиента, покидающего вашу машину.
Одна небрежная паста из любой из этих категорий — это инцидент безопасности, который никто никогда не обнаружит, не сообщает или не убирает.
Как вы подтверждаете, что инструмент на самом деле является клиентской?
Это то, что мне больше всего нравится в архитектуре клиентской стороны: Вам не нужно доверять чьей-либо политике конфиденциальности. Претензия поддается механическому контролю.
- Откройте страницу Инструмента.
- Открыть DevTools (F12) → сеть подразумеваемый Проверьте "Сохранить журнал."
- Вставить некоторые узнаваемые данные испытаний -
MY-SECRET-TEST-12345работает - и запускает инструмент. - Смотрите список запросов.
Если инструмент на стороне клиента, вы увидите начальную загрузку страницы и статические ресурсы, а затем совсем когда вы обрабатываете. если запрос срабатывает при нажатии кнопки преобразования/формата/процесса, отфильтруйте запросы и проверьте полезные нагрузки для вашей тестовой строки. нашел его? Серверная сторона. Сделано - это заняло полминуты, и теперь вы знаете об этом инструменте больше, чем когда-либо рассказывала бы вам его политика конфиденциальности.
Две честности о Toolz.dev, потому что это режет оба пути. Во-первых, сайт загружает аналитику для подсчета просмотров страниц и отслеживает что инструмент использовался - для ограничения использования - но никогда что вы вложили в него. Запустите проверку сети самостоятельно; вход никогда не появляется ни в одном запросе. во-вторых, на стороне клиента есть реальное ограничение: ваш браузер выполняет работу, поэтому расшифровка видео на 4 ГБ is't происходит на вкладке. Однако для категории инструментов форматировщик/конвертер/кодер современный JavaScript более чем достаточно быстр - обычно быстрее, чем на стороне сервера, потому что там 's вообще не загружает туда и обратно.
Серверная и клиентская: прямое сравнение
| Инструменты на стороне сервера | Инструменты на стороне клиента | |
|---|---|---|
| Где происходит обработка | Сервер оператора | Ваш браузер |
| данные передаются? | Да, каждый раз | Нет - скачивается только код инструмента's |
| Может быть зарегистрирован/сохранен оператором | Да, часто по умолчанию | Нет - оператор никогда не получает |
| выставлено в результате нарушения инструмента | Да, если сохраняется | нет |
| Проверяемая вами | Нет - вы доверяете политике | Да - вкладка "Сеть DevTools", ~30 секунд |
| Требуется соглашение об процессоре GDPR | Да, если личные данные (ст. 28) | Обработка третьей стороной не происходит |
| Работает автономно после загрузки | нет | Часто да |
| Скорость для типичных задач разработчика | Загрузка + очередь + загрузка | Мгновенный - нет сети туда и обратно |
| Тяжелые вычисления (видео, огромные файлы) | лучше подходит | ограничен вашим устройством |
Что по этому поводу говорит GDPR?
I' я разработчик, а не юрист, поэтому рассматривайте это как инженерный контекст, а не как юридическую консультацию, но схема имеет значение для всех, кто обрабатывает пользовательские данные ЕС.
под Регламент (ЕС) 2016/679 (GDPR), если вы берете персональные данные - клиент 's поддерживает экспорт, ответ API с пользовательскими записями - и проталкиваете его через сторонний сервер 's, что третья сторона обрабатывает персональные данные от вашего имени. Статья 28 говорит, что требует соглашения об обработке данных. спросите себя, сколько бесплатных онлайн-форматоров предлагают DPA. Я никогда не видел его.
Инструменты на стороне клиента обходят весь вопрос, не с помощью умного юридического составления, а с помощью архитектуры: никакие данные не доходят до поставщика, поэтому нет сторонней обработки для бумажной обработки. минимизация данных (статья 5 (1)(c)) удовлетворяется самым буквальным образом - объем ваших данных, который собирает поставщик, равен нулю. та же логика помогает с HIPAA (данные о состоянии здоровья никогда не доходят до несоответствующего сервера), аудитом SOC 2 (нет несовпадающего подпроцессора в пути передачи данных) и PCI DSS.
Чтобы было ясно: использование инструментов на стороне клиента не делает Ваш продукт Соответствует GDPR. удаляет одну конкретную и удивительно распространенную утечку в рабочем процессе разработки - ту, когда разработчик, пытаясь быть полезным в билете поддержки, вставляет персональные данные на случайный веб-сайт.
Какие задачи никогда не должны касаться сервера?
Моя личная сортировка, отсортированная по тому, насколько сильно повредит утечка:
Никогда не серверная сторона - содержит или подразумевает учетные данные:
- Форматирование ответов и полезных нагрузок API: Форматтер JSON
- Декодирующие токены: JWT декодер, Конвертер Base64
- Форматирование запросов: Форматтер SQL
- Проверка конфигураций: Валидатор YAML
- Отладка данных WordPress: PHP несериализатор
- Хэширование и сравнение значений: хэш-генератор
- Генерация учетных данных: генератор паролей, Генератор UUID
Настоятельно предпочитаю клиентскую сторону - проприетарную, но не секретную:
- Различие внутреннего кода или контрактов: текст разница, JSON диф
- Тестирование регулярного выражения на строках производственного журнала: Тестер регулярного выражения
- Преобразование меток времени из журналов и токенов: Конвертер времени отметки времени
- Сжатие внутренних скриншотов: имиджевый компресс
Низкие ставки, но клиентская сторона все еще быстрее:
- Считается: счетчик слов
- Текст-заполнитель: Генератор Lorem Ipsum
- Цвета и градиенты: палитра, градиент генератора
Есть более длительное прохождение полного набора инструментов в Руководство по инструментам повышения производительности разработчика и тот Руководство по инструментам кодирования, йо-
Если вам действительно нужен инструмент на стороне сервера - тяжелая конверсия без локальной альтернативы - сначала очистите. Поменяйте реальные ключи на YOUR_API_KEY, реальные электронные письма для [email protected], йо- Это 60 секунд поиска и замены, что превращает потенциальный инцидент в несобытие.
Почему большинство онлайн-инструментов вообще на стороне сервера?
Частично история, частично стимулы. в 2010 году браузеры были 't до работы - тяжелая обработка должна была произойти на сервере. это ограничение исчезло: современные движки JavaScript и WebAssembly обрабатывают форматирование, преобразование, хеширование и сжатие изображений на скоростях, неотличимых от собственных, а API браузера (файл, холст, веб-крипто) покрывают ввод-вывод.
Стимулы - это более наклейкая проблема. обработка на стороне сервера позволяет оператору видеть использование в деталях, точно обеспечивать соблюдение ограничений, сохранять логику обработки собственностью и - в худших случаях - рассматривать сами данные как доход. инструмент, который никогда не получает ваши данные, может't монетизировать ваши данные, именно поэтому некоторые операторы не хотят 't хотят архитектуру, даже если это's теперь технически легко.
Когда я построил инструменты для Toolz.dev, клиентская сторона была на самом деле более простый Инженерный выбор, а не только более частный: нет серверов обработки в масштабе, никаких загрузок в безопасную, нет политики хранения, и каждый инструмент одинаково работает в веб-приложении и настольном приложении, потому что логика проста в области, не зависящая от платформы. История конфиденциальности и инженерная история указывают на то же направление. Когда это происходит, редко можно взять победу.
Часто задаваемые вопросы
Что на самом деле означает «обработка на стороне клиента»?
Все вычисления происходят в вашем браузере, в JavaScript (или WebAssembly) на вашем устройстве. Единственная роль сервера — это доставка кода инструмента при загрузке страницы. Ваш ввод никогда не отображается ни в одном сетевом запросе, который вы можете подтвердить на вкладке DevTools Network.
Как проверить, является ли инструмент на стороне клиента?
Откройте DevTools (F12) → Вкладка "Сеть", включите & quot; Сохранить журнал, & quot; вставить узнаваемые тестовые данные в инструмент и обработать их. Если ни один запрос, содержащий вашу тестовую строку, не сработает, инструмент находится на стороне клиента. На Chrome вы также можете переключить DevTools на & quot;Offline& quot; после загрузки страницы - настоящий клиентский инструмент продолжает работать.
Инструменты на стороне клиента медленнее, чем на серверных?
Для типичных задач разработчика, они're быстрее - там's нет загрузки, нет очереди, нет загрузки. обработка 2 МБ JSON-файла локально почти мгновенна, в то время как сервер туда и обратно добавляет задержку на каждом шагу Исключением являются тяжелые вычисления (большие видео транскоды, файлы в гигабайтном масштабе), где мощный сервер превосходит вкладку браузера.
Toolz.dev вообще что-то собирает?
Аналитика просмотра страниц и анонимное количество использований каждого инструмента (используется для ограничения тарифов) - но никогда не контент, который вы обрабатываете. Ввод, вывод и загрузка файлов остаются в вашем браузере. это можно проверить с помощью проверки вкладки "Сеть", а не с помощью чего-то, что вам нужно принять на веру.
Действительно ли вставка JWT в онлайн-декодер рискована?
Да, больше, чем предполагает большинство разработчиков. согласно RFC 7519, полезные нагрузки JWT кодируются, а не шифруются - любой, кто держит токен, может прочитать претензии, и если срок действия токена истек 't, его можно использовать в качестве учетных данных в реальном времени. Вставка одного в декодер на стороне сервера передает возможно допустимый токен сеанса неизвестной третьей стороне. Используйте декодер на стороне клиента.
Делает ли использование клиентских инструментов совместимым с GDPR?
Ни один выбор инструмента не делает вас совместимым. Удаление средств на стороне клиента — это один конкретный риск: личные данные из ваших систем, поступающих на непроверенный сторонний процессор (для которого потребуется соглашение по обработке данных, которое у вас почти наверняка нет с бесплатным инструментальным сайтом). Обязательства вашего собственного продукта не затрагиваются.
Может ли мой работодатель видеть, что я обрабатываю в инструментах клиента?
Мониторинг сети видит, какие сайты вы посещаете, а не то, что вы вводите в клиентский инструмент - там's нет запроса, несущего ваш ввод для наблюдения Мониторинг конечной точки, установленный на самом устройстве (захват экрана, кейлоггеры) видит все независимо от архитектуры инструмента, поэтому честный ответ: не через сеть, возможно, через конечную точку.
Что, если нет альтернативы клиента для моей задачи?
Дезинфицируйте перед вставкой: замените учетные данные на заполнители (YOUR_API_KEY), обмен реальными личными данными на фиктивные значения, имена хостов и внутренние URL-адреса. Затем проверьте политику конфиденциальности инструмента для языка журналирования и хранения, отдавайте предпочтение инструментам с открытым исходным кодом, которые вы можете проверять и рассматривать «бесплатный, закрытый, серверный» как комбинацию с наивысшими рисками.
В чем разница между инструментами на стороне клиента и сервера?
Клиентские инструменты отправляют код в ваш браузер и запускают его там; серверные инструменты отправляют ваши данные на машину, которую вы не контролируете 't, и запускают ее там. Функционально вывод может быть идентичным - разница полностью в том, кто в конечном итоге будет удерживать ваш ввод. С помощью серверного инструмента ваши данные существуют, хотя и вкратце, на диске кого-то другого 's, в их журналах и в их резервных копиях.
Безопасны ли онлайн-форматтеры и украски JSON?
Это зависит от реализации, а не от категории. Форматирование JSON тривиально сделать в JavaScript, поэтому у форматировщика на стороне клиента нет причин что-либо передавать - и проверка вкладки "Сеть" устанавливает это за десять секунд. будьте здесь осторожнее, чем обычно, потому что разработчики JSON вставляют в форматировщики непропорционально часто ответы API, содержащие токены, адреса электронной почты и внутренние идентификаторы.
