Je recherche un moyen d'inspecter le contenu d'un Le pseudocode peut ressembler à ce est-ce possible? httpservletresponse pour les signer avec un hachage MD5.
3 Réponses :
Oui, c'est possible. Vous devez décorer la réponse avec l'aide de HttpServletResponsewrapper code> dans lequel vous remplacez le servletOutPutStream code> avec une implémentation personnalisée qui écrit les octets à la fois au MD5 Digest et à la sortie "originale". Fournir enfin un accesseur pour obtenir la somme du MD5 final.
Le wrapper de réponse: P> // Wrap original response with it:
MD5ServletResponse md5response = new MD5ServletResponse(response);
// Now just use md5response instead or response, e.g.:
dispatcher.handle(request, md5response);
// Then get the hash, e.g.:
byte[] hash = md5response.getHash();
StringBuilder hashAsHexString = new StringBuilder(hash.length * 2);
for (byte b : hash) {
hashAsHexString.append(String.format("%02x", b));
}
System.out.println(hashAsHexString); // Example af28cb895a479397f12083d1419d34e7.
@Pablo: Avez-vous également besoin de signer les en-têtes?
@Thilo juste le contenu serait ok
@Ballusc ne sais pas toujours si c'est l'approche que je vais prendre mais ce classe httpservletresponsewrapper est Nice (+1)
En fait, je suis allé avec une autre solution: passer un imprimeur au lieu d'une httpsservletresponse et d'avoir mes "actions", écrivez-y. Mais c'est une belle solution et serait mieux dans la plupart des cas.
@Ballusc, pouvez-vous nous permettre d'utiliser ce code sans attribution s'il vous plaît? La licence CC0 serait idéale. CreativeRecommons.org/about/cc0
Qu'essayez-vous de faire?
Vous ferez peut-être mieux de chercher un format de message standard et d'envelopper le contenu de votre réponse dans un tel message et signez-le. Oauth nous vient à l'esprit.
En outre, si vous activez SSL, le client peut être sûr que le contenu de la réponse n'a pas été altéré.
J'ai une application de travail. Je souhaite ajouter une signature - hachage à la réponse qui assure que le contenu n'a pas été modifié en transit.
@Pablo: Peut-être juste allumer SSL?
Si quelque chose modifie le contenu, êtes-vous convaincu qu'il ne remplacera pas le Digest MD5 que vous retournez avec un nouveau, aussi? L'approche classique nécessite ici un secret que seuls vous et le destinataire le savent. Par exemple, une chaîne de semences Digest MD5 qui est établie en privé par le destinataire à l'avance.
@Dilum je fais déjà ça. C'était sans importance pour la question réelle et c'est pourquoi je ne l'ai pas dit avant
Techniquement, le terme "signature" est réservé, bien, signatures et fonctions de hachage ne les calculent pas.
Pour vous assurer que les données n'étaient pas modifiées en transit, avec une fonction de hachage, vous devez disposer d'une manière sécurisée de transmission de la valeur de hachage; L'ajout de la valeur de hachage dans les en-têtes HTTP ne le fera pas, car toute personne capable de modifier les données transmises peut recompter le hachage à volonté et modifier les en-têtes HTTP lorsqu'il voit l'ajustement.
avec cryptographie, vous pouvez "concentrer" pour sécuriser la transmission hors bande dans une clé réutilisable. Si le client et le serveur ont une valeur secrète partagée, inconnue de l'attaquant supposé, l'acronyme est alors Mac, comme dans "Code d'authentification du message"; Un Mac habituel est HMAC .
Dans de nombreuses situations pratiques, un Mac ne peut pas être utilisé, car un Mac nécessite un secret partagé et un secret qui partageant trop de fois n'est plus secret. Chaque titulaire secret a le pouvoir de recalculer Mac. Si chaque client connaît le secret, il n'est donc pas un secret et il est prudent de supposer que l'attaquant le sait également. Par conséquent, vous pouvez aller plus loin et utiliser Signatures numériques (vrais, ceux qui utilisent RSA, DSS, ECDSA ...) dans lequel le serveur utilise une clé privée (que seul le serveur sait) et les clients connaissent uniquement la clé publique correspondante . La connaissance de la clé publique suffit à vérifier les signatures, mais de ne pas en produire de nouveaux, et la clé privée ne peut être recomposée de la clé publique (bien qu'elles soient liées mathématiquement les unes des autres). Cependant, mettre en œuvre une signature numérique et l'utiliser correctement est beaucoup plus difficile qu'il n'est généralement supposé; Votre meilleur pari est alors d'utiliser un protocole déjà débogué, avec des implémentations existantes et que le protocole s'appelle «SSL».
Le point ici est que sans SSL, il y a de fortes chances que ce que vous faites ne dissuadera pas un attaquant déterminé; Il utilisera simplement des cycles de processeur et une bande passante réseau, et vous donnera une sensation floue chaude.
Le client et le serveur partagent un commun commun secret . Le MD5 est alors signé en utilisant ce secret (en fait, j'utilise également l'algorithme HMAC-SHA pour la signature). Je ne les précisissies pas parce que cela n'avait pas à voir avec la question en soi.