Ceux qui ont étudié plus ou moins sérieusement PHP sachez qu'il existe un tableau global très utile dans PHP qui est appelée $_SERVEUR. Et dans cet article, je voudrais analyser les clés les plus populaires et leurs valeurs dans ce tableau, car leur connaissance est tout simplement obligatoire même pour un débutant Programmeur PHP.

Avant de commencer tableau global $_SERVER en PHP, je vais vous donner un petit indice tout de suite. Il y a une fonctionnalité intéressante intégrée PHP, qui est appelée phpinfo(). Donnons immédiatement un exemple de son utilisation :

phpinfo();
?>

À la suite de l'exécution de ce script simple, vous verrez un immense tableau avec divers Paramètres de l'interpréteur PHP, y compris, vers la fin, il y aura un tableau de valeurs tableau global $_SERVER. Il listera toutes les clés et toutes leurs valeurs correspondantes. Comment cela peut-il vous aider ? Et le fait est que si vous avez besoin de telle ou telle valeur et que vous oubliez comment s'appelle la clé, alors en utilisant la fonction phpinfo() Vous vous souviendrez toujours de son nom. En général, vous exécuterez ce script et vous me comprendrez immédiatement.

Passons maintenant aux plus populaires aux clés du tableau $_SERVER:

• HTTP_USER_AGENT- cette clé permet de connaître les caractéristiques du client. Dans la plupart des cas, il s'agit certainement du navigateur, mais pas toujours. Et encore une fois, s'il s'agit d'un navigateur, alors lequel, vous pouvez le découvrir dans cette variable.
• HTTP_REFERER- contient le chemin absolu de ce fichier ( Script PHP, Page HTML), à partir duquel nous sommes passés à ce script. En gros, d'où vient le client.
• SERVER_ADDR - adresse IP serveur.
• REMOTE_ADDR - adresse IP client.
• DOCUMENT_ROOT- chemin physique vers le répertoire racine du site. Cette option est définie via Fichier de configuration du serveur Apache.
• SCRIPT_FILENAME- chemin physique vers le script appelé.
• CHAÎNE DE REQUÊTE- une valeur très utile qui vous permet d'obtenir une chaîne avec une requête, puis d'analyser cette chaîne.
• REQUEST_URI- une valeur encore plus utile qui contient non seulement la requête elle-même, mais également le chemin relatif vers le script appelé depuis la racine. Ceci est très souvent utilisé pour supprimer la duplication de index.php, c'est-à-dire quand nous avons un tel URL: "http://mysite.ru/index.php" Et " http://monsite.ru/" mène à une page, et URL différent, donc duplication, ce qui aura un effet néfaste sur l'optimisation des moteurs de recherche. Et avec l'aide REQUEST_URI on peut déterminer : avec index.php ou non, le script a été appelé. Et on peut faire une redirection avec index.php(s'il était présent dans REQUEST_URI) allumé sans index.php. En conséquence, lors de l'envoi d'une telle demande : " http://mysite.ru/index.php?id=5", nous aurons une redirection vers URL: "http://monsite.ru/?id=5". Autrement dit, nous nous sommes débarrassés de la duplication en supprimant de URL ce index.php.
• SCRIPT_NAME- chemin relatif vers le script appelé.

Ce sont peut-être tous les éléments tableau global $_SERVER en PHP qui sont utilisés régulièrement. Vous devez les connaître et pouvoir les utiliser lorsque cela est nécessaire.

Langage de script sur serveur Apache.

index.php- le fichier de démarrage le plus courant pour démarrer le langage de programmation de script PHP sur un serveur WEB, principalement Apache.

Pour un débutant, il faut juste savoir que la plupart des sites commencent leur travail avec ce fichier. Le fichier est placé à la racine du stockage de fichiers principal du site. Peut également être situé dans des répertoires ( annuaire). Ensuite, le serveur Apache recherchera et chargera d'abord index.php dans le répertoire demandé, à moins que quelque chose d'autre ne soit spécifié dans le fichier de paramètres du serveur. htaccess

Comment forcer Apache à charger d'abord index.php (options)

Comment le faire correctement :

# pour que le travail commence uniquement avec index.php DirectoryIndex index.php

Beaucoup de gens font aussi ça :

# commencez à exécuter des scripts en vérifiant la séquence spécifiée DirectoryIndex index.php index.html index.shtml

Ici, cela vaut la peine d'expliquer un peu l'algorithme des actions :

1. Essayer de charger index.php.
2. Si index.php annuaire), puis on essaie de charger index.html.
3. Si index.html introuvable dans le répertoire racine ( annuaire), puis on essaie de charger index.shtml

Il existe de nombreuses autres options pour gérer les téléchargements, mais vous devez lire les spécifications plus avancées. htaccess.

Cette méthode est utilisée généralement, au cas où ils souhaiteraient protéger index.php contre l'analyse de diverses vulnérabilités, par exemple :

Index.php?mode=page&url="%20AND1="1

