Sécurité info - Page 7

Microsoft Account login name
prevent Microsoft Edge and Internet Explorer from leaking your account credentials

les solutions me semblent simple: pas de MS account, pas de edge, pas de IE...

http://blog.ioactive.com/2016/08/multiple-vulnerabilities-in-bhu-wifi.html

Lisez TOUT c'est magnifique

Ca déchure l'anis ^^

Normal ^^
(plus rien ne m'étonne avec les produits Chinois)

Ca aurait été bien qu'il prenne une grosse marque comme xiaomi voir si c'est le même délire. D'ailleurs ça pourrait être comme ça même avec des grosses marques non Chinoises, la plupart du temps les routeurs sont des models spéciaux pour la Chine.

Un joli ouate ze fuque..

Enfin au pire on a le hardware suffit de changer la merde de soft made-in-china par un truc plus propre, ca ne doit pas etre bien complique, si les chinois y arrivent...

oui enfin faut faire le portage openwrt... la le machin est probablement un soft linux de reference du fournisseur de SoC...

mais openwrt donnerait des perfs moins bonnes, apparemment (par absence de drivers corrects)

ca s'écrit les drivers, et honnêtement je doute que les drivers chinois soit un modele de performance!

ca s'écrit a la vitesse d'une tortue, et uniquement quand il y a un datasheet...

On a pas la meme experience alors.

avec ta magnifique experience tu sais écrire des drivers linux de SoC MIPS chinois rapidement et sans documentation?

Tellement inconnu que google trouve des trucs en pas longtemps:

https://forum.openwrt.org/viewtopic.php?id=42449

A vu de nez, c'est la meme version de uboot

Un peu plus sur les TP-Link ici: https://wiki.openwrt.org/toh/tp-link/tl-wr841nd

Et oui j'ai deja eu a faire marcher des boards avec au mieux la schématique (incomplete ou pas dans la bonne version) au pire juste le CPU utilisé, google, et la carte dans les mains.

faire marcher, ok, pas écrire un driver

C'est dingue ça, c'est béant comme faille si j'ai bien compris

Mouarf, malin, et pas évident à corriger en attendant que ça le soit dans les navigateurs !

• Zeph part autoriser son serveur web local pour le domaine "localhost" uniquement

Folco : rétrospectivement, oui, mais il fallait y penser (surtout le coup du serveur DNS).

Zeph (./196) :
• Zeph part autoriser son serveur web local pour le domaine "localhost" uniquement

Le problème, c'est que ces attaques font croire au serveur que la requête vient de localhost, justement (parce que c'est ton navigateur qui fait la requête sans que tu ne le saches).

Oui, mais si tu configures ton serveur web pour répondre au virtual host "localhost" uniquement, il va rejeter les requêtes pour "tutu.dnsrebinding.machin.com" même si ce domaine pointe vers 127.0.0.1. Du coup le serveur va quand même répondre (on peut deviner que tu héberges un serveur web chez toi, savoir lequel et connaître sa version) mais normalement tes fichiers sont protégés, non ?

Je ne sais pas comment les serveurs web gèrent le domaine un peu particulier "localhost", mais il me semble évident que mettre en place un contrôle un cran plus haut, au niveau du firewall logiciel sur le poste, le problème est assez vite résolu.

comment ça ?
1) C'est ton navigateur web qui fait la requête, donc le firewall ne va pas dire grand-chose
2) 'localhost' est un nom de domaine commun autre pour les serveurs web, non ?

1. Si j'ai bien compris, l'usurpation se fait au niveau du contenu de la requête HTTP (qui est au niveau applicatif, si je ne m'abuse). Si tu refuses (au niveau du firewall) tout ce qui ne vient pas de 127.0.0.1 au niveau transport, ces requêtes HTTP n'arriveront jamais au serveur.
2. J'aimerais bien pouvoir te dire que oui, mais je n'en suis pas certain. Justement pour (normalement) éviter qu'un DNS corrompu ne réécrive la définition de "localhost". Après, c'est juste une supposition, mais comme il s'agit d'une spécificité normalisée, ça ne m'étonnerait pas qu'il y ait des traitements particuliers.

Non, c'est le DNS qui est changé.
1) l'attaquant maîtrise le DNS et phishing.com vaut 8.8.8.8
2) ton navigateur charge la page infectée http://phising.com/
3) l'attaquant met à jour son DNS et phishing.com vaut 127.0.0.1
4) ton navigateur fait maintenant une requête JavaScript sur phishing.com:6379 (pas de problème de sécurité vu que c'est le même domaine)

niveau transport, on a une requête de 127.0.0.1 vers 127.0.0.1
niveau HTTP, on a une requête de 127.0.0.1 vers phising.com, mais c'est souvent ignoré par les serveurs web de dév ou complètement ignoré par les autres protocoles (redis ou elasticsearch)

D'accord, j'avais compris le problème partiellement à l'envers, merci du détail.

"Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use."

Je fait l'imprimer sur du A0 tellement c'est ENORME!

N'oublie pas la suite :

I see no data protection issues for these requests, data protection only applies to consumers not businesses so there should be no issues with this information.

En effet mais je trouve ca moins fort de sens .. (mais ca reste bien gros.. )

O_o je n'ose pas imaginer la panique du technicien en voyant les demandes ubuesques...

ou le gros bidonnage avec les collègues