34 votes

Quels problèmes de sécurité dois-je rechercher en PHP

Je viens de commencer à apprendre PHP, je développe des applications Web depuis longtemps sur ASP.Net. Je me demandais s'il y avait des erreurs de sécurité spécifiques à PHP que je devais rechercher.

Donc, ma question est quels sont les meilleurs conseils de sécurité que chaque développeur PHP devrait connaître.

Veuillez le garder à un pourboire par réponse afin que les gens puissent voter efficacement contre.

17voto

AlexV Points 8604

(Dans aucun ordre particulier)

  1. Vérifiez toujours que register globals sont OFF
  2. Vérifiez toujours si les magic quotes sont OFF
  3. Assurez-vous que vous comprenez les attaques par injection SQL
  4. DÉSACTIVER les rapports d'erreurs dans la production

EDIT: Pour les "débutants" là c'est une base, pourquoi (et depuis que j'ai le temps de lui expliquer ce):

  1. Register globals, est une aberration. C'est l'ultime trou de sécurité jamais. Par exemple, si register_globals est à on, l'url http://www.yourdomain.com/foo.php?isAdmin=1 déclarer $isAdmin comme une variable globale avec aucun code n'est requis. Je ne sais pas pourquoi cette "fonctionnalité" a fait son chemin au PHP, mais les gens derrière ce qui devrait avoir le suivant tatoué sur son front: "j'ai inventé PHP Register Globals" afin que nous puissions fuir comme des parasites quand on les voit!

  2. Magic quotes est une autre idée stupide qui a fait son chemin au PHP. En gros, quand SUR PHP va échapper les guillemets automatiquement ("devenir \" et de " devenir \") pour aider à des attaques par injection SQL. Le concept n'est pas mauvais (aider à éviter les attaques par injection), mais échappant à tous les GET, POST et COOKIE valeurs de rendre votre code tellement complexe (par exemple, à ne pas encoder à chaque fois lors de l'affichage des données). De Plus, si un jour vous DÉSACTIVER ce paramètre, sans faire aucune modification de votre code, tout votre code et/ou de données est cassé et (encore plus) vulnérables à des attaques par injection (oui, même lorsque vous êtes vulnérable).

  3. Votre databse de données est votre bien le plus précieux de chose sur votre site. Vous ne voulez pas les gens à jouer avec elle, afin de vous protéger et de lire des choses à ce sujet et code avec cela à l'esprit.

  4. Là encore, cela peut conduire à des problèmes de sécurité. Le message d'erreur peut donner des conseils à hackes sur la façon dont votre code fonctionne. Aussi ces messages ne veux pas dire n'importe quoi à vos visiteurs, alors pourquoi les semer?

16voto

Greg Points 132247

Évitez d'utiliser register_globals

12voto

Dereleased Points 6187
  • Cross Site Scripting (XSS) Wiki, Google
  • Cross Site Request Forgery (XSRF/CSRF) Wiki, Google (merci Tour)
  • SQL Injection (SQLi) Wiki, Google
  • Désactiver les messages d'erreur dans les environnements de Production
  • Gardez tout "include" de code dans un répertoire qui n'est pas accessible sur le web (soit de refuser l'accès ou de le laisser en dehors de la racine du site)
  • Voici un article que j'ai écrit au sujet de stocker les mots de passe de manière sécurisée, et si vous n'avez pas envie de prendre mon mot pour lui, de vérifier les liens en bas.
  • Également liée dans mon article, mais étant donné son propre lien ici, est un document publié par M. I. T. appelé Le DOs et NE pas faire lors de l'Authentification du Client sur le Web [PDF]. Bien que certaines de ses infos (recommandation de l'utilisation de hachage MD5, pour un) est quelque peu obsolète tout simplement parce que de ce qui-nous-savons-maintenant, par rapport à ce que-nous-savait-ensuite, les principes généraux sont très forts et doivent être considérés.
  • L'une des Tours " liens m'a rappelé un autre ensemble important de restrictions
    • Éteignez Register Globals (C'est la valeur par défaut maintenant, donc je n'avais pas parlé avant)
    • Lors de l'upload de fichiers, assurez-vous d'utiliser is_uploaded_file() , afin de valider qu'un fichier a été téléchargé et move_uploaded_file() au lieu de copy() ou rename().
  • Depuis que j'ai mentionné deux fois, découvrez la Réponse de Tours (http://stackoverflow.com/questions/2275771/what-are-the-most-important-safety-precautions-that-a-php-developer-needs-to-know#2275788) incluant un lien vers un document qui contient (Non-PHP-Spécifique) informations sur les principaux problèmes de sécurité (et c'est donc sans doute la bonne réponse).

8voto

Robert Greiner Points 16237

voici un lien de bonnes pratiques de programmation de sécurité PHP.

http://phpsec.org/

La plupart des problèmes de sécurité tournent autour de la saisie des utilisateurs (naturellement) et du fait qu'ils ne vous gênent pas. Assurez-vous toujours de valider votre entrée.

http://htmlfixit.com/cgi-tutes/tutorial_PHP_Security_Issues.php

7voto

prodigitalson Points 38549
  1. Toujours nettoyer et valider les données transmises depuis la page
  2. En conjonction avec # 1, échappez toujours correctement à votre sortie
  3. Toujours désactiver display_errors en production
  4. Si vous utilisez un backend DB, utilisez un pilote qui prend en charge / émule les instructions préparées et utilisez sans préjudice :-)

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X