Quel type d'entrée est le moins vulnérable à une attaque?

Question

Quel type d'entrée est le moins vulnérable aux attaques XSS (Cross-Site Scripting) et à l'injection SQL.

PHP, HTML, BBCode, etc. J'ai besoin de savoir pour un forum que j'aide un ami à mettre en place.

Answer 1

Nous devons en savoir plus sur votre situation. Vulnérable comment? Certaines choses que vous devriez toujours faire:

• Échappez les chaînes avant de les stocker dans une base de données pour vous protéger des injections SQL
• HTML encode les chaînes lors de leur réimpression à l'utilisateur à partir d'une source inconnue, afin d'éviter les codes malveillants HTML / javascript

Je n'exécuterais jamais php fourni par un utilisateur. Les codes BBCode / UBBCode conviennent, car ils sont convertis en HTML sémantiquement correct, bien que vous souhaitiez peut-être examiner les vulnérabilités XSS liées aux balises d’image malformées. Si vous autorisez la saisie HTML, vous pouvez ajouter certains éléments à la liste blanche, mais il s'agira d'une approche compliquée, sujette aux erreurs. Par conséquent, compte tenu de tout ce qui précède, je dirais qu’utiliser une bonne bibliothèque BBCode sur étagère serait votre meilleur choix.

Answer 2

(Je viens de poster ceci dans un commentaire, mais il semble que quelques personnes aient l'impression que les listes de sélection, les boutons radio, etc. n'ont pas besoin d'être nettoyés.)

Ne comptez pas sur la sécurité des boutons radio. Vous devez toujours nettoyer les données sur le serveur. Les gens peuvent créer une page html sur leur ordinateur local, créer une zone de texte portant le même nom que votre bouton radio et rediffuser ces données.

Un utilisateur plus expérimenté pourrait utiliser un proxy tel que WebScarab , et seulement ajustez les paramètres au fur et à mesure de leur publication sur le serveur.

Une bonne règle empirique consiste à toujours utiliser des instructions SQL paramétrées et à toujours échapper aux données générées par l'utilisateur avant de les insérer dans le code HTML.

Answer 3

Aucun d'entre eux sont. Toutes les données attendues sur le serveur peuvent être manipulées par ceux qui en ont la connaissance et la motivation. Le navigateur et le formulaire que vous vous attendez à utiliser ne sont que l’un des moyens de soumettre des données à votre serveur / script.

Familiarisez-vous avec le sujet XSS et les problèmes associés

• http://shiflett.org/articles/input-filtering
• http://shiflett.org/blog/2007 / mar / permettre-html-and-prevent-xss

Answer 4

N'importe quel type de booléen.

Vous pouvez même filtrer les entrées non valides assez facilement.

; -)

Answer 5

Il existe de nombreux analyseurs de code BB qui nettoient les entrées pour HTML, etc. Si aucun paquet n'est disponible, vous pouvez consulter l'un des progiciels de forum open source pour obtenir des conseils.

Le code BB est logique car il s'agit du "standard". pour les forums.

Answer 6

L'entrée la moins vulnérable aux attaques est la "non entrée".

Posez-vous la bonne question?

Answer 7

Pour l'amour d'Odin, ne désinfectez pas les entrées. N'ayez pas peur des utilisateurs qui saisissent ce qu'ils veulent dans vos formulaires.

Les entrées utilisateur ne sont pas intrinsèquement dangereuses. La réponse acceptée conduit à ce type d'interfaces Web, comme celle de ma banque, où M. O'Reilly ne peut pas ouvrir de compte, car il a un caractère illégal à son nom. Ce qui est dangereux est toujours la manière dont vous utilisez les entrées de l'utilisateur.

La bonne façon d'éviter les injections SQL consiste à 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 appropriées de manière rigoureuse (myslq_escape et al). La bonne façon de prévenir les attaques XSS n’est jamais quelque chose comme striptags (). Echappez tout - en PHP, quelque chose comme htmlentities () est ce que vous cherchez, mais cela dépend si vous exportez la chaîne sous forme de texte HTML, d'attribut HTML, ou à l'intérieur de Javascript, etc. Utilisez le bon outil pour le bon contexte. Et n'imprimez JAMAIS l'entrée de l'utilisateur directement sur la page.

Enfin, jetez un coup d'œil aux 10 principales vulnérabilités des applications Web et prenez les mesures qui s'imposent pour les prévenir. http://www.applicure.com/blog/owasp-top-10-2010