Кодировать/обфускировать параметры HTTP

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

Редактировать расширение

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

Использование SSL не препятствует тому, чтобы клиент подделывал данные, но не позволял посредникам видеть или подделывать их. Он также предписывает браузерам с хорошим поведением не кэшировать конфиденциальные данные в истории URL-адресов.

Кажется, у вас есть какое-то простое веб-приложение, которое не имеет аутентификации и передает параметры запроса, которые управляют им, прямо в GET, и поэтому некоторые технически не подкованные люди, вероятно, могли бы понять, что user=WorkerBee можно просто изменить на user=Boss в их панели браузера, и, таким образом, они могут получить доступ к данным, которые они не должны видеть, или делать то, что им не следует делать. Ваше желание (или желание вашего клиента) запутать эти параметры наивно, так как это только помешает наименее технически подкованному человеку. Это недоработанная мера, и причина, по которой вы не нашли существующее решение, заключается в том, что это не очень хороший подход. Вам лучше потратить время на внедрение приличной системы аутентификации с контрольным журналом для хорошей меры (и если это действительно то, что вы делаете, отметьте ответ Гэри как правильный).

Итак, чтобы подвести итог:

1. Безопасность путем обфускации вовсе не является безопасностью.
2. Вы не можете доверять данным пользователя, даже если они скрыты. Проверьте свои данные.
3. Использование безопасных каналов связи (SSL) помогает блокировать другие связанные угрозы.
4. Вам следует отказаться от своего подхода и поступить правильно. Правильным в вашем случае, вероятно, является добавление механизма аутентификации с системой привилегий, чтобы пользователи не могли получить доступ к вещам, для просмотра которых у них недостаточно привилегий, включая то, к чему они могут попытаться получить доступ, подделав параметры GET. ответ Гэри Р., а также комментарий Дэйва и Уилла попали в этот глава.

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

SALT = "so9dnfi3i21nwpsodjf";

function computeUrl(url) {
  return url + "&hash=" + md5(url + SALT );
}

function checkUrl(url) {
  hash = /&hash=(.+)/.match(url);
  oldUrl = url.strip(/&hash=.+/);
  return md5(oldUrl + SALT ) == hash;
}

Если вы пытаетесь ограничить доступ к данным, используйте какой-либо механизм входа в систему с файлом cookie, предоставляющим ключ аутентификации единого входа. Если клиент отправляет файл cookie с ключом, он может манипулировать данными в соответствии с полномочиями, связанными с его учетной записью (администратор, публичный пользователь и т. д.). Просто взгляните на Spring Security, CAS и т. д., чтобы легко реализовать это на Java. Токены, предоставляемые в файле cookie, обычно зашифрованы с помощью закрытого ключа сервера-эмитента и, как правило, защищены от несанкционированного доступа.

В качестве альтернативы, если вы хотите, чтобы ваш общедоступный пользователь (не прошедший проверку подлинности) мог публиковать некоторые данные на вашем сайте, тогда все ставки отключены. Вы должны подтвердить на стороне сервера. Это означает ограничение доступа к определенным URI и обеспечение очистки всего ввода.

Здесь есть золотое правило: запрещать все, кроме того, что, как вы знаете, безопасно.

Если цель состоит в том, чтобы предотвратить манипулирование «статическими» URL-адресами, вы можете просто зашифровать параметры или подписать их. Вероятно, «достаточно безопасно» использовать MD5 параметров URL вместе с некоторой солью. Соль может быть, скажем, случайной строкой, хранящейся в сеансе.

Тогда вы можете просто:

http://example.com/service?x=123&y=Bob&sig=ABCD1324

Этот метод раскрывает данные (т. е. они могут «видеть», что xyz=123), но не могут изменить данные.

Есть преимущество «шифрования» (и я использую этот термин вольно). Здесь вы шифруете весь раздел параметров URL-адреса.

Здесь вы можете сделать что-то вроде:

http://example.com/service?data=ABC1235ABC

Хорошая вещь в использовании шифрования двояка.

Во-первых, он защищает данные (например, пользователь никогда не увидит, что xyz=123).

Другая особенность заключается в том, что он расширяемый:

http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc

Здесь вы можете декодировать исходную полезную нагрузку и выполнить (безопасное) слияние с новыми данными.

Таким образом, запросы могут ДОБАВЛЯТЬ данные к запросу, но не изменять СУЩЕСТВУЮЩИЕ данные.

Вы можете сделать то же самое с помощью метода подписи, вам просто нужно объединить весь запрос в один «блоб», и этот блоб неявно подписан. Это «эффективно» зашифровано, просто слабое шифрование.

Очевидно, вы не хотите делать НИЧЕГО из этого на клиенте. Нет никакого смысла. Если вы можете это сделать, «они» могут это сделать, и вы не заметите разницы, поэтому вы можете вообще не делать этого — если только вы не хотите «шифровать» данные через обычный HTTP-порт (в отличие от TLS, но тогда люди будут мудро задаваться вопросом «зачем беспокоиться»).

Для Java вся эта работа выполняется в фильтре, как я это сделал. Задний конец изолирован от этого.

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

Это также то, что я сделал.

Недостатком является то, что это очень сложно сделать правильно и эффективно. Вам нужен легкий синтаксический анализатор HTML для извлечения URL-адресов (я написал потоковый синтаксический анализатор, чтобы делать это на лету, чтобы он не копировал всю страницу в ОЗУ).

Яркая сторона заключается в том, что вся содержательная сторона «просто работает», поскольку они ничего об этом не знают.

Также существует некоторая особая обработка при работе с Javascript (поскольку ваш фильтр не будет легко «знать», где находится URL-адрес для шифрования). Я решил эту проблему, потребовав, чтобы URL-адреса были подписаны так, чтобы они были конкретными «var signedURL='....'», поэтому я могу легко найти их в выводе. Не такое уж бремя для дизайнеров, как вы могли бы подумать.

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

Больно делать, но в целом приятно.

Что-то вроде jCryption?

http://www.jcryption.org/examples/

Вы можете кодировать данные, используя base64 или что-то подобное. Я бы сам закодировал аргументы в JSON, чтобы сериализовать их.