Une énorme vague d'injections SQL s'abat sur les sites ASP.NET

effectivement, ca ne touche que de l'asp et asp.net or une faille par SQL injection depend surtout de la facon dont on code ses appels à la base.
mais pour moi la prouesse est tout autre parce que attaquer un site mal configuré par SQL injection cela se fait avec de l'habitude mais pour le faire de façon automatiser sur des centaines de sites c'est autre chose mais finir par faire en sorte que le resultat injecté soit en plus affiché dans la page, ca l'est encore plus! ou alors là, on ne voit que la partie immergée de l'iceberg.

bien souvent la première cause de faille est la table users, attaquée par le login et on arrive à setter un pwd pour tous les comptes mais pas faire revenir du JS.
l'autre solution est la recherche, souvent mal protégée mais là encore, le SQL injection doit être un minimum touchy pour faire revenir le js sur les pages du site.

j'ai bien une idée. injecter un code dynamique qui se base sur sys.columns et en fonction du type, va concatener son script à toutes les valeurs sans exception, l'une étant affichée un moment où un autre mais bon, ca se verra vite sur l'interface et pas seulement du js caché dans le code (parce que le texte est souvent encodé avant d'etre affiché.

bref, vivement la suite de cette histoire

ps: certains sont un peu agressifs. y a certes parfois des erreurs dans les news des journalistes mais c'est pas pire que les autres sites et surtout ici il a raison, si c'est en base, c'est une SQL injection qui sert à préparer une attaque XSS point

Le SQL c'est pas du code ?
Ca vient de sortir ?

Tu veux dire que ce n'est pas la tienne.

Euh oui ... mais si je peux comprendre qu'un développeur ne connaisse ni le HTML ni les CSS, je ne prendrais en revanche jamais un gars qui ne connait pas le SQL.

Blague à part, écrire le code SQL d'une application nécessite de connaitre parfairtement l'aspect "métier" de celle ci; donc on ne peut pas imaginer une fraction de seconde comment le DBA, dont ce n'est pas le métier (je ne parle pas de coder en SQL, le DBA sait faire, mais de connaitre le métier de l'application) puisse s'occuper de cette tâche.

Ou alors tu considère la base de données comme rien d'autre qu'une sorte de "super ISAM" juste destinée à servir des données à la demande...... (et c'est, hélas, plus fréquent qu'on ne le pense .....).

Ca ressemble plutôt à une attaque XSS qu'à une injection SQL...

C'est clair... même s'il arrive aux journalistes de faire des erreurs, on peut les signaler courtoisement en évitant les attaques personnelles.

Pas forcément... enfin pour moi en tous cas, une injection SQL, ça consiste à exécuter en base une instruction qui n'aurait pas du être exécutée. Ici, le script JS a simplement été passé via un formulaire, et inséré en base comme n'importe quelle entrée utilisateur. Cette attaque n'a a priori pas bidouillé la requête SQL... même en utilisant des requêtes paramétrées, ça n'aurait pas empêché d'insérer ce texte en base. Le problème est simplement que le script entré dans le formulaire aurait dû être contrôlé et refusé, ou au minimum il n'aurait pas dû être affiché directement sur le site : il aurait dû être "HTML-encoded" (comme avec MvcHtmlString).

Bref, à mon sens il ne s'agit pas d'une injection SQL ; à un moment donné le script malicieux a effectivement été inséré en base, mais sans recourir à un hack quelconque.

Enfin bon, je peux me tromper, j'avoue n'avoir pas examiné en détail tous les éléments...

Exact, un "DecryptByPassphrase" par exemple passera.
Les protections par defauts bloquent les attaques XSS mais pas les injections sql.

Via un formulaire cela me semble difficile en asp .net.
Il y a des parametrages par defaut qui refusent toutes les balises en entrées de formulaires.

On peut desactiver le parametre via <%@ Page validateRequest="false" %> mais là on cherche les ennuis.

http://www.asp.net/learn/whitepapers...est-validation

Par contre cela n empeche pas l'injection SQL : un
INSERT INTO USERS (username) VALUES ('blabla') peut passer
par contre un INSERT INTO USERS (username) VALUES ('<script> ne passera pas...

L'utilisation de procedures stockées me parait le plus sécurisant.
C'est moins souple évidemment, c'est du boulot en plus, il faut faire quelques pirouettes de temps en temps mais je pense que coté securité (injection sql) on ne se pose plus trop de question.

De plus on peut gérer finement les droits sur les proc stock (qui execute quoi).