1

What is the best way to determine if a request being made to my REST service originated from a web client. I know I can look at the user-agent, but my concern is that is very easy to spoof.

The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.

My site is built entirely in HTML and Javascript, any suggestions? Or is there a good way in Javascript to store a hidden username / password I can use just for my website, without it being displayed to the public?

Thanks, Adam

Adam
  • 725
  • 9
  • 17
  • So you have no control over the REST service? It sounds like this question is how to have the REST service make the determination, but the part of HTML/javascript is confusing. – James Black Aug 07 '11 at 01:00

2 Answers2

0

Anything put in the javascript can be found by using a debugger, such as Firebug, so even though it isn't visible to the user, it can be found by a user.

But, if the javascript first calls to a REST service to get an encrypted token, then the token, which has a timestamp encrypted within it, could be the password, so you then pass the username and token to call the rest of the REST services.

Your server could then validate that it had created the token and that it is not expired, and that the username matches what was encrypted in the token.

But, this depends on if you have any control over the REST service.

James Black
  • 41,583
  • 10
  • 86
  • 166
  • Using tokens makes sense. But what is there to stop someone from making that. initial request themselves and then using the response token ad well? – Adam Aug 08 '11 at 03:02
  • @Adam - If they can authenticate then they should be able to use the token, correct? So have them authenticate, get the token, then you store the token and use that in place of the password, as only your server could have generated the token. Anything you do in javascript can be duplicated in a program so you can only control so much of this. – James Black Aug 08 '11 at 10:56
0

The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.

This is not a good assumption. For the reasons you already gave (easily spoofed User-Agent), anyone could make a request to your application. You can even disable cross origin policy in firefox and chrome from the client side - so even if you could verify the request came from a browser, it's still possible to get around your security measures:

Disable same origin policy in Chrome

There are a couple of standard ways to implement security for this kind of service (as James mentioned, assuming you have control over the REST service).

  • Use Basic Authentication - If your application is communicating with the WCF service via HTTPS, basic authentication is probably the easiest method. See this question

  • If both your website and your WCF service are implemented using .NET, and your ASP.NET web application is using Forms Authentication, you could share the Forms Auth cookie and use that for authentication. See this question

Community
  • 1
  • 1
Justin Beckwith
  • 7,686
  • 1
  • 33
  • 55
  • I do have control over the REST service. My goal was to avoid using any service side language for the application. I was trying the build the entire application using JavaScript and HTML. I do use basic authentication for the users. Meaning once they log in all requests are made with their authentication. My concern is the initial request let's say to create an account. I could use a web account, but the that username and pass are exposed because of JavaScript. Maybe I I can't avoid using server side language. – Adam Aug 08 '11 at 02:58