Si index.php est différent, alors tout ce qui vient après index.php n'a aucune signification. Mais il existe d'autres moyens de déterminer quel fichier est le fichier de démarrage principal sur le serveur WEB. Il n’y a donc aucune sécurité particulière de cette méthode. Mais les inconvénients d'utilisation augmentent. Par conséquent, cette méthode doit être traitée avec une extrême prudence et réflexion.

Comment masquer index.php via htaccess

Le serveur WEB Apache doit avoir inclus module mod_rewrite. Aujourd'hui, presque tout le monde a ce module activé, mais dans tous les cas, il faut s'en assurer, sinon cela ne fonctionnera pas. Cette méthode est principalement utilisée par les optimiseurs SEO.

Code pour masquer index.php

# activez le module mod_rewrite RewriteEngine sur # tout après que index.php soit envoyé à la ligne de commande principale RewriteCond %(THE_REQUEST) ^(3,9)\ /index\.php\ HTTP/ # supprimez index.php de la ligne de commande afin que seules des informations utiles RewriteRule ^index\.php$ http://site/

Comment envoyer toutes les requêtes via index.php (redirection)

En général, il n'y a rien de compliqué ici non plus.

# Activez mod_rewrite RewriteEngine sur # si la requête n'est pas un fichier, alors elle sera envoyée à index.php # cela est fait si votre fichier index.php ne gère pas tout # ce qui est requis, car il est souvent nécessaire de diviser le projet en modules plus petits RewriteCond %(REQUEST_FILENAME) !-f # si la requête n'est pas un répertoire, elle sera envoyée à index.php # ceci est fait pour que les répertoires comme /images/ ne soient pas redirigés vers index.php RewriteCond % (REQUEST_FILENAME) !-d # envoyer tout le reste à index.php et y travailler RewriteRule (.*) index.php [L]

Comment télécharger index.php

Si le master WEB respecte les règles de sécurité télécharger index.php c'est interdit un-prieuré.

Vous pouvez télécharger index.php uniquement si :

• Paramètres incorrects dans (.htaccess). Seul le maître WEB lui-même est ici à blâmer.
• Il y a un accès au serveur via le protocole FTP. La manière la plus courante. La victime est attirée vers un site Internet préfabriqué au besoin sous divers prétextes (vous avez gagné un million, votre compte est bloqué sur les réseaux sociaux, etc.). Dès que vous accédez au site requis, les cookies de vous sont copiés. Après cela, ils essaient de les utiliser pour accéder à votre site. C'est facile d'éviter cela, n'utilisez simplement pas d'interfaces WEB pour gérer votre site Internet et n'installez pas sur votre ordinateur des programmes d'auteurs inconnus et de sources inconnues, par exemple : toutes sortes d'accélérateurs Internet ou de barres d'outils douteuses à l'efficacité douteuse. , mais très forte persistance pour l'installer.
• Un script supplémentaire est installé sur le serveur (porte arrière). Grâce à un tel script, vous pouvez récupérer n'importe quel fichier du serveur sans qu'il soit exécuté par le gestionnaire PHP. De tels fichiers peuvent être téléchargés sur le serveur via des vulnérabilités courantes et connues du système de gestion de contenu (CMS). Par exemple : WordPress, Joomla, DLE, Drupal, Codeigniter, etc. Ensuite, sous l'apparence d'un avatar, un message spécialement généré .gif un fichier qui pourra être appelé ultérieurement, connaissant son emplacement sur le serveur de la victime. Si le CMS ne traite pas correctement ces fichiers, l'accès nécessaire au site peut être obtenu via celui-ci. Ou bien un plugin largement annoncé est installé sur un CMS tel que WordPress, Joomla et autres (par exemple : index de recherche php), qui semble remplir sa fonction, mais divulgue en même temps des données sur le site à ses développeurs, leur permettant ainsi d'utiliser le site comme ils le souhaitent.

Quelque chose comme ca. Si vous avez des questions, posez-les dans les commentaires, et bientôt une réponse explicative apparaîtra dans cet article.

Dans la dernière leçon, nous avons déterminé de quels blocs sera composé le modèle de voyage afin que nous puissions nous mettre au travail. Tout d'abord, créons deux dossiers :

images - ce dossier contiendra tous les fichiers graphiques utilisés pour concevoir le modèle. Parce que Nous n'avons pas encore de développements de conception, alors déposez n'importe quel fichier graphique dans ce dossier, sinon Joomla n'installera pas le modèle et donnera une erreur si le dossier est vide.

ATTENTION : Le dossier des images modèles ne contient pas de graphiques de contenu !

css - ce dossier contiendra fichiers de feuilles de style en cascade. Tout d'abord, plaçons-y un fichier template.css vide, qui sera utilisé pour attribuer différents styles de conception aux éléments du site.

Ensuite, vous pouvez commencer à créer le fichier principal index.php, qui déterminera la disposition visuelle des éléments du site et indiquera au CMS Joomla dans quel bloc placer les différents composants et modules. Le fichier est une combinaison de PHP et HTML.

