Je me serais bien inscrit à ce concours mais il n'y a pas de langage que je maîtrise bien (Ruby, JS, Golang), ni que j'ai envie d'apprendre (Rust, F#, Clojure). Je trouve dommage qu'il n'y ait qu'une liste très restreinte de langages que l'on peut utiliser lors d'un tel concours. Pourtant, c'est une limite assez artificielle : un autre concours, l'Agile Cup, a su éliminer cette contrainte.
La plateforme de l'Agile Cup fonctionnait avec un énoncé (résoudre un labyrinthe) décliné en plusieurs niveaux de difficulté croissante (25 niveaux IIRC). On développait son programme chez soi, celui-ci se connectait au serveur de l'Agile Cup pour récupérer le premier niveau, le résoudre puis envoyer la solution au serveur. Si la solution était correcte, on avait alors accès au second niveau… pour 10 secondes ;-)
Le but était donc d'avoir un programme de plus en plus complet, capable de passer tous les niveaux. Et comme ce programme tournait chez soi, on pouvait le coder dans le langage de son choix. J'espère que cela inspirera les organisateurs de CodinGame pour les prochaines éditions.
PS : pour être honnête, je ne suis pas dispo le 25 octobre (vous saurez bientôt sur LinuxFr.org pourquoi ;-) ), sinon, j'aurais tenté le coup avec le C.
Img a visiblement un bug et a du coup atteint la limite du nombre de file descriptors qu'il peut ouvrir. Je l'ai relancé et je vais regarder de quoi ça vient, mais en attendant, il devrait resservir les images.
Pour le premier point, rien de bien compliqué, on crée une fausse page avec une vidéo youtube à la con (pour que la victime garde la page ouverte assez longtemps pour que l'attaque réussisse) et du javascript qui va générer les requêtes depuis une iframe cachée.
Pour le second point, il faut être en mesure d'écouter le trafic, ce qui est trivial sur du wifi mais peut aussi se faire sur des réseaux filaires (un hub, un switch que l'on floode, ARP poisoning, les techniques ne manquent pas).
Je ne suis pas persuadé, soit le script vient du site attaqué (ou est inclus depuis ses pages) auquel cas il a accès au cookie (il me semble)
Non, pas forcément, il existe un flag sur les cookies (httpOnly) et s'il est activé, le cookie en question ne sera pas accessible depuis le javascript.
soit il vient d'un domaine tiers auquel cas non seulement il ne peut pas lire le cookie mais ne peut pas générer de requête non plus vers le domaine à attaquer
Perdu, le javascript peut inclure une image provenant d'un autre domaine, le navigateur fera alors la requête vers cet autre domaine avec les cookies de l'utilisateur pour ce second domaine. Il existe même des techniques pour faire des requêtes POST vers d'autres domaines et pas juste des GET, on parle alors d'attaques CSRF.
J'ai jeté un coup d’œil rapide sur le code et il y a deux choses qui me gênent :
ça utilise le scripting lua de redis, or la version de redis qui tourne actuellement sur LinuxFr.org ne prend pas en charge cette fonctionnalité ;
ça passe par le hub de google, alors que l'on essaye d'éviter les services centralisés, tout particulièrement ceux de grosses sociétés pas très respectueuses de la vie privée de ses utilisateurs.
Sinon, c'est sympa d'avoir proposé un patch et il a l'air plutôt bien codé, donc ça devrait pouvoir se mettre en place rapidement :-)
On ne va pas modifier les règles du karma juste pour PBPG. De toute façon, quelles que soient ces règles, elles ne conviendront jamais à tout le monde. Du coup, je ferme cette entrée de suivi.
Un tout petit indice, en ROT13 de surcroît, ça ne devrait pas gâcher le niveau à qui que ce soit : Y'hgvyvfngrhe xnezn_sbhagnva ivfvgr geèf eéthyvèerzrag yr fvgr.
Dans le monde Ruby on Rails, le guide sur la sécurité est une très saine lecture. Sinon, on peut aussi trouver pas mal d'infos sur le site de l'OWASP (beaucoup de contenus, mais un peu trop fouillis à mon goût). Enfin, il y a quelques autres liens intéressants sur https://stripe-ctf.com/about
Heu, je peux me tromper mais je n'ai vraiment pas l'impression qu'un compte github soit obligatoire pour s'inscrire. Il suffit juste d'entrer une adresse email et un mot de passe pour s'inscrire.
D'autre part, pour les personnes comme moi qui ont utilisé leur compte github pour s'authentifier, ça se passe via OAuth et Stripe n'a pas accès à mon mot de passe. Le token OAuth ne donne qu'un droit de lecture sur les infos publiques.
Bref, pour autant que je puisse en juger, ça respecte les bonnes pratiques du développement web.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Accessibilité du rendu par défaut. Évalué à 3 (+0/-0).
Merci pour ce retour. Ça m'a pris du temps, mais c'est pris en compte.
Cf https://github.com/nono/linuxfr.org/commit/45733a62e3a503f9b74b00a0a4f0d8f0e5d8e0c1
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Chevauchement des liens sur les icônes de section. Évalué à 4 (+0/-0).
J'ai trouvé un hack CSS qui semble faire l'affaire. Cf https://github.com/nono/linuxfr.org/commit/1d35eed8a1bfa62401ae78b5440ef6bf21805aa9
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Impossible de déplacer un journal dans un forum. Évalué à 4 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/e5a680ec82313c09ff9c00e3f170a95b309f0d5d
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Catégorie "DragonFly BSD" et image qui va avec. Évalué à 4 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/dc387f002248959b1c07a64cabf04adc7424384a
# Changement
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Défilement extrêmement lent. Évalué à 3 (+0/-0).
J'ai remplacé l'image par des propriétés CSS3. J'espère que cela résout le problème. Cf https://github.com/nono/linuxfr.org/commit/e17eecff0da153b949f645419cca71c0475e7542
# Non
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Rendre publics les votes sur un commentaire. Évalué à 10 (+0/-0).
Non, on a déjà testé et tout ce que cela donne c'est « untel n'aime pas mes commentaires ? OK, je vais lui pourrir les siens ! ».
# Zut, pas de langage sympa
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Concours de programmation CodinGame. Évalué à 9.
Je me serais bien inscrit à ce concours mais il n'y a pas de langage que je maîtrise bien (Ruby, JS, Golang), ni que j'ai envie d'apprendre (Rust, F#, Clojure). Je trouve dommage qu'il n'y ait qu'une liste très restreinte de langages que l'on peut utiliser lors d'un tel concours. Pourtant, c'est une limite assez artificielle : un autre concours, l'Agile Cup, a su éliminer cette contrainte.
La plateforme de l'Agile Cup fonctionnait avec un énoncé (résoudre un labyrinthe) décliné en plusieurs niveaux de difficulté croissante (25 niveaux IIRC). On développait son programme chez soi, celui-ci se connectait au serveur de l'Agile Cup pour récupérer le premier niveau, le résoudre puis envoyer la solution au serveur. Si la solution était correcte, on avait alors accès au second niveau… pour 10 secondes ;-)
Le but était donc d'avoir un programme de plus en plus complet, capable de passer tous les niveaux. Et comme ce programme tournait chez soi, on pouvait le coder dans le langage de son choix. J'espère que cela inspirera les organisateurs de CodinGame pour les prochaines éditions.
PS : pour être honnête, je ne suis pas dispo le 25 octobre (vous saurez bientôt sur LinuxFr.org pourquoi ;-) ), sinon, j'aurais tenté le coup avec le C.
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi liens de note de page ne fonctionnant plus. Évalué à 3 (+0/-0).
Cf http://linuxfr.org/suivi/liens-markdown
# Img relancé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi image tag non accessible. Évalué à 3 (+0/-0).
Img a visiblement un bug et a du coup atteint la limite du nombre de file descriptors qu'il peut ouvrir. Je l'ai relancé et je vais regarder de quoi ça vient, mais en attendant, il devrait resservir les images.
Par contre, https://img.linuxfr.org/images/icones/tag.png, ça me paraît bizarre, ce n'est https://linuxfr.org/images/icones/tag.png que tu voudrais ?
[^] # Re: Mouais...
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Insertion de xHTML dans un contenu en Markdown. Évalué à 4 (+0/-0).
Tu veux dire « 1er étage » et « Paris Ier. » ?
# Précisions
Posté par Bruno Michel (site web personnel) . En réponse au journal La fin du monde est (une fois de plus) pour demain : SSL crime. Évalué à 10.
Ce genre d'attaques peut s'effectuer sur d'autres protocoles que HTTPS, genre SMTPS. SSL n'est pas cassé mais utiliser sa compression est une erreur.
[^] # Re: Réponse
Posté par Bruno Michel (site web personnel) . En réponse au journal La fin du monde est (une fois de plus) pour demain : SSL crime. Évalué à 5.
Pour effectuer l'attaque, il faut deux choses :
Pour le premier point, rien de bien compliqué, on crée une fausse page avec une vidéo youtube à la con (pour que la victime garde la page ouverte assez longtemps pour que l'attaque réussisse) et du javascript qui va générer les requêtes depuis une iframe cachée.
Pour le second point, il faut être en mesure d'écouter le trafic, ce qui est trivial sur du wifi mais peut aussi se faire sur des réseaux filaires (un hub, un switch que l'on floode, ARP poisoning, les techniques ne manquent pas).
[^] # Re: Réponse
Posté par Bruno Michel (site web personnel) . En réponse au journal La fin du monde est (une fois de plus) pour demain : SSL crime. Évalué à 6.
Non, pas forcément, il existe un flag sur les cookies (httpOnly) et s'il est activé, le cookie en question ne sera pas accessible depuis le javascript.
Perdu, le javascript peut inclure une image provenant d'un autre domaine, le navigateur fera alors la requête vers cet autre domaine avec les cookies de l'utilisateur pour ce second domaine. Il existe même des techniques pour faire des requêtes POST vers d'autres domaines et pas juste des GET, on parle alors d'attaques CSRF.
# Rapide avis
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi pubsubhubbub. Évalué à 4 (+0/-0).
J'ai jeté un coup d’œil rapide sur le code et il y a deux choses qui me gênent :
ça utilise le scripting lua de redis, or la version de redis qui tourne actuellement sur LinuxFr.org ne prend pas en charge cette fonctionnalité ;
ça passe par le hub de google, alors que l'on essaye d'éviter les services centralisés, tout particulièrement ceux de grosses sociétés pas très respectueuses de la vie privée de ses utilisateurs.
Sinon, c'est sympa d'avoir proposé un patch et il a l'air plutôt bien codé, donc ça devrait pouvoir se mettre en place rapidement :-)
# On ferme
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Karma "glissant". Évalué à 4 (+0/-0).
On ne va pas modifier les règles du karma juste pour PBPG. De toute façon, quelles que soient ces règles, elles ne conviendront jamais à tout le monde. Du coup, je ferme cette entrée de suivi.
[^] # Re: Comportement intéressant
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Problème lors d'un post contenant une image sans texte alternatif. Évalué à 3 (+0/-0).
Je confirme, on va garder le comportement actuel.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Impossible d’accéder au journal Frontend a aptitude. Évalué à 4 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/04c819895047dfcb46b06bc6a55a024143b8d67f
# Solutions
Posté par Bruno Michel (site web personnel) . En réponse au journal Jouer avec la sécurité web. Évalué à 4. Dernière modification le 30 août 2012 à 17:57.
Pour les curieux, http://blog.ioactive.com/2012/08/stripe-ctf-20-write-up.html et http://jasiek.posterous.com/stripe-ctf-20-walkthrough donnent les solutions des différents niveaux.
[^] # Re: intéressant mais c'est quoi le but ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Jouer avec la sécurité web. Évalué à 5.
J'espère. Si ce n'est pas le cas, je posterais ici des explications pour les premiers niveaux.
[^] # Re: Pas si facile !
Posté par Bruno Michel (site web personnel) . En réponse au journal Jouer avec la sécurité web. Évalué à 3.
Un tout petit indice, en ROT13 de surcroît, ça ne devrait pas gâcher le niveau à qui que ce soit : Y'hgvyvfngrhe xnezn_sbhagnva ivfvgr geèf eéthyvèerzrag yr fvgr.
[^] # Re: Merci bien...
Posté par Bruno Michel (site web personnel) . En réponse au journal Jouer avec la sécurité web. Évalué à 5. Dernière modification le 24 août 2012 à 00:00.
Dans le monde Ruby on Rails, le guide sur la sécurité est une très saine lecture. Sinon, on peut aussi trouver pas mal d'infos sur le site de l'OWASP (beaucoup de contenus, mais un peu trop fouillis à mon goût). Enfin, il y a quelques autres liens intéressants sur https://stripe-ctf.com/about
[^] # Re: Compte github requis
Posté par Bruno Michel (site web personnel) . En réponse au journal Jouer avec la sécurité web. Évalué à 10.
Heu, je peux me tromper mais je n'ai vraiment pas l'impression qu'un compte github soit obligatoire pour s'inscrire. Il suffit juste d'entrer une adresse email et un mot de passe pour s'inscrire.
D'autre part, pour les personnes comme moi qui ont utilisé leur compte github pour s'authentifier, ça se passe via OAuth et Stripe n'a pas accès à mon mot de passe. Le token OAuth ne donne qu'un droit de lecture sur les infos publiques.
Bref, pour autant que je puisse en juger, ça respecte les bonnes pratiques du développement web.
[^] # Re: pour éviter ce genre de petits c...
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi faille xss et un gosse qui joue avec. Évalué à 3 (+0/-0).
Est-ce que quelqu'un se souvient de la règle exacte pour le timer ?
[^] # Re: Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi faille xss et un gosse qui joue avec. Évalué à 3 (+0/-0).
Oui, ajouté avec https://github.com/nono/linuxfr.org/commit/df806ab9562f33e31af9cc19e86ff5dad371fe33
[^] # Re: Slip plus performant
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi faille xss et un gosse qui joue avec. Évalué à 3 (+0/-0).
Il se trouve où ce code ?