Dois-je vérifier l'injection sql même pour les entrées validées ?

Question

Il s'agit d'un site de petites annonces... J'utilise PHP et MySql pour insérer des enregistrements dans une base de données.

J'ai un formulaire HTML, et les utilisateurs doivent remplir ce formulaire pour continuer.

Voici les entrées du formulaire et la validation effectuée sur chaque entrée (javascript) :
Nom (Seules les lettres sont autorisées)
Tel (Seuls les chiffres sont autorisés)
Courriel : (correspondance spéciale email-regexp)
A la une (Aucun caractère spécial n'est autorisé, tout le reste est acceptable. Par caractères spéciaux, j'entends !(#)<> etc. Longueur maximale de 35 caractères)
Texte (Comme le titre, mais sans limite de longueur)
Prix (Seuls les chiffres sont autorisés)

Je le fais. mysql_real_escape_string() sur le A la une y Texte mais rien d'autre.

Ma question est simplement : est-ce suffisant ?

J'ai aucune autre sécurité mesures que ce soit.

UPDATE

var alphaExp = /^[a-zA-ZåäöÅÄÖ\s\-]+$/; 
var numExp = /^(?=(?:\D*\d){0})[\d -]{0,20}$/;
var num_only = /^[0-9]+$/;
var emailExp = /^[\w\-\.\+]+\@[a-zA-Z0-9\.\-]+\.[a-zA-z0-9]{2,4}$/;
var textExp = /^\s*([\wåäö\-\*][^\w]*){3}.*$/gmi;
var headlineExp = /^[\s\da-zA-ZåäöÅÄÖ&()+%\/*$€é:,.'"-]*$/;

Answer 1

Toutes les mesures de sécurité mises en œuvre en Javascript peuvent être contournées par l'utilisateur, par exemple en les désactivant, en supprimant les écouteurs ou en manipulant le code. Ne comptez pas sur le client à cet égard !

Answer 2

Je n'ai aucune autre mesure de sécurité.

La sécurité doit être mise en œuvre par couches. Souvent, les programmeurs ne comprennent pas cela parce que ce n'est pas de leur ressort (la plupart d'entre eux ont le mantra "si ça compile, on l'envoie"). Vous devez mettre en œuvre la sécurité à chaque point raisonnable. Vous ne pouvez jamais, au grand jamais, faire confiance à l'entrée de l'utilisateur, surtout si elle passe par le Wild Wild Web. Les contrôles d'expressions régulières, les contrôles d'injection connus et le durcissement des serveurs et des applications sont essentiels.

Notez qu'il y a un critère de vraisemblance. Il est parfois facile de faire du théâtre sécuritaire ou d'en faire trop. C'est à vous et aux autres parties prenantes du projet de déterminer quels niveaux de précaution il est nécessaire de mettre en œuvre. Le temps et le matériel ont des coûts associés, donc si vous dépensez 100 000 $ pour la mise en œuvre de la sécurité mais que vous n'obtenez qu'un retour de 80 000 $, cela va à l'encontre du but recherché.

Answer 3

Tout ce qui vient de l'utilisateur doit être vérifié. Exécution du JavaScript avant que l'utilisateur ne l'envoie. Je n'ai pas besoin d'exécuter votre code JavaScript pour envoyer une requête POST.

Answer 4

Vous ne devriez pas utiliser Extension MySQL du tout. On est en 2010 et AOP est la voie à suivre.

Answer 5

Dans presque tous les cas, la réponse par défaut à la question "Dois-je vraiment..." lorsqu'il s'agit de questions de sécurité est "Oui, absolument".

<?php
/* Execute a prepared statement by passing an array of values */
$sql = 'SELECT name, colour, calories
    FROM fruit
    WHERE calories < :calories AND colour = :colour';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':calories' => 150, ':colour' => 'red'));
$red = $sth->fetchAll();
$sth->execute(array('calories' => 175, 'colour' => 'yellow'));
$yellow = $sth->fetchAll();
?>

Le code ci-dessus provient de cette page dans la bibliothèque PHP. Ne vous embêtez pas avec mysql_real_escape_string() et essayez d'incorporer des instructions préparées dans vos requêtes SQL.