Euh.... quand on parle sécurité, on parle protéger des éléments sensibles... on est pas obligé de tout surveiller, tout contrôller non plus... si l'utilisateur bricole et qu'il est le seul pénalisé, on est pas obligé de se prendre la tête :)

Si un utilisateur force la saisi d'un nom de pays qui n'est pas dans ta base au lieu d'utiliser le select que tu proposes, ta requête ne ramenera pas de résultat, point. Pas la peine de faire 36 tests pour vérifier s'il existe, s'il peut l'utiliser, ce n'est pas une donnée sensible et au mieux il se pénalise lui même, c'est tout :)

Après, que la donnée soit passée en post ou get à mon avis ne change rien (c'est juste une question de taille et de soumission automatique ou non en cas de refresh, bref de confort)

En gros, les principales choses que tu devrais contrôler sont (à mon sens)
- que les variables que tu utilises dans tes requêtes sont bien protégées contre les injections (c'est à dire que si l'utilisateur saisi des apostrophes ou guillemets, celles-ci seront protégées d'un antislash pour éviter que le parseur SQL ne l'interprète comme une fin de chaine et n'exécute le reste de la chaine comme du code sql, chose que la fonction mysql_real_escape_string() fait à merveil)
- que si les données que tu récupères de l'utilisateur sont enregistrées en base et ensuite affichée sur ton site, il n'y a pas de code html, ou alors uniquement des balises choisies (voir htmlentities() ou strip_tags())
- que si la donnée permet l'ouverture d'un fichier par inclusion, tu dois t'assurer que l'utilisateur ne pourra inclure d'autre fichiers que ceux que toi tu as prévu (avec une white list, ou en forçant un répertoire, ou autre).

...

Oui, puisque les données restent alors sur le serveur, et ne sont pas modifiables par l'utilisateur.

Juste qu'il est possible de 'voler' la session d'un utilisateur, par l'intermédiaire des cookies, mais ce n'est dangereux que si tu sauvegardes des données personelles de l'utilisateur, qui seraient intéressants pour les méchants.

J'ai rajouté addslashes() devant mes variables GET.

Comment faire pour sécuriser mon site contre les injections SQL ?

Parfois j'utilise les sessions, est ce plus sécurisant que les variables POST et GET ?

bref, la porte ouverte aux injections sql.. pas mal.

Il est dangereux de prendre une donnée si facilement modifiable, et de simplement l'utiliser dans une requête sql.

Un premier pas serait d'échapper tout avec addslashes(), mais le mieux serait de simplement importer ta table dans un tableau php, et de faire la comparaison uniquement dans le script php, pour éviter que les données ne se perdent et causent un dégat quelconque..

Et comment fais-tu pour appeler ta page ? si ça aussi ça dépend d'une variable GET ou POST, tu cours aussi un danger, puisqu'alors il est possible de faire exécuter des scripts distants, et de prendre tout le contrôle sur ton site..

doit-y avoir une meilleure explication et une marche à suivre dans les environs, mais je n'ais pas le lien.

Vérifier si elle existe dans la base par exemple pour une recherche de pays, je regarde si la valeur de la variable $pays existe bien dans ma table pays. Si l'utilisateur tape une autre valeur dans la variable pays ça affichera une erreur.

ça dépend, tu enteds quoi par "vérifier si elles sont correctes" ?

Merci pour ta réponse.

J'ai opté pour les 2 pages (en tête et pied de page), c'est plus simple et pas besoin de passé en paramétre une variable supplémentaire.

Pour les variable GET j'ai fait des contrôle sur les variables pour vérifier qu'elle existe bien et qu'elle sont correcte.

Faut-il protéger ou sécuriser d'avantage les variable (GET et POST) sur mon site pour éviter d'être piraté ?!

[quote="angebleu17"]Donc dans ma page index j'ai le design et ensuite j'inclu des pages qui ont que du contenu (pas de design). Pensez vous que c'est une bonne idée ?[/quote]

C'est effectivement une façon de faire... c'est ce que l'on appelle des "pseudo-frames" : entête et pied de page sont présents dans un unique fichier qui va inclure le contenu de la page demandée.
L'avantage, c'est que cela respecte le modèle MVC2 (model view controller) puisque tout ton site est accessible par un seul point d'entrée (ta page index.php) et que cela permet de simplifier les tests, l'authentification etc en un seul endroit. Avantage également, tu peux facilement ajouter de nouvelle page, suffit de coller un fichier et de le déclarer dans ta liste.
L'inconvénient, c'est qu'il te faut à chaque fois passer un paramètre en plus pour ouvrir la bonne page (tu perds un peu en référencement à moins de faire de l'url rewriting). Cela t'oblige également que la page demandée est autorisée (via une white list) pour éviter que l'utilisateur ne puisse ouvrir n'importe quel fichier et surtout à mon sens, tu ne peux faire de header() dans une page incluse, pour rediriger l'utilisateur puisque l'entête a déjà été envoyé dans le fichier parent.

Personnellement je ne l'utilise pas, je préfère avoir deux fichiers (un entete et un pied de page) qui sont inclus dans chacune de mes pages. L'avantage, c'est que je n'ai aucun des inconvénients listé ci-dessus :) Mais ça reste qu'une façon de faire personnelle et le modèle MVC peut s'avérer très utile lorsque tu as des templates :)

[quote="angebleu17"]Ensuite pour les liens au début je passais les varible par l'UR (méthode GET), puis j'ai modifié en mettant un formulaire et en passant par la méthode POST, pensez vous que c'est bien pour protéger les variables afin que l'utilisateur ne puisse pas modifier les variables dans l'URL ?[/quote]

Le fait d'envoyer tes données en post assure un peu plus de sécurité face à des utilisateurs néophytes qui effectivement n'auront probablement pas l'idée de modifier la variable. Maintenant, un utilisateur confirmé pourra très bien faire son propre formulaire et envoyer à ton site ses données en post. Ca ne te soulage donc absolument pas de la sécurité à mettre derrière pour vérifier que l'accès à tes pages est autorisé ou pas. Tu te compliques donc peut être la tache pour pas grand chose. Par ailleurs, si un utilisateurs fait "précédent" ou "actualiser" un message l'informera que la page ne peut être réaffichée sans l'envoi des données en post. Tandis qu'en get, les données étant déjà dans l'url, la page s'ouvre directement. C'est à mon avis plus confortable :)

Bonjour,

Je commence mon site et je me pose quelques questions.

Tout d'abord je voulais mettre des iframes mais vu que pour le référencement c'est pas top j'ai mis des bloc div. Donc j'ai une page principale (index.php) qui comporte le design du site et ensuite je fait des includes dans le bloc div suivant sur quel lien on a cliqué. Je me demandais si c'était une bonne solution ? Car je pense qe ce n'est pas utile de remmettre dans chaque page le design du site ?!

Donc dans ma page index j'ai le design et ensuite j'inclu des pages qui ont que du contenu (pas de design). Pensez vous que c'est une bonne idée ?

Ensuite pour les liens au début je passais les varible par l'UR (méthode GET), puis j'ai modifié en mettant un formulaire et en passant par la méthode POST, pensez vous que c'est bien pour protéger les variables afin que l'utilisateur ne puisse pas modifier les variables dans l'URL ?


Merci d'avance