Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mécanisme de protection requêtes API #2702

Open
Feiryn opened this issue Dec 12, 2024 · 1 comment
Open

Mécanisme de protection requêtes API #2702

Feiryn opened this issue Dec 12, 2024 · 1 comment
Labels
big feature A lot of work is needed to implement this
Milestone

Comments

@Feiryn
Copy link
Contributor

Feiryn commented Dec 12, 2024

Voilà mes réflexions pour le système de protection du boting pour l'API pour l'appli mobile :

  • Chaque paquet envoyé contient un hash + un timestamp + un tag de version
  • Le tag de version est incrémenté à chaque version de l'API
  • Le timestamp est celui du client
  • Le hash est calculé en concatenant les données suivantes :
    • id unique de l'utilisateur
    • timestamp
    • un "secret" correspondant au paquet en question (exemple : 9875114948 pour une commande profile, 19841259447 pour shop etc.). Ce secret est calculé de la façon suivante :
      • Au moment de la compilation de l'API + appli mobile, on génère un nombre aléatoire pour chaque paquet
      • On génère également un algorithme avec plein de calculs d'une centaine de lignes par exemple (addition, soustraction, modulo, opération binaires etc)
      • On applique cet algo à chaque nombre aléatoire et on stocke ça pour le serveur. Ainsi, le serveur connait le secret
      • Pour l'application mobile, on compile ça nativement (C pour android par exemple), et on refait le calcul entier à chaque paquet envoyé

Ainsi, ceci permet les choses suivantes :

  • Le timestamp empêche le rejeu
  • Le fait que ce soit hashé évite un man in the middle
  • l'id unique évite le partage des données entre utilisateurs
  • le seul moyen (je crois) de reproduire l'ID attendu consiste à décompiler le package de l'appli, trouver l'algo pour chaque paquet + le nombre aléatoire, décompiler un code compilé (très chiant à lire) etc...

Certes c'est de l'obfuscation, mais la complexité + le fait de devoir le faire à chaque mise à jour découragera un certain nombre de personnes. Combiné avec la surveillance active (ex : grafana) ou encore d'autres choses (captcha), on pourra éviter une partie du boting.

Après de toute façon, il n'y a aucun moyen d'éviter le boting, c'est toujours un jeu du chat et de la souris. Le but est de rendre le boting complexe et dissuadant.

@Feiryn Feiryn added the big feature A lot of work is needed to implement this label Dec 12, 2024
@Feiryn Feiryn added this to the X.X.X milestone Dec 12, 2024
@Feiryn Feiryn changed the title Mécanisme de protection requêtes web server Mécanisme de protection requêtes API Dec 12, 2024
@Feiryn
Copy link
Contributor Author

Feiryn commented Dec 12, 2024

Exemple

Compilation

Génération des nombres aléatoires pour les paquets

(à noter que les nombres feront 64 bits donc seront entre 0 et 9223372036854775807, pour éviter le brute force)

ping : 1234
report : 5678
shop : 9012

Génération des algorithmes des paquets

(à noter qu'il y aura en réalité sûrement plusieurs centaines d'opérations)

ping : add 5, multiply 8, modulo 2500
report : sub 50
shop : multiply 2, div 10

Calcul du résultat pour l'API

ping : (((1234 + 5) * 8) % 2500) = 2412
report : (5678 - 50) = 5628
shop : (9012 * 2) / 10 = 1802

Envoi d'une requête par l'utilisateur

Contexte

timestamp : 1734016293
ID utilisateur : 8d4c5e02-03e3-476b-a58e-e835af9f97ad

Calcul du hash d'une commande ping

sha256(timestamp || ID user || nombre paquet) = sha256(17340162938d4c5e02-03e3-476b-a58e-e835af9f97ad2412)
= 699c0ef266dc50800132e76df8bae76d5ca1766eb673eaa4c652c624958a32bd

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big feature A lot of work is needed to implement this
Projects
None yet
Development

No branches or pull requests

1 participant