Каков наилучший и наиболее безопасный способ шифрования данных Ajax? - PullRequest
0 голосов
/ 24 июля 2011

Я разрабатываю веб-сайт, на котором люди смогут регистрироваться и получать доступ к различным данным через Ajax (работает на jQuery).Это все просто, и у меня не будет проблем с этим.проблема в том, что данные, показанные Ajax, должны быть безопасными и недоступными для анализа через удаленные сценарии.Я могу зашифровать данные через AES (в PHP) и успешно расшифровать в javascript, но код javascript всегда будет виден всем (после входа в систему).Я могу использовать шифрование обфускатором и javascript, но оба способа, даже смешанные, недостаточно безопасны и дешифруемы.Я бы предпочел избегать соединений SSL, поскольку я пытаюсь запретить доступ к информации зарегистрированным пользователям, а соединение SSL будет препятствовать доступу данных только незарегистрированным пользователям.

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

К сожалению, система определенно нуждается в Ajax (весь рабочий принцип должен быть основан на Ajax).Идеальным решением будет способ сохранить ключ шифрования в месте, которое может быть сохранено php и доступно javascript, но не пользователями, удаленными парсерами сценариев и т. Д.

Кто-нибудь знает способ созданиябезопасное соединение Ajax для этой цели?

Я очень ценю вашу помощь.

Ответы [ 4 ]

6 голосов
/ 24 июля 2011

Вы хотите то, чего не делают браузеры.

Вы просили: "The ideal solution would be a way to save the encryption key on a place that can be saved by php and accessed by javascript, but not by users, remote script parsers etc."

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

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

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

1 голос
/ 24 июля 2011

Вы не можете делать именно то, что вы хотите. Это похоже на обманчивый игровой дизайн. Вы можете сделать это тяжелее, даже более сложным, но не на 100% безопасным. Вы должны решить проблему с помощью другого подхода, как, например, изучить действия на стороне сервера (например, с учетом состояния) и попытаться обнаружить любое нечеловеческое поведение. Но дело только в том, что кто-то создает реалистичного бота, который имитирует поведение людей. Шифрование используется для предотвращения подслушивания / захвата данных третьими лицами - кроме сервера и клиента, а НЕ для клиента. Я не говорю, что откажитесь от всего этого, но попробуйте другой подход для защиты системы. Я хочу помочь больше, но не знаю, чего именно вы пытаетесь достичь.

0 голосов
/ 04 августа 2011

я думаю, что лучшая практика - делать ваш код (производственный код) слишком сложным для чтения и редактирования, вы должны переименовывать всю вашу переменную буквами [az], вы не должны объявлять ny, всегда используйте function(){} внутри другогосделать его более логичным, чтобы клиент мог видеть код, но не имеет к нему никакого отношения. ПРАВКА: теперь я понимаю, что это ужасный совет

0 голосов
/ 24 июля 2011

аутентификация - единственный способ сделать это.

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

Без начального числа / соли, даже если злонамеренный пользователь может расшифровать ваши данные, он все равно будет мусором.

Если вы хотите, чтобы javascript использовал часть данных, тогда клиенты используют эти данные.

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

Правильная аутентификация должна решить все эти проблемы.

Я хочу, чтобы пользователи могли видеть данные только тогда, когда Ajax отображает их

Затем загружать данные, когда Ajax получает их, а не раньше.Или только частично загрузить данные и разгрузить любую чувствительную работу на сервер.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...