Web Service with AJAX Security Best practices

Question

hi, i am using script manager to call a web method on client side but as you know web methods cant work from user control, so you have to create a web service to do that.

this is going fine with me but i am having the following concerns

• if you use web method in ASPX page the code is invisible to the user so how can i prevent users from browsing to my service and see my code and only let the page or user control call the web service.
• is there anyway users can high jack my code like Cross Site Scripting, Pinging, Etc... with this approach.
• what is exactly visible to the client with this approach, the java script code block that i used to call the service or everything ?
• any extra Advice would be totally appreciated.

thanks in advanced.

Answer 1

All the javascript will be visible, but that's not really an issue.

Adding the attribute EnableSession to your webmethod will let you use the same security code that you have in pages.

Answer 2

Without going into .NET specifies, since that isn't my field:

Anything which runs on the client (e.g. JavaScript) is visible to users who can modify it, within the confines of their system, as much as they want.

Anything which runs on the server is not visible to users.

For a user to be able to click a button and have code on the server run, the browser must send an HTTP request to the server. The simple approach is to use a form. This provides a standard means to structure data.

More complicated approaches involve using JavaScript to construct the request explicitly (rather than just letting the browser take care of it). This lets the data be submitted using other methods than "Visiting a new page", which gives the flexibility needed for Ajax.

With any approach, you essentially define a public API which is accessible via HTTP.

There are two broad classes of attack that you need to defend against (it doesn't matter if Ajax is involved or not, its still the same type of API).

1. Direct attacks - sanity check your data, don't let users edit things without authentication.
2. Indirect attacks - in which a third party tricks a user into entering bad data (e.g. via a link on another site that asks their browser to make the HTTP request to your site). Defenses include things like requiring the client to request a one-use token before their can submit data (e.g. by generating a hidden input when the form is served up to stop third parties using their own form with malicious data and submitting users to your site with JS).

In a nutshell: Use the same defenses you would use if JS wasn't involved.