Les URL signées par mesure de sécurité


1

La mise en œuvre d'URL signées constituerait une mesure de sécurité efficace pour empêcher la falsification et l'empoisonnement d'URL sur des ressources publiques auxquelles on accède via une requête GET.

par exemple. http://www.domain.com/:url_to_resource/:hash http://cdn.domain.com/:url_to_resource.js?:hash

Hash dans mon cas correspondrait à ma clé de cache pour la ressource.

Toute rétroaction, amélioration ou critique serait grandement appréciée.

1

Si le client venait à le modifier, nous aurions également besoin d'un mécanisme permettant aux certificats clients d'avoir confiance. Pour éviter les modifications sur la connexion provenant du serveur, SSL couvrirait déjà cela et plus encore. Vraiment, je ne vois pas ce que cela offrirait sur les capacités de SSL, sauf si vous cherchez simplement un moyen plus léger de protéger les liens sans avoir à utiliser une connexion SSL complète. Il semblerait aussi qu'il serait très ouvert de rejouer des attaques à moins qu'une forme d'IV soit fournie car si le serveur affichait une URL à un attaquant, cette URL pourrait être copiée, avec signature, à tout futur utilisateur. Ce serait particulièrement dévastateur sur un site qui permettait aux utilisateurs d'établir des liens, bien que ces liens puissent être laissés sans confiance et non signés.

  0

Comment cela affecterait-il votre réponse? Lorsqu'un utilisateur frappe la page pour la première fois, vous créez uniquement un protocole HTTP HMAC sécurisé (SessionID, SharedSecret, scrypt (mot de passe), expire). Cookie est associé à une table DB Session (SessionID, données, HMAC, signature, expire). Toutes les données sont cryptées sur le client afin que le serveur ne puisse jamais lire les données. (Déni plausible). 12 août. 132013-08-12 13:33:22

  0

@ 4e494c - Je ne suis pas sûr de suivre votre sens ou votre intention à partir de ce commentaire. Est-ce que vous êtes un serveur? Si oui, quelles sont les données et à quoi fait référence la signature? Il n'y a pas assez de contexte sur la façon dont vous avez l'intention d'utiliser ces valeurs pour que je puisse en comprendre le sens. 12 août. 132013-08-12 13:39:33

  0

Correct, "vous" fait référence au serveur. SharedSecret fait référence à un secret partagé unique entre le serveur et le cookie de l'utilisateur. La signature de session est simplement une représentation normalisée de la signature de hachage et expire est simplement une date d'expiration au format numérique. 12 août. 132013-08-12 13:49:47

  0

@ 4e494c - ok, comment cela est-il censé être utile dans le cas de la signature des liens et dans quelle direction? Je ne comprends toujours pas comment cela serait utilisé dans le contexte de la situation d'origine. 12 août. 132013-08-12 13:52:39

  0

