A chaque fois que je lis un truc sur la façon de sécuriser un site pour
l'injection de code je vois des informations différentes.
- certains vous dirons qu'il faut faire addslashes et stripslashes
pour les quote sauf si les magic_quote sont activées.
- dans d'autre livres l'auteur mets l'accents sur le danger des
balises et vous dira que c'est htmlentities que l'ont doit utiliser.
Je viens d'aider quelqu'un qui avait des problèmes avec son
htmlentities et utf-8 et je lui est montré cette syntaxe:
htmlentities($unevariablepost,ENT_COMPAT , 'utf-8')
Ce qui m'a permis de decouvrir le 2eme parametres dans le manuel
mais le choix entre ENT_COMPAT et ENT_QUOTE ne m'a pas paru evident.
quel est le plus sur des deux? a moins que ce soit ent_noquotes mais
alors là ce sera la preuve que j'ai rien compris.
- certains vous diront rien de tous ça faites tous dans la requete à la
BDD en SQL. moi je veux bien mais comment fais-t-on?
J'ai pas un bout de piste sur cette dernière façon de faire. juste une
affirmation lu dans un forum ou newsgroup sur PHP je sais plus.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Mevzek
A chaque fois que je lis un truc sur la façon de sécuriser un site pour l'injection de code je vois des informations différentes.
- certains vous dirons qu'il faut faire addslashes et stripslashes pour les quote sauf si les magic_quote sont activées.
Ceux qui ont cette réponse montrent qu'ils n'ont rien compris à ce qu'est une injection SQL. On peut très bien y être vulnérable même avec addslashes.
- dans d'autre livres l'auteur mets l'accents sur le danger des balises et vous dira que c'est htmlentities que l'ont doit utiliser.
Cela ne protège pas la même chose, là on est dans le monde de l'injection HTML aussi appelé XSS.
- certains vous diront rien de tous ça faites tous dans la requete à la BDD en SQL. moi je veux bien mais comment fais-t-on?
Pas sûr de comprendre, mais envoyer n'importe quoi au SGBDR n'est jamais une bonne idée.
Il y a une règle simple pour se prémunir contre tous les types d'injection : - être paranoaïque, ne jamais prendre les informations reçues de l'extérieur (au moins l'utilisateur mais jusqu'à potentiellement l'OS ou le SGBDR) comme de confiance, et donc les tester explicitement (format, longueur, etc...) - et seulement après filtrer, selon le contexte où l'on est.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
A chaque fois que je lis un truc sur la façon de sécuriser un site pour
l'injection de code je vois des informations différentes.
- certains vous dirons qu'il faut faire addslashes et stripslashes
pour les quote sauf si les magic_quote sont activées.
Ceux qui ont cette réponse montrent qu'ils n'ont rien compris à ce
qu'est une injection SQL. On peut très bien y être vulnérable même
avec addslashes.
- dans d'autre livres l'auteur mets l'accents sur le danger des
balises et vous dira que c'est htmlentities que l'ont doit utiliser.
Cela ne protège pas la même chose, là on est dans le monde de
l'injection HTML aussi appelé XSS.
- certains vous diront rien de tous ça faites tous dans la requete à la
BDD en SQL. moi je veux bien mais comment fais-t-on?
Pas sûr de comprendre, mais envoyer n'importe quoi au SGBDR n'est jamais
une bonne idée.
Il y a une règle simple pour se prémunir contre tous les types
d'injection :
- être paranoaïque, ne jamais prendre les informations reçues de
l'extérieur (au moins l'utilisateur mais jusqu'à potentiellement l'OS ou
le SGBDR) comme de confiance, et donc les tester explicitement (format,
longueur, etc...)
- et seulement après filtrer, selon le contexte où l'on est.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
A chaque fois que je lis un truc sur la façon de sécuriser un site pour l'injection de code je vois des informations différentes.
- certains vous dirons qu'il faut faire addslashes et stripslashes pour les quote sauf si les magic_quote sont activées.
Ceux qui ont cette réponse montrent qu'ils n'ont rien compris à ce qu'est une injection SQL. On peut très bien y être vulnérable même avec addslashes.
- dans d'autre livres l'auteur mets l'accents sur le danger des balises et vous dira que c'est htmlentities que l'ont doit utiliser.
Cela ne protège pas la même chose, là on est dans le monde de l'injection HTML aussi appelé XSS.
- certains vous diront rien de tous ça faites tous dans la requete à la BDD en SQL. moi je veux bien mais comment fais-t-on?
Pas sûr de comprendre, mais envoyer n'importe quoi au SGBDR n'est jamais une bonne idée.
Il y a une règle simple pour se prémunir contre tous les types d'injection : - être paranoaïque, ne jamais prendre les informations reçues de l'extérieur (au moins l'utilisateur mais jusqu'à potentiellement l'OS ou le SGBDR) comme de confiance, et donc les tester explicitement (format, longueur, etc...) - et seulement après filtrer, selon le contexte où l'on est.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
CPascal
Salut,
A chaque fois que je lis un truc sur la façon de sécuriser un site pour l'injection de code je vois des informations différentes.
- certains vous dirons qu'il faut faire addslashes et stripslashes pour les quote sauf si les magic_quote sont activées. - dans d'autre livres l'auteur mets l'accents sur le danger des balises et vous dira que c'est htmlentities que l'ont doit utiliser.
Je viens d'aider quelqu'un qui avait des problèmes avec son htmlentities et utf-8 et je lui est montré cette syntaxe: htmlentities($unevariablepost,ENT_COMPAT , 'utf-8')
Ce qui m'a permis de decouvrir le 2eme parametres dans le manuel mais le choix entre ENT_COMPAT et ENT_QUOTE ne m'a pas paru evident. quel est le plus sur des deux? a moins que ce soit ent_noquotes mais alors là ce sera la preuve que j'ai rien compris.
- certains vous diront rien de tous ça faites tous dans la requete à la BDD en SQL. moi je veux bien mais comment fais-t-on?
J'ai pas un bout de piste sur cette dernière façon de faire. juste une affirmation lu dans un forum ou newsgroup sur PHP je sais plus.
Et bien merci, pour les infos.
je pensais pas que XSS et injection était différente.
sic tu as surement raison je vais donc devenir paranoiaque...
visiblement j'ai cherché un peu :Ent_quote serait mieux au niveau sécurité
et peut-etre mysql_real-escape-string est ce qui était indiqué pour les requetes bdd...
j'espere que ce message va passer. le dernier n'est pas passer et je ne vois vraiment pas pourquoi.
Salut,
A chaque fois que je lis un truc sur la façon de sécuriser un site pour
l'injection de code je vois des informations différentes.
- certains vous dirons qu'il faut faire addslashes et stripslashes pour
les quote sauf si les magic_quote sont activées.
- dans d'autre livres l'auteur mets l'accents sur le danger des balises
et vous dira que c'est htmlentities que l'ont doit utiliser.
Je viens d'aider quelqu'un qui avait des problèmes avec son
htmlentities et utf-8 et je lui est montré cette syntaxe:
htmlentities($unevariablepost,ENT_COMPAT , 'utf-8')
Ce qui m'a permis de decouvrir le 2eme parametres dans le manuel
mais le choix entre ENT_COMPAT et ENT_QUOTE ne m'a pas paru evident.
quel est le plus sur des deux? a moins que ce soit ent_noquotes mais
alors là ce sera la preuve que j'ai rien compris.
- certains vous diront rien de tous ça faites tous dans la requete à la
BDD en SQL. moi je veux bien mais comment fais-t-on?
J'ai pas un bout de piste sur cette dernière façon de faire. juste une
affirmation lu dans un forum ou newsgroup sur PHP je sais plus.
Et bien merci, pour les infos.
je pensais pas que XSS et injection était différente.
sic tu as surement raison je vais donc devenir paranoiaque...
visiblement j'ai cherché un peu :Ent_quote serait mieux au niveau sécurité
et peut-etre mysql_real-escape-string est ce qui était indiqué
pour les requetes bdd...
j'espere que ce message va passer. le dernier n'est pas passer et
je ne vois vraiment pas pourquoi.
A chaque fois que je lis un truc sur la façon de sécuriser un site pour l'injection de code je vois des informations différentes.
- certains vous dirons qu'il faut faire addslashes et stripslashes pour les quote sauf si les magic_quote sont activées. - dans d'autre livres l'auteur mets l'accents sur le danger des balises et vous dira que c'est htmlentities que l'ont doit utiliser.
Je viens d'aider quelqu'un qui avait des problèmes avec son htmlentities et utf-8 et je lui est montré cette syntaxe: htmlentities($unevariablepost,ENT_COMPAT , 'utf-8')
Ce qui m'a permis de decouvrir le 2eme parametres dans le manuel mais le choix entre ENT_COMPAT et ENT_QUOTE ne m'a pas paru evident. quel est le plus sur des deux? a moins que ce soit ent_noquotes mais alors là ce sera la preuve que j'ai rien compris.
- certains vous diront rien de tous ça faites tous dans la requete à la BDD en SQL. moi je veux bien mais comment fais-t-on?
J'ai pas un bout de piste sur cette dernière façon de faire. juste une affirmation lu dans un forum ou newsgroup sur PHP je sais plus.
Et bien merci, pour les infos.
je pensais pas que XSS et injection était différente.
sic tu as surement raison je vais donc devenir paranoiaque...
visiblement j'ai cherché un peu :Ent_quote serait mieux au niveau sécurité
et peut-etre mysql_real-escape-string est ce qui était indiqué pour les requetes bdd...
j'espere que ce message va passer. le dernier n'est pas passer et je ne vois vraiment pas pourquoi.
Olivier Miakinen
[ vingt-quatre lignes de citation ]
Et bien merci, pour les infos.
[...]
j'espere que ce message va passer. le dernier n'est pas passé
Peut-être pour citation excessive ?
Voir par exemple les paragraphes 3a et 3b de la page suivante : <http://www.faqs.org/faqs/fr/usenet/repondre-sur-usenet/>.
et je ne vois vraiment pas pourquoi.
N'as-tu pas reçu un message de refus ? Si ton adresse est invalide, il est de bon ton de le signaler en ajoutant « .invalid » à la fin, comme ceci : . D'autant plus que, le nom de domaine étant valide, tu fais spammer ce FAI en plus d'encombrer le réseau pour rien.
[ vingt-quatre lignes de citation ]
Et bien merci, pour les infos.
[...]
j'espere que ce message va passer. le dernier n'est pas passé
Peut-être pour citation excessive ?
Voir par exemple les paragraphes 3a et 3b de la page suivante :
<http://www.faqs.org/faqs/fr/usenet/repondre-sur-usenet/>.
et je ne vois vraiment pas pourquoi.
N'as-tu pas reçu un message de refus ? Si ton adresse est invalide, il
est de bon ton de le signaler en ajoutant « .invalid » à la fin, comme
ceci : <maelith.guildwar@free.fr.invalid>. D'autant plus que, le nom
de domaine étant valide, tu fais spammer ce FAI en plus d'encombrer le
réseau pour rien.
j'espere que ce message va passer. le dernier n'est pas passé
Peut-être pour citation excessive ?
Voir par exemple les paragraphes 3a et 3b de la page suivante : <http://www.faqs.org/faqs/fr/usenet/repondre-sur-usenet/>.
et je ne vois vraiment pas pourquoi.
N'as-tu pas reçu un message de refus ? Si ton adresse est invalide, il est de bon ton de le signaler en ajoutant « .invalid » à la fin, comme ceci : . D'autant plus que, le nom de domaine étant valide, tu fais spammer ce FAI en plus d'encombrer le réseau pour rien.
