Jump to content
Sign in to follow this  
Boumbadaboum

check up sécurisation d'un site

Rate this topic

Recommended Posts

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" ?)

Edited by Boumbadaboum

Share this post


Link to post
Share on other sites

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... :P

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

Share this post


Link to post
Share on other sites

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 ;-)

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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 :hypocrite:

Share this post


Link to post
Share on other sites

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 !

Share this post


Link to post
Share on other sites

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.

:)

Share this post


Link to post
Share on other sites
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 :fou: (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

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites

Merci Dudu pour cette liste tres utile.

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Merci Dudu pour cette liste tres utile.

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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?

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.

Share this post


Link to post
Share on other sites

Pour anonymus :

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.

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.

Edited by Boumbadaboum

Share this post


Link to post
Share on other sites

pour destroyedlolo :

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

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 ?

Edited by Boumbadaboum

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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 !

Share this post


Link to post
Share on other sites

Ne vires quand même pas tout non plus :P

Et les liens pour les requires, ils vont ressembler à quoi si ils sortent du répertoire www? Un exemple svp !

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.

Share this post


Link to post
Share on other sites
PS: Note que l'URL www.serveur.tld/dossier/.. est égale à l'URL www.serveur.tld/

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... :/

Share this post


Link to post
Share on other sites

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 :hypocrite:

D'accord Dudu, merci beaucoup ! :P

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...