J'utilise toujours uniquement Macromedia Dreamweaver lors de l'écriture de code. Un excellent programme, je le recommande vivement aux débutants, car... Si vous avez commis une erreur en travaillant sur le code, le programme mettra certainement en évidence votre erreur.

Sur le site vous trouverez un tutoriel sur Macromedia Dreamweaver. Si vous envisagez de développer des sites Web, vous devez maîtriser ce programme, au moins au niveau initial, afin d'éditer les codes de modèles sans erreurs.

Le positionnement des éléments de la page (blocs) se fait à l'aide de code HTML ; nous utiliserons notamment des balises DIV. Mais la façon dont notre site fonctionnera sur le moteur Joomla, c'est-à-dire Ce sera dynamique, alors vous devrez également utiliser le langage PHP. Avec son aide, nous déterminerons dans quels blocs seront situées les positions des modules de sortie, et comment ces positions seront appelées, si les blocs seront réduits ou non. Nous connecterons les feuilles de style des fichiers externes, la langue du contenu, définirons la manière dont la taille du site changera, etc.

index.php

En-tête du fichier

L'en-tête du fichier se compose de plusieurs parties. La première partie du code d'en-tête PHP consiste à garantir que le fichier n'est pas accessible directement, pour des raisons de sécurité.

< ?php
défini ("_JEXEC" ) ou mourir ;
JHtml::_("behavior.framework" , true ) ;
$app = JFactory::getApplication() ;
?>
< ?php echo "< ?" ; ?> version xml="1.0" encodage=" < ?php echo $ce-> _charset ?> "?>

DOCTYPE est un paramètre très important sur la base duquel le navigateur décide comment afficher cette page et comment interpréter le CSS.

< ! DOCTYPE html PUBLIC "- / / W3C/ / DTD XHTML 1.0 Strict/ / FR"" http : // www.w3.org/ TR/ xhtml1/ DTD/ xhtml1- strict.dtd">

L'extrait suivant récupère la langue installée à partir de la configuration globale.

< html xmlns= "http:// www.w3.org/ 1999/ xhtml" xml:lang= " < ?php echo $ce-> langue ; ?> " lang= " < ?php echo $ce-> langue ; ?> " répertoire = " < ?php echo $ce-> orientation ; ?> " >

Vient ensuite un morceau de code qui inclut des informations d'en-tête supplémentaires définies dans la configuration globale. Vous pouvez voir ces informations en consultant le code source de n'importe quelle page Web. Il s’agit notamment de balises méta que vous connaissez déjà.

< head>
< jdoc:include type= "head" / >

Les lignes d'en-tête suivantes contiennent des liens vers les principaux styles CSS de Joomla.

< link rel= "stylesheet" href= "< ?php echo $ce-> baseurl ?> / templates/ system / css/ system .css" type="texte /css" / >
< link rel= "stylesheet" href= "< ?php echo $ce-> baseurl ?> / templates/ system / css/ general.css" type="texte /css" / >

Pour utiliser les styles de conception de modèles, nous établissons un lien vers un fichier contenant des feuilles de style en cascade template.css, qui se trouve dans le dossier CSS. Peu importe que ce fichier soit vide pour l'instant, l'essentiel est de le connecter, nous traiterons du design plus tard, lorsque nous installerons le modèle sur Joomla. Cela facilitera l’observation du résultat.

< link rel= "stylesheet" href= "< ?php echo $ce-> baseurl ?> /modèles/< ?php echo $ce-> modèle ?> /css/template.css" type="texte /css" / >

L'extrait de code suivant nous permet de réduire les colonnes de gauche ou de droite s'il n'y a aucun module situé aux positions gauche et droite. Si les deux colonnes sont réduites, le contenu occupe 100 % de la largeur de la page. Si une seule colonne est incluse, alors le contenu occupe 80 %. Avec deux colonnes activées, le contenu représente 60 % de la largeur de la page.

< ?php
si ($ ce-> countModules("gauche et droite" ) = = 0) $contentwidth = "100" ;
si ($ ce-> countModules("gauche ou droite" ) = = 1) $contentwidth = "80" ;
si ($ ce-> countModules("gauche et droite" ) = = 1) $contentwidth = "60" ;
?>

L'en-tête se ferme

< / head>

< body>

Le bloc « page » contient uniquement le design de la page du site, qui fera 950 px de large.

< div id= "page" >

Le bloc « top » est situé tout en haut de la page et contient deux blocs « logo » et « user1 ».

< div id= "top" >

Dans le bokeh « logo » nous placerons un fichier graphique du logo ; cela sera précisé dans les feuilles de style. Mais nous écrivons l'affichage automatique du nom du site dans le fichier index.php, et plaçons le nom dans la balise H1, ce qui est très important pour l'optimisation des moteurs de recherche.

< div id= "logo" >
< h1> < ?php echo $app - >getCfg("nom du site" ) ; ?>< / h1>
< / div>

Définissons la position « user1 » dans le bloc du même nom pour afficher le module de recherche du site.

