0

I am developing an application using .Net MVC3 that executes some Javascript through a js reference on a page.

Once the script is initiated, some javascript is returned and executed on the client side. At the end of this process I need to do a call back to mysite.com to send client-related details such as browser, IP address, etc.

To accomplish this I'm using an asynchronous call back to my server to send the data:

    xmlhttp.open("GET", "http://mysite.com/record_values/" +
        navigator.appVersion + "/" +
        navigator.cookieEnabled + "/" +
        encodeURIComponent(document.URL), 
        true);

Are there any other recommended ways of getting this information back to my server for recording?

Thanks.

ElHaix
  • 12,846
  • 27
  • 115
  • 203

1 Answers1

0

Note that some of the information you will be looking for (browser version) is already passed in the user agent string. Cookie support is not though. The referrer should already be there in the headers (and thus the url should may not have to be passed)

As Daniel mentioned, this should be POST. 100% absolutely a post. ANY data operation that does something beside a retrieve should always be done via a post (part of the http spec actually)

In addition I would also pass in an MVC AntiForgeryToken (@Html.AntiForgeryToken() and [ValidateAntiForgeryToken] on the controller method) to help ensure an attacker can't overload your server/database with repeated calls for this.

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
  • I read (http://stackoverflow.com/questions/4757890/when-the-use-of-a-antiforgerytoken-is-not-required-needed) that anti forgery tokens are useless in public parts of the site where users are not yet authenticated. The post request will originate from Javascript sitting on site 1, sending data to my controller on mysite.com/xxxx/ . Is it possible to avoid CSRF attacks like this? Probably best for a new question? – ElHaix Dec 30 '11 at 01:09
  • If this is a public facing app that anyone can have access to, then yea - its fairly useless. If its meant for internal, then I would consider some token scheme although unfortunately the built in support doesn't provide single use tokens. Just be careful about who can call a method that ends up putting data in your database. An attacker could easily exploit this directly via a DoS attack on your database or use something like XSS to have every browser that hits the site call this over and over flooding the db. Just something to consider. – Adam Tuliper Dec 31 '11 at 08:13