Discussion :

[steph68b]

Salut!

Une fois de plus je viens chercher des réponses, car je sèche, et le support d'OVH n'est compétent que pour les réponses types qu'ils copient/collent une fois par semaine!! L'incompétence et le j'menfoutisme à l'état pur!!

Bref, mais comme c'est assez compliqué à expliquer et que j'ai déjà mis en place bon nombre de protections (htaccess, anti-injection sql pour les INPUT, htmlentities() pour ce qui arrive en $_GET, etc.....), je vais déjà tenter une question simple... qui me parait débile, c'est vrai... MAIS...
-> est-il possible d'accéder à une page d'admin du site (page accessible uniquement par login+pwd!!), sans pour autant se loger????
-> et pire, peut-on injecter une clé PHPSESSID dans $_POST???

Je suis la cible d'attaque d'un petit con de St Petersburg qui remplace les data de ma page d'accueil par des pub de sites porno!
J'ai fait plein de recherches sur des forums spé, j'ai patché plein de choses..... et pourtant il passe toujours!

Bref, toute aide sera bonne à prendre!
Et s'il le faut, je ferai l'explication complète, avec code source...........

Merci.

[rawsrc]

Salut,

as-tu changé tes mots de passe de connexion : compte OVH et FTP ?, Si non, fais le.
Le site est-il bâti sur un CMS ? Si oui, le CMS a-t-il été mis à jour ?

Tu semble utiliser des formulaires, comment protèges-tu ces entrées.

[sabotage]

Tout est possible en fonction des trous de sécurité qui pourraient exister sur ton site
Pour POST et GET, l'utilisateur peut envoyer n'importe quelles données vers le serveur : c'est pour cela qu'il faut valider systématiquement leur validité.
Pour les sessions, de la même façon, c'est le client qui fourni l'id ; si on connait l'id de session en train d'être utilisé par un administrateur, on peut usurper sa session. On peut empecher cela en effectuant des contrôles supplémentaires.

[steph68b]

alors, réponse groupée:
1.) les pwd: changés 3 fois oui
2.) CMS perso
3.) formulaire: les INPUT sont testés avec ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
function anti_injection($var, $flag)
{
	//bannir les instructions sql s'il y en a!
	$banlist = array (
        "exec", "master_xp", "--", "//", "shutdown", "/*", "*/", "PHPSESSID", "insert", "select", "update", "delete", "distinct", "having", "truncate", "replace",
        "handler", "like", "procedure", "limit", "order by", "group by");
 
 
	foreach($banlist as $item)
	{
		if( stripos ($var, $item) !== false)	{ $var = trim ( str_ireplace ( $banlist, '', $var) ); }
        }
 
 
	//suppr des car indésirables
 
	//autorisés: caractères alphanum + accents
	if( strcmp($flag, GLOBAL_AI_ALPHANUM) == 0 )		{ $var = preg_replace("/[^a-zA-Z0-9À-ÿ]/",'', $var); }		
 
	//autorisés: caractères alphanum + accents + _-&@()=€/ + ponctuation (.,;!?) + <space>
	elseif( strcmp($flag, GLOBAL_AI_TEXT) == 0 )		{ $var = preg_replace("/[^_a-zA-Z0-9À-ÿ-'\"\.,;!?&():\@=€\/  ]/",' ', $var); }
 
	//autorisés: caractères numeric
	elseif( strcmp($flag, GLOBAL_AI_NUMERIC) == 0 )		{ $var = preg_replace("/[^0-9]/",'', $var); }					
 
	//autorisés: car alphanum et les signes _ - . & = @ $
	elseif( strcmp($flag, GLOBAL_AI_PASSWORD) == 0 )	{ $var = preg_replace("/[^_A-Za-z0-9-\.&=\@$]/i",'', $var); }	
 
	//PAS DE TEST particulier
	elseif( strcmp($flag, GLOBAL_AI_NOPREG) == 0 )		{ }	
 
	else												{ echo "ERREUR DEVELOPPEMENT variable ($var) & flag ($flag) <br/>"; return NULL;}
 
	return $var;
}

4.) session: développe un peu là STP..........
-> quels ctrls supplémentaires?
-> comment modifier l'ID de session alors?

[rawsrc]

comment tu échappes les données avant persistance ?

Montre un traitement sql stp.

[steph68b]

heeeeeeeeeeu, je pensais que ça, ça suffisait(??)..........

cela dit, de vos 2 pistes, je pencherai plus pour celle de l'usurpation de la session admin puisqu'il n'y a pas de login (je log la page php de connexion et elle n'est pas appelée!!) pour modifier les data... et que la page ne peut être affichée sans authentification.

MAIS, s'il y a encore des filtres à passer sur les data des INPUT (avant de la sauvegarde en base) en plus de ma fonction, je t'écoute.
Quels autres caractères/expressions faut-il encore filtrer?

[rawsrc]

Ben, ce que tu fais n'est pas du tout suffisant en matière de sécurité pour des données destinées à être sauvegardées en base.

Les bases de données ont chacune leurs propres mécanismes d'échappement pour sécuriser le contenu des variables de manière à les rendre inoffensives.

Pour les fonctions mysql_ c'est mysql_real_escape() (obsolète), pour mysqli_ c'est mysqli_real_escape(), pour PDO, c'est le mécanisme de préparation, rattachement et exécution...

Et si tu fais juste ceci pour tes valeurs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"UPDATE ... SET ta_colonne = '".$valeur."'"

c'est ouvert aux quatre vents...