< div id= "user1" >
< jdoc:include type= "modules" name= "user1" style= "xhtml" / >
< / div>
< / div> < ! - - конец блока top - - >

Sortie du module de menu horizontal dans le bloc « user2 » en position « user2 ». Le bloc s'effondrera s'il n'y a aucun module à cette position.

< ?php if ($ce-> countModules("user2" ) ) : ?>
< div id= "user2 " >
< jdoc:include type= "modules" name= "user2" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Vient ensuite le bloc d’en-tête du site. Nous y définirons la position « en-tête » pour l'affichage des modules. Le bloc s'effondrera s'il n'y a aucun module à cette position. J'ai intentionnellement étendu les capacités de ce bloc pour pouvoir y placer non seulement l'image d'en-tête, mais également des rotateurs d'image.

< ?php if ($ce-> nombre de modules(" entête") ) : ?>
< div id= "entête">
< jdoc:include type= "modules" name= "entête" style="xhtml" />
< / div>
< ?php endif ; ?>

Dans le bloc « user3 », nous définissons la position « user3 » pour les modules de sortie.

Le bloc s'effondrera s'il n'y a pas de sortie de module à cette position "user3".

< ?php if ($ce-> countModules("user3" ) ) : ?>
< div id= "user3" >
< jdoc:include type= "modules" name= "user3" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Un bloc de la colonne de gauche s'ouvre, qui s'effondrera s'il n'y a aucun module en position « gauche ».

< ?php if ($ce-> countModules("gauche" ) ) : ?>
< div id= "left" >
< jdoc:include type= "modules" name= "left" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Le bloc de contenu le plus important s'ouvre, qui peut occuper 100 % de la largeur de la page, 80 % et 60 %, selon le nombre de colonnes incluses.

< div id= "content< ?php echo $contentwidth ; ?> " >

Afficher les messages dans les composants

< jdoc:include type= "message" / >

Contenu de sortie du contenu.

< jdoc:include type= "component" style= "xhtml" / >
< / div> < ! - - конец блока контента- - >

Un bloc de la colonne de droite s'ouvre, qui s'effondrera s'il n'y a aucun module dans la position « droite ».

< ?php if ($ce-> countModules("right" ) ) : ?>
< div id= "rigth" >
< jdoc:include type= "modules" name= "right" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Sortie du bloc « pied de page », conçu pour afficher le module « Code HTML » avec les informations de copyright. Vous pouvez également placer ici un menu horizontal inférieur ou un module de présentation de contenu. Le bloc sera réduit si plus d’un module est affiché dans cette position « pied de page »

< ?php if ($ce-> countModules("footer") ) : ?>
< div id= "footer" >
< jdoc:include type= "modules" name= "footer" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Le bloc de page du site « page », le corps et tout le code sont fermés.

< / div> < ! - - конец блока page- - >
< / body> < ! - - конец блока body - - >
< / html> < ! - - конец кода- - >

Nous avons créé un fichier index.php complet. Vous savez maintenant quelles commandes sont utilisées et dans quel ordre les blocs de modèle sont affichés.

ATTENTION : Pour que le code du modèle soit lu depuis le panneau d'administration de Joomla, le fichier index.php doit être ouvert dans l'éditeur AkelPad et enregistré en encodage UTF-8, tout en décochant la case BOM. Si vous avez utilisé le programme Macromedia Dreamweaver pour travailler avec le fichier, vous devez alors sélectionner « Modifier » > « Propriétés de la page » dans le menu supérieur et sélectionner le codage du document Unicode (utf-8), puis décocher « activer les signatures Unicode (BOM). ) ». Cependant, je vous conseille fortement de ne pas modifier le code depuis le panneau d'administration de Joomla, si vous faites une erreur - il n'y a pas de retour en arrière, contrairement au programme Macromedia Dreamweaver, où vous pouvez toujours annuler les modifications apportées.

La conception des blocs elle-même sera décrite dans template.css. Mais nous configurerons les feuilles de style après avoir installé le modèle sur Joomla 3 (joomla 2.5), et pour cela nous devons créer

Dès le début, tout le monde a accepté PHP avec brio, mais dès que des projets assez importants ont commencé à être créés dans ce langage, les développeurs ont été confrontés à un nouveau problème : PHP manquait du concept de variables globales ! Autrement dit, un certain script a été exécuté, a envoyé la page générée au client et toutes les ressources utilisées par ce script ont été détruites. Je vais essayer d'illustrer : supposons qu'il y ait deux pages d'un même site, index.php et dothings.php. Les sources de ces pages ressemblent à ceci :

index.php choses.php

Si nous exécutons ces deux scripts, alors sur la première page, nous verrons l'inscription « J'ai été affecté à index.php », et la deuxième page sera vide.

