Введение

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

Для компьютеров доверенный платформенный модуль (TPM) уже используется и соответствует спецификациям TPM, установленным Trusted Computing Group (TCG). TPM — это безопасный чип, предназначенный для реализации доверенных систем. TPM является корнем доверенных систем, он является основным модулем доверенных вычислений и обеспечивает надежную защиту для компьютерной безопасности.

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

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

Надежный внешний интерфейс

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

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

1. Почему обфускация JavaScript?

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

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

Поскольку объем файлов JavaScript резко возрос, было выпущено несколько инструментов сжатия JavaScript, чтобы уменьшить объем JavaScript и повысить эффективность передачи HTTP, такие как uglify, компрессор и clouser. Эти инструменты могут:

· Merge multiple JavaScript files;
· Remove spaces and line breaks from JavaScript code;
· Compress variable names in JavaScript files;
· Remove annotations.

[Сжатый код]

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

[Код отформатирован инструментом разработчика Chrome]

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

2. Надежность обфускации JavaScript

Вопрос о том, достаточно ли надежен обфускация JavaScript, уже некоторое время является горячей темой. На самом деле обфускация кода возникла еще в эпоху программного обеспечения для настольных компьютеров, когда программисты перерабатывали большинство программ с обфускацией кода и шифрованием оболочки для защиты своего кода. Java и .NET имеют свои собственные обфускаторы. Хакеры слишком хорошо это знают, и многие антивирусные программы сильно запутаны для антивирусных целей. Однако многие пользователи считают обфускацию избыточной, поскольку JavaScript является динамическим языком сценариев, передача исходного кода в HTTP и реверс-инжиниринг намного проще, чем распаковка скомпилированного программного обеспечения.

[обфускатор .NET, dotFuscator]

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

3. Методы обфускации JavaScript

Обычно обфускаторы JavaScript делятся на две категории:
· Обфускаторы, реализованные путем замены регулярного выражения
· Обфускаторы, реализованные путем замены синтаксического дерева.

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

Термины и сокращения

Маркер: как лексическая единица (известная как лексический маркер), маркер создается лексическим анализатором и является минимальной единицей разделенного текстового потока.
AST: синтаксический анализатор создает абстрактное синтаксическое дерево и имеет дерево -подобное наличие абстрактной синтаксической структуры исходного кода.

[Компиляторы и обфускаторы]

Рабочий процесс компиляторов:
Вкратце, когда система читает фрагмент строкового текста (исходный код), лексический анализатор разбивает его на небольшие единицы (токены). Например, цифра 1 — это токен, а строка «abc» — еще один токен. Затем синтаксический анализатор организует эти более мелкие единицы в дерево (AST), которое представляет отношение композиции различных токенов. Например, он может отображать «1 + 2» в виде дерева сложения, где левый и правый узлы представляют собой токен — 1 и токен — 2, а центральный токен указывает на добавление. Затем компилятор создает промежуточный код на основе сгенерированного AST, который в конечном итоге преобразуется в машинный код.

Рабочий процесс обфускаторов:
компиляторам необходимо преобразовать исходный код в промежуточный код или машинный код, вывод обфускаторов по-прежнему представляет собой код JavaScript и не требует шагов, следующих за синтаксическим анализом. Кроме того, целью здесь является изменение структуры исходного кода JavaScript. Чему соответствует эта структура? Это соответствует AST, и любой правильно разработанный код JavaScript может построить AST. Точно так же AST также может генерировать код JavaScript, поскольку он представляет логическую взаимосвязь различных токенов. Таким образом, вы можете сгенерировать любой код JavaScript, просто создав AST. На рисунке выше справа показан процесс обфускации.

Изменив AST, вы можете создать новый AST, соответствующий новому коду JavaScript.

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

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

Реализация

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

Легко доступны многие имеющиеся в продаже лексические и синтаксические анализаторы JavaScript, такие как v8, SpiderMonkey для Mozilla и esprima. Ниже описывается рекомендуемый uglify, парсер на основе nodejs. Этот инструмент предоставляет следующие возможности:

· Parser - which can parse JavaScript code as the AST
· Code generator - which can generate code by using the AST
· Scope analyzer - which can analyze definitions of variables
· Tree walker - which can traverse tree nodes
· Tree transformer - which can change tree nodes

Изучив приведенный выше эскиз проекта обфускатора, вы увидите, что вы изменили только синтаксическое дерево.

Примеры
Чтобы помочь вам понять, как спроектировать обфускатор, в следующем простом примере подробно показано, как преобразовать число «1» в «var a = 1» в его шестнадцатеричный вид с помощью правил обфускации. Во-первых, выполните лексический и синтаксический анализ исходного кода и создайте синтаксическое дерево, просто используя метод uglify. Затем найдите число в синтаксическом дереве и преобразуйте его в шестнадцатеричную форму, как показано ниже:

Код примера:

var UglifyJS = require("uglify-js");
var code = "var a = 1;";
var toplevel = UglifyJS.parse(code); //toplevel is actually the syntax tree.
var transformer = new UglifyJS.TreeTransformer(function (node) {
if (node instanceof UglifyJS.AST_Number) { //Locate the leaf node that needs to be modified.
        node.value = '0x' + Number(node.value).toString(16);
        return node; //A new leaf node is returned to replace the original leaf node.
    };
});
toplevel.transform(transformer);  //Traverse the AST.
var ncode = toplevel.print_to_string(); //Restore to strings from the AST.
console.log(ncode); // var a = 0x1;

Глядя на приведенный выше простой код, вы можете понять, что сначала вам нужно построить синтаксическое дерево с помощью метода синтаксического анализа, а затем пройти по дереву с помощью TreeTransformer. Когда вы проходите узел типа UglifyJS.AST_Number до (см. ast для полного списка типов AST), токен этого узла имеет атрибут value, который хранит конкретное значение числового типа. Затем измените значение на шестнадцатеричное и запустите return node, чтобы заменить исходный узел новым узлом.

Результат
Ниже показаны коды до и после обфускации:

4. Влияние обфускации на производительность

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

· Reduce cyclic obfuscation as too many obfuscations can impact code execution efficiency
· Avoid too many concatenated strings as string concatenation imposes performance issues in earlier versions of IE
· Control code volume - Specifically, control the proportion of inserted waste code as an oversized file can exhaust network request and code execution performance.

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

5. Защита от обфускации

Цель обфускации — защитить код без ущерба для его исходной функциональности.

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

· Develop detailed unit tests for obfuscators
· Perform high-coverage functional tests on obfuscation target code to ensure that the execution results of the pre- and post-obfuscation code are consistent
· Perform multi-sample tests to obfuscate the class libraries complemented by unit tests, such as obfuscating jQuery and AngularJS. Then, perform those unit tests again using the obfuscated code and ensure that the execution results are the same before and after the obfuscation.

Резюме

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

использованная литература

https://en.wikipedia.org/wiki/Trusted_Platform_Module
https://en.wikipedia.org/wiki/Trusted_system
http://lisperator.net/uglifyjs< br /> http://esprima.org

Ссылка:

https://www.alibabacloud.com/blog/Path-to-a-Trusted-Front-end-Code-Protection_p90573