regles generales de securité - PHP - Programmation
Marsh Posté le 07-12-2004 à 10:19:30
- dès la conception du site une architecture cohérante en utilisant variables GET et POST et un controle sans faille des entrée-sortie (source de 99% des failles). Register global= Off indispensable
(pseduo frame, mais à manipuler avec bcp de précaution: test fiable sur l'url et interdiction de revenir dans l'arborescence ...)
Se mettre en codant le site à la place d'une personne malintentionnée
- Pour la mise en production : Configurer le serveur Web pour cela : passer apache,php,mysql en mode production de façon à pas afficher les erreurs, versions, etc. : mine d'informations pour une futur potentiel hacker
Marsh Posté le 07-12-2004 à 11:02:03
ce qui est pas mal aussi c'est balancer le mot de passe en md5 depuis le client et pas le faire seulement lors de l'insertion !
Marsh Posté le 07-12-2004 à 14:09:07
comment faut il faire pour parametrer le Register global en Off?
merci
Marsh Posté le 07-12-2004 à 15:43:47
attentio a écrit : comment faut il faire pour parametrer le Register global en Off? |
dans la version 1.7 d'easyPHP (donc PHP 4 qquechose), il y est par défaut)
EDIT: sinon, comme te le dis spike, dna sle php.ini de ton répertoire apache.
Marsh Posté le 07-12-2004 à 15:53:51
en local, je comprends bien ...
mais sur le net comment ai-je acces au fichier apache (je suis chez OVH)
merci de votre aide
Marsh Posté le 07-12-2004 à 18:01:18
Si tu es chez un quelconque provider, tu n'as pas de moyen de contrôle. Tout au plus peux-tu tester si une feature donnée est activée oui ou non.
En général, un bon provider suit des règles de bonnes pratique, donc orientées vers la sécurité (ce qui limite d'ailleurs parfois l'utilisabilité), mais un compromis est parfois nécessaire entre facilité d'utilisation (genre afficher les messages d'erreurs) et sécurité (ne rien afficher).
Si tu comptes faire une application de commerce en ligne, ce n'est sans doute pas une solution adapatée.
Il est indispensable de lire les docs PHP, Apache sur les points de sécurité - assez claires il me semble.
Marsh Posté le 08-12-2004 à 14:45:22
actuellement, beaucoup d'hébergeurs on un register_global à ON, paske ça permet de faire tourner tout les vieux scripts déjà en place.
rien qu'avec les sites perso que je fait, je peux t'assurer que c'est le cas chez:
- Tiscali (1 site perso)
- La Poste (2 sites perso)
- OVH (site de mon asso hébergé chez eux)
maintenant, pour changer la valeur d'une variable du php.ini quand c'est pour un site distant (en opposition à local), il te faux utiliser ini_set, mais ça ne permet pas de toucher à toutes les variables du PHP.ini.
En plus, le ini_set sur certaine variable est parfois autorisé par la doc, mais verrouillé par ton hébergeur par sécurité (comme le max_execution_time par exemple)
Marsh Posté le 08-12-2004 à 15:03:42
Les Register Global = Off ne sont faites que pour palier aux deficiences des développeurs. Si les variables sont bien déclarés et initialisés avant utilisation, ca n'apporte rien de plus au niveau sécurité.
Une bonne chose est également d'activer la notification de variable non déclaré dans le php.ini, mais bon on en revient au principe d'avoir accès à la config PHP du serveur.
ce que certains hébergeurs mutualisés proposent je crois.
Enfin pour un site d'e-commerce peut-etre qu'il est préférable d'avoir un serveur dédié notament si il y a une base de données avec un back-office que tu ne veux pas forcement programmer en php, y'a des langages plus adaptés peutetre.
Marsh Posté le 08-12-2004 à 16:50:31
Tu pourras trouver de bonnes explications sur le site de developpez.com à cette adresse :
http://thierrylhomme.developpez.com/php/php_secure/
Marsh Posté le 12-12-2004 à 00:05:36
sircam a écrit : Si tu es chez un quelconque provider, tu n'as pas de moyen de contrôle. Tout au plus peux-tu tester si une feature donnée est activée oui ou non. |
Faux !
Chez Lost-Oasis, tu peux avoir ton propre php.ini, même pour un hébergement mutualisé
Et en plus ils proposent les BDD PostgreSQL
Marsh Posté le 12-12-2004 à 15:08:44
sylva1n a écrit : Faux ! |
Il ne s'agit plus alors d'un quelconque provider.
Et cette merveille est gratuite ?
Marsh Posté le 12-12-2004 à 16:55:09
sylva1n a écrit : Faux ! |
on peut aussi utiliser ini_set() pour redefinir temporairement(temps d'execution du script) certaines variables modifiables du php.ini
Marsh Posté le 13-12-2004 à 23:27:42
sircam a écrit : Il ne s'agit plus alors d'un quelconque provider. |
Non, mais pour 30/an tu as un hébergement 100 Mo (soit trafic illimité, soit trafic 1Go mais débit garantit) + 1 BDD + boîtes mail/alias/sous domaines illimités + PHP 5 + des tas d'autre trucs très pratiques.
Rapport prestations/prix, je crois qu'il sont dur à battre.
Marsh Posté le 14-12-2004 à 17:31:46
sylva1n a écrit : Non, mais pour 30/an tu as un hébergement 100 Mo (soit trafic illimité, soit trafic 1Go mais débit garantit) + 1 BDD + boîtes mail/alias/sous domaines illimités + PHP 5 + des tas d'autre trucs très pratiques. |
Pas mal du tout. Rapport qualité/prix, je pense cependant que free conserve pour moi la première place avec ses 0.
Mais bon, ils le font plus que pour les abonnés, j'ai lu .
Et dans la pratique, le QoS est aussi effectivement bon ?
Marsh Posté le 14-12-2004 à 18:01:24
pow: pow! pow! php5 il mette le paquet !
Marsh Posté le 15-12-2004 à 11:37:40
sircam a écrit : Et dans la pratique, le QoS est aussi effectivement bon ? |
Ca dépend
La qualité oscille entre "putain, ça p00tre" et "sa race, ça rame"
En fait, ils sont encore jeune, et ils grossissent vite, alors il ont souvent à faire des traveaux sur l'infrastructure. Faut dire que niveau infrastructures, ils mettent des moyens ! Le PHP etait super rapide, ils sont en train d'ajouter des serveurs pour le rendre encore plus rapide.
J'hesiterai à l'utiliser pour un gros site d'entreprise (mais bon, pour un site comme ça j'aurai un serveur dédié ) par contre, pour un gros site perso, ou un site d'asso, je pense que c'est vraiment très bien !
Après, il y a plus fiable ... mais c'est plus cher ...
Marsh Posté le 06-12-2004 à 18:18:10
bonsoir,
j'aimerais savoir en gros les regles generales pour avoir un site de ecommerce a peu pres securisé.
pour info, mon site utilise :
les sessions, du javascript, les pseudos frames,des formulaire en post, flash, des fichiers htaccess,... etc
ma zone admin est protegée par sessions, et mon mot de passe en md5
laconnexion ama base se trouve dans un repertoire protegé par un fichier htaccess
(en faite je sais pas si C tres utile de tout enumerer ya un peu de tout)
merci de me dire ce qu'il ne faut pas faire et surtout ce qu'il est conseillé de faire
Message édité par attentio le 24-03-2005 à 20:49:53
---------------
L'ordinateur a de la mémoire mais aucun souvenir ...