S'il vous plaît définir sécurité PHP...Si vous pensez que vous pouvez!

Donc, j'ai été moi-même enseignant PHP depuis environ un an maintenant, et souvent je prends les différents scripts que j'ai créé et géré par des gens sur les forums, comme celui-ci. Une des choses que j'ai toujours entendre est que mes scripts ne sont pas sécurisés. Ok, je suis bien mal à la sécurité, je peux l'accepter. Mais quand d'autres sur les forums, essayez de souligner les failles de sécurité dans mon code, il tourne toujours dans un débat sur whats sûr et ce qui ne l'est pas. Donc, je suis donc pas d'indice si mes scripts sont sécurisés ou non, et aucune direction à prendre pour les résoudre.

Donc, ma question est: Peut-on définir les éléments de la sécurité du code PHP? Quelqu'un peut-il point à des articles ou des exemples de la sécurité PHP? Est-ce que quelqu'un veut essayer de la définir dans leurs propres mots?

Peut-être que ce fil peut se transformer en quelque chose de bénéfique pour tout le monde.

Cela dépend ce qu'on entend par sécurité. Êtes-vous en essayant d'éviter les injections SQL? Êtes-vous d'essayer de limiter l'accès des utilisateurs?

Je suppose que la définition de "sécurité" devrait être notre première priorité. Mais cela fait partie du problème, il semble que si il ya tellement d'idées différentes sur ce que de façon sécuritaire. C'est pourquoi je me pose cette question pour discussion.

La sécurité est, comme vous l'avez dit, un sujet controversé où les gens ont des opinions différentes sur ce qui est sûr et la manière de faire de tels scripts.

La sécurité en général, empêchant les autres de faire tout ce que les effets négatifs de l'autre groupe. Si vous pensez que les injections SQL est mauvais pour vous, que vous voulez faire une certaine protection contre un tel acte. (Im sûr SQL Injection sont mauvais ).

Pour obtenir un peu plus technique, avec la définition de la sécurité PHP, nous avons à réfléchir sur les autres et ce qu'ils pensent de lui et de mettre un compromis qui profite à la fois la définition et / ou tous les groupes de personnes avec des définitions différentes.

À ce jour, venant de moi, la définition de la sécurité PHP -- Tenir les gens d'effectuer toute personne par qui que ce soit en aucune façon par le biais de votre script .

Peut-être que cette définition est trop large ou trop général, je ne sais pas. Mais c'est ce que j'essaie de faire. Si quelqu'un, en utilisant mon PHP peut faire quelque chose pour une autre personne de portefeuille ou de quelque chose sur mon site, Im va être inquiets au sujet de ma pensée et de la sécurité PHP peut-être pas assez sûr de son.

Excellente définition Bogey! Je me demande si elle pourrait être plus dynamique si l'on parle de différentes menaces spécifiques telles que les injections SQL et de les définir, parler de la façon dont ils sont exécutés, et comment se défendre contre eux. Toute autre personne ont des idées pour commencer?

Erreur piège si vos déclarations

Désolé de le dire, je ne veux pas prétendre que certains programmeurs sont «à courte vue". Mais je pense que tout dépend de votre approche sur le sujet.

En tant que programmeur de new-york a expliqué dans son blog, il ya des problèmes. deux types de programmeurs. Les idéalistes et pragmatiques, si l'on considère l'ensemble du code du point de vue des idéaux sans prendre la "fonctionnelle" de l'examen du code en plus du code qui utilise un formulaire html pourrait être considéré comme un risque de sécurité.

Du point de vue pragmatique, je voudrais tout d'abord vous demander ce que vous voulez que le code à faire et puis finalement étudier les options de votre code pour moi de faire des choses différentes alors déclaré la fonctionnalité. Par exemple,

Si vous voulez que je ne doit être en mesure de signer à l'aide de votre formulaire, et je suis en mesure de le faire à partir d'un emplacement différent. Je pourrais considérer ce soit une faille de sécurité, ou une fonctionnalité non documentée.

