J'écris une application ASP.NET WebForms où j'appelle une page d'édition, un passage dans les données sur l'enregistrement à modifier à l'aide des paramètres de chaîne de requête dans l'URL.
J'aime: P>
http://myapp.path/QuoteItemEdit.aspx?PK=1234&DeviceType=12&Mode=Edit
7 Réponses :
Les variables de session peuvent également être manipulées, bien que pas aussi facilement. Quelle que soit l'authentification que vous utilisez sur votre site, vous devez également l'utiliser sur votre page cible. Sinon, vous serez ouvert à l'exposition de données que vous ne voudrez peut-être pas que vous avez découvertes.
Avez-vous des liens sur la manière dont il est possible pour un utilisateur de modifier les variables de session? Je n'ai pas entendu parler de cela
Une variable de session n'est vraiment qu'un cookie de session-scopée. Utilisez Firebug pour Firefox et allez à Cookies> Afficher les informations de cookie. De là, vous pouvez éditer des cookies pour le site actuel.
Vous n'êtes envoyé que deux cookies: une pour la sessionID (qui ne contient aucune valeur) et éventuellement une autre pour l'authentification des formulaires ... Les deux sont cryptés. Comment changeriez-vous des valeurs sur le client qui ne sont pas là?
Vous devez toujours valider avant la réelle exécution de l'action, surtout si vous passez les paramètres de la chaîne de requête. Pour la deuxième page, l'exécution que vous n'avez peut-être pas besoin autant de commentaires pour l'utilisateur depuis que vous n'avez pas besoin d'être gentils avec l'utilisateur s'il essaie de cirumvent votre sécurité, la manutention d'erreur devrait donc être beaucoup plus facile.
Passer les variables par session est acceptable mais IMHO, vous devez toujours valider les valeurs.
Vous pouvez effectuer ce qui suit pour rendre vos URL un peu plus sécurisées:
-Utilisez -user les GUID pour les clés primaires afin que les utilisateurs ne puissent pas deviner d'autres identifiants d'enregistrement
-Le mode Couls implicitement: GUID = EDIT, AUCUN GUID = NOUVEAU
et ..
- La validation du côté Server est la seule façon d'aller.
accepté, vous voudrez valider des autorisations sur la page cible, c'est le seul moyen d'être absolument sûr. En ce qui concerne la sécurité, la redondance n'est pas une mauvaise chose. Sécurisez votre base de données comme si vous ne faites pas confiance à la couche d'entreprise, sécurisez votre couche d'entreprise comme si vous ne faites pas confiance à l'interface utilisateur et sécurisez l'interface utilisateur.
D'accord, il n'y a pas de "assez sécurisé". Ne faites même pas confiance à un autre code complètement car il pourrait être un programmeur inepte (ou malveillant) qui apporte quelques modifications à l'une des couches supérieures (c'est-à-dire dans notre application, l'entrée est (malheureusement) SQL s'est échappée au début de la Script et il se passe qu'une valeur était nécessaire sans s'échapper, de sorte que la variable globale (de nouveau: tristement) n'a été inévitable ... Ouverture d'un trou pour l'injection SQL (comme la couche de DB ne vérifie plus, devinez que tout était échappé avant) ). Être paranoïaque aide.
Nous utilisons toujours QueryStrings afin que les enregistrements puissent être favorisés facilement, mais toujours valider à la fois dans les deux endroits, si vous vous écrivez le code de contrôle d'accès gentiment, il devrait simplement être un cas de réutilisation du code existant ...
Je crois que la pratique courante est de faire ce que vous évitez: sur la page d'origine, vous devez vérifier pour voir ce que l'utilisateur doit avoir des capacités à faire et afficher leurs options de manière appropriée. Ensuite, sur la page de travail réelle, vous devez vérifier à nouveau l'utilisateur pour vérifier qu'ils sont autorisés à y être, avec accès à cette tâche spécifique.
à partir d'un point de vue de la convivialité, c'est ce que l'utilisateur voudrait (le garde simple, leur permet de bloquer certaines pages, etc.) et la sécurité des deux pages est la seule façon de le faire.
Si vous ne voulez vraiment pas vérifier les droits d'accès sur la page cible:
Vous pouvez avoir récupéré le PK avec l'ID utilisateur, puis ajouter la valeur hachage à la chaîne de requête. P>
string hash = hashFunction(PK.toString() + UserID.toString());
C'est un site Web confronté au public, mais ce n'est pas ouvert au public. Nous émettons des noms de connexion et des mots de passe uniquement à nos clients. Vous pouvez donc appeler cela "invitation uniquement". Le domaine est hébergé sur un serveur d'accueil d'hébergement et si vous connaissez l'URL, vous pouvez vous surfer directement. Vous allez frapper la page de connexion. Cependant, pourquoi cela importerait-il? Votre suggestion semble tout aussi appropriée si public ou interne.
Je voulais juste dire que cette solution est probablement suffisante pour une application interne. Une page publique au monde peut justifier des mesures de sécurité supplémentaires que celle du chèque de hachage.
Merci à tous ceux qui ont répondu. Il est clair que la concentration de 100% est que vous devez valider les droits d'accès à la page cible, même si le flux de travail précédent a été éliminé pour limiter ce que l'utilisation peut voir / faire. Je dois apprendre à apprécier cette approche prudente.
Malheureusement, je n'ai pu marquer que sur une réponse comme acceptée, mais presque tout le monde aurait pu être marqué comme accepté.