Méthodes de page ASP.NET et JQuery AJAX Post & # 8211; Comment est-il vraiment sécurisé?

Question

J'ai un scénario suivant - et ce que je recherche réellement, c’est l’aide réelle de personnes réelles. Suggestions / solutions? S'il vous plaît.

J'ai un site extranet pour ex. www.foo.com (asp.net 3.5) J'utilise JQuery 1.3.2 pour appeler ValidateLogin PageMethods dans la page default.aspx (www.foo.com/default.aspx)

Le code ressemblera à ceci

$.ajax({
            type: "POST",
            contentType: "application/json; charset=utf-8",
            dataType: "json",
            url: "Default.aspx/ValidateLogin",
            data: '{' + arg + '}',
            success: function(data) {
                if (data.d != 0) {
                    window.location = "http://www.google.com";
                } else {
                    alert("Invalid UserName/Password.");
                    ResetLoginForm();
                }
            },
            error: function(xhr, status, error) {
                var strerror = xhr.status + error;
                alert("Error Communicating with Server:" + strerror);
                ResetLoginForm();
            }
        });

Le code est stocké dans un fichier js externe. Par exemple, default.js.

Étant donné que ce site Web est public, tout le monde peut télécharger le fichier default.js et ainsi consulter le code fourni ci-dessus.

Ma question est une fois que la personne a reçu l'URL suivante: "Default.aspx / ValidateLogin", il peut faire une demande au serveur et le serveur répondra fièrement à la demande.

Quelles sont mes options ici? Comment valider la demande? Comment puis-je empêcher ce type de demandes non autorisées?

Answer 1

Les demandes Web sont, de par leur nature même, publiques. Ils n'ont même pas besoin de regarder le fichier source. Ils pourraient simplement surveiller les requêtes HTTP et les rejouer (c'est très facile avec un outil comme fiddler par exemple).

Problème de limitation

Les solutions de limitation ne sont vraiment pas viables, bien qu’elles réduisent le nombre d’attaques. Le problème est qu'un adversaire peut écrire un script qui dure plusieurs jours. Là encore, il peut utiliser des mandataires pour envoyer des requêtes parallèles. Et si vous limitez par nom d'utilisateur l'adversaire peut réaliser un déni de service en tentant de fausses connexions sur des noms d'utilisateur légitimes. Lorsque l'utilisateur réel essaie de se connecter, il ne saura pas pourquoi il est verrouillé.

Solution

L’approche typique consiste à utiliser des clés nonce. Cela demandera du travail supplémentaire, mais cela atténuera le problème et ne sera recommandé que si vous anticipez vraiment une attaque d'attaques ou quelque chose du genre. Une version simplifiée de ce serait le client passe la clé de nonce en tant que paramètre de requête URI. La clé est d'abord attribuée par le serveur au client. Une fois la demande effectuée, le serveur valide que la clé nonce existe dans la base de données et autorise les demandes. Il supprime immédiatement la clé de nonce afin que l'utilisateur ne puisse pas faire une autre requête avec la même clé de nonce mais le serveur devra alors lui envoyer plus de clés de nonce.

La solution simplifiée consiste à autoriser uniquement les utilisateurs authentifiés à faire des demandes de service Web, mais comme vous concevez un système de connexion, cela ne tient évidemment pas.

Je ne m'inquiéterais pas à moins que vous n'ayez de vils adversaires.

Answer 2

Je suppose que vous avez exposé votre méthode Page charge la session. Par conséquent, vous pouvez définir une variable de session lors du chargement de la page, puis vérifier si elle existe lors de l'appel de la méthode. Ce n'est pas la chose la plus sûre au monde mais ça va aider.

Personnellement, je ne voudrais pas essayer de le rendre plus sécurisé - comme d'autres l'ont dit, les services Web sont par nature publics.

Answer 3

Je dirais qu'il n'y a pas de problème; Toutefois, vous souhaiterez probablement effectuer une limitation de taux pour empêcher les utilisateurs de l'essayer. brute le forçant.

Answer 4

Vous pouvez également mettre un captcha après 2 ou 3 échecs de connexion, ce qui vous évitera la force brutale.