hier, j'ai participé à une interview pour la postion de développeur PHP. Mon travail consistait à résoudre 15 questions assez simples. L'une des questions était de décider que le code de WEET semblable ci-dessous doit être traité comme dangereux. Je me suis trompé (comme il s'est avéré) et l'argumentation de l'autre personne de cette interview était assez surprenante (au moins pour moi).
code était quelque chose comme ça: P>
function someFunction($a)
{
echo $a * 4;
}
someFunction($_GET['value']);
registre_globals code> est activé, li>
- jamais. li>
ul>
Vous pouvez obtenir un point pour une réponse correcte et une seconde pour donner une bonne explication (argumentation) sur la réponse de réponse choisie. p>
Ma réponse était troisième: Ce code n'est jamais dangereux em>. Plus argumentation: parce que, c'est juste une équation simple forte>. Il n'y a pas d'opérations de fichier ou de base de données ici, aucun flux, protocoles, sans rien. C'est juste une équation. Rien d'autre. L'attaquant est incapable de faire quoi que ce soit de mal au script PHP, peu importe la requête de l'URL mal formée, il va essayer d'exécuter. Aucune chance. P> J'ai zéro point. Ni ma réponse n'était correcte, ni mon argumentation n'a été acceptée. La bonne réponse était la suivante: Ce code est toujours dangereux - vous devriez toujours fort> Escape, ce que vous avez obtenu de la requête URL. Em> p> Ma question est la suivante: Ce très bon point de vue? Devons-nous toujours toujours utiliser une règle de base, que tout ce qui est pris directement contre la requête est dangereux, sinon filtré, échappé ou sécurisé de quelque manière que ce soit? Cela signifie-t-il que j'enseigne à mes élèves une méthodologie de codage inverse, car lors de la première conférence PHP, ils écrivent un script pour calculer une zone de triangle et utilisent des params non filtrés non facétatifs de l'URL dans leur tâche? P>
Je comprends que la sécurité et l'écriture du code de sécurité devraient être une question de priorité la plus élevée. Mais, d'autre part, n'est-ce pas un peu coffre-code-fascisme em> (pardonnez-moi, si j'ai offensé quelqu'un) à menacer n'importe quel code dangereux, même si personne n'est capable de faire N'importe quel préjudice avec elle? p> ou peut-être que je suis complètement faux et que vous peut strong> faire des dommages sur la fonction qui fait écho à quatre, ce que vous avez donné à cela? P>
3 Réponses :
Le problème est que, plus tard, une personne peut modifier la fonction "quelquefonction" et faire plus que simplement la multiplier par 4.
La fonction en soi n'est pas dangereuse, mais la ligne: p>
someFunction($_GET['value']);
+1, Vérifiez également cette réponse .
Je suis d'accord avec l'exécution générale de la validation des intrants, mais je ne suis pas d'accord sur lequel il faut essayer de prédire ou d'anticiper les contextes futurs que le résultat sera utilisé ou comment une personne peut modifier le code à l'avenir.
@Rambocoder En tant que professionnel, vous devriez être censé anticiper des contextes futurs communs tels que «Le code peut changer afin de ne pas assumer que les données utilisateur sont en sécurité».
Bien que je suis généralement d'accord avec votre réponse, je suis également d'accord avec Coder Rambo Commentaire. Cela me rappelle une pensée, mon ami a: vous devriez toujours ajouter; Même à la dernière règle de CSS, parce que quelqu'un un jour peut vouloir ajouter quelque chose et ne pas voir qu'il n'y a pas; à la fin . Ne devienons pas paranoïaques.
@Trejder Protection contre les données utilisateur malveillantes est la programmation de base 101 non sur-paranoïa. Ce n'est pas une question difficile ou truc.
Par la paranoïa Je ne reflete pas au fait que nous devons protéger contre les données utilisateur malveillantes, mais à votre pensée à venir: peut-être une certaine fonction est refactore dans un autre fichier . Mais, comme je l'ai écrit, ce n'est que ma petite addition / commentaire, car je suis généralement d'accord avec votre réponse et votre point de vue.
En tant que professionnel, vous êtes censé résoudre les problèmes correctement. Il est fondamental que vous ne pouvez pas échapper à une valeur sans connaître le contexte dans lequel la valeur sera placée, car une évasion appropriée nécessite un contexte. Par exemple, échapper à une valeur pour l'insertion de la base de données, la sortie en tant que fichier HTML, sous forme de nom de fichier, ou en tant que commentaire EXIF intégré à une image binaire nécessitent tous des systèmes d'échappement différents et non interssers.
@Trejder Oui, cette situation exacte peut être une étirement, mais tous les créateurs de nouvelles choses devraient prendre en compte dans des ramifications générales facilement applicables de leur création. Si je construis une arme à feu, ce n'est pas un étirement de deviner que quelqu'un pourrait le pointer à leur pied dans le futur. Certaines choses que vous pouvez protéger contre et éviter, d'autres que vous ne pouvez pas raisonnablement vous attendre à attraper, mais simplement parce que vous ne pouvez pas protéger contre tous les résultats possibles, ne signifie pas ne pas protéger contre les médias impliqués (utilisateur Web Données dans ce cas) et pour vos futurs entretiens d'embauche, veuillez simplement supposer $ _GET est toujours dangereux.
@Ray: Je dois être d'accord avec vous. Merci pour un grand nombre d'informations.
N'ayant pas passé beaucoup de temps à jouer avec votre exemple de code, je ne dirai pas que cela pourrait être utilisé pour «faire du mal», votre fonction ne fonctionnera pas correctement, à moins que cela ne soit passé de la forme de nombre. À long terme, il est préférable d'échapper à votre code et de gérer des données erronées, puis attendez la journée lorsqu'un utilisateur sans méfiance place le mauvais type de valeur dans votre boîte et casse les choses. Je suis sûr que la société que vous avez interviewée pour la recherche de quelqu'un avec une habitude solide de veiller à ce que leur code soit complet et incassable.
SARN, je ne vais pas vous voter depuis que vous êtes un débutant et que vous n'avez pas beaucoup de points, mais oui, l'exemple du code est dangereux.
Vous étiez sur un emploi pendant une interview? Comme c'est intéressant.
Un conseil: si l'intervieweur donne un code et demande s'il est dangereux, si certaines variables sont présentes, dites toujours qu'il est dangereux, même si cela va à l'encontre de votre logique.
Dépend de votre implémentation de
$ _ obtenir . Mais c'est évidemment une question d'astuce. Lorsqu'il est présenté avec une implémentation spécifique, vous devez juger sur sa spécificité, non pas sur les généralisations ou les paramètres de serveur daté hypothétiques. Avez-vous des questions comme celle-ci?@Mario: Non! :] Seulement quatre ou cinq sur quinze! Mais oui, j'ai eu un petit mal de tête après cette interview! :]