comment savoir si mon site est suffisamment sécuriséFermé

Question

bonjour a tous

j essaye de savoir comment je pourrais savoir si mon site est prêt a supporter une éventuelle attaque mineure
car on ne pourra jamais empêcher une vraie attaque 
mais déjà arrêter les petits rigolos
j ai vu qu il existait des dizaines de scans en lignes avec des résultats qui partent un peu dans tous les sens 
donc ma question est de savoir après les requêtes préparées , ce que je pourrais faire pour protéger mon site 
j ai aussi entendu parler du fichier .htaccess
dans lequel on pouvait ajouter pas mal de choses 
mais n ayant vraiment aucune expérience dans ce domaine 
je préfère demander votre avis 
merci de l aide

Totox · Accepted Answer

Salut,
que voulez vous sécuriser au juste?
Les contenus d'un site web sont faits pour être diffusés donc il n'y a rien à sécuriser, c'est public par définition.

Le reste c'est le serveur qui envoie le site (voir HTTP et HTTPS)et ça c'est le rôle de l'hébergeur de sécuriser son matériel.
Pour les données stockées et échangées c'est en partie la base de donnée(donc le gestionnaire de celle ci: l'hébergeur) celle ci n'est pas accessible directement.
Donc c'est par le programme exécuté sur le serveur que passe une partie de la sécurité(le reste c'est le boulot des hébergeurs), ça dépends donc de la façon dont le site est fait et de la qualité du programme(c'est assez trivial mais à prendre en compte).

Si c'est pour d'autres types de transaction de données "sensibles" comme une transaction bancaire ce sont les organismes bancaires qui ont leurs propres sécurité.

Donc avant de vous demander "comment sécuriser un site" il faut savoir qu'est ce que au juste vous devez sécuriser, contre quel type de faille ou attaque. Chaque point particulier aura ses propres réponses.


htacess est un fichier de configuration du serveur Apache donc pas grand chose à voir avec la sécurité d'un site il me semble.

Côté programme:

"donc ma question est de savoir après les requêtes préparées , ce que je pourrais faire pour protéger mon site "
Une requête préparée est une sécurité pour l'intégrité du programme(et de ses données) et contre l'injection SQL(surtout par rapport à ce qu'il y avait avant) mais il y a d'autres moyens à utiliser.
Généralement interdire le cross domain origin suffit(que quelq'un utilise son propre fichier dans un programme) et c'est fait de base à moins de vouloir le changer:

https://developer.mozilla.org/fr/docs/Web/HTTP/CORS

Sinon pour d'autres règles pour sécuriser il existe tellement de façons de faire et de choses à sécuriser que je ne pourrais(ni ne sait) détailler celles ci et particulières à chaque langage de programmation et structure derrière.

Pour le web j'ai dit l'essentiel: C'est la sécurité du programme contre les injections le problème principal que vous avez à gérer sauf si les infrastructures matérielles c'est vous qui les mettez en place.
Par exemple les attaques de type DDOS n'ont rien à voir avec votre site mais avec le serveur web.
C'est les données qui doivent être sécurisées et non le contenu du site(HTML) puisque celui ci est public.
La sécurité signifie surtout intégrité des données donc un systèmes d'informations et des tables de données bien organisées avant tout, si c'est mal fait la base de données ne tiendra pas ou devient simplement ingérable et récupérer les données (pour un meilleur système)va s’avérer ingérable, en tout cas très compliqué en temps et ressources à faire.

Mais contre quelqu'un qui veut contourner une sécurité il y a ce principe déjà qui isole l'utilisateur(physiquement) d'un accès direct aux données(et rend nécessaire un programme serveur pour faire des requêtes et traiter les résultats pour les fournir à la page):
https://fr.wikipedia.org/wiki/Architecture_trois_tiers


Après si vous êtes protégé contre les injections SQL et le CROSS DOMAIN ORIGIN vous avez l'essentiel.

Donc vous voulez protéger quoi ? De quoi?
Si c'est pour afficher des contenus de façon privé ou semi-privé il faut passer par une identification par mot de passe.
Exemple: Pour me connecter à mon compte sur le site "NimporteQuelSite.com" je doit être authentifié et personne ne peut y accéder sauf moi(un identifiant et un mot de passe c'est plus personnel qu'une clé, ça ne se partage pas).

C'est donc le programme qui rends certains emplacements(pages) et informations privés, elles ne sont pas accessibles au public.
Côté sécurité ça passe par la validation d'une connexion(identifiant +mot de passe) et la création de variables de session entre autres, voir ce qu'est un Intranet de gestion.

flexi2202 · Answer

bonjour avant toute chose un très grand merci pour cette explication je vais en faire un imprimer et le relire a mon aise tête reposée car j apprends beaucoup de choses a travers cette lecture beaucoup de terme sont nouveaux pour moi .. a présent je sais déjà qui est responsable de quoi et comment c est vrai que quand on parle de sécurisé son site cela veux tout dire et ne rien dire de mon cote j ai déjà fais toutes mes requêtes en requêtes préparés j ai également rendu propre chaque variable je suis allé visiter le lien que tu as mis mais cela a l air vachement complique de se protéger de CROSS DOMAIN ORIGIN Mon inquiétude a commencer lorsque j ai scanner mon site sur des sites avec des robots pour détecter les failles éventuelles oui je sais que c est pas bien , car c est surement peut être attire les petits malins a me rendre visite et me pirater si ils découvrent une faille voici les sites ou je me suis rendu par exemple dans ce lien ou nous indiques ce qu il manque au fichier htaccess https://www.seomix.fr/guide-htaccess-performances-et-temps-de-chargement/ je me suis rendu sur ce site et j ai fait un scan https://webhint.io/scanner/ et voici ce qu il en ressort astuce # 1: Un en-tête 'cache-control' contient des directives qui ne sont pas recommandées: 'must-revalidate', 'no-store' https://phil.pecheperle.be/ Cache-Control: no-store, no-cache, must-revalidate conseil n ° 2: la ressource doit utiliser le contournement du cache mais l'URL ne correspond pas aux modèles configurés https://phil.pecheperle.be/css/album.css astuce n ° 3: les ressources statiques doivent utiliser un en-tête 'cache-control' avec 'max-age = 31536000' ou plus. https://phil.pecheperle.be/css/album.css Cache-Control: public, max-age=604800 astuce n ° 7: la ressource doit utiliser le contournement du cache, mais l'URL ne correspond pas aux modèles configurés. https: //phil.pecheperle… youtube-peche-perle.png Nature

astuce n ° 1: la réponse ne doit pas inclure les en-têtes non autorisés: x-powered-by https://phil.pecheperle.be/ x-powered-by: php/7.4.11 astuce # 2: L'en-tête «Expires» ne doit pas être utilisé, «Cache-Control» doit être préféré. https://phil.pecheperle.be/ et j en passe ... donc que faire avec toutes ces astuces et conseil c est une partie de ma question plus en detail

bg62 · Answer

surtout ne te casses pas trop la tête avec tout ce que certains disent savoir .....    :)
- protéger côté serveur ( chmod )
- instructions simple et claires : en-tête et .htaccess
- un fichier .htaccess ( même vierge ! ) dans chaque dossier
faire des tests de vulnérabilité et en tirer parti, voir ici :
www.acunetix.com
( parfois lourd et lent quand le site est gros, mais fiable ! )
:)

Comment savoir si mon site est suffisamment sécurisé

3 réponses

Discussions similaires

Newsletters