Bonjour,
Voilà j’ai un problème, je m’occupe de la maintenance et de l’administration d’un site web, mais un petit malin a réussit à trouver mon mot de passe administrateur, et utilise comme nom d’utilisateur ’ or ‘1’=‘1’ or ‘2’ = ’ , et bien sur ce petit c*n à modifier certaines pages du site :-@:, or je n’arrive pas à le dégager, car ce comte n’aparais nul part dans la base de données O_o
voici le panneau de connexion sécurisé
si vous pouviez m’aider merci.
Edité le 01/08/2009 à 17:03
Heu non, il n’est pas sécurisé ton panneau hein 
Faut que tu ailles modifier le code de ton fichier ASP pour protéger la chaine que tu injectes dans ta requête SQL.
Fait péter le code qui fait la requête de vérification des droits de l’utilisateur. Cependant, ne connaissant pas ASP, je ne saurais t’indiquer la meilleure solution (dans un premier temps : remplacer ’ par ‘’, voire virer les ')
I faudrais que je change juste le mot admin non?
Non. Je ne sais pas qui a pondu cette page de login, mais tu a droit à un beau hack par injection SQL…
En fait, c’est simple : quand tu saisit en login
' or '1' = '1'
ton site affiche
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC Microsoft Access Driver] Syntax error in string in query expression 'admin_login = '' or '1' = '1'' AND admin_pass='''.
/admin/login.asp, line 21
Alors ça c’est du pain béni pour les pirates, un site qui leur explique les erreurs… Maintenant il sait que le site vérifie les connexions par une requête SQL du type
(accepte la connexion si) 'admin_login = ''toto'' AND admin_pass=''pass'
Du coup, ladite chaîne de caractères permet de générer la requête
(accepte la connexion si) 'admin_login = ''' or '1'='1' or '2' = ''' AND admin_pass='''
Comme 1 = 1, alors ton système autorise la connexion…
Changer le mot de passe admin n’y changera rien. Tant qu’un pirate pourra injecter une requête SQL, il pourra rentrer dans ta partie admin… Là, toute la procédure d’authentification est à revoir…
Edité le 28/07/2009 à 05:12
Salut,
Faut surtout pas te laisser faire!
Ce genre d’intrusion (même une tentative) est sévèrement puni : article 323 alinéa 7 du code pénal.
Si tu penses que ça en vaut la peine, transmet aux flics l’ip du ptit malin, et on verra s’il recommence après qu’ils lui aient fait peur… (ou après 3 ans de tôle et 10 ans de dettes…)
Sinon, plus que remplacer les ’ , faut autoriser uniquement les lettres et les chiffres.
En général en sécurité, faut pas faire une liste d’interdits, mais une liste d’autorisés. Car y’aura toujours un ptit malin pour trouver un truc que t’as pas interdit.
Oui enfin, d’un autre coté, il vient de publier toute la procédure pour s’y connecter de cette manière, et a même invité les forumeurs ici à venir voir… Donc là il doit avoir graaaas d’IPs qui se sont connectées de cette manière.
Mais… tu a vu le problème ? Je l’ai expliqué plus haut… Ce n’est pas un problème d’interdit/autorisé, mais d’implémentation de la vérification…
Je te retourne la question : as-tu bien lu ce que j’ai écris?
Ma préconisation s’ajoutait à celle de Sans-Nom qui était de remplacer les ’ par des ". Ce qui est en d’autre termes l’interdiction du caractère ’ . Je proposais donc de ne pas se contenter d’interdire ce caractère, mais de n’accepter que ceux voulus.
Et pour ce qui est des ip, il a déjà localisé à quel endroit des logs se situe la “vraie” tentative de piratage, il devrait retrouver la bonne ip sans pb.
Et toi tu n’a pas lu ce que moi j’ai écris : il a une grosse faille d’injection SQL, limiter les caractères est un patch à 2 balles qui peut être inacceptable du point de vue de l’utilisateur en plus de simplifier les mots de passe, et ne pas combler la faille. Ce qu’il a à faire c’est surtout de gérer les autorisations de manières applicative.
Soit dit en passant, il n’y a pas de frameworks de sécurité en ASP ?
Je pense qu’on a tous vu que c’était de l’injection sql, mais tu ne va pas au bout de ton idée et je ne pige pas… (et je pense que ismael ne pigera pas non plus) :
Quand tu parles d’application tu parles de quelle “couche”? Car un script php est une application… (donc pour jouer sur les mots, notre solution est applicative) Et je ne vois pas quelle restriction de droits peut empêcher l’interprétation d’un code qu’on aurait pas filtré…
En tout cas je n’ai que quelques notions de sécurités, mais filtrer les données entrantes et sortantes est la première chose qu’on apprend aux devs. Mais si tu veux aller plus loin, je suis preneur! Mais avec plus d’explications stp!
ismael : faut JAMAIS afficher les erreurs en prod!!!
Bah ça, je l’avais dit aussi : c’est du pain béni pour les pirates 
Bon Kiki, pour le reste, et en ayant une réflexion globale car toit tu me parle de php alors que le site là est en asp 
Donc, le problème d’une application ouverte qui utilise une base est de contrôler les requêtes qui sont exécutées vers la base. Pour cela, quel que soit le champs, il faut éviter au maximum que l’utilisateur saisisse un texte car il peut introduire un pattern SQL. Pour cela, il faut découpler la logique données de la logique applicative (c’est ça que je voulais dire). En pratique, pour une authentification, on récupère au niveau de l’application les champs, on récupère les valeurs qui vont bien de la base, et on les compare au niveau de l’applicatif avec évidemment des vérifications (dont le retrait de tout ce qui pourrait être instruction SQL, chose où tu a raison avec les quots mais pas suffisamment dans le cas présent ici). Là à priori, il a laissé la base prendre toute la décision (= autorisation basée sur les données).
Je sais pas si je suis plus claire, mais j’ai pas envie de tartiner tout un tuto dans un forum. Si tu lis l’anglais, je ne peux que te conseiller ce lien :
cwe.mitre.org…
De manière globale, cette page est assez intéressante : cwe.mitre.org…
Donc en clair, faudrait utiliser de la requête paramétrée (par ex) pour ne pas nous même faire le filtre (au risque de se planter)?
C’est vrai que c’est plus sûr, mais c’est aussi plus long (à coder). Faut juste voir si le jeu en vaut la chandelle.
Car on peut aussi hacher et comparer le hachage, là c’est pas tellement plus long à coder mais à exécuter oui…
Je ne pense pas que filter à la main soit un vulgaire patch, mais plutôt une méthode en adéquation avec le dev web : faire vite et bien.
Votre client, il s’est barré
Bof non, c’est pas plus long, en général c’est même plus court…
Et “faire vite et bien” ok, mais faire trop vite, c’est jamais bien.
On s’en fout, on philosophe
:miam: (à daufaut d’un smiley avec une bière…)
Edité le 29/07/2009 à 13:58
Ouai on s’en fout! en SSII Même si le client se barre on est payés! :miam:
PS : ok je vais ptet me mettre aux requêtes paramétrées et autres trucs bizares :)… je m’arrêtais aux “on dit”, mais si tu trouves que c’est presque plus rapide… je verrais bien par moi même!
Les requêtes paramétrées, c’est pas plus long à mettre en place surtout.
Ensuite, c’est sécurité over performance. Mais même, la requête est en principe déjà compilée.