Bonjour,
J'ai bientot terminé mon site internet, merci au Hub au passage.
Avant de le mettre en ligne, je voudrais faire un point sur les mesures à prendre afin de se prémunir le mieux possible contre les pirates.

Exemple sur mon site j'ai :

- Un url rewriting (cache le nom des variables et empêche de trifouiller les urls).
- Un filtrage des formulaires avec la fonction php strip_tags.
- Un htaccess pour le PHPmyAdmin

Est-ce déjà suffisant, pour le pirate de base du moins, où est-ce encore une vrai passoire? Dois je mettre un Hhaccess pour les dossiers du sites (ceux avec les scripts notamment) ou est ce que cela va gêner le fonctionnement ?)

Et surtout : Comment faire donc pour obtenir une sécurisation optimale?

J'ai eu l'idée suivante, dites moi ce que vous en pensez svp :

Je me suis dit que j'allais acheter un mini hébergement avec bdd pour réceptionner dans celle ci le contenu des formulaires, les traiter ensuite depuis mon admin perso afin de les insérer dans la vrai base de donnée du site qui elle est donc inaccessible depuis le site lui même.
Mais est-ce possible de se connecter à des bases de différents sites depuis un même site? Et si oui est-ce utile comme je le pense?

J'écoute vos suggestion !

(j'ai pas fait une faute à "check up" ?)

Salut à toi !

Il faudrait utiliser un htmlentities pour mieux sécuriser tes formulaires... Comme ça, ils ne pourraient pas écrire de balises du genre <script>

En fait, dis toi qu'une sécurité optimale n'existe pas, sinon tous les sites officiels seraient sécurisés, et aucun pirate ne pourrait aller sur les sites de l'armée américaine...
Tu ne fais pas le site d'une banque non plus, si ? J'ai l'impression que tu cherches à te prendre la tête avec tes bases de données, mais regarde tous nos sites : on utilise la bdd de notre site et on n'a pas de problèmes de sécurité majeurs...

Avec une sécurisation des formulaires, tu as déjà une bonne partie du boulot de fait...

Ok c'est noté pour le htmlentitie

Autre choses?
Sinon pour le coup de mes deux bases est-ce que c'est faisable ou impossible?

oui c'est faisable, mais c bcp de boulot pour rien... inutile d'être parano.... à moin que tu ne sois un terroriste... et dans ce cas n'oublie pas que les américains sont pas si nul que ça ;-)

Je me rend pas bien compte en fait. C'est fréquent les sites piratés?
C'est fatale pour le site ou pas? Vous allez me dire ça dépend de l'attaque, mais en général ?

Salut,

Pour moi, il y a deux sortes de 'hacker' :

1 - Le petit jeune prépubère bien au chaud dans sa chambre reprenant certaines méthodes exposées sur le web sur des sites pour maisons de retraites.
Eux, ils saccagent généralement tout.

2 - Le hacker qui a étudié ton site de fond en comble. Celui là à le respect du code mais parfois... il te change 'seulement' ta page index ^_^

Tu auras beau essayer de tout prévoir, un hacker peut aussi passer par le serveur en lui même....


Portekoi le parano

Site entier piraté, pas si fréquent que ça... Souvent, c'est à partir de scripts ou de failles dans les forums (du genre phpbb pas mis à jour quoi...) que les gens passent, vu que ce sont des failles plus connues... Les sites tout fait à la main, comme le mien, sont moins sujets à des attaques je pense !
Les "gentils" hackers te changeront juste ton index.php en mettant un petit message et laisseront le reste en place, les moins sympas vireront tout ce qu'il y a sur ton disque, voire feront des redirections vers d'autres sites, bref... Enfin bon, là encore tout est possible !

La premiere des precautions a prendre consiste a faire des sauvegardes regulieres.
base de donnees et fichiers.

La seconde : garder un oeil attentif et se tenir pret a reagir en cas de probleme.


Dans la plupart des cas, ces precautions suffisent amplement.

Franchement je ne sais pas à quoi ca leur sert de pirater un site,c'est inutile.

Bon mais alors à part passer pas les formulaires et trifouiller les urls non rewrité, qu'est ce qu'ils ont donc comme porte d'entré les pirates?

tous les accès si le mot de passe est trop simple à craquer au brute force.
Je sais çà a l'air bête mais c'est la première règle: un vrai mot de passe c'est des majuscules, des minuscules, des caractères spéciaux tel que _ ! § & < et des chiffres.
"azerty" n'est pas un mot de passe valable. Encore moins une date de naissance, un nom commun, ou le nom de son chinchilla.

Ensuite, il y a plusieurs choses (en fonction de son degré de paranoïa)
- masquer la ligne <address> dans une page d'erreur est un bon début
- masquer le langage avec lequel on travaille
- masquer les index de répertoires ou ne permettre leur affichage qu'avec restrictions (mot de passe)
- faire des pages d'erreur personnalisés avec envoi au webmaster d'un mail automatique lui précisant l'IP du visiteur et l'URL de la page qui a provoqué l'erreur
- balancer des htmlentites() à outrance dès qu'un visiteur est amené à envoyer un formulaire
- ne pas passer dans l'URL des variables "sensibles"
- vérifier avec son hébergeur que seules les requêtes GET, POST et HEAD sont autorisées (PUT, PROPFIND et les autres sont parfaitement inutiles)
- ne jamais concevoir d'URL de type ?page=/includes/article1.inc (j'en ai croisé il y a peu de temps) même si elles sont amenées à etre réécrites par .htaccess
- ne pas donner de noms trop explicites aux choses (exemple: un champ "password" pour les mots de passe dans la BDD)
- crypter en MD5 les données sensibles
- changer par .htaccess le nom du fichier par défaut d'un répertoire
- empêcher l'accès direct par URL à des fichiers destinés soit à être inclus, soit destinés à la configuration
- ne jamais nommer un fichier destiné à être inclus par une extension .inc (son contenu pourra être lu)
- etc ..

