CODEWITHSUNDEEP
asp.netweb-servicessecuritysoap
Phil
Phil

Reputation:

How do I tighten security of my hybrid ASP.NET 1.1 / Ajax solution?

Scenario

I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.

The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.

I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.

Questions

  1. With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
  2. If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?

Upvotes: 0

Views: 149

Answers (4)

Bryan Batchelder
Bryan Batchelder

Reputation: 3637

There are a few simple options:

  1. SSL + Cookie
  2. If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
  3. If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).

Upvotes: 1

mpez0
mpez0

Reputation: 2883

The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.

That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.

Upvotes: 1

AJ.
AJ.

Reputation: 13761

A few suggestions to consider:

  • List the threats, and compare each to your current setup.
  • Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
  • Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
  • Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords

Upvotes: 1

warren
warren

Reputation: 33453

Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.

Upvotes: 0

Related Questions