Encode / Occultation HTTP paramètres

Question

Nous travaillons actuellement sur une Webapp très simple, et nous aimerions « Dissimulation » (ce serait le bon terme?) Ou encode en quelque sorte le paramètre de demande, afin que nous puissions réduire les risques un utilisateur inactif de l'envoi de données arbitraire.

Par exemple, les regards url comme /webapp?user=Oscar&count=3

Nous aimerions avoir somthing comme:. /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT et ont cette valeur décodée dans le serveur avec la vraie information de demande

Je voudrais savoir s'il y a quelque chose à faire déjà avant d'entrer dans la mise en œuvre quelque chose comme nous-mêmes (et probablement faire mal)?

Nous avons Java sur le serveur et JavaScript sur le client.

Answer 1

Non, ne fais pas ça. Si vous pouvez construire quelque chose dans votre code client pour obscurcir les données transmises au serveur, alors si vous un pirate volontaire. Vous ne pouvez pas les données de confiance envoyées à votre serveur, peu importe ce que votre client officiel fait. Memory Stick pour échapper à des données clients et de valider contre une liste blanche sur le côté serveur . Utiliser SSL, et si vous pouvez, mettez vos paramètres de demande dans un POST au lieu de GET.

modifier d'extension

Votre confusion vient du but de bloquer les utilisateurs de falsifier les données de demande, la nécessité de mettre en œuvre des mesures de sécurité standard. mesures de sécurité standard pour les applications Web impliquent l'utilisation d'une combinaison d'authentification, le privilège et la gestion des sessions, des pistes de vérification, validation des données, et des canaux de communication sécurisés.

L'utilisation de SSL n'empêche pas le client de falsifier les données, mais il n'empêche les hommes intermédiaires de voir ou de falsification avec elle. Il indique également les navigateurs bien comportés ne pas mettre en cache les données sensibles dans l'historique des URL.

Il semble que vous avez une sorte d'application web simple qui n'a pas d'authentification, et passe autour de paramètres de la requête qui le contrôlent droit à l'EEG, et donc certaines personnes non techniquement avertis pourrait probablement comprendre que user=WorkerBee peut simplement être changé user=Boss dans leur barre de navigation, et ils peuvent ainsi accéder à des données qu'ils ne devraient pas voir, ou faire des choses qu'ils ne devraient pas faire. Votre désir (ou le désir de votre client) à obscurcir ces paramètres est naïve, car il ne va déjouer la personne les moins technophiles. Il est une demi-mesure sortis du four et la raison pour laquelle vous ne trouvez pas une solution existante est que ce n'est pas une bonne approche . Vous êtes mieux de passer du temps la mise en œuvre d'un système d'authentification décent avec une piste de vérification pour faire bonne mesure (et si tel est bien ce que vous faites, marque réponse de Gary comme correct).

Donc, pour l'envelopper:

1. Sécurité par l'obscurcissement n'est pas la sécurité du tout.
2. Vous ne pouvez pas confiance les données utilisateur, même si elle est obscurci. Valider votre données.
3. Utilisation des canaux de communication sécurisés (SSL) aide à bloquer d'autres menaces connexes.
4. Vous devrait abandonner votre approche et faire la bonne chose. La bonne chose, en votre cas, signifie probablement ajouter un mécanisme d'authentification avec système de privilèges aux utilisateurs Empêchez d'avoir accès à des choses qu'ils ne sont pas eu le privilège de voir - y compris des choses qu'ils pourraient essayer d'accéder par l'altération des paramètres GET. Gary de réponse de R, ainsi que le succès de commentaires de Dave et Will celui-ci sur la tête.

Answer 2

Si votre objectif est de « réduire le risque d'un utilisateur inactif d'envoyer arbitrairement des données, » il y a une autre approche plus simple, je voudrais essayer. Créez une clé de chiffrement privée et la stocker dans le côté du serveur d'applications. Chaque fois que votre application génère une URL, créez un hachage de l'URL en utilisant votre clé de chiffrement privée et mettez-hachage dans la chaîne de requête. Chaque fois qu'un utilisateur demande une page avec des paramètres dans l'URL, le hachage et recalcule voir si elle correspond. Cela vous donnera une certaine certitude que votre application calcule l'URL. Il laissera vos paramètres de chaîne de requête lisible cependant. En 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;
}

Answer 3