Les développeurs de sites Web, sans y réfléchir à deux fois, ont commencé à utiliser des cookies pour stocker des variables globales côté client. Le processus ressemblait à ceci : l'utilisateur accède à la page principale du site, effectue certaines actions, et toutes les informations associées à cet utilisateur, qui peuvent être nécessaires sur d'autres pages du site, seront stockées dans son navigateur sous la forme de cookies. Cette méthode présente des inconvénients assez sérieux, à cause desquels de nombreux développeurs se sont détournés de PHP à un moment donné. Par exemple, nous devons autoriser un utilisateur à lui permettre d'accéder aux sections privées (ou privées) du site. Vous devrez envoyer à l'utilisateur un cookie, qui lui servira ultérieurement d'identifiant sur le site. Cette approche devient très lourde et peu pratique dès que le site commence à collecter de plus en plus d’informations sur le comportement de l’utilisateur, car il est conseillé de coder toutes les informations envoyées à l’utilisateur afin qu’elles ne puissent pas être falsifiées. Tout récemment, en créant des cookies, il était possible de « pirater » plusieurs discussions, et parfois même de se faufiler dans le courrier de quelqu'un d'autre. De plus, il existe encore des personnes étranges dans le monde dont le navigateur ne prend pas en charge les cookies.

Je n'entrerai pas dans les enjeux technologiques du mécanisme de session, mais décrirai seulement comment travailler correctement avec les sessions en PHP.

Comment travailler avec des sessions ?

Si vous testez les exemples de l'article (ou vos scripts) sur n'importe quel hébergement commercial, vous ne devriez rencontrer aucun problème pour travailler avec les sessions. Si vous configurez votre serveur vous-même (qu'il s'agisse d'un vrai serveur ou d'un émulateur), des erreurs ressemblant à ceci peuvent apparaître :

"Avertissement : échec de l'ouverture (/var/state/php/sess_6f71d1dbb52fa88481e752af7f384db0, O_RDWR) : aucun fichier ou répertoire de ce type (2)."

Cela signifie simplement que votre PHP n'est pas configuré correctement. Vous pouvez résoudre ce problème en spécifiant le chemin correct (vers un répertoire existant) pour enregistrer les sessions dans le fichier php.ini et en redémarrant le serveur.

Tout script qui utilisera des variables (données) des sessions doit contenir la ligne suivante :

Session_start();

Cette commande indique au serveur qu'une page donnée a besoin de toutes les variables associées à un utilisateur (navigateur) donné. Le serveur extrait ces variables du fichier et les met à disposition. Il est très important d'ouvrir une session avant que des données ne soient envoyées à l'utilisateur ; en pratique, cela signifie qu'il convient d'appeler la fonction session_start() en tout début de page, par exemple comme ceci :

Session_start(); ?> ... Pour définir le répertoire dans lequel les fichiers de session seront enregistrés, utilisez la fonction session_save_path() : session_save_path($_SERVER["DOCUMENT_ROOT"]."/session"); session_start();

Une fois la session démarrée, vous pouvez définir des variables globales. Lors de l'attribution d'une valeur à n'importe quel champ du tableau $_SESSION, une variable portant le même nom est automatiquement enregistrée en tant que variable de session. Ce tableau est disponible sur toutes les pages utilisant la session. Par exemple, regardons le programme :

index.php Tout va bien. La session a été chargée ! Passons en revue et voyons ce qu'il y a : choses.php

Lors de l'exécution séquentielle de ces fichiers, le premier script "index.php" produira le résultat suivant :

Tout va bien. La session a été chargée ! Passons en revue et voyons ce qu'il y a :

Et le deuxième « dothings.php » est le suivant :

On m'a demandé d'index.php

La variable $a est désormais disponible sur toutes les pages d'un site donné ayant lancé des sessions.

Autres fonctionnalités et techniques utiles pour travailler avec des sessions :

• non défini($_SESSION["a"])- la session « oublie » la valeur de la variable de session spécifiée ;
• session_destroy()- la session est détruite (par exemple, si l'utilisateur a quitté le système en cliquant sur le bouton « se déconnecter ») ;
• session_set_cookie_params (int durée de vie [, chemin de chaîne [, domaine de chaîne]])- en utilisant cette fonction, vous pouvez définir la durée de « durée de vie » de la session en définissant unix_timestamp, qui détermine l'heure de « mort » de la session. Par défaut, la session "en direct" jusqu'à ce que le client ferme la fenêtre du navigateur.
• session_write_close()- enregistrer les variables de la session et la fermer. Ceci est nécessaire pour ouvrir le site dans une nouvelle fenêtre si le traitement de la page est long et a bloqué le fichier de sessions de votre navigateur.

Exemples

Passons maintenant à l'application pratique du mécanisme de session. Ici, nous examinerons quelques exemples assez simples et en même temps utiles.

Autorisation de l'utilisateur

Des questions sur l'autorisation des utilisateurs à l'aide de sessions PHP sont constamment posées lors des conférences de programmation Web. Le mécanisme d'autorisation des utilisateurs du système à l'aide de sessions est assez bon du point de vue de la sécurité (voir section).

Notre exemple sera composé de trois fichiers : index.php, authorize.php et secretplace.php. Le fichier index.php contient un formulaire dans lequel l'utilisateur saisira son nom d'utilisateur et son mot de passe. Ce formulaire transmettra les données au fichier authorize.php qui, si l'autorisation est réussie, permettra à l'utilisateur d'accéder au fichier secretplace.php, et sinon affichera un message d'erreur.

Exemples: index.php

Se connecter:
Mot de passe:

autoriser.php page... header("Emplacement : secretplace.php"); sortie; ) ) // si quelque chose n'allait pas, l'utilisateur recevra // ​​un message d'erreur. ?> Vous avez entré un mauvais mot de passe ! lieu secret.phpBonjour,

