dcz a écrit:Le truc, c'est d'éviter que le contenu de config.php puisse être vu, comme il contient le code de la base de donnée en clair, c'est sensible.

De manière générale, c'est mieux de ne pas compter que sur une méthode de sécurisation de fichier, et même si cela semble redondant, ça fait toujours un rempart de plus. L'art du hacker étant de réussir à passer outre les barrières, plus il y en as, mieux c'est

++

Exactement ! Autant Embêter un maximum ceux qui voudraient hacker le site.

Pour config.php, j'ai trouvé quelqu'un qui suggère de le coder. Il coller le contenu du fichier, sans les balises <?php et?> dans le formulaire à l'adresse suivante :

http://www.btt-scripts.com/demo/encrypt/

puis récupérer le texte codé et le replacer dans son config.php comme ceci :

Code: Tout sélectionner

<?php
eval(gzuncompress(gzinflate(base64_decode('AXEAjv942tPX19JS8K0MDvRRKE4tKcnMSy9W0NLS1+flUklJii9OLSpLLVJQULBVUMqtLC7MMdU1VLKGyOUl5qYqKEDk8vJzkxKLU4EKYLKlQK1gFUDZnPz0zDwkuYLE4uLy/KIUsKn5JSmpIIFUkCwAmYgq2g=='))));
?>


Ca sert juste à embêter un peu le méchant...
Bientôt, je vais creer un post sécurité dans lequel je présenterai mes méthodes pour embêter un peu ceux qui se touvent à un endroit de mon site où ils n'ont rien à faire.

Dans le principe, c'est un rempart de plus de crypter, même si ça doit être déjouable, mais il faut pas que le site qui propose le service triche, parce que lui, il récolte tout en clair

@++

Oui, effectivement. L'auteur pourrait se placer un rootkit dans le code, ou se créer une base de données d'identifiants/mot de passe.

Pour le rootkit, j'ai testé, c'est bon.

Avant Encodage :

Code: Tout sélectionner

// phpBB 3.0.x auto-generated configuration file
// Do not change anything in this file!
$dbms = 'mysql';
$dbhost = 'LeServeur';
$dbport = '';
$dbname = 'MonNomDeBase';
$dbuser = 'MonNomUser';
$dbpasswd = 'MonMdpSecret';

$table_prefix = 'MonPrefixe';
$acm_type = 'LeAcmType';
$load_extensions = 'LeLoadExt';

@define('PHPBB_INSTALLED', true);
// @define('DEBUG', true);
// @define('DEBUG_EXTRA', true);


Forme encodée :

Code: Tout sélectionner

gzuncompress(gzinflate(base64_decode('AQgB9/542n2QTUvEMBRF9wPzH54gVEGngstBsKVFhc5QbAfclUzz+gHtS01Sbf+9aRrHnbucey6X8HwfhmYIQ3jcPewmYKMW9zUSSqaRQymoauvRQCsIqrbD7cb3IRJAQkPZMKoRGM26aamGlsA8lO1dbTfX/NwreAKvn9Vn5+1t0gillyzBDOUXjtLlg5A2d0isxwUPgo6ijzBkCp0aFco/dTL0O8GU+uZOHfiQYSlRL9Jozc4dFoPEqp1cJbWwzrKyL/Q84Pq1oOxzA9Z0gvECJ42kzA3UWkhMGE9u+5mbHcIbL31Nw7B4O2Z5kCRx5N2BliPe7u3NLq0oDk8v/7ki/sjfg0vjB0iNf+g=')));

Décodé par mes soins :

Code: Tout sélectionner

// phpBB 3.0.x auto-generated configuration file // Do not change anything in this file!
$dbms = 'mysql';
$dbhost = 'LeServeur';
$dbport = '';
$dbname = 'MonNomDeBase';
$dbuser = 'MonNomUser';
$dbpasswd = 'MonMdpSecret';
$table_prefix = 'MonPrefixe';
$acm_type = 'LeAcmType';
$load_extensions = 'LeLoadExt';
@define('PHPBB_INSTALLED', true);
// @define('DEBUG', true);
// @define('DEBUG_EXTRA', true);