la signature && || HMAC contiendra le hachage du fichier JS. Flux de processus: Utilisateur -> Site -> Cookie/Session -> Site -> JS (avec l'URL signée). Appologies pour la confusion, j'essayais de mulitask quelques-unes à beaucoup de questions. 12 août. 132013-08-12 14:02:06

  0

@ 4e494c - alors essayez-vous simplement de vous assurer qu'un lien retourné par le client est le même que celui qui lui est fourni? Si le HMAC et la signature proviennent tous deux ou sont connus sur le serveur, qu'essayez-vous d'accomplir? Je suis vraiment perdu à ce stade. 12 août. 132013-08-12 14:19:35

  0

Désolé, longue journée. Pour mon cas d'utilisation Je cherche juste un moyen de valider qu'un fichier javascript envoyé à partir du serveur est authentique et inchangé quand il atteint l'utilisateur. Autre crypto côté client est assez inutile, et facilement exploitable si je ne peux pas valider la signature des fichiers. Bien que mes questions initiales étaient que la signature d'URL puisse être utilisée pour protéger contre l'attribution d'exploits d'URI, j'ai tenté de généraliser la question pour rendre la question plus utile aux autres. par exemple. /index.php?:hash&file=../../../etc/password 12 août. 132013-08-12 14:30:32

  0

@ 4e494c - dans ce cas, une simple signature basée sur le certificat du serveur suffirait à vérifier le fichier JS, mais le problème serait faire savoir au navigateur qu'il doit s'attendre à ce que le fichier JS soit signé. C'est en fait le même problème fondamental que la plupart des attaques SSL récentes exploitent à côté du processus en faisant en sorte que le navigateur n'attend pas de contenu signé ou crypté. Je ne vois pas de réel avantage à utiliser simplement le protocole SSL pour la connexion, car sans cela, l'indicateur permettant de définir le navigateur à vérifier pourrait être supprimé, tout comme le fait SSLStrip. 12 août. 132013-08-12 15:14:06

  0

développerait un addon du navigateur qui valide/vérifie le fichier JS être une solution viable à ce problème? 14 août. 132013-08-14 14:14:56

  0

@Null - À moins que chaque fichier JS sur Internet ne soit signé, le navigateur n'a aucun moyen de savoir, lors de la première visite sur un site, que le fichier JS doit fournir une signature. Toute tentative d'établissement d'une connexion SSL par le serveur peut être supprimée et envoyée à l'utilisateur en tant que page non protégée. 14 août. 132013-08-14 14:49:47

  0

Je ne pense pas que tous les JS en auraient besoin. Il peut être activé en déclarant une configuration de type CORS sur le même serveur et en appliquant les mêmes règles d'origine. Cela pourrait ensuite être lié le concept d'url signé, j'ai demandé plus haut.SSLStrip est une préoccupation que je n'ai pas beaucoup réfléchie. Merci pour la direction. 14 août. 132013-08-14 15:47:39

  0

@Null - mais comment vous assurer que cette information atteint le client. Le point d'une telle signature est d'empêcher une attaque de mitm, mais un mitm pourrait simplement ne pas placer la config. Vous ne parleriez jamais au bon serveur, votre navigateur ne saurait jamais s'y attendre. 14 août. 132013-08-14 16:21:06


0

Peut aider si la falsification est faite en transit (proxy, MITM), mais n'aidera pas si la falsification est faite sur le serveur (injection SQL ou PHP, ou remplacement de fichiers). Etant donné qu'un très grand pourcentage du web est généré dynamiquement, le hachage devrait être calculé par le serveur comme il sert la page ... Je pense que cela nécessiterait une refonte du serveur et du navigateur une requête devrait renvoyer à la fois la page et son hash, sinon au moment où la deuxième requête est envoyée pour obtenir le hash, la page peut avoir légitimement changé. Tout ce que cela prouve vraiment, c'est que la page est la page que le serveur vous a envoyé et nous avons déjà HTTPS pour cela.

  0

Merci Rod, appréciez votre contribution. Ma conception originale était de permettre une transmission JS côté client sécurisée à partir d'un SERVEUR de confiance sur SSL/TLS, ce serait un actif relativement statique, le cas d'utilisation prévu est le cryptage côté client. Voyez-vous des pièges évidents, en plus de la crypto côté client habituel n'est pas sécurisé. 12 août. 132013-08-12 12:38:55

  0

Si vous l'utilisez pour prouver que l'url n'a pas été modifiée, vous perdez un peu de temps car https le prouve. Que voulez-vous dire par crypto côté client? Parlez-vous de l'authentification? 12 août. 132013-08-12 12:45:56

  0

Avec les différentes attaques sur SSL/TLS présentées à BlackHat 2013, mes préoccupations sont SSL/TLS aka HTTPS est déjà faible, pas nécessairement cassé. La preuve HTTPS n'est donc pas totalement infaillible. par exemple. Si une entité devait intercepter le trafic HTTPS (PRISM), je pourrais théoriquement modifier la réponse (fichier) au niveau du réseau ou encore remapper plus facilement l'URL du CDN sur un faux serveur et envoyer des ressources malveillantes. Mon cas d'utilisation prévu est de fournir une crypto inbrowser pour crypter les données de session sur le client en utilisant une clé partagée, et traiter uniquement les données cryptées sur le serveur. 12 août. 132013-08-12 13:04:19

  0

Si une partie malveillante peut changer le contenu de la page, alors ils peuvent certainement vous diriger vers n'importe quel actif qu'ils veulent (et désactiver toute validation basée sur javascript que vous implémentez) 12 août. 132013-08-12 13:17:56

  0

@RossDargan Correct, mais si je pouvais utiliser ce hachage/signature le serveur envoyé pour tester cela pour la validité, je pourrais alors rejeter la session, actualiser la page, avertir l'utilisateur et essayer de régénérer. Ou est-ce que je manque quelque chose? 12 août. 132013-08-12 13:22:42

  0

Si quelqu'un était malveillant, les chances sont qu'elles vous forceraient à obtenir des données d'un serveur différent sans vérification.S'ils voulaient l'obtenir de votre serveur alors ils pourraient probablement faire une attaque de MITM où ils vous obligent à faire un get à partir de là, ce qui fait une requête get à votre serveur pour obtenir un hachage valide, ils obtiennent alors ces données et retournent ça à toi. S'ils ont rompu SSL, ils ont vos cookies de session et peuvent donc vous usurper. 12 août. 132013-08-12 13:27:01

  0

@RossDargan, comment cela affecterait-il votre réponse? Lorsqu'un utilisateur frappe la page pour la première fois, vous créez un HTTP uniquement, HMAC Cookie sécurisé (SessionID, SharedSecret, scrypt (mot de passe), expire). Cookie est associé à une table DB Session (SessionID, données, HMAC, signature, expire). Toutes les données sont cryptées sur le client afin que le serveur ne puisse jamais lire les données. Donc, ce serait inutile pour un attaquant? 12 août. 132013-08-12 13:36:01

  0

Il devient difficile de comprendre ce que vous protégez réellement. Si vous craignez que ssl soit cassé, alors faire le cookie http n'a aucune importance - une attaque MITM ramasserait le cookie et pourrait m'a utilisé par l'attaquant pour déchiffrer toutes les informations requises. 12 août. 132013-08-12 14:09:26

  0

@RossDargan, je vais donner à ma question une réflexion et une reformulation. 12 août. 132013-08-12 14:15:02