, vous êtes sur une page secrète !!! :)

Sécurité

• Ainsi, nous sommes capables de transmettre un identifiant d'une page (script PHP) à une autre (jusqu'au prochain appel de notre site), ce qui nous permet de distinguer tous les visiteurs du site. L'identifiant de session étant un très grand nombre (128 bits), il n'y a pratiquement aucune chance qu'il puisse être trouvé par force brute. Par conséquent, l’attaquant se retrouve avec les options suivantes :
• il y a un cheval de Troie sur l'ordinateur de l'utilisateur qui vole les numéros de session ;
• l'attaquant intercepte le trafic entre l'ordinateur de l'utilisateur et le serveur. Bien sûr, il existe un protocole SSL sécurisé (crypté), mais tout le monde ne l'utilise pas ;

un voisin s’est approché de l’ordinateur de notre utilisateur et lui a volé le numéro de session.

De telles situations, basées sur le fait que quelqu'un vole quelque chose à quelqu'un d'autre, ne relèvent généralement pas de la compétence du programmeur. Les administrateurs et les utilisateurs eux-mêmes doivent s'en occuper.

• Cependant, PHP peut très souvent être « trompé ». Examinons les points de piratage possibles dans le programme d'autorisation des utilisateurs :
• Le fichier authorize.php est une tentative de deviner un mot de passe à l'aide d'un script tiers ;
  Le fichier secretplace.php est une tentative de tromper le programme en saisissant les valeurs de la variable $logged_user dans la barre d'adresse du navigateur, par exemple comme ceci : " http://www.yoursite.ru/secretplace.php ?"

utilisateur_connecté = pirate informatique

Ainsi, deux « trous » sont clairement visibles dans notre programme, l'un est petit et pas particulièrement visible, mais le second est tout simplement énorme, par lequel la plupart des pirates informatiques pénètrent là où ils n'ont pas besoin d'aller.

Comment « reboucher » le trou numéro 1 ?

Nous n'écrirons pas des tonnes de code pour bloquer une adresse IP, etc., mais vérifions simplement d'où vient la demande, ou plutôt de quelle page vient la demande, s'il s'agit d'une page de notre site, alors tout va bien, mais dans dans tous les autres cas, nous ne vous laisserons pas entrer. Ajustons le fichier authorize.php : autoriser.php V2 ) ) // si quelque chose n'allait pas, l'utilisateur recevra // ​​un message d'erreur. ?>
page... header("Emplacement : secretplace.php"); sortie;

Disons que vous disposez d'un site Web sur lequel tout le monde peut s'inscrire pour publier sur un forum. Naturellement, dans le forum, certains utilisateurs (administrateurs, modérateurs) ont plus de possibilités que d'autres ; par exemple, ils peuvent supprimer les messages d'autres utilisateurs ; Vous stockez le niveau d'accès de l'utilisateur dans la session, dans la variable $user_status, où $user_status = 10 correspond à un accès complet au système. Un attaquant qui accède au site doit simplement s'inscrire de la manière habituelle, puis ajouter dans la barre d'adresse du navigateur ?statut_utilisateur=10. Vous avez donc un nouvel administrateur sur votre forum !

En principe, n'importe quelle variable de script peut être définie via la barre d'adresse en ajoutant simplement un point d'interrogation et le nom de la variable avec sa valeur après l'adresse complète du script. Corrigeons notre code pour éviter cela :

lieu secret.php V2 variable non définie ($_SESSION["logged_user"]); // ouvre la session session_start(); /* vous ne pouvez pas simplement aller sur cette page... si le nom d'utilisateur n'est pas enregistré, alors nous le redirigeons vers la page index.php pour saisir le login et le mot de passe... ici vous pouvez réellement faire beaucoup de choses, par exemple, mémorisez l'adresse IP de l'utilisateur et après la troisième tentative d'accès aux fichiers, bloquez-le. */ if(!isset($_SESSION["logged_user"]))( header("Location: index.php"); exit; ) ?> lieu secret.php, vous êtes sur une page secrète ! Résultats

Le mécanisme de session est une très bonne fonctionnalité du langage PHP. Les sessions sont simples et très flexibles à utiliser. À propos, il existe une fonctionnalité peu documentée des sessions PHP (disponible à partir de la version 4.0.3) : dans les sessions, vous pouvez stocker non seulement des variables, mais également des objets.

Exemples

