How can myWebservice.asmx (being called from myJavascript.js), only be callable from my website and not XSS?

Question

Is there any best practices techniques that would greatly improve the security of the asp.net application, when Javascript is directly submitting data from the html/form to the asp.net/c# webservice like this:

HTML:

<input type="text" id="txtData" />

<input type="button" onclick="SendData()" />

JAVASCRIPT:

function SendData()
{
    var userData = document.getElementById('txtData').value;

    MyWebservice.DoSomething(userData, SendData_Result);
}

function SendData_Result(result)
{
    //handle output displayed to user from 'result'
}

Webservice/ASMX:

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ScriptService]
public class MyWebservice : System.Web.Services.WebService
{
    public MyWebservice() { }

    [WebMethod]
    public string DoSomething(string userInputGoesHere)
    {
        //how to make sure the user input is valid?
    }
}

For example, if www.SomeBadGuysSite.com sends XSS via either referencing and manipulating the javascript on my site, OR they directly reference the webservice itself... - how can I try to enforce that the input came from my website and not from the bad guy's website or PC?
- and I'm not concerned about what data is in the textbox, only to attempt to make sure the only time the webservice can be called is from my html/forms page.

Note: I am using Forms Authentication and only authenticated users can access any pages or webservices. However, if a bad guy is authenticated on my website, but runs his own malicious code from his website or PC, wouldnt my site think he is already authenticated anyway and allow him to submit data to the webservice?

I'm wondering if encrypted cookies could play any part in fixing this security problem? (and for reasons not worth getting into, using Sessions/SessionState is not an option for me)

Answer 1

From Building Secure Web Services :

Web services that provide sensitive or restricted information should authenticate and authorize their callers. Weak authentication and authorization can be exploited to gain unauthorized access to sensitive information and operations.

The Authentication section should give you some ideas.