Dev Faq
6
votes

Comment savoir quand s'échapper est nécessaire pour MySQL

Je suis en train de construire un site avec CodeIdIditer. C'est le 1er site que j'ai construit moi-même qui interagit avec une base de données. J'utilise MySQL pour ce projet. Comment puis-je dire si les données doivent être échappées avant de l'enregistrer dans la base de données?

0 commentaires

8 Réponses :

1
votes

En cas de doute, échappez à tout. Ne peut pas être trop sûr.

D'accord, d'accord. Je l'obtient

toujours échapper à

7 commentaires

c'est une mauvaise réponse. Votre, @josiah aussi. Il n'y a rien d'utilisateur ou de doutes pertinents. Il n'y a rien de pertinent du tout. S'échapper est une procédure inconditionnelle.

+1 à Col. Shrapnel. L'échappement n'est pas réellement un problème de sécurité, échappant est la façon de faire la requête valide.

@Shrapnel et @zerkms faire une requête valide sonne comme une bonne chose? Qu'est-ce que je rate?

@Mike: Supprimer "Doute" et "Trop sûr". La seule règle est "toujours". Le programmeur ne devrait pas penser à "échapper ou non"

Cela doit être certains actes. S'échapper redondant gâchera les données.

S'échapper n'est pas une situation "en cas de doute". C'est une situation "toujours".

Donc, pour clarifier, je dois échapper à mes questions pour que elles soient valides et que j'ai besoin d'échapper à mes soumissions pour la mesure de sécurité / de validité? Ai-je eu ce droit?

-2
votes

Quand échapper? Dès que votre site se rend public.

2 commentaires

terrible mauvaise erreur. Bonne réponse - dès que vous commencez à travailler avec la base de données

@Col: écrivez votre propre réponse s'il vous plaît donc nous pouvons +1 cela aussi mieux ;-) (pas ironie)

4
votes

Ne vous inquiétez pas de vous échapper (vous allez le bousiller). Utilisez une couche DB dans laquelle vous préparez d'abord l'instruction, puis ajoutez-y les données.

in php Vous devez utiliser PDO . Vous écrivez xxx

puis ajoutez les données en appelant des fonctions.

0 commentaires
2
votes

Si les données sont une chaîne, il doit toujours être échappé.

Cependant, il est préférable d'utiliser des paramètres à la place.

0 commentaires
3
votes

Si vous utilisez le classe de base de données avec Bindings de requête , vous n'avez pas à faire de l'échappement manuel:

L'avantage secondaire de l'utilisation des liaisons est que les valeurs sont automatiquement échappé, produisant des requêtes plus sûres. Vous Ne pas avoir à retenir manuellement Échapper aux données; le moteur le fait automatiquement pour vous.

8 commentaires

À la bownvoter, s'il vous plaît veillez à élaborer;) Heck, c'est la seule réponse pertinente pour le codédiciteur.

J'ai été évité à cause d'une deuxième partie stupide. Il n'est pas pertinent de remettre en question et une idée terrible elle-même. Si vous avez besoin dans le filtrage des données en raison de la logique des entreprises, attendez-le, mais n'est-ce pas pour essayer de sécuriser quelque chose.

+1 correct et fournit des références. Il utilise même le fait que l'asker de la question utilise CodeDIGNITER

@zerkms: le filtrage sur l'entrée ou la sortie dépend beaucoup des cas d'utilisation. L'entrée de filtrage n'est pas intrinsèquement fausse.

@ Jonathan Finland: Filtrage ne correspondant pas à l'échappement. du tout. Toute données de chaîne Toujours devrait être échappée. Ne confondez pas OP.

Oui, la validation / le filtrage est une préoccupation distincte.

@zerkms: accordé. bon point. L'OP est clairement un novice par son propre admission et je l'ai interprété comme une question plus large que littéralement énoncée. Si pris strictement, le filtrage n'était pas ce qui a été demandé.

Je suis content de le demander. Je dois faire beaucoup plus de lecture. La majeure partie de mon code est développé après avoir regardé des tutoriels, et cela n'est jamais venu dans aucun d'entre eux.

-1
votes

Vous échappez à une chaîne de requête MySQL lorsque l'une des chaînes est composée d'une entrée utilisateur, par exemple:

en PHP: $ nom d'utilisateur =; // valeur de l'utilisateur utilisateur

Alors votre chaîne de requête est: "Insérez dans Tableau ('Nom d'utilisateur') (". $ $ Nom d'utilisateur. ")"

Vous devriez échapper à cette requête MySQL en raison du fait que la variable Nom d'utilisateur $ pourrait avoir un code maliceux inséré par le client à injecter dans votre base de données.

1 commentaires

Pas une chaîne de requête mais une chaîne de données. Pas lorsque l'une des chaîne est composée d'une entrée de l'utilisateur, mais simplement n'importe quelle chaîne . Allez comprendre

8
votes

Je vous conseillerais de vous accueillir pour utiliser des déclarations préparées. Surtout que vous êtes nouveau pour travailler avec des bases de données. Plus tôt vous commencez à utiliser ceux-ci, plus cela devient une seconde nature.

I, par exemple, ne connaissait pas les déclarations préparées lorsque j'ai commencé avec des bases de données. Et j'ai vécu ma propre stubborness quand je suis entré en contact avec eux. Parce que je m'étais habitué à une autre façon de faire les choses déjà. Maintenant, cela pourrait ne pas être un métier de caractère de vous-même, mais cela ne fait pas mal de commencer dès que possible avec de toute la manière que possible. P>

Les déclarations préparées vous permettent d'utiliser des espaces réservés dans des requêtes. Ces espaces réservés peuvent ensuite être substitués par des valeurs réelles en les liant aux espaces réservés. Ce processus de liaison échappe automatiquement aux valeurs. P>

Voici un (simple) PDO A > Exemple: p> 

$statement = $db->prepare( 'INSERT INTO table VALUES( :username, :password )' );
$result = $statement->execute( array( 
                                   ':username' => $dirtyUsername, 
                                   ':password' => $dirtyPassword
                             ) );
// result checking ommited for brevity

2 commentaires

Le processus de liaison ne s'échappe pas. Le reste est correct

Dans le cas de l'utilisation de PDO, cela pourrait effectivement (OK, pas l'appel à BindParam () lui-même). Lorsque le drapeau ATTR_EMULE_PRANDES est défini (ou forcé parce que le pilote ne prend pas en charge les instructions préparées côté serveur), PDO crée une chaîne de requête contenant les paramètres (échappés).

1
votes

Si vous générez des SQL vous-même plutôt que d'utiliser quelque chose comme PDO, vous devez toujours échapper.

Les chaînes d'échappement sont une exigence de base de la langue SQL. C'est ce qui vous permet d'utiliser des caractères comme des apostrophes ou des backslashes dans une corde sans que tout soit mauvais. Il n'y a pas de situation du tout dans lequel les chaînes d'échappement ne sont pas nécessaires.

Même les non-strings devront être filtrés pour s'assurer qu'ils sont, en effet, des non-chaînes.

Si vous apprenez, veuillez envisager sérieusement d'apprendre quelque chose comme PDO autant d'autres que d'autres, plutôt que d'échapper à vos propres chaînes.

0 commentaires

Articles qui pourrait vous intéresser :

Pourquoi est-ce que j'obtiens une erreur laravel lors de la création d'un nouveau projet?
Select2 ne s'affiche pas correctement dans le mode bootstrap
Laravel Echo n'écoute pas
La validation de la demande de formulaire ne fonctionne pas. Il charge juste la page d'accueil dans Postman