PHP

effacer des données bdd apres expiration d'une session

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 3 Page Suivante Page Précédente Bas de page
Auteur	Sujet : effacer des données bdd apres expiration d'une session

freed102

Arayashiki

Reprise du message précédent :

Citation :

Donc, en supposant que le serveur soit blindé (pas de ports ouverts & co).

Etre sur un serveur dédié => sinon faille du glob();

ça... j'ai pas le choix ! on sera sur un serveur mutualisé !

Citation :

SID par cookie exclusivement, générée dynamiquement sur le serveur & autres trucs de secu des sessions .

ça c'est pas déja comme ça par defaut ?

Citation :

Liaison SSL impérative

Citation :

Supposer par defaut que tout ce qu'on recoit du navigateur du user est faux et tente de nous hacker (ne jamais se dire : Il peut cliquer juste sur oui ou non donc c'est secure).

Citation :

Rediriger tout les messages d'erreur PHP vers un gestionnaire qui n'envoie au client qu'un message "neutre" ... Pour empecher qu'il recupere des infos au cas ou on aurait oublier une faille.

Citation :

Disons que c'est deja un bon debut ... Apres il y a probablement d'autres choses a controler mais c'est ce qui m'est venu directement a l'esprit ...
Perso je prend 2 autres petites secu supplémentaires :
Je met des noms de table/champ générés par un generateur de password. Ca empeche le fait que qqn qui arrive a passer une SQL injection puisse tomber trop facilement sur le nom d'une de mes tables.
Je stoque le md5 du contenu de mes fichiers de session pour etre sur que personne ne les a modifié entre 2 appels.

visiblement toi tu brouiles toutes les pistes !!! Mais bon apres c à la limite de la parano je trouve !

---------------
Freed102

Publicité

freed102

Arayashiki

le SSL c pas l'hebergeur qui gere ça directement ? voici ce que me propose mon hebergeur :

Citation :

500 Mo d'espace disque
PHP4 et PHP5 avec votre propre php.ini
Support des CGI : Perl, Python, C, TCL, Shell
Support des SSI (Server Side Includes)
Serveur SSL mutualisé
Option serveur multimédia Real ou IceCast
Compatible Citelis, Cyberplus, Sogenactif ...
Bases de données MySQL illimitées + DBI
Panneau de contrôle Web
Protection des répertoires par mot de passe
Support technique illimité et non surtaxé
Alias de domaine illimités
Sous domaines illimités
1000 comptes de messagerie POP3
Webmail
Extensions Frontpage 98/2000/2002
Statistiques de fréquentation
1 compte telnet/ssh et 2 comptes FTP
Fractionnable en 2 comptes indépendants
(Possibilité d'héberger jusqu'à 2 sites)

---------------
Freed102

zzarbi974

freed102 a écrit :

le SSL c pas l'hebergeur qui gere ça directement ? voici ce que me propose mon hebergeur :

Citation :

Heu non du tout, lui il a juste la possibilité de les traiter, c'est comme le php, c'est pas pasu'il traite le php qu'il fait les requet tt seul...
J'avais trouvé de la doc dessu si tu veux je peux refaire une recherche...

Et moi ça fait un bout de temps que j'attend des conseils et doc sur la sécu.

---------------
Chouette cette Inspiron 9300

zzarbi974

Et pour ça esox_ch :

Citation :

Rediriger tout les messages d'erreur PHP vers un gestionnaire qui n'envoie au client qu'un message "neutre" ... Pour empecher qu'il recupere des infos au cas ou on aurait oublier une faille.

J'aimerais bien savoir comment le faire... :jap:

Citation :

Je met des noms de table/champ générés par un generateur de password. Ca empeche le fait que qqn qui arrive a passer une SQL injection puisse tomber trop facilement sur le nom d'une de mes tables.

ça c'est pas con...

et ça aussi j'aimerais plus d'info :

Citation :

Je stoque le md5 du contenu de mes fichiers de session pour etre sur que personne ne les a modifié entre 2 appels.

Message édité par zzarbi974 le 09-09-2005 à 12:34:52

---------------
Chouette cette Inspiron 9300

freed102

Arayashiki

je pense qu'il y a une histoire de ini_set() et de error_reporting()

---------------
Freed102

esox_ch

freed102 a écrit :

Citation :

Donc, en supposant que le serveur soit blindé (pas de ports ouverts & co).

Etre sur un serveur dédié => sinon faille du glob();

ça... j'ai pas le choix ! on sera sur un serveur mutualisé !
Alors ne laisse pas le rep par defaut pour les sessions (/tmp en general) , met le dans ton repertoire parceque sinon depuis un autre site sur le meme hebergeur on peut te hacker

Citation :

SID par cookie exclusivement, générée dynamiquement sur le serveur & autres trucs de secu des sessions .

ça c'est pas déja comme ça par defaut ?
Non, par defaut il cherche a envoyer par cookie et si ca passe pas il l'envoie par url

Citation :

Liaison SSL impérative