?>
// Insère automatiquement le SID dans les liens. ini_set("session.use_trans_sid", true); session_start(); ?> Cliquez ici!
Cliquez ici!!

// Un exemple de travail avec des sessions. session_start(); // Si vous venez de visiter le site, réinitialisez le compteur. if (!isset($_SESSION["count"])) $_SESSION["count"] = 0; //Augmente le compteur dans la session. $_SESSION["compte"] = $_SESSION["compte"] + 1; ?>

Comptoir

fois).
Fermez votre navigateur pour réinitialiser le compteur.
" target="_blank"> Ouvre une fenêtre de navigateur enfant.
// Un exemple simple d'utilisation de sessions sans Cookies. nom_session("test"); session_start(); $_SESSION["compte"] = @$_SESSION["compte"] + 1; ?>

Comptoir

Vous avez ouvert cette page dans votre session de navigateur actuellefois).
Fermez votre navigateur pour réinitialiser ce compteur.
?">Cliquez ici pour actualiser la page !

Aujourd'hui, nous examinerons l'exploitation d'une vulnérabilité critique d'un jour dans le populaire CMS Joomla, qui a explosé sur Internet fin octobre. Nous parlerons des vulnérabilités avec des chiffres CVE-2016-8869, CVE-2016-8870 Et CVE-2016-9081. Tous les trois proviennent d'un seul morceau de code qui a langui dans les profondeurs du framework pendant cinq longues années, attendant dans les coulisses, pour ensuite se libérer et entraîner avec lui le chaos, les sites piratés et les larmes des utilisateurs innocents de ce Joomla. Seuls les développeurs les plus vaillants et courageux, dont les yeux sont rouges à cause de la lumière des moniteurs et dont les claviers sont jonchés de miettes de pain, ont pu défier les mauvais esprits déchaînés et poser leur tête sur l'autel des correctifs.

AVERTISSEMENT

Toutes les informations sont fournies à titre informatif uniquement. Ni les éditeurs ni l'auteur ne sont responsables de tout dommage éventuel causé par les éléments de cet article.

Où tout a commencé

Le 6 octobre 2016, Demis Palma a créé un sujet sur Stack Exchange dans lequel il demandait : pourquoi, en fait, dans la version 3.6 de Joomla, il existe deux méthodes pour enregistrer des utilisateurs avec le même nom register() ? Le premier se trouve dans le contrôleur UsersControllerRegistration et le second dans le contrôleur UsersControllerUser. Damis voulait savoir si la méthode UsersControllerUser::register() était utilisée quelque part, ou s'il s'agissait simplement d'un anachronisme évolutif issu de l'ancienne logique. Son souci était que même si cette méthode n'est utilisée par aucune vue, elle peut être appelée par une requête spécialement conçue. Ce à quoi j'ai reçu une réponse d'un développeur sous le pseudo itoctopus, qui a confirmé : le problème existe vraiment. Et envoyé un rapport aux développeurs Joomla.

Ensuite, les événements se sont développés le plus rapidement. Le 18 octobre, les développeurs de Joomla ont accepté le rapport de Damis, qui avait alors rédigé un PoC permettant l'enregistrement des utilisateurs. Il a publié une note sur son site Internet, dans laquelle il parlait en termes généraux du problème qu'il avait rencontré et de ses réflexions à ce sujet. Le même jour, une nouvelle version de Joomla 3.6.3 est publiée, qui contient encore du code vulnérable.

Après cela, Davide Tampellini fait tourner le bug au point d'enregistrer non pas un simple utilisateur, mais un administrateur. Et le 21 octobre, un nouveau cas arrive à l'équipe de sécurité de Joomla. Il parle déjà d'augmenter les privilèges. Le même jour, une annonce apparaît sur le site Web Joomla selon laquelle la prochaine version portant le numéro de série 3.6.3 sera publiée le mardi 25 octobre, qui corrige une vulnérabilité critique dans le noyau du système.

25 octobre Joomla Security Strike Team découvre le dernier problème créé par le morceau de code découvert par Damis. Ensuite, un commit daté du 21 octobre portant le nom discret Prepare 3.6.4 Stable Release est poussé dans la branche principale du référentiel officiel Joomla, qui corrige le malheureux bug.

Après cette révélation, de nombreuses personnes intéressées rejoignent la communauté des développeurs – ils commencent à promouvoir la vulnérabilité et à préparer des exploits.

Le 27 octobre, le chercheur Harry Roberts télécharge un exploit prêt à l'emploi dans le référentiel Xiphos Research, capable de télécharger un fichier PHP sur un serveur doté d'un CMS vulnérable.

Détails

Eh bien, le contexte est terminé, passons à la partie la plus intéressante : l'analyse de la vulnérabilité. J'ai installé Joomla 3.6.3 comme version de test, donc tous les numéros de ligne seront pertinents pour cette version. Et tous les chemins d'accès aux fichiers que vous verrez ci-dessous seront indiqués par rapport à la racine du CMS installé.

