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

Question

В настоящее время мы работаем над очень простым Webapp, и нам бы хотелось, чтобы «obfuscate» (что было бы правильным термином?) Или кодировать как-то параметр запроса, поэтому мы можем уменьшить вероятность незанятый пользователь от отправки произвольных данных.

Например, гиперссылка выглядит /webapp?user=Oscar&count=3

Мы хотели бы иметь Somthing как: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT и имеют это значение декодированного на сервере с реальной информацией запроса.

Прежде чем вступить в реализацию чего-то подобного этого (и, вероятно, сделать это неправильно), я хотел бы знать, есть ли что-то, чтобы сделать это уже?

У нас есть Java на сервере и JavaScript на клиенте.

Answer 1

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

Expansion редактировать

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

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

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

Таким образом, чтобы обернуть его:

1. безопасности путем запутывания не безопасности на всех.
2. Вы не можете доверять пользовательским данным, даже если он скрыт. Validate your data.
3. Использование защищенных каналов связи (SSL) помогает блокировать другие связанные угрозы.
4. Вам необходимо отказаться от вашего подхода и сделать правильной штукой.Правильное, в вашем случае, вероятно, означает добавление механизма аутентификации с системой привилегий, чтобы запретить пользователям доступа к вещам, которые они не достаточно привилегия, чтобы увидеть - в том числе вещей, которые они могли бы попытаться получить доступ с помощью фальсификации Параметры GET. Gary R's answer, а также комментарий Дэйва и Уилла этот по голове.

Answer 2

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

Answer 3

Если ваша цель состоит в том, чтобы «уменьшить вероятность того, что простой пользователь отправит произвольные данные», есть еще один более простой подход. Создайте секретный ключ и сохраните его на стороне сервера приложений. Всякий раз, когда ваше приложение генерирует 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; 
} 

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

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

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

Другая особенность Тхо, что это расширяемый:

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

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

Таким образом, запросы могут добавлять данные ADD к запросу, просто не изменяя СУЩЕСТВУЮЩИЕ данные.

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

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

Для Java все эти работы идут в Фильтр, так я сделал это. Задняя часть изолирована от этого.

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

То же и я сделал.

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

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

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

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

Боль, которую нужно сделать, но в целом все хорошо.

Answer 6

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

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

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