Secure info from SL to web

Hello!

When I use the http-function in SL to send parameters to a url to update the SQL-database, I'm a little afraid that the user might be able to track down the address SL is looking up so the user can change the values in the database by modding the url. Is there a secure way to keep this from happening?

It may be difficult to understand what I mean here, but please ask if you don't understand!

Why not simply verify the information posted to the URL via the default header information sent with the llHTTPRequest() command?

You can also require a "registration" of a communicating object if you're worried about security. Simply have an initial command sent that checks validity via header-info, records the object to the database, and then returns an encrypted password variable or some-such (with the final step of encryption being completed on the LSL-side, further ensuring that it is your code being used on the LSL side). Then, when the object sends information to update the database...the database checks against the object key AND password (for registration) before changing any information.

Maybe I should try something like that, thanks!

Just for your understanding...

Scripts are executed server side.
If your script is NO MOD then the "client" or "user" cannot look at the script and has no was to track down the url you are using as the HTTP requests are not done by the client computer but the server.

This alone is not enough. I can fake a request to your web server from outside of SL that includes all of the necessary llHTTPRequest()-style headers to fool a script that checks only those headers.

One way to mitigate this and prevent outside people from communicating with the web server is to check that the IP address belongs to linden lab. You might do something like this:

1. Reverse-lookup the IP address that the HTTP request came from.
2. If it's not in *.lindenlab.com, drop the request.
3. Now look up the hostname that you got from step 1. If it doesn't resolve back to the same IP address you got originally, drop the request.

This is necessary because it's possible for anyone to forge reverse-lookup results to pretend that an IP address is in *.lindenlab.com, but it's not possible for someone to convince LL to add a subdomain that resolves to a given IP address, short of actually breaking into LL's DNS servers.

Good luck figuring out:
1) which server I use
2) which script I call
3) what security access method and data I use to validate requests (esp if I am using https and HTTP_VERIFY_CERT)

Yeah I know, security through obscurity isn't, yadda yadda yadda. Still, it is good enough for many applications. It all comes down to how high you want to raise the bar.

Still, it is a good method to add to the repertoire, if you need that extra layer. It can be a bit slow, though, because making two DNS queries takes time.

You can skip the DNS lookup for IP blocks you know belong to Linden Lab. http://wiki.secondlife.com/wiki/Simulator_IP_Addresses

Ruby/Rails example: http://w-hat.com/application_controller.html

Also it should be pointed out that there have been several script theft and permission escalation exploits and glitches, and Linden Lab has an abysmal security track record. For anything important you should assume your source is visible.

Thanks for all the great tips! I will try them out!