Fonctionnement technique de Jeuxvideo.com

Introduction

Jeuxvideo.com utilise 2 serveurs frontaux qui sont depuis le 7 mai 2022 protégés par le service Cloudflare. Chaque serveur frontal utilise un serveur HTTP Apache, tout ce qu'il y a de plus classique. En revanche, avant d'arriver sur le serveur Apache, on a plusieurs mailles dans la chaîne. En effet, lorsque vous faites une requête auprès de JVC, la chaîne suivante est effectuée avant d'arriver jusqu'au back-end :

Cloudflare → Round-robin entre les 2 serveurs frontaux → HAProxy → Varnish → Apache → PHP / Express (Node.js)

Processus d'une requête HTTP

Cloudflare est le premier point d'entrée pour accéder à JVC. Il gère les enregistrements DNS du site et ses IPs sont majoritairement aléatoires et anycastées/géocastées. Ce service touche la couche réseau/transport tout comme la couche applicative du modèle OSI : il fait office d'anti-DDoS à forte valeur (bien que JVC utilise le service "Volterra" en tant qu'anti-DDoS sur couches basses du côté des IPs de son AS 35717). Une partie de la couche applicative est protégée par Cloudflare, via des règles éditées manuellement par Webedia (entre autre, blocages de pools IPv4 de VPN connus, et de certains pays d'après certains retours d'utilisateurs).

Un round-robin est effectué via Cloudflare auprès des serveurs DNS de Webedia. Le but est de déterminer de façon algorithmique quel serveur frontal va être utilisé pour la requête HTTP.

HAProxy est un proxy et load-balancer TCP d'une efficacité remarquable, il est utilisé sur la totalité des environnements de production gérés par Webedia. C'est entre autre ce service à l'origine de l'erreur 403 Forbidden. En effet, HAProxy fait aussi office de protection applicative (on peut donc en déduire que JVC utilise plusieurs services sur couche haute pour protéger l'applicatif). On peut notamment remarquer le blacklistage des IPs du réseau "Tor", mais également le blacklistage des pools de l'AS 16276 (appartenant à la société OVH et n'étant utilisé que dans des contextes d'hébergement) - blocage mené suite à l'utilisation massive des services de la société OVH dans le but de scrapper/attaquer JVC.

Apache est un serveur HTTP. Il a été optimisé par l'équipe technique actuelle de Webedia, mais également par l'ancienne équipe du site (on peut notamment citer Dargor et Haazel en tant que personnes ayant participées à l'élaboration de tunning du serveur HTTP).

Le dernier point est selon la page qui est demandée. Des parties du site sont développées en PHP, et d'autres en Node.js. Pour l'anecdote, le site est hébergé côté serveur dans le dossier /opt/datas/sites/JEUXVIDEO.COM/^[1]. Il n'y a quasiment aucune protection de ce côté (si ce n'est une protection contre les IPs Tor).

Protection applicative Cloudflare

L'applicatif est donc, comme on a pu le voir, protégé par Cloudflare en premier point d'entrée. Cloudflare est binaire : si l'IP source est blacklistée, une HTTP 403 est retournée et l'accès à l'URI est refusé.
Le blocage est en outre simple à bypasser, pour le moment, on peut constater que l'usage d'IPs géolocalisées en France est un bon bypass.

Domaine de fichiers statiques

static.jvc.gg est notamment utilisé pour servir les feuilles de styles et scripts et utilise comme serveur nginx au lieu d'Apache. N’étant pas protégé par Cloudflare en janvier 2023 il permet d’avoir un aperçu technique de comment était servi l’ensemble du site avant la mise en place de Cloudflare.

Côté DNS, cinq serveurs de noms sont utilisés : ns1.webedia-group.org, ns2.webedia-group.net, ns3.webedia-group.com, ns4.webedia-group.biz, ns5.webedia-group.app. Les deux premiers sont sur leur AS 35717 ; les trois derniers sont respectivement hébergés chez Scaleway, OVH, Gandi.

Avant Respawn

Avant Respawn, JVC était développé sur plusieurs langages différents côté back-end : on peut citer le C et le PHP. La base de données finale utilisait le moteur de base de données PostgreSQL. L'anarchie technique du back-end a menée au développement de Respawn (qui est également anarchique).

Les Cartes de visite

Les Cartes de visite étaient développés en PHP et avaient la particularité notable de stocker les données publiques de chaque utilisateur (par exemple, sa description personnelle) dans de simples fichiers HTML stockés sur disque : il n'y avait pas de requête SQL d'invoquée pour obtenir certaines données liées aux CDV. Lors de certains floods d'avis utilisateurs (notamment menés par UnifiedLinux), les CDV retournaient aléatoirement des pages blanches. La cause est toujours inconnue.

Les forums

Les forums étaient en C, et Dargor les nommaient "modulaires".

Les articles

Les articles n'étaient pas mis en ligne immédiatement après leur rédaction. Un système de "compilation" était nécessaire et à effectuer manuellement afin que le site "compile" les articles pour qu'ils deviennent accessibles au public. On peut imaginer que ce système de compilation a été développé dans un but de gestion de charge applicative.

Modération

La modération des forums était liée à une authentification à 2 étapes, menant à l'attribution du cookie mocoedivxuejdom permettant la modération de certains forums selon les permissions attribuées à chaque modérateur. Cette deuxième étape était une page spéciale réclamant 5 mots de passe, qui avaient la particularité d'être remplis de caractères aléatoires et spéciaux.

Authentification

Le cookie wenvjgol était utilisé pour l'authentification.

La recherche des forums

La recherche des forums était connue pour être atrocement lente et affichant incorrectement la liste des résultats, des topics étaient manquants et s'affichaient une fois sur deux.

Sécurité informatique

Lorsqu'une IP tentait d'envoyer trop de requêtes HTTP (HTTPS n'était pas déployé à ce moment-là), le site redirigeait chaque requête HTTP vers une erreur 404. La page d'erreur 404 étant très peu consommatrice techniquement, cela permettait de désaturer la charge serveur en cas de DoS/DDoS.

Sur les CDV et les forums, il y a eu un grand nombre de failles XSS, notamment exploitées en masse par PyjamaSam.

Le Captcha était également tout le temps cassé, permettant des floods de topics/messages/contributions. Cela a permis par exemple de créer un pseudo rang rubis en moins d'un jour, dont le pseudo était RubyOne (par UnifiedLinux, qui a également créé un pseudo rang diamant en moins d'un jour via un flood de contributions).

Respawn

Respawn a été développé entièrement en PHP côté back-end. Il utilise notamment des frameworks tels que Symfony côté forums, et des moteurs de templates tel que Twig. Respawn semble être divisé techniquement en plusieurs parties : en effet, on peut constater que certaines parties du site respectent le modèle vue-contrôleur (on peut citer les forums), bien que d'autres parties du site n'utilisent pas ce modèle et utilisent de l'url rewriting hardcodé dans des fichiers .htaccess. Respawn semble posséder une base de code identique entre JVC et ForumJV (désormais fermé), on pouvait constater de nettes interactions entre les 2 sites lorsque ForumJV était ouvert, interactions ayant menées à certains abus (ForumJV accordait des droits de modération sur son forum personnel, des failles de sécurité était donc existantes derrière ce privilège).

Schéma de base de données

Le schéma de base de données de Respawn semble anarchique et composé de mélange entre le Français et l'Anglais. Exemples de tables appartenant à Respawn : "get_compte_infos", "session_renew_v2", "jeu_get_v7". Notez le "v" à la fin de chaque table, laissant penser qu'il existe plusieurs versions de celles-ci.

Exemple d'appel en base de données

SELECT out_id_type, out_nom_type, out_dirname_type, out_affichage, out_date_publication, out_date_modification, out_id_alias_auteur, out_id_groupe_auteur, out_ip, out_titre, out_texte, out_commentaire, out_visibilite, out_liaisons, out_tags, out_medias, out_version, out_fiche, out_jeu, out_data, out_url, out_id_jeux FROM jeu_get_v7 WHERE id_contenu = xxx

Organisation technique

Comme dit précédemment, Respawn semble être un mélange de MVC et de code classique sans modèle particulier de respecté. Les fichiers du back-end sont également mitigés du côté de leur appellation, laissant encore droit au mélange entre Français et Anglais. Exemples de fichiers côté back-end :

/opt/datas/JEUXVIDEO.COM/htdocs/forums/liste_topic.php
/opt/datas/JEUXVIDEO.COM/app/modeles/core/OiPDOStatement.php
/opt/datas/JEUXVIDEO.COM/app/modeles/sso/Transaction.php
/opt/datas/JEUXVIDEO.COM/app/modeles/GoogleTagManager.php
/opt/datas/JEUXVIDEO.COM/app/modeles/sso/Compte.php
/opt/datas/JEUXVIDEO.COM/app/controllers/forum/liste_topic.php
/opt/datas/JEUXVIDEO.COM/app/modeles/sso/Session.php
/opt/datas/JEUXVIDEO.COM/app/vendor/...

Nommage des fonctions

Respawn possède aussi des fonctions dont le nommage est entre le Français et l'Anglais. Exemples de fonctions côté back-end :

getInfoFromIdForum
loadMenu
checkMenuItem
getSingleton
getHtmlJeuForum
blocHtmlBoutiqueRandom

Optimisations

Le back-end PHP utilise Memcache (https://www.php.net/manual/fr/book.memcache.php) afin de faire baisser la charge technique de l'applicatif.

Stockage des utilisateurs

Depuis Respawn, les utilisateurs de JVC sont référencés sous un identifiant numérique côté base de données, contrairement au fonctionnement de l'ancien JVC où les utilisateurs étaient référencés par leur pseudo (pouvant mener à des posts sur les forums avec des pseudos identiques organisés différemment côté minuscules/majuscules).

Il est possible d'obtenir son ID via la page permettant d'éditer votre profil, l'ID est à la fin de l'URL.

Les forums

Les posts des forums sont déclarés sur plusieurs serveurs différents. Les IDs de ceux-ci semblent aléatoires (bien qu'un offset était attribué pour les posts présents sur ForumJV). Les IDs sont choisis selon l'emplacement dans lequel la ressource sera stockée lors de la création du topic. Le choix de l'emplacement se fait à la création du topic, les messages dans le topic sont alors stockés dans le même emplacement. Il semblerait qu'il y ait 8 emplacements. ID + 8 pour accéder à la ressource suivante, et ID - 8 pour accéder à la ressource précédente.

Exemple de messages séquentiels:

L'ID est incrémenté de 8 à chaque fois. Tous ces messages sont répertoriés dans le 7ème serveur (ID % 8, donc 905193382 % 8 = 6, 7ème).

À noter toutefois que les messages datant d'avant respawn sont complètement désordonnés, certainement dû à la migration durant respawn où la migration de ces messages a été effectué en parallèle.

Modération

La modération sur Respawn se nomme "Accès étendu". L'accès étendu peut être appelé via la page qui lui est dédiée : https://www.jeuxvideo.com/sso/auth.php ; il nécessite en revanche également un mot de passe, qui est envoyé via un lien sécurisé utilisable une seule fois par MP à chaque modérateur. A noter que le 103 est accessible à n'importe quel modérateur même sans authentification à l'accès étendu.

Authentification

Le cookie coniunctio est utilisé pour l'authentification.

Recherche des forums

La recherche des forums utilise le moteur de recherche Sphinx qui est intégré au site. La recherche des forums est limitée à 1 mois sur les blablas, elle peut être contournée via https://jvarchive.com/.

Sécurité informatique

Dans les débuts de Respawn, le site était rempli de failles permettant de faire exploser la charge du site. Il existait également de nombreuses failles sur ForumJV qui permettaient de modérer sans être modérateur, sur n'importe quel forum. Les failles ici citées ont en majorité été exploitées par edwado.

Il a également existé une faille RCE (Remote Code Execution) exploitée par Tsain, qui permettait d'injecter du CSS sur n'importe quelle partie du site (la faille fut très mal exploitée étant-donné que celle-ci n'était pas qu'une simple injection CSS mais bien une RCE où il était possible d'injecter un shell PHP).

JvCare

JvCare est un étrange algorithme d'obfuscation développé avec Respawn. Il est notamment distingué dans les sources HTML des pages du site, et semble destiné à obfusquer des URLs.

Les codes ci-après permettent de décoder une chaîne obfusquée.

PHP

function jvCare(string $classe) : string {
  $base16 = "0A12B34C56D78E9F";
  $lien = "";
  $s = explode(" ", $classe)[1];
  for ($i = 0; $i <= strlen($s)-1; $i += 2) {
    $lien .= chr(strrpos($base16, $s[$i]) * 16 + strrpos($base16, $s[$i+1]));
  }
  return $lien;
}

JavaScript

function jvCake(classe) {
  const base16 = '0A12B34C56D78E9F';
  let lien = '';
  const s = classe.split(' ')[1];
  for (let i = 0; i < s.length; i += 2) {
    lien += String.fromCharCode(base16.indexOf(s.charAt(i)) * 16 + base16.indexOf(s.charAt(i + 1)));
  }
  return lien;
}

Python

def jvcare(classe: str) -> str:
  base16 = '0A12B34C56D78E9F'
  url = ''
  s = classe.split()[1]
  for i, j in zip(s[0::2], s[1::2]):
    url += chr(base16.index(i) * 16 + base16.index(j))
  return url

C

const char *__jvcarebase16 = "0A12B34C56D78E9F";

char *jvcare(const char *class) {
  char *s = strchr(class, ' ') + 1;

  int urllen = strlen(s) / 2;
  char *url = malloc(urllen + 1);
  for (int i = 0; i < urllen; i++) {
    char pos1 = strchr(__jvcarebase16, s[i * 2]) - __jvcarebase16;
    char pos2 = strchr(__jvcarebase16, s[i * 2 + 1]) - __jvcarebase16;
    url[i] = pos1 * 16 + pos2;
  }
  url[urllen] = '\0';
  return url;
}

Phoenix

Phoenix est une partie de JVC développée en Node.js et utilisant React. Elle semble de plus en plus abandonnée, et nous n'avons pas beaucoup d'informations à son sujet.