Как защитить файлы JavaScript?
Я знаю, что невозможно скрыть исходный код, но, например, если мне нужно связать файл JavaScript из моего CDN с веб-страницей, и я не хочу, чтобы люди знали местоположение и / или содержимое этого сценария, это возможный?
Например, чтобы связать скрипт с сайта, мы используем:
<script type="text/javascript" src="http://somedomain.com/scriptxyz.js">
</script>
Теперь можно скрыть от пользователя, откуда взят сценарий, или скрыть содержимое сценария и по-прежнему использовать его на веб-странице?
Например, сохранив это в моем личном CDN, которому нужен пароль для доступа к файлам, это сработает? Если нет, что будет работать, чтобы получить то, что я хочу?
14 ответов
Хороший вопрос с простым ответом: вы не можете!
Javascript - это язык программирования на стороне клиента, поэтому он работает на компьютере клиента, поэтому вы не можете ничего скрыть от клиента.
Запутывание вашего кода - хорошее решение, но этого недостаточно, потому что, хотя это сложно, кто-то может расшифровать ваш код и "украсть" ваш скрипт.
Есть несколько способов сделать ваш код трудным для кражи, но, как я уже сказал, ничто не является пуленепробиваемым.
Вдобавок ко всему, одна идея - ограничить доступ к вашим внешним js-файлам за пределами страницы, в которую вы встраивали свой код. В этом случае, если у вас есть
<script type="text/javascript" src="myJs.js"></script>
и кто-то пытается получить доступ к файлу myJs.js в браузере, ему не следует предоставлять доступ к источнику скрипта.
Например, если ваша страница написана на php, вы можете включить скрипт через include и пусть скрипт решит, безопасно ли"возвращать его источник.
В этом примере вам понадобится внешний файл "js" (написанный на php) myJs.php:
<?php
$URL = $_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
if ($URL != "my-domain.com/my-page.php")
die("/\*sry, no acces rights\*/");
?>
// your obfuscated script goes here
это будет включено в вашу главную страницу my-page.php:
<script type="text/javascript">
<?php include "myJs.php"; ?>;
</script>
Таким образом, только браузер мог видеть содержимое файла js.
Еще одна интересная идея заключается в том, что в конце вашего сценария вы удаляете содержимое элемента вашего сценария dom, так что после того, как браузер оценит ваш код, код исчезнет:
<script id="erasable" type="text/javascript">
//your code goes here
document.getElementById('erasable').innerHTML = "";
</script>
Это все простые взломы, которые не могут, и я не могу этого подчеркнуть: не могу полностью защитить ваш js-код, но они могут бесить того, кто пытается "украсть" ваш код.
Обновить:
Недавно я наткнулся на очень интересную статью, написанную Патриком Вейдом о том, как скрыть ваш js-код, и он раскрывает другой подход: вы можете кодировать свой исходный код в изображение! Конечно, это не является пуленепробиваемым, но это еще один забор, который вы можете построить вокруг своего кода.
Идея этого подхода заключается в том, что большинство браузеров могут использовать элемент canvas для управления пикселями изображений. И поскольку пиксель холста представлен 4 значениями (rgba), каждый пиксель может иметь значение в диапазоне 0-255. Это означает, что вы можете хранить символ (фактически это код ascii) в каждом пикселе. Остальное кодирование / декодирование тривиально.
Спасибо, Патрик!
Единственное, что вы можете сделать, это запутать ваш код, чтобы сделать его более трудным для чтения. Независимо от того, что вы делаете, если вы хотите, чтобы JavaScript выполнялся в их браузере, у них должен быть код.
Прочитайте это. Он имеет очень хороший способ скрыть ваш код как в источнике представления, так и в инструменте отладки, таком как firebug.
Вдобавок ко всему, вы можете сделать что-то вроде этого (если вы можете создавать серверные сценарии, что звучит так, как вы можете):
Вместо обычной загрузки скрипта отправьте запрос AJAX на страницу PHP (это может быть что угодно; я просто использую его сам). Попросите PHP найти файл (возможно, на непубличной части сервера), откройте его с помощью file_get_contentsи вернуться (читай: echo) содержимое в виде строки.
Когда эта строка вернется в JavaScript, создайте новый script пометить, заполнить его innerHTML с кодом, который вы только что получили, и прикрепите тег к странице. (У вас могут быть проблемы с этим; innerHTML может быть не то, что вам нужно, но вы можете поэкспериментировать.)
Если вы делаете это много, вы можете даже захотеть настроить страницу PHP, которая принимает переменную GET с именем скрипта, чтобы вы могли динамически получать разные скрипты, используя один и тот же PHP. (Возможно, вы могли бы вместо этого использовать POST, чтобы другим людям было немного сложнее увидеть, что вы делаете. Я не знаю.)
РЕДАКТИРОВАТЬ: Я думал, что вы только пытаетесь скрыть местоположение сценария. Это, очевидно, не сильно поможет, если вы пытаетесь скрыть сам скрипт.
Google Closure Compiler, YUI-сжатие, Minify, / Packer /... и т. Д. - это варианты сжатия / обфускации ваших JS-кодов. Но никто из них не может помочь вам скрыть ваш код от пользователей.
Любой, обладающий хорошими знаниями, может легко декодировать / де-обфускацировать ваш код с помощью таких инструментов, как JS Beautifier. Вы называете это.
Таким образом, ответ таков: вы всегда можете сделать свой код труднее для чтения / декодирования, но наверняка нет способа скрыть.
Насколько мне известно, это невозможно.
Ваш браузер должен иметь доступ к файлам JS, чтобы иметь возможность их выполнять. Если у браузера есть доступ, то у пользователя браузера также есть доступ.
Если вы защищаете свои файлы JS паролем, браузер не сможет получить к ним доступ, отказавшись от цели иметь JS в первую очередь.
Я думаю, что единственный способ - разместить необходимые данные на сервере и разрешить доступ к данным только зарегистрированному пользователю (вы также можете выполнить некоторые вычисления на стороне сервера). Это не защитит ваш код JavaScript, но сделает его неработоспособным без кода на стороне сервера
Как я уже сказал в комментарии, который я оставил на ответе gion_13 раньше (пожалуйста, прочитайте), вы действительно не можете. Не с помощью JavaScript.
Если вы не хотите, чтобы код был доступен на стороне клиента (= можно украсть без больших усилий), я бы предложил использовать PHP (ASP,Python,Perl,Ruby,JSP + Java-Servlets), который обрабатывается сервером и только пользователю предоставляются результаты вычислений / выполнения кода. Или, если вы предпочитаете, даже Flash или Java-апплет, которые позволяют выполнять вычисления / выполнение кода на стороне клиента, но компилируются и, таким образом, труднее выполнить обратный процессинг (таким образом, это невозможно).
Просто мои 2 цента.
Я согласен со всеми здесь: с JS на клиенте кошка выпадает из мешка, и нет ничего абсолютно надежного, что можно сделать.
Было сказано, что; в некоторых случаях я делаю это, чтобы помешать тем, кто хочет взглянуть на код. Вот как работает алгоритм (примерно)
Сервер создает 3 хешированных и соленых значения. Один для текущей метки времени, а два других для каждой из следующих 2 секунд. Эти значения отправляются клиенту через Ajax клиенту в виде строки, разделенной запятыми; из моего модуля PHP. В некоторых случаях, я думаю, вы можете жестко запечь эти значения в разделе сценария HTML, когда страница сформирована, и удалить этот тег сценария после того, как использование хешей закончится. Сервер защищен CORS и выполняет все обычные SERVER_NAME и т. Д. check (который не является большой защитой, но, по крайней мере, обеспечивает некоторое сопротивление скриптовым детишкам).
Также было бы неплохо, если бы сервер проверял, действительно ли клиент аутентифицированного пользователя делал это
Затем клиент отправляет те же 3 хешированных значения обратно на сервер через вызов ajax для получения фактического JS, который мне нужен. Сервер проверяет хеши на соответствие текущей отметке времени... Три значения гарантируют, что данные будут отправлены в течение 3-секундного окна, чтобы учесть задержку между браузером и сервером.
Сервер должен быть уверен, что один из хэшей совпадает правильно; и если это так, он отправит важный JS обратно клиенту. Это простой и грубый "Одноразовый пароль" без необходимости использования какой-либо базы данных на сервере.
Это означает, что у любого хакера есть только 3-секундный период окна с момента генерации первого набора хэшей, чтобы добраться до фактического JS-кода.
Весь клиентский код может находиться внутри функции IIFE, поэтому некоторые переменные внутри клиента еще сложнее читать из консоли Inspector.
Это не глубокое решение: решительный хакер может зарегистрироваться, получить учетную запись и затем попросить сервер сгенерировать первые три хэша; делая уловки для обхода Ajax и CORS; а затем заставьте клиента выполнить второй вызов, чтобы добраться до фактического кода, но это разумный объем работы.
Более того, если соль, используемая сервером, основана на учетных данных для входа; сервер может определить, кто это тот пользователь, который попытался получить конфиденциальный JS (серверу необходимо проделать дополнительную работу в отношении поведения пользователя ПОСЛЕ того, как конфиденциальный JS был получен, и заблокировать человека, если этот человек, скажем, например, не выполнял другие действия, которых ожидалось)
Старая грубая версия этого была сделана для хакатона здесь: http://planwithin.com/demo/tadr.html. Это не сработает, если сервер обнаружит слишком большую задержку, и она выйдет за пределы периода окна в 3 секунды.
Я знаю, что сейчас неподходящее время для ответа на этот вопрос, но я просто подумал о чем-то
Я знаю, что это может быть стрессом, но, по крайней мере, это может сработать
Теперь уловка состоит в том, чтобы создать много сценариев кодирования на стороне сервера, они должны быть декодируемыми (например, сценарий, который заменяет все гласные числами и добавляет букву 'a' к каждому согласному так, чтобы слово 'летучая мышь' стало ba1ta), затем создайте сценарий, который будет рандомизируйте между сценариями кодирования и создайте файл cookie с именем используемого сценария кодирования (быстрый совет: попробуйте не использовать фактическое имя сценария кодирования для файла cookie, например, если наш файл cookie имеет имя 'encoding_script_being_used' и сценарий рандомизации выбирает сценарий кодирования с именем MD10, старайтесь не использовать MD10 в качестве значения файла cookie, а 'encoding_script4567656' только для предотвращения предположений), затем после того, как файл cookie был создан, другой сценарий проверит файл cookie с именем 'encoding_script_being_used' и получит значение,затем он определит, какой сценарий кодирования используется.
Теперь причина случайного выбора между сценариями кодирования заключалась в том, что язык на стороне сервера будет случайным образом выбирать сценарий, который использовать для декодирования вашего javascript.js, а затем создавать сеанс или файл cookie, чтобы узнать, какие сценарии кодирования использовались, тогда язык на стороне сервера также будет кодировать ваш javascript.js и поместить его как файл cookie
Итак, теперь позвольте мне резюмировать пример
PHP случайным образом выбирает между списком сценариев кодирования и шифрует javascript.js, затем он создает файл cookie, сообщающий клиентскому языку, какой сценарий кодирования использовался, затем язык клиентской стороны декодирует файл cookie javascript.js (который, очевидно, закодировано)
чтобы люди не могли украсть ваш код
но я бы не советовал, потому что
- это долгий процесс
- Это слишком напряженно
Вы также можете настроить mime-тип для приложения /JavaScript, чтобы он работал как PHP, .NET, Java или любой другой язык, который вы используете. Раньше я делал это для динамических файлов CSS.
Этот метод частично работает, если вы не хотите раскрывать наиболее разумную часть вашего алгоритма.
Создавайте модули WebAssembly (.wasm), импортируйте их и выставляйте только свой рабочий процесс JS и т. д. Таким образом, алгоритм защищен, поскольку крайне сложно преобразовать ассемблерный код в более понятный для человека формат.
После создания модуля wasm и корректного импорта вы можете использовать свой код как обычно:
<body id="wasm-example">
<script type="module">
import init from "./pkg/glue_code.js";
init().then(() => {
console.log("WASM Loaded");
});
</script>
</body>
используйте nwjs, я думаю, это полезно, он может скомпилироваться в bin, после чего вы можете использовать его для создания приложений для win, mac и linux