[spip-dev] Formulaire et sécurité

Dev
1

Bonjour à tous,

Sur les versions de la 3.0 :

Est-ce que les formulaires côté publique (forum par exemple) sont sécurisés contre les attaques par injection SQL ?

En décortiquant un peu le code, je n’ai pas trouvé ce qui nettoierais les valeurs envoyées par l’internaute.
(mysql_real_escape_string, addslashes, htmlentities, ou autre …)

J’ai regardé les fonctions :

  • _request()
  • sql_insertq() et les fonctions de base/abstract_sql.php

Merci d’avance pour vos réponses.

logo.jpg

2

Est-ce que les formulaires côté publique (forum par exemple) sont sécurisés
contre les attaques par injection SQL ?

dans l'état actuel de nos connaissances, oui.

En décortiquant un peu le code, je n'ai pas trouvé ce qui nettoierais les
valeurs envoyées par l'internaute.

les fonctions de nettoyage sont réparties à divers endroits :
écran de sécurité, spip_desinfecte(), safehtml(), interdire_scripts()...

3

et sql_quote pour échapper les saisies utilisateurs et les injecter dans la base, en fonction du type de base SQL utilisée (mysql_real_escape_string est spécifique mySQL, addslashes ne devrait jamais être utilisé pour ce type d'usage)

Cédric

4

Bonjour,

logo.jpg

5

> les fonctions de nettoyage sont réparties à divers endroits :
> écran de sécurité, spip_desinfecte(), safehtml(), interdire_scripts()...

et sql_quote pour échapper les saisies utilisateurs et les injecter dans
la base, en fonction du type de base SQL utilisée (mysql_real_escape_string
est spécifique mySQL, addslashes ne devrait jamais être utilisé pour ce
type d'usage)

C'est pourtant addslashes() qui est utilisé en bout de chaine par
sql_quote() [qui va utiliser _q() ]

sql_quote()
=> sql_serveur('quote', $serveur, true);
=> spip_mysql_quote()
=> _q()
=> addslashes()

6

_q n’est utilisé qu’en dernier ressort si on ne connait pas le type du champ, c’est un fallback…
Si on connait le type du champ, on mysql_cite

Et en effet, j’avais remis au propre le cite de SQLite
http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/sqlite_generique.php#L1467
en prenant en compte la fonction d’echappement sqlite_escape_string

Il me semblait me souvenir l’avoir fait sur mySQL aussi mais je vois que non.
C’est donc à corriger sur le même modèle (si fonction mysql_real_escape_string l’utiliser, sinon utiliser addslashes)

Cédric