Asp.net Webservice - secure web service call using jquery AJAX

Question

I want to use web services with Ajax. What is the best way to ensure security when calling webservice using ajax? I want to protect against remote calling an application.

I have the following webservice , for example:

[WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [System.ComponentModel.ToolboxItem(false)] [System.Web.Script.Services.ScriptService] public class Users : System.Web.Services.WebService { [WebMethod] public List<User> GetUsers() { List<User> listUsers = new List<User>(); User user = new User(); user.Id = 1; user.Name = "John"; User user2 = new User(); user2.Id = 2; user2.Name = "Martin"; listUsers.Add(user); listUsers.Add(user2); return listUsers; } } } 

I call webservice using jquery ajax:

 <script type="text/javascript"> $(function () { getUsers(); function getUsers() { $.ajax({ type: "POST", url: "Webservices/Users.asmx/GetUsers", data: "{}", contentType: "application/json; charset=utf-8", dataType: "json", success: function (response) { var users = response.d; $.each(users, function (index, user) { console.log(user.Name); }); }, failure: function (msg) { } }); } }); </script> 

Answer 1

There is no such thing as a better way, and the answer is always it depends , although it is very useless. For example, you can use forms authentication . If the web application using the web service and the web service is part of the same ASP.NET application , the browser can seamlessly send a form authentication ticket (cookie) for each call to the web service.

In the configuration file you can have

 <authorization> <deny users="?" /> </authorization> 

This will restrict access to anonymous users and will also cover web services. In other words, if the user does not log in and does not receive a valid cookie with a ticket, the service cannot be used. Of course you must HTTPS . Otherwise, any of them may receive a cookie in the headers and call your service.

Finally, it is impossible to ensure that no one calls the web service outside of your application in the absolute sense. The above approach ensures that none of them visit your service. But there is no way to guarantee that a valid user calls the service directly outside of your application, since the caller of the web service is JavaScript, and any security that you create in JavaScript can be easily understood by the user by looking at the script or even looking at traffic from and to the browser. Any end user who is a bit technical can play requests or modify requests and send them to the web service using valid credentials.

EDIT: -

Here is the more detailed information you are looking to enable FormsAuthentication.

(1) In Web.config , under <system.web> , make sure you have this.

 <authentication mode="Forms"> <forms loginUrl="Login.aspx" defaultUrl="~/" /> </authentication> <authorization> <deny users="?" /> </authorization> 

This ensures that all unauthenticated (anonymous) users are redirected to Login.aspx.

(2) Enter Login.aspx login logic to get the user ID and password and check them against the database or something else. After successful authentication, that is, the user enters the identifier and password that match what you have in the database, maybe in the handler of the click of the login button, set the ticket.

 protected void Button1_Click(object sender, EventArgs e) { // Do all your login logic here // once user ID and password entered by the user are okay, call this string ticket = FormsAuthentication.Encrypt( new FormsAuthenticationTicket("userId", false, 15)); HttpCookie FormsCookie = new HttpCookie( FormsAuthentication.FormsCookieName, ticket) { HttpOnly = true }; HttpContext.Current.Response.Cookies.Add(FormsCookie); } 

(3) Add PrincipalPermissionAttribute to a web method like this.

 public class Users : System.Web.Services.WebService { [PrincipalPermissionAttribute(SecurityAction.Demand)] [WebMethod] public List<User> GetUsers() { // Same code as what you have now } } 

If you go to any page, you will be redirected to login.aspx, where you will need to enter a user ID and password and login. When you enter the file, a forms authentication cookie is created and recorded. From now on, all requests to your application will be loaded into a cookie (the browser will do this for you). Without logging in, if you go to the web service directly, you will still be redirected to the login page. As I mentioned in my initial answer, a registered user, however, will have access to the web service directly. If JavaScript can do something, the user can do the same.

BTW, web services (asmx) - Deprecated technology.

Answer 2

This is a very important topic for discussion. There are many ways to do this.

We personally use the Service Stack for the API and use the key when accessing the API. The key is a guide that remains the same for the client and server. If the Client and the server are the same system, then there will be no problem sending the key.

Detailed protection methods are provided here. http://www.stormpath.com/blog/secure-your-rest-api-right-way http://codebetter.com/johnvpetersen/2012/04/02/making-your-asp-net-web-apis -secure /

Also for a further example, Creating a Secure Public API with PHP / MYSQL

Answer 3

One thing you can do to help prevent calls outside the browser is to put a one-time token on your page when you create it, and then publish it during an AJAX call. A simple implementation would be a database table with a bunch of random values ​​(maybe 32 alphanumeric or similar). When you create a page, extract one of the values ​​from the table and place it on your page - when you create an AJAX form message, specify this value.

On the server side, verify that the value exists in the table, and then remove it from the table.

If this service is called again with this value, it will fail because the value is no longer in the table.

This means that in order to create a valid token, you must first get the page, and then use this token only once.

You can add additional checks there, such as IP address, user agent, cookie values, expiration dates, etc., and also do things like hashing values ​​using a secret key or other obscurity security methods.

In the end, as Badri points out, all of this can be faked if someone really wants to, by simply manually creating the HTTP request that the browser is about to make to make an AJAX call. The best thing you can do is make sure that only valid users can call the service (regardless of the client’s technology used), and this is achieved through the authentication of traditional forms.