Si vous ne voulez pas que n'importe qui pour obtenir "admin", sans statut de l'utilisation de votre admin panneau soigneusement écrit, et je suis en mesure de le faire à partir de votre site sans utiliser le panneau admin soigneusement écrit, je pourrais envisager de nouveau une faille de sécurité ou d'un fonctionnalité sans-papiers...

Je suppose que tout dépend de vos exigences fonctionnelles final et ce que vous permettent de le faire par écrit, fort ou faible de code dans certains points.

-Regards,

Mai est assez bonne quand il s'agit de la sécurité

Je suis d'accord avec vous sur la définition d'approche - idéaliste / pragmatique. Cependant, je ne pense pas que la sécurité est (ou devrait être) que ambigu.

L'utilisation de votre exemple:



IMHO, vous, en tant que personne qui essaie d'exécuter un exploit, il n'est pas question de ce que vous "envisager". De l'auteur du point de vue des codes de votre examen a été par la fenêtre lorsque vous passé par le panneau d'admin. Par conséquent, si vous affichez le code de la faiblesse comme une opportunité ou "sans-papiers fonction" n'est pas pertinente parce que vous n'êtes pas l'auteur du code et maintenant admin "status" quand ils ne sont pas normalement autorisés.

Le but de ce fil est de discuter de la sécurité PHP avec des exemples précis de code sécurisé forte. De ne pas prendre l'avis d'un opportuniste tenu de la faiblesse de code.

Désolé pour le GABS qui permettent ce côté route. Mais le principe même de l'Penetration Testing (CEH) est fondée sur la rupture code / architectures / systèmes, par rapport à ce que ceux-ci sont censés faire. Qui à son tour définit forts ou faibles de code. Et de nous offrir les connaissances nécessaires pour faire le meilleur ou pour le protéger tous toghether.

Encore une fois, c'est toujours mon avis, vous pouvez l'accepter ou non votre thats libre choix et je ne vais pas essayer de vous convaincre, il...

Mais ce que je tente de souligner, c'est que si jamais il ya un certain type d'interaction entre deux systèmes de code, basé sur réseau ou autre, il y aura des "risques". Et tout en traitant avec eux quelqu'un doit faire un choix la manière de traiter avec elle .

Concernant votre exemple mis en évidence, un développeur peut reconnaître ce «risque» est vrai à cause d'une faille dans le logiciel de moteur de PHP, et peut-être la prochaine à faire le choix soit d'écrire le code d'accepter ce risque ou de ne pas écrire à tous et à trouver un autre plus moyen sécurisé de gestion de la demande. A la fin quelqu'un sera tenu pour responsable du risque, soit laisser les entreprises décider si le risque est acceptable et de les laisser à la responsabilité ou de prendre vous-même...

-Regards,

Bien dit, thats ce que cela se résume à toujours. Im pragmatique de l'école . S'agissant de la forme permet de dire que vous la vérification de chaque domaine sur le serveur pour les caractères non désirés, vous pouvez prendre le risque de ne pas effectuer cette vérification sur les données à partir d'une boîte de sélection, car l'utilisateur ne fait pas entrer n'importe quoi (juste choisit), mais une personne peut prendre Firebug ou certains dom éditeur et modifiez la valeur dans la boîte de sélection, alors vous êtes en difficulté. Donc, comme dit mai, sur l'ensemble de ses risques.

RedBMedia, Id-dire l'utilisation http://devzone.zend.com/tag/Security_Tips comme une ligne directrice. Naturellement, vous permettra de formuler votre propre approche moment donné, surtout si vous avez un test que vous travaillez avec qui arrive à casser le code.

cipher, je vous remercie pour cela: http://devzone.zend.com/tag/Security_Tips - Ce sont les types de ressources j'avais l'intention de se retirer de ce fil!