I'm using jquery ajax to fetch data from an asp.net webservice. I'm wondering how I can secure it and have it work with jquery ajax. The service is part of my web application and to access it you have to be logged in to the application. However I'd like to further secure it. For example a consultant looking up all their customers in an autocomplete box is good, but they can instead send in some other consultant's id. What's the best way to secure this?
I've looked at this article here http://msdn.microsoft.com/en-us/library/w67h0dw7%28VS.71,classic%29.aspx . However, I don't know how to make this work with jquery ajax. Any help would be appreciated.
As far as I understand you want to make sure that you know the identity of the person using your service. If the web service is part of your application this should not be a problem by using cookies (assuming the web service is on the same domain as the site). See this e-book for some ideas.
Otherwise you could hand out temporary identifiers to the logged in members of your site which would be used in the webservice calls - this way even if the identifier is stolen, it can only be used for a limited time.
I made it more secure by using encryption. I encrypt the consultant's id when passing it via ajax, and decrypt it on the server side. Obviously I do the encryption on server side and pass it to client when rendering the page. And then ajax makes the call using that encrypted id.
Related
These are the criteria:
My users are unauthenticated.
My app is a single page web app (written in JavaScript) that uses RESTful web API endpoints to fetch data from my own server.
Objective: I'd like to constrain the web API to only allow requests from my own app, without requiring users to authenticate. Are there existing techniques for this?
The issue is that since the web app's code and the requests made by it are transparent to the client it can't hold a secret for authenticating with the server.
I thought about creating single-use access tokens on the server side, then use those from the client side for the API calls. Now this would make it harder to do requests from the outside, but still you could make requests if you fetch this token from the original website first (even if you'd have to do it for every request).
If it matters I'd implement this with an ASP.NET MVC website and ASP.NET Web API endpoints.
Similar to this question but not entirely the same.
Thanks in advance.
I asked pretty much the same question a couple of years ago, and for unauthenticated users, some kind of token is pretty much going to be your only option. It doesn't make it impossible to get unauthorized access to your API, but does make it a little more painful.
I took a slightly different approach in my solution, using 2 cookies to protect some anonymous GET requests. One of them was the anonymous identification cookie, which was used as an encryption salt for another custom cookie given to the page that delivered the javascript. Only when the API request received both of these cookies and the decrypted result was satisfactory did I allow the WebAPI to respond. But like I mentioned, this only makes it more painful to gain access outside of the javascript app, not impossible.
Here is a reference for using tokens in WebAPI: http://codebetter.com/johnvpetersen/2012/04/02/making-your-asp-net-web-apis-secure/
Let's assume that client wants to be a new user(sing up) with using iphone/ipad application. I need to add this new user record in to MSSQL database in my host. This request should come to my asp.net pages, and then i need to reply to client. I was using this:
www.exampleWebSite.com/registerUser.aspx?newUserEmail=aaa#aa.com&newUserPassword=123
and then i can return result with JSON like this:
{
"processResult":"True",
"processMessage":"sign up is done"
}
it works like this but i know this is not good for security, right?
by the way, i can return all values(from mssql database) and all CRUD process from my asp.net web site. (.net 4.0) i must use this.
so first question, what is the best way for this? using rest api?
second question, how can i send the data? (client side is ios)
third question, how can i get the data? (host side is asp.net c#)
fourth question, can i develop rest api with visual studio 2010? or do i need higher version?
thanks!!
Several ways to do it but I can go over a few points
Make it a POST rather than a GET as you are doing it in the querystring. This is an idealistic approach, there's nothing stopping you from putting the username and password in the querystring but it's nicer if you put the registration info in the body.
Make it HTTPS and ensure, in the client, that you trust the certificate that the server presents. This allows you to maintain an SSL connection between the client and the server without someone snooping in on the body.
You may want to consider making your JSON response more meaningful. By virtue of it being a 200 response, you can imply that processing was successful. You can return a 401 or 500 if the processing was unsuccessful. The JSON response could simply return OK or a user token that the client stores and uses to communicate with your server.
The MVC Web API is a great framework for building RESTful web services in ASP.NET. See instructions here for VS 2010.
As for getting the data, you could use the generated token in each request to get user specific information; you would need to store that generated token upon user registration in a database against the user.
As a further topic, you may also want to, at least, read up on OAuth and implementing OAuth in your Web API. This would involve performing the login on your own website but giving the mobile client a secret token to use when communicating with your API; the token can also expire every, say, 30 minutes and you would keep reissuing new tokens for that user. However, depending on the nature of your audience and size of your application, you may not want to do this and just having a 'static' token for each user suits your purposes.
Wondering about how to do the following efficiently, securely, and in a fashion that won't have us tearing our hair out because of overcomplication: we have an ASP.Net site that uses forms authentication and would like to implement some WCF restful web services that can be called from the first site, provided the user calling them has been authenticated.
We'd like to host the WCF RESTful service in a different web site from the ASP.Net site. Both sites will be in the same domain (my-domain.com for instance).
I've been reading up on the various bindings in WCF and am not sure if webHttpBindings are the way to go here (they being the most REST-friendly, but can they accommodate forms-authenticated users?)
I'm looking for suggestions and references as much as code, but I'd love to know where to start and what to look for, what's possible and what isn't.
Every time I read about WCF authentication it seems to inevitably sluice into discussions about WS-security and X509 certificates, and I don't know that I need all that for what I'm doing? What I'm really looking to build is a series of WCF restful services that only respond to forms-authenticated users. If that's not possible without diving deep into WS-Security and X509 then so be it, but I'd like to keep it as simple as possible.
Note: I asked a somewhat similar question about a month ago, but have decided to go with forms authentication.
If you are not calling your WCF services from the browser, then you don't even need to secure them. Just call them from your ASPX code to a non-public site that hosts WCF. Or use X509 certs in a server-to-server mode.
If you do plan to call them from the browser, then things get more complicated. In this case, you may want to ditch WCF and look at with Web API included in the MVC 4 beta release to build your REST services.
http://www.asp.net/web-api
Have your javascript generated from the code behind. If Page.User.IsAuthenticated, render the ajax script. If not, render javascript that alerts the user that they need to be logged in. If you don't want the user cutting the javascript out of the browser source and running it later, when they are not authenticated, you will need to generate a token based on the session ID, that can be passed between the site and the service.
I want to create an internal website, preferably in asp.net, that uses ajax calls for performing all operations.
The requirements are that the site should use windows domain authentication (to act as a single-sign-on solution) for verifying which user is sending the request. What is the best way to accomplish this in a secure fashion? I am open to a solution using https or cookies or anything else feasible.
( I would prefer regular ajax using jquery since I havent used asp.net ajax but if that solves some issues more easily, then let me know)
The current way I am doing this (not through ajax) is disabling anonymous access in iis and then getting the logged in username from asp.net, but this requires the site to perform postbacks, etc which i want to avoid.
An Ajax request is not different from any other HTTP request when it comes to authentication.
Your user will most likely be authenticated when they access the index of your site. Any subsequent request, Ajax or not, will be authenticated. There is nothing special to do, and your jQuery code will look just like what it normally looks.
Windows authentication is checked on every request.
How this is checked depends which authentication method /provider is enabled and supported on the server (kerberos, ntlm, custom, etc)
Credentials are automatically sent over under certain rules (I believe intranet trusted for IE, I dont recall what else outside of that).
Firefox will prompt you if I recall every time.
Check out:
http://www.winserverkb.com/Uwe/Forum.aspx/iis-security/5707/IIS-6-0-Windows-Authentication-401-Every-Request
The important thing to note is the browser and server will take care of this and prompt the user when necessary.
Also to note is I highly highly suggest ALL traffic is under an SSL connection at this point to prevent sniffing and credential stealing/token stealking (such as is extremely easy for basic auth)
You can enable this protection inside of IIS and use all file permissions or you can control this in your web applications web.config by enabling windows authentication. How this is accomplished though depends on your server config (kerberos support, etc)
You should absolutely:
Use an https connection to transmit username and password
Authenticate on the server side, with asp.net
Leverage the asp.net session to as great an extent as possible.
If you're not familiar with ASP.Net ... well, consider this a good opportunity to learn :)
jQuery is great, but it's just a tool. In this case, it's probably not the best tool for this particular job.
IMHO...
I am maintaining a public website (no authorization required) that uses web services over https to perform various operations. Most of the calls to the web services are invoked from javascript.
What has recently occurred to me is that a malicious hacker could, if he/she chose to, call the webservices directly in an attempt to play havoc with the system.
In reality, there is not much damage they could do, but in practice these things are difficult to predict.
Bearing in mind that the web service calls will be exposed in javascript code (which is available to the client) what is the best approach I could use to prevent unauthorized and/or malicious access to the web services.
Sadly, I can't just restrict access by IP, as there are windows forms-based client applications out there which also interact with the web services.
Using windows authentication may be difficult, as these client apps can be run from anywhere in the world and the users are not part of any specific AD Group - or even domain for that matter.
I'd appreciate any suggestions, bearing in mind the two different classes of access and the exposure of the javascript code.
Anything called by javascript can be mimicked easily by a malicious user who has the right to use that javascript. I would suggest modifying the page to use a more server-side solution. Leave AJAX to stuff that can't be easily exploited.
Preventing an unauthorized user is MUCH easier than supporting full public access. If you drop a time-expiring guid on the user's cookies, tied to the individual user, that gets sent as one of the arguments to the Web Service, you have an extra, generally difficult-to-break, layer to the application.
Anyone who has access to execute the javascript, though, should have no trouble piecing it together. Someone who has no access to the javascript can probably be kept from accessing the Web Service easily.
It takes a bit of doing, but if your page is also ASP.net you can set up a shared session, turn on the EnableSession attribute on your webservice and use session data to secure the session. An overview can be found here: http://blogs.lessthandot.com/index.php/WebDev/ServerProgramming/ASPNET/sharing-asp-net-session-state-between-we
This would necessitate a different "version" of the service for your windows apps to consume.