Kodowanie / zaciemnianie parametrów HTTP

Jeśli twoim celem jest "zmniejszenie szansy bezczynnego użytkownika na wysyłanie dowolnych danych", jest inne prostsze podejście, którego bym spróbował. Utwórz prywatny klucz szyfrowania i przechowuj go po stronie serwera aplikacji. Za każdym razem, gdy aplikacja generuje adres url, Utwórz skrót adresu url przy użyciu prywatnego klucza szyfrowania i umieść ten skrót w ciągu zapytania. Za każdym razem, gdy użytkownik żąda strony z parametrami w adresie url, Przelicz hash i sprawdź, czy pasuje. To da ci pewność, że Twoje aplikacja obliczyła adres url. To pozostawi parametry ciągu zapytania czytelne choć. W pseudo-kodzie,

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;
}

Jeśli próbujesz ograniczyć dostęp do danych, użyj pewnego rodzaju mechanizmu logowania z ciasteczkiem dostarczającym pojedynczy znak na kluczu uwierzytelniania. Jeśli klient wyśle plik cookie z kluczem, może manipulować danymi zgodnie z władzami powiązanymi z jego kontem (administrator, użytkownik publiczny itp.). Wystarczy spojrzeć na Spring Security, CAS itp., Aby uzyskać łatwe w użyciu implementacje tego w Javie. Tokeny zawarte w pliku cookie są zwykle szyfrowane kluczem prywatnym wydającego serwera i są zazwyczaj odporne na manipulacje.

Alternatywnie, jeśli chcesz, aby Twój publiczny użytkownik (nieautoryzowany) mógł opublikować niektóre dane na swojej stronie, wszystkie zakłady są wyłączone. Musisz potwierdzić po stronie serwera. Oznacza to ograniczenie dostępu do określonych Uri i upewnienie się, że wszystkie dane wejściowe są wyczyszczone.

Złota zasada tutaj jest zakazać wszystkiego, z wyjątkiem rzeczy, które wiesz, że są bezpieczne.

Jeśli celem jest zapobieganie manipulowaniu "statycznymi" adresami URL, możesz po prostu zaszyfrować parametry lub podpisać je. Prawdopodobnie jest to "wystarczająco bezpieczne", aby zweryfikować MD5 parametrów URL, wraz z odrobiną soli. Sól może być przypadkowym ciągiem przechowywanym w sesji, powiedzmy.

Wtedy możesz po prostu:

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

Ta technika ujawnia dane (tzn. mogą "zobaczyć", że xyz=123), ale nie mogą zmienić danych.

Jest zaleta "szyfrowania" (i używam tego termin luźno). W tym miejscu zaszyfrowujesz całą sekcję parametrów adresu URL.

Tutaj możesz zrobić coś takiego:

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

Fajną rzeczą w używaniu szyfrowania jest dwukrotność.

Jeden chroni dane (użytkownik nigdy nie widzi, że xyz=123, na przykład).

Inną cechą jest to, że jest rozszerzalna:

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

Tutaj możesz odszyfrować oryginalny ładunek i wykonać (bezpieczne) połączenie z nowymi danymi.

Tak więc żądania mogą dodawać dane do żądania, tylko nie zmieniaj istniejących danych.

Możesz zrobić to samo za pomocą techniki podpisywania, wystarczy skonsolidować całe żądanie w jednym "obiekcie blob" , A Ten obiekt blob jest niejawnie podpisany. To jest" skutecznie " zaszyfrowane, tylko słabe szyfrowanie.

Dla Javy, cała ta praca idzie w filtrze, tak to zrobiłem. Tylny koniec jest odizolowany od tego.

Jeśli chcesz, możesz całkowicie odizolować back end z filtrem wychodzącym, który obsługuje szyfrowanie/podpisywanie URL po wyjściu.

Jasną stroną jest to, że cała strona treści "po prostu działa", ponieważ oni nic o tym nie wiedzą.

Istnieje również specjalna obsługa JavaScript (ponieważ twój filtr nie będzie łatwo "wiedział", gdzie znajduje się adres URL do zaszyfrowania). Rozwiązałem to wymagając, aby adresy URL były podpisywane jako " var signedURL="....'", więc mogę je łatwo znaleźć w wyjściu. Nie tak miażdżące obciążenie dla projektantów, jak mogłoby się wydawać.

Drugą jasną stroną filtra jest to, że możesz go wyłączyć. Jeśli masz jakieś "dziwne zachowanie" dzieje, po prostu wyłączyć. Jeśli zachowanie będzie kontynuowane, znajdziesz błąd związany z szyfrowaniem. Pozwala również programistom pracować w zwykłym tekście i pozostawić szyfrowanie do testowania integracji.

Coś jak jCryption ?

Http://www.jcryption.org/examples/

Możesz kodować dane za pomocą base64 lub czegoś podobnego. Kodowałbym argumenty inself w JSON, aby je serializować.