Statut
=> Annulée lors du Comité de Pilotage du 22/06/2017
Porteur principal : Laurent Groleau
Porteur secondaire : ?
Résumé
Abandon de la substitution systématique de " par ’
Motivation
Cette substitution semble obsolète, et gêne notamment la saisie de requêtes SQL dans om_requete et om_sousetat, notamment quand on veut un titre de colonne au sous état sous la forme SELECT … AS “Prix Unitaire”.
Pré-requis
A ré-évaluer sur OM 4.5.0, la proposition initiale étant ancienne (https://adullact.net/tracker/index.php?func=detail&aid=8348&group_id=265&atid=1999)
Proposition et implémentation
En attendant la branche …
Dans ./core/om_formulaire.class.php:
-la méthode constructeur formulaire() initialise les champs ainsi:
$this->val[$champs[$i]] = strtr($elem, chr(34), “’”);
-la méthode recupererPostvar() effectue sur les champs textes des traitements qui semblent initialement prévu pour lutter contre l’injection SQL:
Un premier traitement est obsolète depuis PHP 5.4:
// Cette fonction a été supprimée avec PHP 5.4.0 et
// renvoi toujours la valeur FALSE depuis
// @deprecated
if (get_magic_quotes_gpc()) {
// Supprime les antislashs de la chaîne
$value = stripslashes($value);
}
Un second traitement est d’une utilité douteuse, et perturbe les formulaires (états, lettre-type, sous-état) qui comportent un champ textarea destiné à des requêtes SQL, telle que:
SELECT 1 AS “c’est égal à 1”;
// On remplace les doubles quotes par des simples quotes ?
$value = strtr($value, chr(34), “’”);
JE PROPOSE de supprimer cette fonctionnalité :
-supprimer dans recupererPostVar() les 2 traitements.
-modifier formulaire() pour avoir directement: $this->val[$champs[$i]] = $elem;
On peut en revanche étudier sur la fonction recupererPostvar() ou ailleurs des mécanismes anti-injection:
*SQL:
entier => intval()
chaine hors SQL => pg_escape_string()
chaine SQL => ne pas activer les contrôles
…
*HTML / JS / CSS
htmlspecialchar(), htmlentities()
Risques
Il y a un risque de régression dans l’absolu, notamment sur les éditions, car les motivations de cette substitution restent obscures, mais rien de prévisible. Le risque semble nul pour une application déjà en OM 4.5.0 sur PostgreSQL.