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

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

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

Топ-10 OWASP и ложная безопасность

Раскрытие конфиденциальных данных A6 входит в десятку наиболее серьезных угроз безопасности веб-приложений, о которых предупреждает Проект безопасности открытых веб-приложений (OWASP). Что касается создания безопасных приложений, каждый из следующих приемов не соответствует этому принципу и должен пониматься как таковой.

Какие методы ложной защиты могут быть введены, чтобы разработчик почувствовал, что он реализует безопасное решение?

Маскирование конечных точек API

В основе современного Интернета лежит асинхронный HTTP-запрос. В большинстве случаев понимание того, как они устроены в приложении, может многое рассказать злоумышленнику о состоянии программы, чтобы найти способы манипулировать ею.

Если вы следуете реализации API REST или, возможно, GraphQL, конечная точка - это место, в котором выполняется запрос информации. URL-адрес надлежащим образом определяет ресурс, который извлекается или изменяется. Имея это в виду, кажется ли уместным отказ от этих стандартных условностей путем маскировки местоположения цели?

Скрытие вызовов XMLHttpRequest (XHR) в непонятных файлах JavaScript с именами, не имеющими отношения к функции, или неправильное присвоение имени самой конечной точке - две из многих тщетных попыток удержать слежку от копания в ответах, заголовках и других метаданных.

Анализ сетевых запросов

Сетевая панель Chrome DevTools (или, альтернативно, Wireshark) может быстро раскрыть эти методы. Особенно с функцией предварительного просмотра, вызовы XHR, возвращающие JSON, становятся все проще для анализа.

Использование неправильного названия для определения местоположения конфиденциальных данных может показаться идеальным, но на самом деле это может сбить с толку разработчиков, работающих с кодовой базой в будущем. Кроме того, выполнение других методов, таких как скрытие параметров запроса в URL-адресе заголовка Referer, не требуется. При наличии возможности быстро перехватывать сетевые вызовы эти подходы в конечном итоге несерьезны.

Примечание. Считается, что методы, использующие WebSockets, предотвращают эти уязвимости, но если вы можете обнюхивать http:, вы можете обнюхивать ws: ». JSONP также использовался посредством внедрения сценария, но это очень небезопасная практика, и ее не следует использовать.

Как показано выше, внешне незаметный вызов REST (/assets/css/svg/generate) возвращает закодированную строку Base64. Теперь, хотя есть вероятность, что здесь оптимизируется настоящий SVG, злоумышленнику всегда интересно проанализировать данные ответа, когда они закодированы в Base64.

Кодирование и модификация Base64

Base64 не является шифрованием. По замыслу, это строковое представление двоичных данных в формате ASCII, и его следует рассматривать как таковое.

Кодирование данных на сервере в последовательности Base64 с последующим изменением строки перед открытием ее клиентской стороне использовалось разработчиками для ограничения видимости необработанных данных полезной нагрузки в обычном представлении.

Непрактичный подход

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

Собственный atob() метод декодирования JavaScript может вызвать ошибку, в то время как другие инструменты, найденные в Интернете, могут быть частично более успешными. Base64 Decode and Encode может, возможно, декодировать строку Base64, но определенно в набор неразборчивых символов.

Расшифровка запроса

Просеивание исходных файлов веб-приложения, возможно, становится самой сложной частью при опровержении решений безопасности на стороне клиента. Но с помощью базовых методов поиска, таких как запрос значения заголовка Request URL или поиск того, где используются значения свойств ответа, злоумышленник может и в конечном итоге найдет источник, из которого был вызван запрос.

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

После реализации всех этих методов обработки ошибочных данных вызов XHR может быть затемнен, чтобы повысить уровень неоднозначности методов обработки, используемых приложением.

Уязвимости в обфускации

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

Обфускатор JavaScript и инструменты сборки

Разработчикам доступны различные инструменты сборки для выполнения обфускации, наиболее известными из которых являются JavaScript Obfuscator, Google Closure Compiler, YUI Compressor и UglifyJS. Возможно, эти процессоры - всего лишь минификаторы с добавленной оптимизацией для искажения кода.

После обработки примера запроса и методов синтаксического анализа с помощью JavaScript Obfuscator можно увидеть, что исходный текст становится почти невозможным для усвоения.

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

Обфускация с красивой печатью в браузере

Благодаря функциям форматирования Chrome DevTools исходный код в браузере становится проще визуализировать, но с обфускацией анализ этих методов - далеко не простая задача.

Будучи языком, компилируемым и интерпретируемым точно в срок, виртуальные машины JavaScript, такие как движок Google V8, представляют очень высокопроизводительные приложения за счет оптимизации и компиляции удобочитаемого исходного кода во время выполнения. Если нереалистично скомпилировать до машинного кода, исходный код любого клиентского JavaScript-приложения можно реконструировать.

Обфускация обратного инжиниринга

С помощью простого сценария, похожего на тот, который я быстро разработал ниже, человек может проанализировать обфусцированный JavaScript в более удобочитаемом формате для дальнейшей проверки.

И теперь реверсивные методы очень похожи на оригинальные.

Деобфускация, парсинг веб-страниц и AST

Среди различных доступных инструментов деобфускации простого сценария, который считывает файл JavaScript и анализирует его, как показано выше, злоумышленнику достаточно, чтобы проанализировать, как эти методы манипуляции изменяют ответ XHR. Вызывает тревогу то, что можно даже использовать исходный исходный код для написания скрипта очистки веб-страниц для автоматизации обработки этих конфиденциальных данных.

Для более сложных методов обратной обфускации можно разобрать свой сценарий в абстрактное синтаксическое дерево (AST) и более эффективно преобразовать его с помощью Babel’s Babylon или одного из многих других JavaScript-синтаксических анализаторов AST.

Прагматическое мышление

Как и в случае с любым другим приложением, разработчики должны решить, какие методы, по их мнению, имеют техническую ценность и будут ли они ограничивать способность хакера управлять состоянием своего приложения. Но определенные механизмы, такие как фреймворки авторизации, такие как OAuth с веб-токенами JSON (JWT), действительно необходимы. Надлежащие решения по безопасности конечных точек, обеспечивающие надежную защиту конфиденциальных ресурсов и поступающие запросы из аутентифицированных источников, являются обязательными условиями для безопасных веб-приложений.

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

Эта статья изначально была размещена на моем собственном сайте patmigliaccio.com