Grâce à la découverte de Damis Palma, nous savons qu'il existe deux méthodes pour enregistrer les utilisateurs dans le système. Le premier est utilisé par le CMS et se trouve dans le fichier /components/com_users/controllers/registration.php:108. Le deuxième (celui que nous devrons appeler) réside dans /components/com_users/controllers/user.php:293. Regardons-le de plus près.

286 : /** 287 : * Méthode pour enregistrer un utilisateur. 288 : * 289 : * @return boolean 290 : * 291 : * @since 1.6 292 : */ 293 : public function register() 294 : ( 295 : JSession::checkToken("post") ou jexit(JText::_ ("JINVALID_TOKEN")); ... 300 : // Récupère les données du formulaire. 301 : $data = $this->input->post->get("user", array(), "array"); 315 : $return = $model->validate($form, $data); 316 : 317 : / Vérification des erreurs 318 : if ($return === false) 319 : ( ... 345 : / / Terminez l'enregistrement 346 : $return = $model->register($data);

Ici, je n'ai laissé que des lignes intéressantes. La version complète de la méthode vulnérable peut être consultée dans le référentiel Joomla.

Voyons ce qui se passe lors de l'enregistrement normal d'un utilisateur : quelles données sont envoyées et comment elles sont traitées. Si l'enregistrement des utilisateurs est activé dans les paramètres, le formulaire peut être trouvé à l'adresse http://joomla.local/index.php/component/users/?view=registration.

Une demande d'enregistrement d'utilisateur légitime ressemble à la capture d'écran suivante.

Le composant com_users est responsable du travail avec les utilisateurs. Faites attention au paramètre de tâche dans la requête. Il a le format $controller.$method . Regardons la structure des fichiers.

Noms des scripts dans le dossier contrôleurs correspondent aux noms des contrôleurs appelés. Puisque notre requête contient désormais $controller = "registration" , le fichier sera appelé inscription.php et sa méthode register().

Attention, question : comment transférer le traitement de l'enregistrement vers un endroit vulnérable du code ? Vous l'avez probablement déjà deviné. Les noms des méthodes vulnérables et réelles sont les mêmes (registre), il suffit donc de changer le nom du contrôleur appelé. Où se trouve notre contrôleur vulnérable ? C'est vrai, dans le fichier utilisateur.php. Il s'avère que $controller = "user" . En mettant le tout ensemble, nous obtenons task = user.register . La demande d'inscription est désormais traitée par la méthode dont nous avons besoin.

La deuxième chose à faire est d'envoyer les données dans le bon format. Tout est simple ici. Le registre légitime() attend de nous un tableau appelé jform , dans lequel nous transmettons les données d'enregistrement - nom, login, mot de passe, e-mail (voir capture d'écran avec la demande).

• /components/com_users/controllers/registration.php : 124 : // Récupère les données utilisateur. 125 : $requestData = $this->input->post->get("jform", array(), "array");

Notre client obtient ces données à partir d'un tableau appelé user.

• /components/com_users/controllers/user.php : 301 : // Récupère les données du formulaire. 302 : $data = $this->input->post->get("user", array(), "array");

Par conséquent, nous changeons les noms de tous les paramètres de la requête de jfrom en user .

Notre troisième étape consiste à trouver un token CSRF valide, car sans lui il n'y aura pas d'enregistrement.

• /components/com_users/controllers/user.php : 296 : JSession::checkToken("post") ou jexit(JText::_("JINVALID_TOKEN"));

Cela ressemble à un hachage MD5, et vous pouvez le récupérer, par exemple, à partir du formulaire d'autorisation sur le site /index.php/component/users/?view=login.

Vous pouvez maintenant créer des utilisateurs en utilisant la méthode souhaitée. Si tout s'est bien passé, alors félicitations : vous venez d'exploiter une vulnérabilité. CVE-2016-8870"Vérification des autorisations manquantes pour l'enregistrement de nouveaux utilisateurs."

Voici à quoi cela ressemble dans la méthode « fonctionnelle » register() du contrôleur UsersControllerRegistration :

• /components/com_users/controllers/registration.php : 113 : // Si l'enregistrement est désactivé - Redirection vers la page de connexion. 114 : if (JComponentHelper::getParams("com_users")->get("allowUserRegistration") == 0) 115 : ( 116 : $this->setRedirect(JRoute::_("index.php?option=com_users&view= login", false)); 117 : 118 : return false ; 119 : )

Et donc en vulnérable :

• /components/com_users/controllers/user.php :

Ouais, pas question.

Pour comprendre le deuxième problème, beaucoup plus grave, envoyons la requête que nous avons créée et voyons comment elle est exécutée dans différentes parties du code. Voici l'élément chargé de valider les données soumises par l'utilisateur dans la méthode Worker :

La suite est disponible uniquement pour les membres

Option 1. Rejoignez la communauté « site » pour lire tous les documents sur le site

L'adhésion à la communauté pendant la période spécifiée vous donnera accès à TOUS les documents Hacker, augmentera votre remise cumulée personnelle et vous permettra d'accumuler une note professionnelle Xakep Score !