Forum > Le Hall > Suggestions pour le forum, le site de l'AE, FAQ, Hotline > Comment aller au gala gratos en tuant le site AE

Comment aller au gala gratos en tuant le site AE

Reply Mark as favorite

1

Profile
Sli

Salut tout le monde, comment ça va ? Intéressé par une petite histoire tristement drôle sur le site AE ? Vous êtes au bon endroit ! Accrochez-vous, ça peut être légèrement technique !

Comment aller au gala gratos en tuant le site AE au passage ?

Ça vous intéresse ? Dommage, c'est trop tard maintenant, on a réglé le problème. Il n'empêche que ça reste assez intéressant à raconter.

Comment s'y prendre ?

  • Avoir effectué au moins un achat sur le site AE
  • Avoir le lien de l'eticket de quelqu'un d'autre
  • Y accéder avec son compte
  • Attendre en espérant que le site ne crash pas avant
  • Se prendre une erreur « time out » de toute façon

Si on veut juste faire planter le site, il suffit d'y accéder avec un compte qui n'a pas les accès du tout.

La découverte

Ça fait déjà plusieurs années que le site AE fait office de billeterie en ligne, comment est-ce possible que nous ne nous soyons pas rendu compte de ce bug avant ?

Lors de l'achat d'un eticket, un mail est envoyé au client. Ce mail contient un lien vers le récapitulatif des achats de l'utilisateur, c'est directement depuis cette interface que les etickets pouvaient être téléchargés.

Récemment, nous avons commencé à envoyer un lien direct vers ce eticket, c'est là où les choses se compliquent. Il suffisait que l'utilisateur ne soit pas connecté pour qu'il se retrouve dans une situation où il n'avait pas les droits de visionnage et donc provoquer le bug qui met le site en PLS. Il s'agit donc de la première fois où nous avions à faire à ce bug à une aussi grande échelle, ce qui a provoqué énormément de perturbations !

Ça viens d'où ce bug ?

Tout repose sur notre système de permissions. Voyez-vous, lorsque vous accédez à une page, nous vérifions automatiquement si vous avez les droits de la visionner. Pour les etickets c'est pareil, nous vérifions qu'il vous appartient avant de le générer et de vous le transmettre.

Mais du coup, il se passe quoi ? Eh bien, dans notre brique fondamentale de vérification, nous faisons la distinction entre deux cas, celui où il s'agit d'un seul élément qui est accédé (le cas ici entre autre) ou celui où il s'agit d'une liste d'éléments (la recherche d'utilisateur par exemple). Pour faire automatiquement la différence entre ces deux cas d'usage, nous utilisions ce que nous appelons un try/catch. On agit comme si on savait qu'il s'agissait d'un unique élément. Si une erreur était produite, nous outrepassions l'erreur et considérions que c'était une liste d'élément. Simple, efficace mais dangereux, comme nous allons le voir.

Dans ce cas précis, puisque nous n'avions pas la permission d'y accéder, une erreur était levée quelque part et le système de permissions considérait juste que c'était une liste d'éléments. Il se mettait donc à récupérer l'intégralité des ventes et les testaient une à une pour savoir si l'utilisateur avait le droit de les voir. Pour donner une idée de la taille de notre base de données de vente, elle dépasse les 910 000 éléments !

La conséquence de tout ça est que chaque fois que ce bug se produisait, le site se mettait à consommer de plus en plus de mémoire vive (RAM). Au bout d'un moment, il n'y en avait plus et pouf ! Tout plante ! Le système ne peut plus fonctionner du tout, le site est inaccessible.

Correction côté infrastructure

Dans un premier temps, le temps que l'on identifie clairement le bug côté code, nous avons procédé à quelques correctifs au niveau de l'infra. L'infra, c'est le nom sympa qu'on donne à toute la partie administration de machines, là où on fait fonctionner le site AE.

Nous avons configuré le serveur pour qu'il tue l'exécution de la requête si elle dépasse un certain temps d'exécution, ce qui libère la mémoire utilisé et soulage fortement le serveur.

Nous avons également établi un nombre de requête maximal avant que le serveur ne rende la mémoire (c'est très simplifié) afin d'éviter l'effet « ballon ». Mis simplement, plus le site consomme de mémoire, plus on lui réserve de la mémoire. Le serveur se souvient du seuil maximal que le site a utilisé et lui réserve cette mémoire. Cela évite de libérer la mémoire pour la redemander au système juste après. Plus le serveur est lancé depuis longtemps, plus il consomme de mémoire, surtout dans le cas où nous étions.

Même après tous ces correctifs, il était encore très simple de faire tomber le site AE. Il suffisait de lancer en parallèle plusieurs requêtes buggées et le tour était joué. Nous avons tout de même gagné du temps pour supprimer le problème à la source !

Correction côté code

Après avoir installé quelques gardes fous, nous avons pu nous poser sereinement sur le problème. Nous avons réécrit une partie de notre système de permissions, testé et réparé les zones du site où ce changement provoquait des erreurs, relu plusieures fois par différentes personnes (merci Skia) avant d'envoyer les modifications en production (en ligne).

Pour ceux qui sont intéressés, il est possible de voir ces modifications ici : https://ae-dev.utbm.fr/ae/Sith/merge_requests/251.

Venez nous aider

Si vous souhaitez apporter votre pierre à l'édifice, nous recherchons toujours des bénévoles motivés.

Si vous ne savez pas et que vous ne souhaitez pas apprendre à coder ou gérer l'infra, nous recherchons toujours des bénévoles pour la communication et la gestion d'équipe.

Si en revanche vous êtes intéressé par le côté technique, foncez ! Le challenge est très intéressant !

Dans tous les cas, rejoignez nous les mercredi soirs au foyer à 19h30 où nous nous rassemblons pour discuter. Vous pouvez aussi nous contacter à ae.dev@utbm.fr.

N'oubliez pas, contribuer, c'est la vie !


Someone :"Tu donnerais ce try/catch à quelqu'un que tu aime bien ?" AE-info : "Passons à la mise en prod'"


Ce titre est un clic-bait. Après lecture, je dois quand même payer ma place et n'aurait pas le plaisir de crasher le site .... Rendez moi mes 2 minutes de lecture perdues !!

PS : bonne vulgarisation, j'ai l'impression (peut être fausse), d'avoir compris un truc.

PPS : merci, parce que faire tourner tout ce bouzin info AE ca reste un bon boulot ingrat.

IMSI INP - Master A2I - Double diplomé - Bac +10 les enfants, c'est ca la puissance intellectuelle !


C'est vraiment cool de faire des communiqués sur le dev du site ae, super boulot Sli ^^


Citation de MouMan

Ce titre est un clic-bait. Après lecture, je dois quand même payer ma place et n'aurait pas le plaisir de crasher le site .... Rendez moi mes 2 minutes de lecture perdues !!

PS : bonne vulgarisation, j'ai l'impression (peut être fausse), d'avoir compris un truc.

PPS : merci, parce que faire tourner tout ce bouzin info AE ca reste un bon boulot ingrat.

Tu viens pour de vrai ???

Reply

1