Un attaquant peut-il renifler des données dans une URL via HTTPS?

19

Les données incluses dans une URL peuvent-elles être considérées comme sécurisées si la connexion est établie via HTTPS? Par exemple, si un utilisateur clique sur un lien dans un e-mail pointant vers https://mysite.com?mysecretstring=1234 , un attaquant pourrait-il récupérer "mysecretstring" dans l'URL?

security https url

— James Cadd
source

27

L'ensemble de la requête HTTP (et de la réponse) est crypté, y compris l'URL.

Mais oui, il existe un moyen pour un attaquant de récupérer l'URL complète: via l'en-tête Referer. S'il existe un fichier externe (Javscript, CSS, etc.) qui n'est pas sur HTTPS, l'URL complète peut être reniflée dans l'en-tête Referer. Idem si l'utilisateur clique sur un lien dans la page qui mène à une page HTTP (pas SSL).

De plus, les requêtes DNS ne sont pas cryptées, donc un attaquant pourrait savoir que l'utilisateur va sur mysite.com.

— Julien
source

Lorsque vous dites "l'URL complète", cela inclut-il les paramètres (par exemple mysecretstring = 1234)?

— sampablokuper

Sur l'en-tête Referer, si les paramètres sont dans l'URL, cela peut être vu

— chmeee

1

donc, ne chargez aucune image externe, css, js. utiliser / stocker la chaîne secrète et rediriger en interne pour se débarrasser de la chaîne secrète. après cela, vous pouvez utiliser des URL externes.

— Neil McGuigan

14

Non, ils peuvent voir la connexion, c'est-à-dire mysite.com mais pas le? Mysecretstring = 1234 le https est serveur à serveur

— Chris
source

6

En fait, ils ne peuvent même pas voir à quel nom de domaine vous vous connectez, mais à quelle adresse IP. Étant donné que les certificats SSL ne fonctionnent que raisonnablement sur une relation 1: 1 nom de domaine-adresse IP, cela est très probablement hors de propos. De plus, si l'attaquant peut renifler votre trafic DNS, cela pourrait être révélé. Les paramètres GET et POST sont aussi sécurisés que le trafic HTTPS: si vous êtes le client et que le certificat de serveur est valide et sans compromis, les données sont protégées contre les écoutes par des tiers.

— Paul

0

Ils devraient avoir la clé de chiffrement. Théoriquement, ce n'est pas possible, mais n'importe quelle bonne attaque le pourrait. C'est tout le but de SSL pour crypter toutes les données envoyées vers et depuis le serveur pour éviter de pouvoir renifler.

— Chris
source

0

Gardez vos blogs en sécurité ou ne les écrivez même pas. Si vous obtenez un exploit à distance où les journaux peuvent être lus, toutes les données URL seront visibles dans les journaux.

Les données de publication ne figurent pas dans les journaux.

— Ryaner

tout cela dépend de la configuration =)

— spacediver

-1

Seulement s'ils sont capables de renifler l'authentification https via une sorte d'usurpation d'identité

— Jimsmithkka
source

Voulez-vous dire une attaque d'homme au milieu? C'est plus que renifler, l'attaquant doit usurper l'identité du serveur.

— Julien

bien son MiM pour la poignée de main, mais après il ne fait que renifler, l'outil spécifique est le hamster et le furet que j'ai vu démontré

— Jimsmithkka