Verschlüsseln/verschleiern von HTTP-Parametern

Derzeit arbeiten wir auf eine sehr einfache Webapp, und wir möchten "verschleiern" ( was wäre der richtige Begriff? ) oder Kodieren irgendwie die request-parameter, so reduzieren wir die Wahrscheinlichkeit, dass eine im Leerlauf Benutzer aus senden, willkürlich Daten.

Beispielsweise die url sieht aus wie /webapp?user=Oscar&count=3

Hätten wir gerne so etwas wie: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT haben und dass Wert dekodiert der server mit der realen Anforderung info.

Bevor wir in der Umsetzung so etwas wie dieses, uns selbst ( und wahrscheinlich tun es falsch ) ich würde gerne wissen, ob es etwas zu tun dies bereits?

Wir haben Java auf dem server und JavaScript auf dem client.

InformationsquelleAutor der Frage OscarRyz | 2010-10-25

27

Nein, Tue das nicht. Wenn Sie bauen können, etwas in Ihrem client-code zu verschleiern die übertragenen Daten zurück an den server, dann kann so ein Vorsatz hacker. Sie kann einfach nicht Vertrauen gesendeten Daten auf Ihrem server, egal, was Ihre offiziellen client. Stick zu entkommen-client-Daten und Prüfung gegen eine whitelist auf der server-Seite. Verwenden Sie SSL, und wenn Sie können, setzen Sie Ihr request-Parameter in einem POST anstelle von GET.

Erweiterung Bearbeiten

Ihre Verwirrung ergibt sich aus dem Ziel, zu verhindern, dass Benutzer die Manipulation mit Daten anfordern, mit der Notwendigkeit der Implementierung von standard-Sicherheitsmaßnahmen. Standard-Sicherheitsmaßnahmen für web-Anwendungen beinhalten die Verwendung einer Kombination von Authentifizierung, Berechtigung und session-management, audit Trail, Validierung von Daten, und sichere Kommunikationskanäle.

Verwendung von SSL nicht verhindern, dass der client die Manipulation der Daten, aber es nicht verhindern, dass Mitte-Männer aus zu sehen oder zu manipulieren. Er weist brav Browsern nicht zwischengespeichert werden sensitive Daten in der URL-Geschichte.

