llHTTPRequest - secure on the receiving end?

[Tommy Rampal]

So pretty much, my scripts communicate with my PHP files via. llHTTPRequest; depending on the POST data, it does a query and returns the results in an echo.

It works fine and I am currently working on a token based system to ensure no spoof requests can be made; I am a bit clueless however when it comes to checking that the HTTP request has been sent from Secondlife servers. Has anyone got some advice and/or sample code to check this?

Also, additional advice to keeping my PHP-LSL communications secure/spoofless would be greatly appreciated.

[Rufus Darkfold]

You can use https.

 

[Void Singer]

there are some things you should check when using llHTTPRequest, headers should state that the shard is production, ip address should be in range for SL servers, and object name and owner should be as expected, object key as well for statically rezzed items.

please also not that the http_response event is not entirely secure on it's own, and will be triggered in all scripts within the same prim, so you need to be sure the item does not allow modification, or don't send secure data in the response from your server (it also exposes the originating address)

ETA:
while you can use https, there have been certificate problems, and since all SL scripts will be using that certificate it's only usefulness when configured properly is to ensure that it came from an SL server, but does not guarantee the source within SL.

[Tommy Rampal]

I am not so familiar with HTTPS, how to set it up and how to make use of it within PHP (I have been making use of my University studies, and security hasn't been a hot topic as of yet (early years)).. And checking that the request came from Secondlife servers is what I want. I intend to store a log of all HTTP communications from my PHP scripts, so any malicious communication sent can be manually checked and the owner key can be blacklisted from all further communications.

HTTP_responses are just confirmations and return data (e.g. the script sends a special command to request it, and generates that command within the singular script), and to get that confirmation, the token needs to be checked (the token gets created and destroyed on the fly in a handshake, every time the script requests something).

[Darkie Minotaur]

For HTTPS will give you good security with most aspects - but it will also cost you. Plus the limitations Void mentioned.

Logging your HTTP will not add too much security - if someone is clever enough to get your token, this person is most likely also clever enough to manipulate the header.

A further step would be encrytion. The means of encrytion you can use with LSL are limited - but there are even some simple examples of strong encrytion out there - just google for lsl and encryption.

In 90% of the cases in which I use http-communication, I hardly use anything more but a simple token - it's simply not worth it since the data is not really sensitive or worth any money.

[Void Singer]

as long as the data itself isn't sensitive you don't need encryption on outgoing requests, just authentication (which a token system can provide depending on the method used)

https for the server means A) other sites on that server are blind to that incomming request, and b) you can control access based on credentials. talk to your server admin to set it up, it's been awhile since I managed a server but all the basic packages should be there it's just a matter of adding the directives to conf, and your php will have an extra variable it can check (or the server can do all of that part, and it'll be transparent to the php).

don't blacklist information given in headers as this can be faked, just look up the ip ranges on the LSL_Portal (they're linked from the request article)

[Tommy Rampal]

I'll look into HTTPS more and chat with my host, thanks.

Pretty much this is how my communication works:

• A token is created within the LSL script
• The request is sent to the php page along with the token as a 'create token' command
• The web server responds, clarifying the token was created ok, and sends back the request
• The LSL script sends the request (e.g. get server variables) along with the token
• The web server checks if the token exists with the owner key, if not, return 'badtoken' else return whatever depending the request, and destroys the token.

So right now I have these additional worries on my mind...

• Someone could easily make a mock of my script, thus sending a create token request. Once that token is created they can potentially send any request; most worryingly database input data (e.g. game saves).. Or they can just use the 'create token' request to send the request they wish.
  >> Though to make it slightly more secure I can make tokens bind to a specific request, so tokens are created to serve a specific purpose than just be a master key to anything.

I guess for purposes of security. I can save the original command via. LSL variable, so that http_responses are purely for clarification or server variables?

[Void Singer]

I like the oAuth method, which essentially amounts to the person that has access the the server sends a one time request, then then accesses the server to authorize that specific item (which will have a unique and unguessable value of its own). and then gives you something to put in the script that the server recognizes but can can be revoked on the server end.

of course that may or may be overkill, or may not be enough depending on what data can be accessed or is being transmitted.... a simple key value that must be present is fine for low level security (much like a pin number only longer).

https takes care of most man in the middle attacks, so the only thing you need to worry about is front end attacks. there are examples of authentication on the wiki, and additional encryption if you need it, depending on the content.

[Tommy Rampal]

The following was from my hosting provider:

The changes you described can be created with a .htaccess file. To deny all except the IP you wish:

Create a .htaccess file and put

Deny from all

This will block all access to the site, and then add another line to enable access only for yourself:

Allow from 1.2.3.4

where 1.2.3.4 is the IP address of the server you would like to allow to.

To force it to connect over the shared SSL you would use this:

RewriteEngine On

RewriteCond %{SERVER_PORT} !443

RewriteRule (.*)  https://WEBHOSTURL/~username [R]

Would you suggest this is the optimal way to go about it? So 'Allow from *.agni.lindenlab.com'

[Void Singer]

specifying a friendly address will require a double reverse lookup, so actual IP address ranges will be much more efficient... you can find the proper format by looking in the apache docs, the configuration format is the same as the .htaccess format.

ref:
http://httpd.apache.org/docs/2.0/howto/auth.html
http://httpd.apache.org/docs/2.0/mod/mod_access.html

I wouldn't worry about forcing ssl, just ignore anything that doesn't use it.
mod_rewrite has some gotchas and it's not worth dealing with unless you have to.