Voilà mes quelques idées en vrac (liste non exhaustive).
Sinon, LE lien pour la sécurité PHP c'est encore le célèbre manuel: http://www.php.net/manual/fr/security.php
Notons aussi que travailler avec le célèbre couple PHP-MySQL rend le travail plus aisé aux hackeurs puisqu'il s'agit de langages non propriétaires et très fréquents.
Je suis près à parier qu'une page trouée en JSP sera craquée moins vite qu'une page un peu plus sécurisée en PHP

Et à tout ceci, il ne faut pas non plus oublier qu'une bonne partie des 'pirates' entrent en fait avec un pass autorisé, autrement dit, ce sont des personnes que tu auras validé auparavant.
Exemple ?
Tu prends un stagiaire, tu lui donnes un mot de passe pour travailler sur ton serveur, puis au bout de quelques jours tu t'embrouilles avec lui. Il part donc, mais tu oublies de désactiver ses droits d'accès. Il a donc un accès valide.


Mais à trop être parano, on finit par éteindre son micro, alors..

Merci Dudu pour cette liste tres utile.

Comment faire pour qu'un formulaire ne puisse etre posté QUE depuis le serveur ?

Tu vérifie le http_referer et un autre truc aussi mais je le fais jamais

Ouais, ça c'est de la réponse !

Le post reste ouvert, si vous avez d'autres idées n'hésitez pas.

Et mon idée de récupérer les contenues des formulaires dans la Bdd d'un autre site/nom de domaine qui ne sert qu'à ça avant de les réexpédier tous dans la vrai Bdd du site (insertion différée après controle). Qu'est ce que ça vaut alors?

Un trucs facile a faire et important :
placer les fichiers includes contenant des donnees importante en dehors de l'espace web.

L'avantage est que meme si tu fais une erreur dans la protection dans tes .htaccess (ca arrive vite lorsque tu as plusieurs centaines de pages, ce qui est mon cas), les fichiers ne seront pas lisibles sans se connecter directement au serveur.

Sinon, la base est encore et toujours de verifier le contenu des formulaires et de ne rien passe par URL.

Lolo

C'est farfelu. Ca ne sert pas à grand chose : Si la personne est capable de berner le premier site, il est aussi capable de berner le second site intermédiaire. De plus, tu risques de doubler le temps d'execution du programme, de la page. Si le second site est arreté, ou si son accès est 'lent', alors tu ralentis tout le processus. De plus, à sortir de ton serveur, tu multiplies les risques, notamment ceux inhérents au réseau en lui même.
Bref, c'est 'capilo-tracté', autrement dit tiré par les cheveux !

Pour en revenir aux formulaires par méthode GET, il faut savoir qu'il est aussi possible d'ouvrir une page sur un serveur distant, en simulant l'ouverture de la page par méthode POST. Autrement dit, même si c'est une précaution élémentaire, elle n'en reste pas moins 'basique'

Anonymus.

Pour anonymus :



Moi je veux bien te croire je suis pas encore un pro loin de là. Mais pourtant : Le gars réussit à s'introduire dans la base de donnée depuis un formulaire. Cette base de donnée est donc (serait donc) situé sur un autre site. Il n'y a rien d'autre sur cette base que le contenu des formulaires récemment remplis. Une fois dans cette base il n'a donc rien du tout sous la dent, si ce n'est les quelques dernières news postées.
Comment peut il ensuite faire le pont entre cette base de donnée de transit et la vrai base du site qui récupère les news validées depuis l'admin perso qui elle fait donc le pont entre la base de transit et la vrai base ?
Je voudrais comprendre ça m'intéresse.

pour destroyedlolo :


