Sécuriser page de connexion des requête SQL

Bonjour a tous,

Je viens chercher de l’aide auprès de vous pour sécuriser mes pages de connexions contre les requête SQL car récemment un pirate m’a fait pars de cette recommandation après avoir pu mettre à mal ma bdd en découvrant mon mot de passe simplement.

J’avoue avoir lus plusieurs chose depuis hier et ne pas trop bien comprendre… Il ne m’a pas tout dit non plus, il m’a simplement indiquer pouvoir ajouter la fonction : mysql_real_escape_string() *… bon ça je comprends mais je ne veux pas l’entrée manuellement devant chaque variable de votre wordpress

Donc j’ai trouver cela

function sanitize_string($str) {
if (get_magic_quotes_gpc()) {
$sanitize = mysqli_real_escape_string(stripslashes($str));
} else {
$sanitize = mysqli_real_escape_string($str);
}
return $sanitize;
}

function que je pensais ajouter a mon fichier function.php de mon thème personnalisé.

J’ai essayer THE MOLE pour contrôler cela… je pense avoir a peu prêt compris avec une commande du genre

url https://mon_site_web/login.php?id=1

needle mon_identifiant

schemas

et j’obtient : Could not detect SQL Injection:needle not found (needle not in page)

Je ne suis pas du tout sur de bien faire, ni même d’avoir bien tester avec THE MOLE que je connais depuis ce matin seulement…

Par ailleurs j’ai installer Woocommerce sur mon wordpress et en conséquent si je comprends bien c’est la boutique qui fournit une page d’inscription et qui est donc la première a devoir être sécurisée…

Voici l’adresse si vous souhaitez regarder.

https://logic-68consolessystem.fr/inscription/

Donc es-ce que je comprends bien?

la page a sécurisée avant tout des failles SQL est bien celle-ci?
La page Login.php qui me permet d’entré dans mon interface administration est aussi vulnérable?
Passer par cette function comme décrite plus haut en exemple, est-elle suffisante pour sécuriser au plus simple toutes mes entrées SQL dans ma base?
La function tel quel, est-elle encore d’actualité?
Merci pour votre aide… j’ai du mal a suivre

La 1re chose a vérifier sont les mises à jour de Wordpress et Woocommerce.
Si ce sont les dernières versions, alors, il y a peu de chance d'avoir une faille par injection SQL de ce côté.

Regardez ensuite les autres extensions que vous avez utilisées. Si elles ne sont pas très connues, c'est possible que certains pirates ont trouvé des failles et que les développeurs des extensions n'ont pas été prévenus.

Bonjour Mathieu,merci d'être passer par là..

Pour être honnête avec vous ce sont les règles de base que j'applique bien évidemment...
Lors de cet intrusion, j'ai également subit une attaque ddos ce qui m'a donner du travail et beaucoup de recherche.

J'ai donc effectuer des test, mon Wordpress était bien sur la dernière révision 4.8.1 et mon Woocommerce aussi 3.1.1. J'ai retirer absolument tous les plugins et repris certain compatible 4.8.1 et fraîchement mis à jour, mais cela ne servait a rien, il me prouvait en live qu'ils infiltraient ma Bdd.

A la longue décourager, j'ai retirer mon site car mon hébergeur m'isolait et me demandait de faire le nécessaire. Puis les pirates son venu s'excuser pour le ddos car il se trompait de cible. Une erreur selon eux.
Mais l'un d'eux ma alors indiquer et conseiller de sécuriser mes pages de connexions, car c'est par là qu'il exploitait une faille SQL toute simple pour entrer dans bdd.

' UNION SELECT password FROM membres WHERE id=1

Avec cette requête connu, et m'indiqua devoir rajouter au minima cette function mysql_real_escape_string();*
Mais comme je suis pas DEV et que je ne voulait me taper la recherche de chaque formulaire, qui serait forcementécraser lors d'une mise a jour je voulais trouver une function global pour l'insérer dans mon fichier function.php de mon thème légèrement personnaliser.

j'ai donc trouver celle-ci en ayant conscience qu'une faille est été découverte sur stripslashes depuis quelques temps, c'est pour ça que je m'interroge encore sur cette function.

function sanitize_string($str) {
if (get_magic_quotes_gpc()) {
$sanitize = mysqli_real_escape_string(stripslashes($str));
} else {
$sanitize = mysqli_real_escape_string($str);
}
return $sanitize;
}

