Points clés
allow_url_fopen et allow_url_include dans le fichier php.ini. session_regenerate_id() pour modifier périodiquement l'ID de session et stocker l'ID de session dans un endroit où seul votre script peut accéder. La sécurité n'est pas seulement une série d'opérations, mais aussi une façon de penser, une façon de regarder les problèmes et une façon de traiter avec le monde. Cela signifie "Je ne sais pas ce qu'ils feront, mais je sais qu'ils essaieront de bousiller mon système", puis d'empêcher de manière proactive le problème plutôt que de tomber dans des émotions négatives. Cependant, vous ne pouvez pas violer les règles statistiques. Personne ne lirait un article intitulé "Codage for Security". Tout le monde veut un article avec des chiffres, tels que: «8 attaques de sécurité PHP les plus courantes et comment les éviter», «23 choses ne disent pas aux mannequins» et «15 raisons d'éviter l'intoxication aux radiations». Par conséquent, voici les "Top Ten PHP Security Vulnerabilities".
Injection SQL
La première place est l'attaque d'injection SQL. Dans ce cas, quelqu'un entre des extraits de code SQL (des exemples classiques suppriment les instructions de la base de données, bien qu'il existe de nombreuses autres opérations potentiellement destructrices) comme valeurs dans votre URL ou votre formulaire Web. Maintenant, ne vous inquiétez pas de la façon dont il connaît le nom de votre table; Vous combattez un ennemi sinistre et ingénieux. Alors, que pouvez-vous faire pour éviter cela? Tout d'abord, vous devez être sceptique quant à toute entrée que vous recevez de l'utilisateur. Je crois que tout le monde est amical? Regardez la famille de votre conjoint… Ils sont bizarres, bizarres et certains sont même dangereux. La façon d'éviter de tels problèmes consiste à utiliser des instructions de prétraitement APD. Je ne veux pas discuter de l'APD en détail maintenant. Dites simplement que l'instruction de prétraitement sépare les données des instructions. Cela empêche les données d'être traitées comme autre chose que les données. Pour plus d'informations, vous pouvez afficher l'article "Migrant de l'extension MySQL vers PDO" Écrit par Timothy Boronczyk.
Attaque de script de site transversal (XSS)
Renforce ces gens au cœur noir qui comptent sur cette tromperie pour survivre. Parents, parlez aux enfants aujourd'hui pour qu'ils ne deviennent pas les attaquants XSS maléfiques! L'essence de toute attaque XSS est d'injecter du code (généralement du code JavaScript, mais peut être n'importe quel code client) dans la sortie de votre script PHP. Ce type d'attaque est possible lorsque vous affichez l'entrée qui vous est envoyée, par exemple, vous pouvez le faire dans un post de forum. Un attaquant peut publier du code JavaScript dans son message qui peut causer des dommages indescriptibles à votre site Web. S'il vous plaît, ne me laissez pas expliquer en détail; mon cœur fait mal quand je pense à ce que ces voleurs peuvent faire. Pour plus d'informations et comment vous protéger, je recommande de lire ces excellents articles sur Phpmaster:
FEUX DE CODE SOURCE
Cela a à voir avec la possibilité de voir les noms de fichiers et le contenu que les gens ne devraient pas voir quand la configuration d'Apache échoue. Oui, je comprends, cela ne se produit probablement pas, mais cela peut arriver et il est facile de vous protéger, alors pourquoi pas? Nous savons tous que PHP est côté serveur - vous ne pouvez pas simplement regarder le code source pour voir le code du script. Mais si Apache échoue et que vos scripts servent soudainement en texte brut, les gens verront le code source qu'ils n'auraient pas dû voir. Une partie de ce code peut énumérer les fichiers de configuration accessibles ou contenir des informations sensibles, telles que les informations d'identification de la base de données. Le cœur de la solution est la façon dont vous configurez la structure du répertoire de votre application. Autrement dit, ce n'est pas un problème pour les mauvaises personnes de voir un code, le problème est quel code ils peuvent voir si les fichiers sensibles sont enregistrés dans les répertoires publics. Enregistrez des fichiers importants en dehors des répertoires accessibles au public pour éviter les conséquences de cette erreur. Pour plus d'informations, y compris l'exemple de la structure de votre répertoire, voir le point 5 de cet article. Pour plus de discussions sur ce sujet, consultez cette discussion du forum.
Le fichier distant contient
Veuillez patienter et laissez-moi expliquer: l'inclusion des fichiers distants signifie que les fichiers distants sont inclus dans votre application. Très profond, non? Mais pourquoi est-ce un problème? Parce que les fichiers distants ne sont pas dignes de confiance. Il a peut-être été modifié de manière malveillante, contenant du code que vous ne souhaitez pas exécuter dans votre application. Supposons que votre site Web www.mlace.com contient la bibliothèque www.goodpeople.com/script.php. Une nuit, www.goodpeople.com a été piraté et le contenu du fichier a été remplacé par un code malveillant qui détruirait votre application. Ensuite, quelqu'un visite votre site Web, vous introduisez du code mis à jour, puis - Bang! Alors, comment arrêtez-vous? Heureusement, la résolution de ce problème est relativement simple. Il vous suffit d'aller sur votre php.ini et de vérifier les paramètres de ces drapeaux.
allow_url_fopen - Indique si les fichiers externes peuvent être inclus. Le paramètre par défaut est "ON", mais vous devez le désactiver. allow_url_include - Indique si les fonctions include(), require(), include_once() et require_once() peuvent faire référence à des fichiers distants. Il est désactivé par défaut, et désactiver allow_url_fopen oblige également à être désactivé. Rijacking de session
Le détournement de session, c'est quand une mauvaise personne vole et utilise l'ID de session de quelqu'un d'autre, ce qui est comme la clé d'un coffre-fort sécurisé. Lorsqu'une session est établie entre le client et le serveur Web, PHP peut stocker l'ID de session dans un cookie nommé PHPSESSID sur le client. Envoie l'ID avec la demande de page pour accéder aux informations persistantes de session sur le serveur (cela remplit le tableau de variable Global $_SESSION). Si quelqu'un vole la clé de session, est-ce mauvais? La réponse est: si vous n'effectuez aucune action importante dans cette session, la réponse est non. Cependant, si vous utilisez cette session pour authentifier les utilisateurs, cela permettra à certaines personnes de se connecter et à entrer dans quelque chose. Ceci est particulièrement mauvais si l'utilisateur est important et a beaucoup d'autorisations. Alors, comment les gens volent-ils ces identifiants de session, et que pouvons-nous faire, à ceux d'entre nous qui sont droits et craints de Dieu? Les identifiants de session sont généralement volés à travers les attaques XSS, donc empêcher les attaques XSS est une bonne chose qui peut avoir un double avantage. Il est également important de modifier l'ID de session aussi souvent que possible. Cela raccourcira votre fenêtre temporelle volée. Dans PHP, vous pouvez exécuter la fonction session_regenerate_id() pour modifier l'ID de session et informer le client. Pour les utilisateurs utilisant PHP 5.2 et plus tard (vous l'utilisez?), Il existe un paramètre PHP.ini qui empêche JavaScript d'accéder à l'ID de session (session.cookie.httponly). Alternativement, vous pouvez utiliser la fonction session_set_cookie_parms(). Si vous utilisez des services d'hébergement partagés (qui stockent les informations de session dans un répertoire accessible à l'échelle mondiale, par exemple /tmp), l'ID de session peut également avoir des vulnérabilités du côté du serveur. Vous pouvez bloquer ce problème en stockant simplement l'ID de session dans un emplacement qui n'est accessible qu'à votre script (sur disque ou dans la base de données).
falsification de la demande croisée
Le contrefaçon de demande de site croisé (CSRF), également connu sous le nom de stratégie de Brett Mafrick ou Sean Spencer, implique de faire en sorte qu'un utilisateur plutôt informe en envoyant un que nous devons dire est très défavorable à lui-même. Mais au lieu de me laisser continuer à discuter des attaques du CSRF, reportez-vous à l'exemple exceptionnel d'un tel contenu sur PHPMaster: prévenir la contrefaçon de demande de site croisé, écrite par Martin Psinas.
Catalogue Transfert
Ce type d'attaque, comme de nombreuses autres attaques, recherche des sites Web avec une mauvaise sécurité, et lorsqu'il trouve un site Web, il provoque l'accès aux fichiers auxquels le propriétaire n'a pas l'intention d'accéder publiquement. Il est également appelé ../ (point, point, barre oblique), attaque d'escalade et attaque de retour en arrière. Il existe plusieurs façons d'empêcher cette attaque. Tout d'abord, j'espère sincèrement que cela ne vous arrivera pas. Parfois, faire un souhait aux fées et aux licornes aide. Parfois ce n'est pas le cas. La deuxième approche consiste à utiliser une liste blanche pour définir quelles pages peuvent être retournées pour une demande donnée. Une autre option consiste à convertir les chemins de fichier en chemins absolus et à s'assurer qu'ils font référence aux fichiers dans le répertoire autorisé.
Résumé
Ce sont les 10 meilleurs problèmes qui peuvent entraîner le piratage de votre application PHP si vous les évitez accidentellement. Oui, 10. Comptez… 1,2,3… quoi? Vous n'en avez compté que 8? Ok, peut-être 7. Eh bien, cela montre que vous pouvez facilement être dupe et je ne suis même pas un méchant! images de Fotolia
Des questions fréquemment posées pour les vulnérabilités de sécurité PHP (FAQ)
Les vulnérabilités de sécurité PHP les plus courantes comprennent l'injection SQL, les attaques de scripts inter-sites (XSS), la contrefaçon de demande croisée (CSRF), les vulnérabilités d'inclusion de fichiers et l'injection d'objets PHP. S'ils sont gérés mal, ces vulnérabilités peuvent entraîner un accès non autorisé, un vol de données et même une prise de contrôle du serveur. Il est crucial pour les développeurs de comprendre ces vulnérabilités et de mettre en œuvre des mesures de sécurité appropriées pour protéger leurs applications PHP.
Des instructions de prétraitement ou des requêtes paramétrées peuvent être utilisées pour empêcher l'injection de SQL. Ces méthodes garantissent que la saisie de l'utilisateur est toujours traitée comme des données littérales, et ne fait pas partie des commandes SQL. Cela élimine efficacement le risque d'injection SQL. De plus, vérifiez et nettoyez toujours les entrées utilisateur pour vous assurer qu'elle ne contient pas de code malveillant.
Attaque de script de site transversal (XSS) est une vulnérabilité qui permet à un attaquant d'injecter des scripts malveillants dans les pages Web visualisées par d'autres utilisateurs. Cela peut entraîner un détournement de session, un vol d'identité et d'autres problèmes graves. Pour éviter les XS, codez toujours l'entrée utilisateur et n'insérez jamais de données non fiables dans la sortie HTML.
Le jeton de bouffes de bouffées peut être utilisé pour empêcher les attaques du CSRF. Ce sont les seules valeurs aléatoires associées à la session utilisateur. Ils sont inclus dans chaque demande de changement d'état (tel que la soumission de formulaire) et sont vérifiés par le serveur. Si le jeton est manquant ou incorrect, la demande sera refusée.
La vulnérabilité d'inclusion de fichiers fait référence à la situation où une application utilise l'entrée utilisateur pour créer un chemin de fichier pour les opérations. Un attaquant peut manipuler l'entrée pour contenir des fichiers à partir d'un serveur distant, ce qui entraîne une exécution de code, une fuite de données ou un déni de service. Pour atténuer cette vulnérabilité, évitez d'utiliser la saisie de l'utilisateur dans les chemins de fichier ou vérifiez et nettoyez soigneusement l'entrée.
L'injection d'objets PHP est une vulnérabilité, qui se produit lorsque l'entrée de l'utilisateur est utilisée pour instancier une classe. Un attaquant peut manipuler l'entrée pour créer une instance de n'importe quelle classe et exécuter ses méthodes. Pour éviter cela, ne vous désérifiez jamais de données provenant de sources non fiables.
Les sessions PHP peuvent être protégées en utilisant des cookies sécurisés, en régénérant les identifiants de session après la connexion et en mettant en œuvre des délais de session. De plus, les données de session sont stockées du côté du serveur et seul l'ID de session est utilisée pour la référence.
Certaines meilleures pratiques pour la sécurité PHP incluent: garder la version PHP à jour, configurer avec des configurations de sécurité, vérifier et nettoyer les entrées des utilisateurs, utiliser des algorithmes de hachage de mot de passe sécurisés et implémenter la gestion des erreurs correctes.
Les vulnérabilités PHP peuvent être détectées grâce à l'examen du code, aux tests de pénétration et à l'utilisation d'outils de sécurité automatisés. La révision régulière des applications pour les vulnérabilités de sécurité est un élément essentiel du maintien des applications PHP sécurisées.
Il existe de nombreuses ressources pour en savoir plus sur la sécurité PHP, y compris les manuels PHP, les tutoriels en ligne, les blogs de sécurité et les forums. De plus, des organisations telles que OWASP fournissent un guide complet sur la sécurité des applications Web.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Comment l'Oracle tourne
Que signifie ICO ?
Comment fermer le port 135 445
Comment résoudre le problème de l'absence du fichier msxml6.dll
Comment résoudre l'absence de route vers l'hôte
Comment résoudre le problème lorsque la température du processeur de l'ordinateur est trop élevée
Explication détaillée de la fonction fork Linux
Logiciel de base de données couramment utilisé
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