Si vous essayez de restreindre l'accès aux données puis utiliser une sorte de mécanisme de connexion avec un cookie fournissant une authentification unique clé d'authentification. Si le client envoie le cookie avec la touche alors ils peuvent manipuler les données selon les autorités associées à leur compte (admin, utilisateur public, etc.). Il suffit de regarder Spring Security, CAS etc pour les implémentations facile à utiliser de ce en Java. Les jetons fournis dans le cookie sont généralement cryptés avec la clé privée du serveur d'émission et sont généralement inviolable.

Par ailleurs, si vous voulez que votre utilisateur public (non authentifié) pour pouvoir poster des données sur votre site, tous les paris sont éteints. Vous devez valider sur le côté serveur. Cela suppose de restreindre l'accès à certains URIs et faire en sorte que toutes les entrées est nettoyée.

La règle d'or ici est tout disallow, sauf des choses que vous savez est sûr.

Answer 4

Si l'objectif pour empêcher les URL statiques « de » d'être manipulé, alors vous pouvez simplement chiffrer les paramètres ou les signer. Il est probable « assez sûr » pour virer de bord sur un MD5 des paramètres d'URL, ainsi que du sel. Le sel peut être une chaîne aléatoire stocké dans la session, par exemple.

Ensuite, vous pouvez simplement:

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

Cette technique expose les données (à savoir qu'ils peuvent « voir » que xyz = 123), mais ils ne peuvent pas changer les données.

Il y a un avantage de « cryptage » (et je l'utilise vaguement ce terme). C'est là que vous chiffrez toute la section des paramètres de l'URL.

Ici, vous pouvez faire quelque chose comme:

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

La chose agréable sur l'utilisation de cryptage est deux fois.

Un protège les données (ils utilisateur ne peut jamais voir que xyz = 123, par exemple).

L'autre caractéristique tho est qu'il est extensible:

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

Ici, vous pouvez décoder la charge utile d'origine, et faire un (sûr) fusion avec les nouvelles données.

Ainsi, les demandes peuvent ajouter des données à la demande, tout simplement pas modifier les données existantes.

Vous pouvez faire la même chose par la technique de signature, vous avez juste besoin de consolider toute la demande pour un seul « blob », et que blob est implicitement signé. C'est crypté « efficace », juste un cryptage faible.

Il est évident que vous ne voulez pas faire tout cela sur le client. Il est inutile. Si vous pouvez le faire, « ils » peuvent le faire et vous ne pouvez pas faire la différence, vous pouvez aussi bien ne pas le faire du tout - sauf si vous voulez des données « Chiffrer » sur un port HTTP normal (vs TLS, mais les gens vont se demander à bon escient « pourquoi la peine »).

Pour Java, tout ce travail va dans un filtre, qui est la façon dont je l'ai fait. L'extrémité arrière est isolé à partir de ce produit.

Si vous le souhaitez, vous pouvez faire la fin arrière complètement isolé de cela avec un filtre sortant qui gère le cryptage URL / signature à la sortie.

C'est aussi ce que je faisais.

Le côté bas est qu'il est très impliqué pour obtenir ce droit et performant. Vous avez besoin d'un analyseur HTML poids léger pour tirer les URL (je l'ai écrit un analyseur en continu de le faire à la volée il n'a pas copié la page entière dans la RAM).

Le côté lumineux est tout du côté du contenu « fonctionne juste », car ils ne savent pas quoi que ce soit à ce sujet.

Il y a aussi une manipulation particulière lorsqu'ils traitent avec JavaScript (comme filtre « saura » pas facilement là où il y a une URL à chiffrer). Je résolus cela en exigeant urls être signé pour être précis « var signedURL = « .... » », donc je peux trouver les facilement dans la sortie. Pas aussi écraser un fardeau pour les concepteurs que vous pourriez penser.

L'autre côté lumineux du filtre est que vous pouvez le désactiver. Si vous avez un « comportement étrange » qui se passe, il suffit de tourner hors tension. Si le problème persiste, vous avez trouvé un bug lié au chiffrement. Il laisse également aux développeurs de travailler en texte clair et laisser le cryptage pour les tests d'intégration.

La douleur à faire, mais il est agréable dans l'ensemble à la fin.

Answer 5

Quelque chose comme jCryption?

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

Answer 6

Vous pouvez encoder des données en utilisant base64 ou quelque chose de similaire. Je coder les arguments inself dans JSON sérialisation.