Je ne vois pas trop ce que tu veux dire. Prenons mon site :
J'ai un répertoire global www.
tout de suite à l'intérieur j'ai l'index dans lequel sont inclu des fichiers, Les fichiers donc, qui eux se trouvent dans un répertoire Mesfichiers.
Bon je peux mettre un htacess la dedans à priori?

Mais en dehors de l'espace web ça veut dire quoi? en dehors du répertoire global www ?

Exactement. Tu as tout compris (au pire, vérifies auprès de ton hébergeur au cas où il aurait une configuration hors-norme)
Apache pourra accéder à ces fichiers, mais il sera impossible d'y accèder en tapant une URL dans la barre d'adresse, même en y rajoutant des ../../.
À ce propos, Apache ne tient aucun compte des .htaccess (puisqu'il accède de l'intérieur aux fichiers, et non de l'extérieur) donc ne pas hésiter à mettre un petit deny from all dans tous les répertoires 'sensibles' (ex: répertoire où sont stockés les fichiers de configuration).

Ok mais alors on peut tout placer en dehors du répertoire www à l'exception de l'index alors?

Mais ça va fiche en l'air tout mon url rewriting ça, non ?!
Et les liens pour les requires, ils vont ressembler à quoi si ils sortent du répertoire www? Un exemple svp !

Ne vires quand même pas tout non plus
Quand tu travailles en lien relatif, tu peux aller où tu veux

include_once("configuration.php");
Inclut le fichier configuration.php situé dans le même dossier

include_once("./functions.php");
Même chose

include_once("../functions.php");
Inclut le fichier configuration.php situé dans le dossier parent

include_once("../../functions.php");
Inclut le fichier configuration.php situé dans le dossier parent du dossier parent

include_once("../../../functions.php");
Inclut le fichier configuration.php situé dans le dossier parent du dossier parent du dossier parent

include_once("/configuration.php");
Inclut le fichier configuration.php situé à la racine du serveur (dans l'espace web)

On peut donc aller très loin comme çà, pas de souci pour tes liens

PS: Note que l'URL www.serveur.tld/dossier/.. est égale à l'URL www.serveur.tld/
Fais l'essai sur n'importe quel site tu verras.

Euh Dudu, là j'avoue que je te suis plus... Tu appelles quoi "égale" ? Un fichier qui est dans un dossier n'est pas dans un autre dossier, si ? lol
non sérieusement, je vois pas pourquoi tu dis ça... :/

Exemple: http://www.webmaster-hub.com/publication/
Une fois sur la page rajoute les deux points à la fin de l'URL

Pour dire que par convention les deux points signifient "dossier parent"

Oui, avec le bon nom, je comprends, quelqu'un a bizarrement modifié l'url dans les posts, et on me fait passer pour un bête maintenant lol
Ni vu, ni connu

D'accord Dudu, merci beaucoup !

Non, tous ce qui doit etre accessibles 'directement' au navigateur de ton visiteur ou a apache lui-meme doit se trouve dans ton www (images, html et derrives, ...).
Par contre, tous les includes et les fichiers de donnees de PHP peuvent se trouver hors de cette arbo.



Nan, les url rewriting se passent au niveau d'apache donc ne consernent que ce qui se trouvent dans www.

Ben c'est rassurant de savoir ce que les gens pense des jeunes :'(

Je modifiais un module de nuked klan et j'ai trouvé une faille dedans qui permettait à n'importe qui de devenir membre niveau 9 (admin du site quoi), et la seule chose que j'ai fait, c'est faire la manip sur le site officiel pour prévenir les dev dans leur forum privé...

Sinon dans le domaine de la sécurité, je n'y connais pas grand chose. Mais en général c'est plutot les failles de bases qui sont importantes (un seul champs de formulaire qui a été oublié d'être vérifié et c'est le drame).

Et comment il fait pour le trouver ce formulaire non filtré ? faut quand même qu'il le cherche un peu à la base non? qu'il surveille, qu'il guette, qu'il épie, qu'il contrôle, vérifie, note..........aux aguets, équipé derrière son PC tel un barbe noire furtif qui... que... .

Hein ? Quoi ?

Salut ,
Voici l'URL d'une pages interessante par la sécurisation de votre site :
10 failles de sécurité

Bonne lecture !

voici quelques articles interessants sur les injections SQL:
Injection SqL
Injection SqL Partie 2

merci a phpsecure

Encore une fois, moi je suis tombé dessus par hasard, un champs de formulaire qui était déstiné à contenir le type d'écran. Je tape "17' plat" et je me rend compte que toute les valeurs tapés dans le formulaires n'ont pas été prises en compte.

Donc quelqu'un qui veut hacker un site peut déjà commencer par envoyer des guillemets simples sur tout les formulaires de ton site puis regarder si il y a eu des erreurs ou bugs.