CODEWITHSUNDEEP
asp.netjavascriptajaxweb-servicessecurity
Andrew Rollings
Andrew Rollings

Reputation: 14551

Least intrusive way of securing a web service?

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.

Upvotes: 0

Views: 464

Answers (2)

AlexCuse
AlexCuse

Reputation: 18296

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.

Upvotes: 2

user54650
user54650

Reputation: 4426

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.

Upvotes: 3

Related Questions