Шифрование JavaScript (или обфускация) структур данных на стороне клиента

Question

Есть ли способ «скрыть» структуру и содержимое объектов javascript?

У меня на клиентской стороне довольно обширные объекты JavaScript, содержащие информацию о пользовательском интерфейсе пользователя (и других вещах). Он содержит много информации о ресурсах, над которыми будет работать пользователь. На самом деле, кто-то с Firebug может просто открыть консоль и увидеть структуру всех этих данных. Я не в восторге от этого по соображениям безопасности.

Есть ли способы защитить эти данные?

Спасибо

Answer 1

Нет, вы не можете защитить эти данные. Все, что может видеть и использовать браузер, может также видеть и использовать лицо, проверяющее, что имеет браузер.

Вам действительно нужно подумать, почему это проблема для вас? Если вы беспокоитесь о слежке «человек посередине», который может перехватывать эти данные, то вам следует запускать соединения через https.

Если вы обеспокоены тем, что конечный пользователь сам видит эти данные, я бы спросил, почему вас это беспокоит? Это собственное состояние пользователя. Там не должно быть никаких секретов.

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

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

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

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

Answer 2

Нет, нет.

Однако у вас есть несколько вариантов:

1. Вы можете запутать свой javascript - это поможет немного, поскольку затруднит чтение и понимание вашего кода.Есть много хороших обфускаторов там.Я советую против этого!
2. Вы можете минимизировать свой javascript - это может выглядеть как метод запутывания, но это не так.Он может быть легко возвращен обратно в читаемый JavaScript и в основном предназначен для ограничения полосы пропускания.Я поощряю это, но советую против этого по этой причине!
3. Вы можете попытаться разместить как можно больше ваших конфиденциальных данных и кода на вашем сервере.Это может иметь смысл, а может и нет.
4. Вы можете зашифровать свои данные и расшифровать их на лету с помощью собственной библиотеки расшифровки JavaScript.Не очень хорошая идея, поскольку эту защиту довольно легко обойти и она требует значительных ресурсов.Однако это будет немного препятствовать «краже» ваших данных. Я настоятельно рекомендую против этого!
5. Если вы можете согласиться только с таргетингом на Google Chrome (на данный момент) или Chromium, вы можете реализовать свой код и данные в Native Client, который в основном компилируется в Cкод работает в песочнице в вашем браузере (Chromium / Chrome).Единственный способ получить доступ к вашему коду - это декомпиляция.Если вы действительно параноидально относитесь к краже данных, вы можете запутать свой код C перед компиляцией, чтобы попытаться убить отладчики от захвата ваших данных и, возможно, получить все ваши данные по SSL с вашего сервера в реальном времени, а не хранить их в двоичном файле.

Хотя, помните, даже с вариантом 5 есть способы требовать ваши данные, хотя очень немногие из них будут иметь желание, время и ноу-хау для их получения.

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

Answer 3

Я бы не предлагал пытаться запутать логику javascript.Но вы можете минимизировать это (то есть унизить это).по крайней мере, вы бы затруднили чтение.Если вы беспокоитесь о безопасности своего кода на стороне клиента, то нет другого способа, кроме как использовать код на стороне сервера.Возможно, сделав больше кода доступным через сервисы, а затем вызывая ваши сервисы через $ .ajax или что-то подобное.

Answer 4

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

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

Answer 5

Запутывание может дать вам только столько, потому что Javascript по своей природе состоит в том, что он загружается в систему пользователя, чтобы его браузер (и пользователь) могли его прочитать. Создание чего-то более сложного для чтения не означает, что оно полностью скрыто. Вы не можете зашифровать его, не предоставив своим пользователям какой-либо способ расшифровать его, тем самым победив цель. То, что вам нужно, это серверный язык, который компилируется до того, как его увидит пользователь, например PHP, Python, Java и т. Д.

Answer 6

Если это проблема безопасности, не отправляйте ее клиенту. Даже если вы запутываете это, вы не делаете его более безопасным.