Es scheint, Sie haben irgendeine Art von einfachen web-Anwendung, die keine Authentifizierung hat, und geht um request-Parameter, die Steuern, in den BEKOMMEN, und so sind einige nicht-technisch-versierte Menschen könnten wahrscheinlich herausfinden, dass user=WorkerBee können einfach geändert werden, um user=Boss in Ihre browser-Leiste, und damit Sie kann auf Daten zugreifen, Sie sollte nicht sehen, oder Dinge tun, die Sie nicht tun sollten. Ihre Wünsche (oder die Ihrer Kunden Wunsch) zur Verschleierung dieser Parameter ist naiv, es ist nur Folie die am wenigsten technisch versierte person. Es ist eine unausgegorene Maßnahme und den Grund, warum Sie nicht gefunden haben, eine vorhandene Lösung ist, dass es nicht ein guter Ansatz. Du bist besser, verbringen Sie Zeit die Umsetzung eine anständige Authentifizierung-system mit audit-trail für eine gute Maßnahme (und wenn dies tatsächlich das, was Sie tun, mark Gary ' s Antwort als korrekt).

So, um es einpacken:
1. Sicherheit durch Verschleierung ist nicht
  Sicherheit.
2. Sie nicht Vertrauen können
  Nutzer-Daten, auch wenn es verschleiert wird.
  Überprüfen Sie Ihre Daten.
3. Über sichere Kommunikationskanäle (SSL)
  hilft blockieren andere Verwandte Bedrohungen.
4. Sie
  verlassen sollten Sie Ihre Vorgehensweise und machen
  das richtige zu tun. Die richtige, in
  deinem Fall wohl bedeutet, das hinzufügen einer
  Authentifizierung-Mechanismus mit einer
  Privileg-system, um zu verhindern, dass Benutzer
  Zugriff auf Dinge, die Sie nicht
  privilegiert genug, um zu sehen, einschließlich
  Dinge, die Sie versuchen könnten, Zugriff
  Manipulation der GET-Parameter. Gary
  R s Antwort, sowie Dave und Will ' s Kommentar trifft
  dieses auf den Kopf.
InformationsquelleAutor der Antwort Mike Atlas
10

Wenn Ihr Ziel ist es "verringert sich die chance, eine untätige Benutzer aus senden, willkürlich Daten," da ist ein einfacher Ansatz, den ich versuchen würde. Machen Sie einen privaten Schlüssel und speichern Sie es auf Ihrem Anwendung-server. Sobald Ihre Anwendung generiert eine url, erstellen Sie eine hash der url mit Ihrem privaten Schlüssel und setzen Sie das hash in der Abfrage-string. Wenn ein Benutzer fordert eine Seite mit Parametern in der url, berechnen den hash und sehen, ob es passt. Dies gibt Ihnen eine gewisse Sicherheit, dass Ihre Anwendung berechnet die url. Es wird lassen Sie Ihre query-string-Parameter lesbar, obwohl. In pseudo-code,
```
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;
}
```
InformationsquelleAutor der Antwort Dave Aaron Smith
5

Wenn Sie versuchen, Zugriff auf die Daten verwenden Sie dann eine Art login-Mechanismus mit einem cookie bietet eine Single-Sign-On-Authentifizierung-Schlüssel. Wenn der client sendet das cookie mit dem Schlüssel, dann können Sie die Daten Bearbeiten, die in übereinstimmung mit den Behörden im Zusammenhang mit Ihrem Konto (admin, Benutzer public etc). Schauen Sie nur, Spring Security, CAS usw für einfach zu bedienen Implementierungen dieser in Java. Die Token in den Cookies sind in der Regel verschlüsselt und mit dem privaten Schlüssel des ausstellenden Servers und sind in der Regel manipulationssicher.

Alternativ, wenn Sie möchten, dass Ihre öffentliche Benutzer (nicht authentifizierte) posten zu können, einige Daten zu Ihrer Website, dann sind alle Wetten ab. Sie müssen überprüfen, die auf der server-Seite. Dies bedeutet, dass die Beschränkung des Zugangs auf bestimmte URIs und sicherstellen, dass alle input gereinigt.

Die goldene Regel hier ist, verbieten alles, außer Sachen, die Sie wissen, ist sicher.

InformationsquelleAutor der Antwort Gary Rowe
3

Wenn das Ziel, es zu verhindern "statische" URLs manipuliert, dann können Sie einfach verschlüsseln der Parameter, oder Sie signieren. Es ist wahrscheinlich ein "sicher genug" für das Heften auf einen MD5 des URL-Parameter, zusammen mit etwas Salz. Das Salz kann eine zufällige Zeichenfolge, die in der session gespeichert, zu sagen.

Dann kann man nur:
```
http://example.com/service?x=123&y=Bob&sig=ABCD1324
```
Diese Technik macht die Daten (D. H. Sie "sehen" können, dass xyz=123), aber Sie können nicht ändern die Daten.

Es ist ein Vorteil der "Verschlüsselung" (und ich verwende diesen Begriff lose). Dies ist, wo Sie verschlüsseln den gesamten parameter-Abschnitt der URL.

Hier können Sie etwas tun:
```
http://example.com/service?data=ABC1235ABC
```
Die nette Sache über die Verwendung von Verschlüsselung besteht aus zwei teilen.

Einen schützt es die Daten (Sie können Benutzer nie sehen, dass xyz=123, zum Beispiel).

Anderen Funktion tho ist, dass es erweiterbar:
```
http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc
```
Hier können Sie decodieren die ursprünglichen Nutzlast und eine (sichere) verschmelzen mit den neuen Daten.

So, Wünsche können Daten HINZUFÜGEN, die auf die Anforderung, nicht nur BESTEHENDE Daten ändern.

Können Sie das gleiche tun über die Unterzeichnung-Technik, würden Sie brauchen nur zu konsolidieren, die gesamte Anforderung in einem einzigen "blob", und das blob ist implizit unterzeichnet. Das ist "quasi" verschlüsselt, nur eine schwache Verschlüsselung.

Offensichtlich wollen Sie nicht tun dies auf dem client. Es gibt keinen Punkt. Wenn Sie es tun können, "Sie" es tun können, und Sie können nicht sagen, der Unterschied, also kann man da auch nicht, es überhaupt tun-es sei denn, Sie wollen zum "verschlüsseln" von Daten über eine normale HTTP-port (vs TLS, aber dann, die Leute werden klug zu Fragen, "warum die Mühe").

Für Java, alle diese Arbeit geht in einem Filter, das ist so, wie ich es gemacht habe. Das Backend ist isoliert von diesem.

Wenn Sie möchten, können Sie mit der zurück-Ende völlig isoliert von diesem mit einem outbound-filter für die Verarbeitung des URL-Verschlüsselung/- Signierung auf dem Weg nach draußen.

Das ist auch das, was ich getan habe.

Die Kehrseite ist, dass es sehr beteiligt, es richtig zu machen und performant. Sie müssen ein geringes Gewicht-HTML-parser zu ziehen, die URLs (ich schrieb ein streaming-parser, es zu tun, on the fly, so dass Sie nicht kopieren Sie die gesamte Seite im RAM).

Die helle Seite ist der gesamte Inhalt der Seite "funktioniert einfach", da Sie nicht wissen nichts über es.

Gibt es auch einige spezielle Handhabung beim Umgang mit Javascript, (wie Ihre filter nicht einfach "wissen", wo es eine URL zu verschlüsseln). Ich habe dieses Problem gelöst, indem die urls unterzeichnet werden, um eine spezifische "var signedURL='....'", also ich finde diese einfach in die Ausgabe. Nicht als Brech-eine Belastung für Designer, wie Sie vielleicht denken.

Der anderen hellen Seite des filters ist, können Sie es deaktivieren. Wenn Sie einige "merkwürdige Verhalten" passiert, einfach abschalten. Wenn das Verhalten weiterhin, Sie haben einen bug gefunden im Zusammenhang der Verschlüsselung. Außerdem lassen die Entwickler arbeiten in text und lassen Sie die Verschlüsselung für integration testing.

Schmerzen zu tun, aber es ist schön, insgesamt in die Ende.

InformationsquelleAutor der Antwort Will Hartung
1

Etwas wie jCryption ?

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

InformationsquelleAutor der Antwort oimoim
0

Können Sie Kodieren von Daten mit base64 oder ähnliches. Ich würde Kodieren die Argumente, die inself in JSON zu serialisieren.

InformationsquelleAutor der Antwort Florian

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.