J'ai également ce filtre dans mon fichier .htaccess

RewriteEngine On
RewriteCond %{REQUEST_METHOD} (GET|POST) [NC]
RewriteCond %{QUERY_STRING} ^(.*)(%3C|<)/?script(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=)?javascript(%3A|:)(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)document\.location\.href(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%3D|=)(https?|ftp|mosConfig)(%3A|:)//(.*)$ [NC,OR] ## ATTENTION A CETTE REGLE. ELLE PEUT CASSER CERTAINES REDIRECTIONS RESSEMBLANT A: http://www.truc.fr/index.php?r=http://www.google.fr ##
RewriteCond %{QUERY_STRING} ^.*(_encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)GLOBALS(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)_REQUEST(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(SELECT(%20|\+)|UNION(%20|\+)ALL|INSERT(%20|\+)|DELETE(%20|\+)|CHAR\(|UPDATE(%20|\+)|REPLACE(%20|\+)|LIMIT(%20|\+)|CONCAT(%20|\+)|DECLARE(%20|\+))(.*)$ [NC]
RewriteRule (.*) - [F]

RewriteEngine On
RewriteCond %{REQUEST_URI} .*((php|my)?shell|remview.*|phpremoteview.*|sshphp.*|pcom|nstview.*|c99|r57|webadmin.*|phpget.*|phpwriter.*|fileditor.*|locus7.*|storm7.*)\.(p?s?x?htm?l?|txt|aspx?|cfml?|cgi|pl|php[3-9]{0,1}|jsp?|sql|xml) [NC,OR]
RewriteCond %{REQUEST_METHOD} (GET|POST) [NC]
RewriteCond %{QUERY_STRING} ^(.*)=/www/(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^work_dir=.*$ [OR]
RewriteCond %{QUERY_STRING} ^command=.*&output.*$ [OR]
RewriteCond %{QUERY_STRING} ^nts_[a-z0-9_]{0,10}=.*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)cmd=.*$ [OR]
RewriteCond %{QUERY_STRING} ^c=(t|setup|codes)$ [OR]
RewriteCond %{QUERY_STRING} ^act=((about|cmd|selfremove|chbd|trojan|backc|massbrowsersploit|exploits|grablogins|upload.*)|((chmod|f)&f=.*))$ [OR]
RewriteCond %{QUERY_STRING} ^act=(ls|search|fsbuff|encoder|tools|processes|ftpquickbrute|security|sql|eval|update|feedback|cmd|gofile|mkfile)&d=.*$ [OR]
RewriteCond %{QUERY_STRING} ^&?c=(l?v?i?&d=|v&fnot=|setup&ref=|l&r=|d&d=|tree&d|t&d=|e&d=|i&d=|codes|md5crack).*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)([-_a-z]{1,15})=(ls|cd|cat|rm|mv|vim|chmod|chdir|concat|mkdir|rmdir|pwd|clear|whoami|uname|tar|zip|unzip|gzip|gunzip|grep|more|ln|umask|telnet|ssh|ftp|head|tail|which|mkmode|touch|logname|edit_file|search_text|find_text|php_eval|download_file|ftp_file_down|ftp_file_up|ftp_brute|mail_file|mysql|mysql_dump|db_query)([^a-zA-Z0-9].+)*$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(wget|shell_exec|passthru|system|exec|popen|proc_open)(.*)$
RewriteRule (.*) - [F]


Mais pour ce fichier .htaccess il étant déjà en place au moment de l'attaque, donc je me pose des question sur son efficacité! il aurait du empêcher l'intrusion et visiblement cela n'a pas été le cas.

Pour finir j'ai tester moi même (mais sans connaissance particulière) sqlmap sur mon propre site
j'ai obtenu ceci

[20:50:57] [WARNING] the web server responded with an HTTP error code (403) which could interfere with the results of the tests

[20:50:58] [WARNING] target URL is not stable. sqlmap will base the page comparison on a sequence matcher. If no dynamic nor injectable parameters are detected, or in case of junk results, refer to user's manual paragraph 'Page comparison' and provide a string or regular expression to match on



Enfin pensez-vous que le nécessaire est été fait pour corriger les failles XSS efficacement?
Merci pour votre attention et votre lecture

Bien a vous