Ça me parait plus saint en effet

Ce serait vraiment bête de se faire phisher en cryptant sa config

++

dcz a écrit:Le truc, c'est d'éviter que le contenu de config.php puisse être vu, comme il contient le code de la base de donnée en clair, c'est sensible.

De manière générale, c'est mieux de ne pas compter que sur une méthode de sécurisation de fichier, et même si cela semble redondant, ça fait toujours un rempart de plus. L'art du hacker étant de réussir à passer outre les barrières, plus il y en as, mieux c'est

++

merci dcz!
en gros c'est comme si je rajouteais une sérure sur ma porte d'entrée chez moi, si je comprend bien..

par contre si on peut m'expliquer comment utiliser un fichier php distant sans qu'il soit interpreter je suis preunneur. car j'aimerais bien faire de l'intersite..

Ça dépends plus du système d'apache et de php que du script, mais c'est bien ça de hacker un serveur, voir le contenu des fichiers.
C'est rarement un truc qui se fait pour un seul fichier à la fois.

Qu'entends tu par "intersite" ?

Tu as pas forcément besoin de voir la source des codes php entre des serveurs pour ça il me semble, file_get_contents(), c'est pratique.

il me semble que les variable ne passe pas de serveur en serveur.
c'est meme pas il me semble, mais c'est sur. (bon je referrais des tests avec file_get_contents() )
mais vu ce que j'ai lu, c'est aussi sur que le javascript ne peut pas accèder au disque dur du client.

les hackers se servent le plus souvent d'une faille php pour uploader un fichier sur le serveur victime. a partir de la ils récuperent ce qu'ils les interresse.
donc vu que ça se passe sur le serveur, le fichier htacces ne sert plus a grand chose pour proteger le config.php, vu que celui-ci a été inclu dans un autre fichier.

Quand je parle d'inter-site, c'est des sites qui ne sont pas sur le meme serveur ni meme sur le meme hébergeur.
leur seul moyen de comuniquer et le ftp et le html.
Pour faire passer des variable j'utilise a fonction de lecture de fichier txt.
je séparre le résultat par des ";". a la fin je fait un explode pour séparer et trier mes variable lol

Enfin, pour dire tout simplement que si je fait ça c'est bien parceque les variable ne passe pas d'un serveur à l'autre (heureusement).

C'est pour ça j'ai un doute sur cette protection via htacces..
a la limite on devrais interdire l'access distant de tous les fichiers, sauf ceux qui sont indispensable...
comme ça les fichier uploader par des hacker sur le site seront inutilisable (enfin.. en téhorie)

C'est juste que j'aimerais comprendre...

GostSn a écrit:il me semble que les variable ne passe pas de serveur en serveur.

Oui, mais là, on parles des cas ou l'impossible arrive, et donc ou une protection supplémentaire peut être utile. Genre, le hacker parviens à ouvrir des droit en écriture sur config.php, mais il ne peut rien faire grâce au deny du .htaccess, pas de PUT, pas de DELETE.

Mais je t'accorde que :

SeO a écrit:c'est bien ça de hacker un serveur, voir le contenu des fichiers.
C'est rarement un truc qui se fait pour un seul fichier à la fois.

Si non, pour "l'intersite", serialize() c'est bien aussi, les flux xml aussi.

++

bon si l'impossible peut arriver lol c'est une protection suplémentaire genre je ferme ma porte a double tours...

enfin bon, je le laisse.. si l'équipe seo l'as mis... et que l'équipe phpbb l'as mis aussi.. doit bien avoir une raison..
je croi que je suis pas asser caller en haking pour comprendre^^

C'est aussi une question de principe, pourquoi se priver d'une couche de protection supplémentaire n'utilisant pas php et ne nécessitant que trois lignes de code ?