0
votes

Comment nier les demandes de post HTTP d'autres applications?

Je fais des vérifications de sécurité sur mon application Web qui a hébergé dans .net IIS, je parviens à savoir qu'il est possible d'accéder à mes pages Web via une méthode de post HTTP à partir de toute autre application, nous devons nier ces demandes qui viennent via la méthode de post http, y a-t-il une façon possible de nier cela?

de l'exemple ci-dessous du code 'www.example.com' est mon site Web et "récepticule.aspx" est un Page Web qui a accédé à une autre application Web (par exemple: www.hacker1.com) via httpClient, comment je peux empêcher cela?

code écrit sur (www.hacker1 .com) xxx

J'ai besoin de refuser les demandes de courrier http à partir d'autres applications Web à mes pages Web, mais je peux permettre aux demandes de navigateur < / p>


3 commentaires

Puis-je savoir quelle technologie et quelle plate-forme utilisez-vous sur votre serveur?


Si vous utilisez un système d'autorisation tel que l'identité ASP.NET. Il suffit de mettre [Autoriser (Roles = "Admin ou rôle que vous souhaitez autoriser")] En tant qu'attribut sur la méthode postale qui devrait la rendre bien


En supposant que "toute autre application" signifie toute autre application il n'y a aucun moyen. Si vous pouvez réduire vos besoins, cela peut devenir responsable.


4 Réponses :


-1
votes

Vous pouvez définir l'origine spécifique dans Web config de l'endroit où vous souhaitez autoriser une demande. Vous pouvez définir le protocole HTTP pour votre application dans Web config, comme celui-ci xxx

ici Cet exemple de code contient * pour la valeur d'origine qui signifie qu'il permettra à toutes les demandes d'application afin que vous puissiez transmettre la demande de votre demande. URL ici au lieu de *.


0 commentaires

0
votes

Si vous souhaitez simplement bloquer vos demandes en fonction de n'importe quel paramètre sur demande, que dans votre cas est Verbes HTTP , vous pouvez facilement le faire sur IIS via Ceci


1 commentaires

Merci Mohamman, j'ai ajouté plus d'informations sur ma question, s'il vous plaît jeter un oeil.



0
votes

Vous pouvez refuser les demandes postales, mais il n'y a pas de manière raisonnable - sans ajouter d'authentification - à raconter quelle application ces demandes provenaient, ce qui signifie que vous ne serez pas en mesure de permettre aux demandes postales de votre application cliente, mais pas d'autres.

Sécurisez correctement le point final en utilisant une sorte d'authentification.

Si vos points d'extrémité ne sont censés être consultés que par votre application, pourquoi les rendez-vous accessibles au public en premier lieu? S'il s'agit de la la même application , appelez simplement les fonctions directement. S'il s'agit d'une application distincte, utilisez des règles de pare-feu pour vous assurer qu'elle ne peut être accédée que par localhost (par exemple).


0 commentaires

1
votes

Vous ne pouvez nier que la demande postale pour tout le monde - vous ne pouvez pas les refuser de manière sélective. Toute protection que vous mettrez en place (comme la vérification du référent) Site Hacker peut facilement se moquer. Une protection correcte est de forcer l'authentification des utilisateurs et n'autorise qu'un utilisateur authentifié de faire une telle demande.

I.e. Avoir terminal identifiant login.aspx - nom d'utilisateur / mot de passe d'échange pour authentification Cookie / ou jeton et récepticule.aspx doit vérifier si le cookie / jeton authentification est présent.

BTW. Le sujet d'authentification est complexe et ASP.NET/IIS possède de nombreux modèles. Il est toujours facile de le faire mal. Donc, si vous n'êtes pas sûr, il est préférable de déléguer l'authentification à OAuth / Utilisez un des grands fournisseurs, vous faites confiance à HTTPS: //fr.wikipedia.org/wiki/list_of_oauth_providers


3 commentaires

Merci Ondrej, j'ai eu votre point, dans ce cas si httpClient a utilisé dans l'application de la console, le serveur de récepteur compte tenu de la demande à partir duquel navigateur (c'est-à-dire Mozila ou Chrome)?


@ Rajeshkanna.s - Le navigateur s'identifie avec une chaîne d'agent d'utilisateur. Ceci est connu en-tête HTTP. Cependant, cela peut être simplement moqué comme httpclient.defaultrequestheers.add ("utilisateur-agent utilisateur", "Mozilla / 5.0 (Windows NT 10.0; Win64; x64) Applewebkit / 537.36 (KHTML, comme Gecko) Chrome / 60.0.3112.113 Safari / 537.36" ); - Maintenant, Server pensera que votre application de console est un navigateur chrome.


Ok, merci Ondrej.