Защита клиентского кода - PullRequest
1 голос
/ 29 марта 2011

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

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

Ответы [ 5 ]

2 голосов
/ 29 марта 2011

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

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

2 голосов
/ 29 марта 2011

Если код на стороне клиента, у них есть код.Период.Вот как работает интернет.

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

1 голос
/ 29 марта 2011

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

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

0 голосов
/ 29 марта 2011

Помимо стандартной обфускации JS, которая обсуждается, например, здесь: https://stackoverflow.com/questions/2285593/how-to-sell-and-protect-software-that-has-easily-visible-source-like-javascript, это практически невозможно.

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

0 голосов
/ 29 марта 2011

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

...