Cette question peut être associée à une question subjective, mais ce n'est pas vraiment un.
Lorsque vous développez un site Web, vous devez connaître plusieurs points: les attaques XSS, l'injection SQL, etc. Il peut être très très difficile (et prendre beaucoup de temps à coder) pour sécuriser toutes les attaques potentielles.
J'essaie toujours de sécuriser mon application mais je ne sais pas quand arrêter.
Prenons le même exemple: un réseau social comme Facebook. (Parce qu'un site Web bancaire doit sécuriser toutes ses données.)
Je vois des approches:
Ne sécurisez pas XSS, SQL Injection ... Cela peut être réellement fait lorsque vous faites confiance à votre utilisateur: Back Terminer pour une entreprise privée. Mais assurez-vous ce type d'application?
Attaques sécurisées uniquement Lorsque l'utilisateur tente d'accéder à des données non propriétaires: c'est pour moi la meilleure approche.
sécuriser tout, tous, tous: vous sécurisez toutes les données (propriétaire ou non): l'utilisateur ne peut pas casser ses propres données et autres données utilisateur: c'est très long à faire et est-ce très utile? < / p>
Attaques communes sécurisées mais ne sécurisez pas les attaques très difficiles (car il est trop long de coder la comparaison des chances d'être piraté).
Eh bien, je ne sais pas vraiment quoi faire ... Pour moi, j'essaie de faire 1, 2, 4 mais je ne sais pas si c'est le grand choix.
Y a-t-il un risque acceptable pour ne pas sécuriser toutes vos données? Puis-je sécuriser toutes les données mais cela me prend double pour coder une chose? Quelle est l'approche d'entreprise entre le risque et le "temps est de l'argent"?
Merci de partager cela parce que je pense que beaucoup de développeurs ne savent pas quelle est la bonne limite.
Prenons un forum. Un thread peut être rédigé dans un forum où nous sommes modérateur. Ainsi, lorsque vous envoyez des données à la vue client, vous ajoutez ou supprimez le bouton "Ajouter" pour ce forum. Mais lorsqu'un utilisateur tente d'enregistrer un thread sur le côté du serveur, vous devez vérifier que l'utilisateur a le droit de le doter (vous ne pouvez pas faire confiance à la sécurité du client).
C'est un exemple très simple, mais dans certaines de mes applications, j'ai une hiérarchie de droits qui peut être très très difficile à vérifier (besoin de nombreuses requêtes SQL ...) mais en revanche, c'est Vraiment difficile à trouver le hack (les données sont pseudo cryptées dans la vue client, il y a beaucoup de données à modifier pour faire fonctionner le piratage, et le pirate informatique a besoin d'une bonne compréhension de mes règles d'application pour faire un piratage): dans ce cas, Puis-je vérifier que des trous de sécurité de surface (vraiment faciles de hack) ou puis-je vérifier des trous de sécurité très difficiles (mais cela diminuera mes performances pour tous les utilisateurs et m'avère longtemps à développer).
La deuxième question est la suivante: Peut-on "faire confiance" (pour ne pas développer de code dur et long qui diminue les performances) sur la vue client pour un hack très dur?
Voici une autre post parle de ce type de piratage: (Vérification de l'hibernate et de la collection) Question de sécurité: Comment sécuriser les collections hibernate revenir du client au serveur?
5 Réponses :
Toutes les applications doivent avoir un certain degré de sécurité. Vous ne demandez généralement pas de SSL sur des sites Web intranet, mais vous devez prendre soin des attaques SQL / XSS.
Toutes les données que votre utilisateur entre dans votre application devrait être sous votre responsabilité. Vous devez vous assurer que personne n'est pas autorisé à y avoir accès. Parfois, une information "non critique" peut poser un problème de sécurité très de sécurité, car nous sommes tous des paresseux.
Il y a quelque temps, un ami dirigeait un site Web de jeux. Les utilisateurs créent leurs profils, forum, tout ce genre de choses. Ensuite, un jour, quelqu'un a trouvé une porte ouverte d'injection SQL quelque part. Cet attaquant obtient toutes les informations utilisateur et mot de passe.
Pas un gros problème, hein? Je veux dire, qui se soucie d'un compte joueur dans un site Web? Mais la plupart des utilisateurs ont utilisé le même utilisateur / mot de passe à MSN, à la recherche de la grève, etc., devenez donc un gros problème très rapide.
La ligne de fond est la suivante: toutes les applications doivent avoir une certaine préoccupation de sécurité. Vous devriez jeter un oeil à Stride pour comprendre vos vecteurs d'attaque et prendre meilleure action.
Je pense qu'il est utile de distinguer entre prévenir l'injection de code et l'autorisation de données unis.
À mon avis, il suffit de quelques bonnes habitudes de codage pour éliminer complètement l'injection SQL. Il n'y a tout simplement aucune excuse pour cela.
L'injection XSS est un peu différente - je pense que cela peut toujours être empêché, mais il peut ne pas être trivial si votre application fonctionnait au contenu généré par l'utilisateur. Je veux simplement dire que cela peut ne pas être aussi trivial pour sécuriser votre application contre XSS tel qu'il est comparé à l'injection SQL. Donc, je ne veux pas dire qu'il est correct de permettre à XSS - je pense toujours qu'il n'y a pas d'excuse pour lui permettre, il est simplement plus difficile d'empêcher que votre application s'affrigne sur le contenu généré par l'utilisateur.
SO SQL Injection et XSS sont des questions purement techniques - le niveau suivant est l'autorisation: quelle est la manière dont une bouclier d'accès à des données n'était pas une entreprise de l'utilisateur actuel. Ici, je pense que cela dépend vraiment de la demande et je peux imaginer qu'il est logique de distinguer entre: "L'utilisateur x peut ne pas voir quoi que ce soit de l'utilisateur Y" vs "ne dérangeant pas l'utilisateur X avec les données de l'utilisateur y améliorerait la convivialité et la fabrication l'application plus pratique à utiliser ".
« Présentation des données » ne sont pas quelque chose qui ne devrait jamais être possible, par l'utilisateur autorisé ou quelqu'un d'autre. Je dépose ce sous « la validation et à l'assainissement des entrées utilisateur », et il est quelque chose que vous devez toujours faire. S'il y a juste la possibilité d'un utilisateur « casser vos données », il va arriver tôt ou tard, vous devez valider toute entrée dans votre application. Échapper requêtes SQL va dans cette catégorie aussi bien, qui est à la fois un problème de sécurité et de l'assainissement des données.
La sécurité générale dans votre application doit être solide, peu importe. Si vous avez un système de gestion des utilisateurs, il doit faire son travail correctement. C'est à dire. les utilisateurs qui ne sont pas censés quelque chose d'accès ne devrait pas être en mesure d'y accéder.
L'autre problème, tout droit attaques XSS, n'a pas grand-chose à voir avec « données », mais la rupture avec un accès non autorisé aux données. Ceci est quelque chose qui dépend de l'application, mais si vous êtes au courant de la façon dont les attaques XSS fonctionnent et comment vous pouvez les éviter, est-il une raison pas ?
En résumé:
Il suffit de faire une habitude de coller aux meilleures pratiques va un long chemin à faire une application sécurisée, et pourquoi pas vous? :)
Vous devez voir les applications Web que l'architecture client-serveur qu'ils sont. Le client peut poser une question, le serveur donne des réponses. La question est juste une URL, parfois avec un peu de données jointes POST.
Puis-je avoir Votre sécurité ne peut compter que sur le client ne demande pas la bonne question. Jamais.
/ forum / view_thread / 12345 / s'il vous plaît?
Puis-je ce POST $ data / forum / new_thread / s'il vous plaît?
Puis-je avoir / forum / admin / delete_all_users / s'il vous plaît?
Le serveur a toujours besoin d'évaluer la question et la réponse Non si nécessaire.
Je pense que vous devriez essayer de sécuriser tout ce que vous pouvez, le temps passé à faire cela n'est rien comparé au temps nécessaire pour réparer le désordre effectué par une personne exploitant une vulnérabilité que vous avez laissée quelque part.
La plupart des choses de toute façon sont assez faciles à réparer:
Bien sûr, il y a plus d'attaques de détournement de la session, mais ce sont les premières choses que vous devriez regarder.
Je ne suis pas sûr de bien comprendre vos exemples, en particulier ce que vous entendez par «confiance sur la sécurité du client». Bien sûr, toutes les pages avec accès restreint doivent commencer par un chèque pour voir si l'utilisateur dispose de droits de voir le contenu et éventuellement s'il (ou elle) a le niveau de privilège correct: il peut y avoir des actions disponibles pour tous les utilisateurs et certains d'autres seulement disponibles pour un groupe plus restreint (comme modérateurs dans un forum). Tous ces contrôles doivent être effectués du côté serveur, car vous pouvez jamais confiance ce que le client vous envoie, étant donné des données via Get, Publier et même les cookies. Aucun de ceux-ci n'est facultatif.
Je préfère personnellement tout sécuriser à tout moment. Il pourrait s'agir d'une approche paranoïaque, mais lorsque je vois des tonnes de sites Web partout sur Internet, qui sont vulnérables à l'injection SQL ou même des attaques beaucoup plus simples, et elles ne sont pas dérangées de le réparer jusqu'à ce que quelqu'un "piratant" et voler leurs données précieuses, elle me rend presque effrayé. Je ne veux pas vraiment être celui qui a été responsable des mots de passe fuite ou d'autres informations utilisateur.
Demandez simplement à quelqu'un d'expériences de piratage pour vérifier votre candidature / site Web. Cela devrait vous donner une bonne idée de ce qui ne va pas et de ce qui devrait être mis à jour.
Vous voulez avoir une bonne face API ACL. Il y a quelques jours, j'ai vu un problème où un gars avait obtenu chaque interface utilisateur, mais le site Web était vulnérable à travers Ajax, juste parce que son API (où il envoiait des demandes), il suffit de faire confiance à chaque demande à vérifier. Je pourrais essentiellement tirer une base de données entière via ce bogue.
devrait être un wiki communautaire