c'est ça qui m'interesse ! là sur ce point là j'ai des choses à apprendre ! j'ai jamais fait de liaison SSL directement sur mon site... (je sais pas si la liaison avec SIS Atos est considérée comme une liaison SSL... ça m'etonnerait !
Des que tu traites des données sensibles (je considere que mon num de telephone est une donnée sensible) tu passes par SSL

Citation :

Supposer par defaut que tout ce qu'on recoit du navigateur du user est faux et tente de nous hacker (ne jamais se dire : Il peut cliquer juste sur oui ou non donc c'est secure).

là je comprends pas trop ce que tu veux dire.. dans mon cas.. je m'arrange toujours pour que l'utilisateur soit identifié avant de pouvoir avancer dans le site... si ya aucune variable indiquant que l'utilisateur est connecté... il retourne à la case depart !
Je veux dire que le mec qui c'est autentifié peut modifier les requetes HTTP qu'il envoie a ton serveur.. Par exemple admetons que tu as une select liste avec 10 options .. rien n'empeche l'utilisateur de créer une 11ème option sur une page hebergée chez lui et de te l'envoyer a ton formulaire... selon comment tu geres le tout et ce qu'il met dedans ca peut faire tres mal

Citation :

Rediriger tout les messages d'erreur PHP vers un gestionnaire qui n'envoie au client qu'un message "neutre" ... Pour empecher qu'il recupere des infos au cas ou on aurait oublier une faille.

ça je suis d'accord mais il est surement plus pratique de désactiver les warnings quand on est en prod ! mais en dev (même si je ne devrais pas bosser sur le serveur) je suis bien obligé de laisser les messages d'erreur
Le error_reportig a false c'est le meilleur moyen de pas voir une faille sur ton serveur de prod. Il faut que ce soit pas visualisable pour l'utilisateur mais que ce le soit pour toi => regarde dans la doc php les error_handler et log_error (je suis plus sur du nom)

Citation :

visiblement toi tu brouiles toutes les pistes !!! Mais bon apres c à la limite de la parano je trouve !
Totalement d'accord, mais autant tu trouves parano que la banque qui gere ta carte de credit cryptes tes transmissions avec des clefs de 1024bit (je crois que c'est du 1024 bit ... je suis plus sur ...) ? P-e mais ca te fait quand meme plaisir qu'elle le fasse.. alors toi, fait de meme pour tes clients , c'est leurs tunnes et ils veulent probablement leur faire courrir le moins de risques possible .. En outre si un jour un des sites que j'ai developpé ce fera hacker et qu'on m'attaque en justice pour ça, le fait que je paraisse un total parano qui a tenté de securiser un maximum pourra me sauver les fesses

zzarbi974 a écrit :

Et pour ça esox_ch :

Citation :

Rediriger tout les messages d'erreur PHP vers un gestionnaire qui n'envoie au client qu'un message "neutre" ... Pour empecher qu'il recupere des infos au cas ou on aurait oublier une faille.

J'aimerais bien savoir comment le faire... :jap:

Citation :

Je met des noms de table/champ générés par un generateur de password. Ca empeche le fait que qqn qui arrive a passer une SQL injection puisse tomber trop facilement sur le nom d'une de mes tables.

ça c'est pas con...
L'idée m'est venue au cours d'une compétition de hacking ... On a forcé l'acces en faisant devinner a un bruteforce le nom de la table et en injectant une requete dessus ...
et ça aussi j'aimerais plus d'info :

Citation :

Je stoque le md5 du contenu de mes fichiers de session pour etre sur que personne ne les a modifié entre 2 appels.

