ENCORE ??? Mais je croyais qu'elle avait été corrigée, cette faille ?

AAAwwwww... je viens de réaliser que quand vous chargez une image dans votre canvas qui ne provient pas du même domaine que la page en cours, les navigateurs vous refusent l'accès aux pixels avec getImageData() (pour des raisons de sécurité, bien sûr.).   Adieu les manipulations d'image.  :-(((
Du coup, Javascript est nettement moins intéressant pour réaliser un webGobbler dans le navigateur, sauf à transformer mon site en gigantesque proxy pour images (beuark... et ça plairait moyen à mon hébergeur, je crois)  :-(((

EDIT: http://lehollandaisvolant.net/index.php?mode=links&id=20130408154008
Marche pas non plus: Je me fais jeter pour des raisons de sécurité quand je veux faire un .toDataURL().  Tant pis.  Merci.

Juste un warning contre ce genre de choses:
 - les proxy ne masquent pas forcément votre adresse IP réelle.
 - ils VOIENT TOUT VOTRE TRAFIC HTTP, donc méfiance.
 - ils ont la possibilité technique de substituer n'importe quoi dans les pages.

Entre-aperçu des forums du marché noir de la sécurité informatique: http://www.xylibox.com/2013/04/darkode-leak.html

Vous avez sûrement déjà du voir passer cette news...

Rhaa... non... le même bug que chez Debian: un tout petit bug sur le générateur de nombres pseudo-aléatoire, et c'est la faille SSL.
(<troll> Le plus amusant, c'était les commentaires des BSDiens sur Debian quand la faille était arrivée chez Debian: "Ah, c'est pas chez BSD que ça arriverait. BSD c'est super sécurisé !" </troll>)

EDIT: à propos des générateurs de nombres aléatoires: http://sebsauvage.net/rhaa/index.php?2011/08/25/07/32/33-le-hasard-est-une-chose-difficile-pour-un-ordinateur

GitHub subit actuellement un DDOS.

Ah... pas glop. J'espère juste que des services comme OpenDNS savent contrer les attaques par amplification (même si je ne vois vraiment pas comment).
Ou alors il faudra probablement déclarer son IP sur leur site web avant de pouvoir utiliser leurs DNS   :-/
(source: http://blog.cloudflare.com/good-news-open-dns-resolvers-are-getting-clos)

Haha ! Super EA: Visiblement on peut bidouiller les fichiers côté client dans SimCity... et cela affecte les jeux côté serveur. Conséquence: VOUS POUVEZ FOURTRE LA MERDE DANS LES VILLES DES AUTRES JOUEURS.
Bien joué EA.
On est en 2013, et malgré son jeu qui exige une connexion internet permanente, EA n'a toujours pas compris un des principes de base de sécurité du mode client/serveur: Ne jamais faire confiance aux données client.

Oups...

Ça y est, j'ai enfin réinstallé Certificate Patrol dans Firefox, car ils ont enfin implémenté ce que j'attendais: La possibilité d'ignorer certains changements de certificats pour des domaines spécifiques, tant que l'autorité racine ne change pas (merci à Google qui - avec ses CDN à la con - n'est pas foutu d'avoir des certificats synchronisés sur ses différents serveurs pour un même domaine -- d'où des alertes incessantes avec les anciennes versions de CertPatrol.)

Pour ceux qui ne seraient pas au courant du problème posé par les certificats racines SSL, je vous recommande la lecture de ces articles:
http://sebsauvage.net/rhaa/index.php?2010/08/18/11/16/54-des-extensions-firefox-pour-controler-les-certificats-https
http://sebsauvage.net/rhaa/index.php?2010/11/08/19/54/41-je-suis-content-d-utiliser-certpatrol

Avec ce qui se passe de nos jours (surveillance des gouvernements, vente de matériel de surveillance, certificats frauduleux, autorités racines douteuses ou piratées...), je considère que cette extension devient aussi indispensable que WOT ou AdBlockPlus.

LOL.

Et voilà une nouvelle source pour le Rainbow Cracking.
http://crackstation.net/

Sauf que - je le répète - si votre système de stockage de mots de passe utilise un salt, ces jolies tables de hash sont inutilisables pour retrouver les mots de passe.

Tiens... la nouvelle version d'Avast vérifie la version des logiciels installés afin de vous prévenir de vulnérabilités. D'autres éditeurs ont-ils eu cette excellente idée ? Parce que c'est un des points d'entrée majeur des infections: Je veux parler de vieilles versions de Java, Flash, Shockwave et autres.

LOL

CloudFlare donne les raisons techniques de sa panne (cf.http://sebsauvage.net/links/?URz2-w). S'il y a une chose à leur crédit, c'est qu'ils sont toujours totalement transparents quand il y a des problèmes ou des piratages chez eux. C'est à ce prix qu'ils gagnent la confiance de leurs clients.
Et ils ont raison: La sécurité par l'obscurité ne marche pas.

Si vous pensiez vous mettre à l'abri des scans en déplaçant le port de votre serveurs ssh de 22 à 2222, vous avez tout faux. Tout le monde utilise déjà 2222. Prenez carrément des ports beaucoup plus élevés (hé... vous pouvez aller jusqu'à 65535 !), et surtout n'oubliez pas: Installez fail2ban !
(ou encore, connectez-vous avec des certificats et désactivez les mots de passe.)

Voilà (coucou tester): Java est désormais la principale source d'infection.

J'étais complètement passé à côté de ça (merci Nono): Malekal et botnets.fr se sont associés pour lancer ce site à destination du grand public pour sensibiliser les internautes à la sécurité. Je ne peux qu'approuver (ayant moi-même fait ce genre de page, mais sans doute en moins didactique et attrayant: http://sebsauvage.net/safehex)

Mais enfin... NON !  On utilise JAMAIS un UUID comme token !  Rhhâââ...
Les UUID offrent la garantie d'unicité, mais en **aucun cas** d'aléa non prédictible.
Ou alors il faut recourir à des fonctions crypto, par exemple en concaténant un salt à l'UUID et en hashant le tout (sha1 ou autre). Là on a un token assez solide (et résistant à l'attaque d'anniversaire). L'idéal étant tout de même un véritable générateur aléatoire, mais ce n'est pas à la portée de tous.
(Et là je viens de m'apercevoir que dans Shaarli, comme un con, j'ai oublié d'ajouter un salt avant de hasher pour générer les tokens ...  doh. Rassurez-vous, le risque sécurité est très faible (Je vois mal quelqu'un lancer une attaque d'anniversaire à travers une attaque CSRF... ou alors je me trompe ? En javascript ? ça me paraît assez peu réaliste.)

(Oui j'ai bien conscience que j'ai dû perdre quelques lecteurs depuis le début de cet article.)

EDIT: Si vous voulez patcher Shaarli tout de suite, dans la fonction getToken() modifiez la ligne:
$rnd = sha1(uniqid('',true).'_'.mt_rand());
en:
$rnd = sha1(uniqid('',true).'_'.mt_rand().'####CE QUE VOUS VOULEZ, ÇA PEUT MÊME ÊTRE ASSEZ LONG####');

Et voilà. Bye bye l'attaque d'anniversaire.

Un bug de "privilege escalation"... provoqué par un pilote de carte graphique. Doh.

Bloqué à 200 km/h pendant 200 km dans sa Renault Laguna.
Mais à part ça, tout va bien, les millions de lignes de code des automobile n'ont pas de bug. Non non, ce n'est pas possible.
EDIT: ça pourrait être une manœuvre de la part du conducteur (merci : http://www.courrier-picard.fr/courrier/Actualites/Info-regionale/Miracule-mais-sans-permis-de-conduire (via g.neuromancien.free.fr)

Pourquoi, hein, pourquoi les Chinois ont-ils le plus gros taux d'infection par des malwares ? Parce que ce sont les plus gros utilisateurs d'Internet Explorer.
Et quand je parle d'IE, je parle aussi d'IE6. Oui oui, vous avez bien lu.
Quand IE6 est à 0,4% aux USA ou 0,1% en Norvège, est il à 21,3% en Chine (!).
(source: ie6countdown.com)

Et vous vous doutez bien que s'ils sont aussi en retard sur les navigateurs, ils doivent avoir aussi plusieurs versions de retard sur Flash, Java et Acrobat Reader.  Je vous laisse imaginer la boite de pétri que ça donne.  Pouah.

Et après ont s'étonne de voir des attaques ou du spam venir d'IP chinoises...

Cette page recense différentes formes d'attaque (dont XSRF). Pas encore eu le temps de lire mais ça a l'air bigrement intéressant.
Ça explique aussi la raison pour laquelle Google ajoute while(1); au début de tout json renvoyé par des services comme GMail: http://stackoverflow.com/questions/3146798/why-do-people-put-code-like-throw-1-dont-be-evil-and-for-in-front-of

à mon avis, une lecture à garder sous le coude sur la sécurité web.

Héhé... Je n'avais pas regardé mes logs de connexion Shaarli, et j'y ai vu ça:

2012/08/18_13:51:38 - 82.242.x.x - Login successful
2012/08/18_14:39:50 - 82.242.x.x- Login successful
2012/08/18_15:18:02 - 92.147.x.x- Login failed for user sebsauvage' --
2012/08/18_15:18:17 - 92.147.x.x- Login failed for user sebsauvage" --
2012/08/18_15:38:51 - 82.242.x.x- Login successful
2012/08/18_16:10:54 - 82.242.x.x- Login successful

C'est mignon   :-D