Quel type d'entrée est le moins vulnérable aux attaques de type Cross-Site Scripting (XSS) et SQL Injection.Quel type d'entrée est le moins vulnérable aux attaques?
PHP, HTML, BBCode, etc. Je dois savoir pour un forum que j'aide un ami mis en place.
Nous avons besoin d'en savoir plus sur votre situation. Vulnérable comment? Certaines choses que vous devriez toujours faire:
Je n'exécuterais jamais le php fourni par un utilisateur. BBCode/UBBCode sont bien, car ils sont convertis en html sémantiquement correct, bien que vous pouvez vouloir regarder dans les vulnérabilités XSS liées à des balises d'image malformées. Si vous autorisez l'entrée HTML, vous pouvez ajouter certains éléments à la liste blanche, mais ce sera une approche compliquée qui risque d'entraîner des erreurs. Donc, étant donné tout ce qui précède, je dirais que l'utilisation d'une bonne bibliothèque BBCode serait votre meilleur pari.
Veuillez ne pas échapper les chaînes pour vous protéger contre les injections SQL. Utilisez des instructions préparées avec des espaces réservés. –
HTML + HTML Purifier est un bon pari. – TRiG
Il y a beaucoup de parseurs de code BB qui nettoient l'entrée pour HTML et ainsi de suite. Si aucun paquet n'est disponible, vous pouvez consulter l'un des logiciels du forum open source.
Le code BB a du sens car c'est le "standard" pour les forums.
Je veux juste noter qu'il est important que le BBCode lui-même ne soit pas une solution - c'est l'analyseur qui empêcherait l'injection XSS et SQL. Le fait que la fonctionnalité de texte enrichi est gérée par le balisage BBCode est complètement hors de propos. –
L'entrée qui est la moins vulnérable aux attaques est la "non-entrée".
Posez-vous la bonne question?
N'importe quel type de booléen.
Vous pouvez même filtrer des entrées non valides assez facilement.
;-)
if (entrée! = Bool.FileNotFound) // C'est sûr. http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx –
Aucun d'entre eux ne l'est. Toutes les données attendues sur le serveur peuvent être manipulées par ceux qui ont les connaissances et la motivation. Le navigateur et le formulaire que vous attendez des utilisateurs ne sont que l'un des moyens valables de soumettre des données à votre serveur/script.
S'il vous plaît vous familiariser avec le sujet de XSS et les questions connexes
(je viens de publier cela dans un commentaire, mais il semble que quelques personnes sont sous l'impression que les listes de sélection, les boutons radio, etc. n'ont pas besoin d'être nettoyés.)
Ne comptez pas sur les boutons radio étant sécurisés. Vous devriez toujours désinfecter les données sur le serveur. Les utilisateurs peuvent créer une page html sur leur ordinateur local et créer une zone de texte portant le même nom que votre bouton radio, et récupérer ces données.
Un utilisateur plus avancé peut utiliser un proxy tel que WebScarab et modifier les paramètres au fur et à mesure qu'ils sont renvoyés au serveur.
Une bonne règle de base est de toujours utilisation instructions SQL paramétrées, et toujours données échappement générées par l'utilisateur avant de le mettre dans le code HTML.
Dans Opera, vous pouvez également modifier le code HTML ou JS d'une page, ce qui modifie tout ce que l'utilisateur a ajouté pour vous empêcher de faire quelque chose. Très cool à des fins de test, mais il est facile de gâcher les choses. –
Oui, Firebug dans Firefox le permet aussi. – pkaeding
Pour l'amour d'Odin, ne désinfectez pas les entrées. N'ayez pas peur que les utilisateurs entrent ce qu'ils veulent dans vos formulaires.
L'entrée utilisateur n'est pas intrinsèquement dangereuse. La réponse acceptée mène à ces types d'interfaces web comme celle de ma banque, où M. O'Reilly ne peut pas ouvrir un compte, parce qu'il a un caractère illégal à son nom. Ce qui est dangereux, c'est toujours comment vous utilisez l'entrée de l'utilisateur.
La meilleure façon d'éviter les injections SQL est d'utiliser des instructions préparées. Si votre couche d'abstraction de base de données ne vous permet pas de les utiliser, utilisez les fonctions d'échappement correctes rigoureusement (myslq_escape et al). La manière correcte d'empêcher les attaques XSS n'est jamais quelque chose comme striptags(). Échapper à tout - en PHP, quelque chose comme htmlentities() est ce que vous cherchez, mais cela dépend de si vous publiez la chaîne dans le texte HTML, un attribut HTML ou Javascript, etc. Utilisez le bon outil pour le bon contexte. Et ne JAMAIS simplement imprimer l'entrée de l'utilisateur directement sur la page. Enfin, jetez un oeil aux 10 principales vulnérabilités des applications Web, et faites le bien pour les prévenir. http://www.applicure.com/blog/owasp-top-10-2010
Vulnérable à quoi exactement? Le piratage? Cross-site scripting? Injection SQL? – wcm
Scrutation de sites croisés et injection SQL. Désolé, je pensais que je l'ai mentionné dans la question (je me suis distrait et quand je suis revenu, j'ai appuyé sur submit sans vérifier ce que j'avais écrit). – Iwasakabukiman
Ce serait génial si vous pouviez éditer la vraie question et mettre ce genre de choses là-dedans. Pouvez-vous également clarifier ce que vous entendez par "entrée"? Ma première réaction était que vous vouliez dire quel type de contrôle de formulaire était le moins vulnérable, auquel cas je devrais dire le bouton radio! –