Tu checksum ton fichier de session ,tu stoques le resultat quelque part ou il est pas trop visible par qqn qui explore tes rep (genre j'aime bien l'enregistrer dans un fichier genre "header.gif" ou qqch du style, et apres, quand tu es dans les endroits sensibles de ton site tu controles si le checksum est toujours le meme ... dans le cas contraire c'est que qqn est passé par la .. C'est particulierement utile si tu as un processus qui dure un certain temps ...

Message édité par esox_ch le 09-09-2005 à 14:08:47

---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait

freed102

Arayashiki

Citation :

Alors ne laisse pas le rep par defaut pour les sessions (/tmp en general) , met le dans ton repertoire parceque sinon depuis un autre site sur le meme hebergeur on peut te hacker

là je sais pas trop ou ça se met dans le serveur.. j'ai tenté d'ouvrir une session et je suis allé voir dans le dossier tmp ou temp sur la racine du site et j'ai rien vu

Citation :

ça c'est pas déja comme ça par defaut ?
Non, par defaut il cherche a envoyer par cookie et si ca passe pas il l'envoie par url

moi je le passe pas par l'url, j'ai même désactivé une option qui generait automatiquement un input type="hidden" dans la page contenant le numero de session (ça generait un code invalide XHTML) resultat il ne reste aucune trace de la session dans ma page (à priori!)

Citation :

Des que tu traites des données sensibles (je considere que mon num de telephone est une donnée sensible) tu passes par SSL

je vais me renseigner aupres de mon hebergeur pour savoir comment utiliser les services SSL

Citation :

Je veux dire que le mec qui c'est autentifié peut modifier les requetes HTTP qu'il envoie a ton serveur.. Par exemple admetons que tu as une select liste avec 10 options .. rien n'empeche l'utilisateur de créer une 11ème option sur une page hebergée chez lui et de te l'envoyer a ton formulaire... selon comment tu geres le tout et ce qu'il met dedans ca peut faire tres mal

dans cet exemple je m'arrange toujours pour tester mon champ avec un switch... avec evidement un valeur par defaut si aucune ne correspond aux parametres indiqués... je sais pas si c la bonne méthode mais ça me parait impossible à devier, pour les champs de saisie.. un addslashes ou un htmlentities me paraissent efficaces pour ne pas avoir de bidouilleurs qui voudraient mettre du code dans un champs pour detourner le site, sur mon site il faut que je mettes des tests sur les champs qui doivent porter que des valeurs numeriques car je suppose que ça fait planter mon script si tu respectes pas ça... mais ça c prevu dans l'optimisation du site (c vers la fin dans mon planning)

Citation :

Totalement d'accord, mais autant tu trouves parano que la banque qui gere ta carte de credit cryptes tes transmissions avec des clefs de 1024bit (je crois que c'est du 1024 bit ... je suis plus sur ...) ? P-e mais ca te fait quand meme plaisir qu'elle le fasse.. alors toi, fait de meme pour tes clients , c'est leurs tunnes et ils veulent probablement leur faire courrir le moins de risques possible .. En outre si un jour un des sites que j'ai developpé ce fera hacker et qu'on m'attaque en justice pour ça, le fait que je paraisse un total parano qui a tenté de securiser un maximum pourra me sauver les fesses

je suis d'accord avec toi.. mais c pareil ça doit etre des choses qui se font lors de l'optimisation du site... je sais pas comment vous montez vos sites mais moi je prefere commencer par faire un truc qui marche avant de faire la déco et la "canonisation"

---------------
Freed102

esox_ch

Justement, c'est pas une question d'optimisation , c'est une question de securité de base. Maintenant, tant que tu ne mets pas en prod ton site, tu peux faire ce que tu veux, mais des qu'il est en prod toutes les mesures de secu DOIVENT etre prises ... c'est pas un "oui mais p-e plus tard quand j'aurais le temps".

Pour le rep des session et le fait que oui ou non ca envoie le SID par url je te laisse lire la doc, c'est clairement expliqué

---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait

freed102

Arayashiki

bah mon sites n'est pas en prod (même si il a été visible de tous) et je prends note de tout ce que tu m'as dit... en fait je pensais sécuriser mon site un minimum... en cachant les sessions, en detournant les données dans les scripts etc etc c peut etre pas suffisant ! mais ça viendra !

---------------
Freed102

omega2

esox_ch a écrit :

L'idée m'est venue au cours d'une compétition de hacking ... On a forcé l'acces en faisant devinner a un bruteforce le nom de la table et en injectant une requete dessus ...

Chouet, mais si c'est grace à un bruteforce que le nom de la table avait été trouvé, alors même avec des noms bizaroide, le bruteforce finira par le retrouver. Ca prendra peut être plus de temps, mais c'est bien la force des bruteforce : ils ont tout leur temps.
Et franchement, s'ils sont capable d'exécuter une requette donnée sur le serveur, c'est qu'il y a un gros probléme de sécurité ailleur, soit au niveau de la base de donnée, soit dans un autre service réseau, soit au niveau du site web. En tout cas, si le bruteforce n'a pas accés à la base de donnée, même avec des noms de tables relativement standard, il ne poura jamais rien faire.

Du coup, je me demande si, avec ça, t'as vraiment relevé le niveau de sécurité au bon endroit.

Publicité

esox_ch

Disons que vu que le nom de la table etait user_info il a trouvé assez rapidement avec un dico linguistique ... Alors qu'une table dont le nom est un chaine de 12 caracteres aleatoires est beaucoup moins rapide a trouver.

Le but n'etait pas que ce soit la seule secu contre les SQL injections, mais que ce soit un plus ..

---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait

zzarbi974

Pour les bases de la sécurité j'avais trouvé ça :
http://www.phpteam.net/articles/ex [...] tions-web/
http://www.phpsecure.info/
Si sa peut aider quelqu'un @+

---------------
Chouette cette Inspiron 9300

Publicité

Page : 1 2 3

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

PHP

effacer des données bdd apres expiration d'une session

Sujets relatifs
recup données d'une colonne	[BESOIN D'AIDE] phpmyadmin, données et jeux de caractères...
Quel est la durée de vie d'une variable session	La page que vous tentez de voir contient des données POSTDATA ... ???
Suppression d'anciennes données	Demande d'aide VBA : tableau dynamique et importation de données
problème de session avec Easyphp [RESOLU]	Base de données et php
Interface avec frames à partir de données XML	[CODAGE] Extraire le message d'un bloc de données
Plus de sujets relatifs à : effacer des données bdd apres expiration d'une session

Page générée en 0.082 secondes