Using llHTTPRequest and php security

Hello there. I'm working on a simple system to get some information to an ouside database via llHTTPRequest and php (on the web end).

For instance, let's say when someone rezzes a copy of this object, it has something like this in the on_rez event:

string args = "id="+(string)llGetKey();
httpID=llHTTPRequest("http://mysite.com/slinfo.php?"+args,[HTTP_METHOD,"GET"],"");

Now on the php end basically slinfo.php would do nothing unless it gets a value for "id", but if it gets a reasonable value for id, it will record some info in a database, like the time, the object's id, etc.

What I want is something that is reasonably secure since it might be part of an automated update system. I'm thinking the following should be enough but I'm not sure.

1. First, the URL for the "slinfo.php" script only appears within a no mod script in lsl. No one is going to accidently come across it. I could also name it something like "rsid24ksi345.php", making it impossible to guess.
   
2. Second, to send valid info to the script, they would also need to know what I call the variable in php. Here I'm using "id" as the name of the variable that holds the object key, but I could name is something complicated or obscure, again making it hard to guess like "connors_object_id_for_lsl" or simply "widkfiwkdid".

I would think these two measures would make it hard/difficult to crack, simply because how would someone guess an obscure name for the php script and the obscure name for the variable name. But then I got thinking, is there a reasonable way that a nosy hacker might be able to find this info? Let's say they knew the name of the website I'm using. Would they somehow be able to find log files from a server somewhere along the traceroute which contained requests to:

http://mysite.com/rsid24ksi345.php?connors_object_id_for_lsl=5df9b35c5-f48a-50fb-1253-25729fa986b2"

If they saw examples, they could easily crack it I would think. Do I need to be concerned about somehow these URL's being snooped? I don't know enough abuot internet security to know if things like this are easy to for a hacker to find.

What you're describing is a method of 'security through obscurity', which is rarely a good solution. Something you might want to try instead, is using PHP to check the client header requests, or maybe encrypt the variable names and their values with base64 and decrypt them with PHP. Another thing you can do is try using the POST method instead of GET. If you're worried about the log files being seen, all they will see is the request for the php file, but not the variables that were sent to it.

A better solution all around would be to secure the application on the server side somehow, so that even if a cracker could find the variables and php files, it would be useless to them. For instance, you could make it so that the variables are only accepted if they're coming from a certain location, like SL's servers. Or you could make it so that the client has to be authenticated before the variables are accepted by php. Like you can use .htpasswd files and have PHP verify if the person logged in correctly or not, and use the variables accordingly.

Just some suggestions.

I've been looking into this lately, looking at encryption etc between the two. And my conclusion is:

Use an https server. Many hosts offer the ability now, and it's easy to set-up if you have your own machine hosting. It also provides far more security than you can really achieve via LSL and should take much less time (since it's handled as part of the http_response event rather than you having to code it).

They added the ability, and it's just begging to be used

Some kind of rudimentary jumbling of the data, maybe using llXorBase64StringsCorrect could secure it further, but an https server ought to cover your needs quite happily.

That ought to handle the snooping etc.

Then just make sure your system is sensible, for example, when an object is purchased it could register itself along with it's owner (which is data passed by default in HTTP requests iirc). Then your PHP script can refuse requests from people who have not purchased your object.

I tend to check the origination IP for the HTTP request and make my script send along a password as a separate variable in the request. It's not perfect, but it makes it far less likely that some random person could guess how to make my script do something in the unlikely event that they found it.

Packets that traverse through backbone internet routers aren't logged. That'd be way too much data to log! An attacker would need to position themselves in the path of traffic from LL to my server, or hack LL to get at the llHTTPRequest logs, or somehow convince SL to share info about a script, or break into MY server to get at my HTTP logs... but if they do the latter, then I guess I don't really need to worry about them messing with my script, there's no need.

Anyway, my system isn't perfect by any means, but there's not much that someone can really do that's evil if they find it. Also, spoofing IPs on the internet isn't trivial.

yea your best bet is to check the originating host that requests the data on the PHP side and if it's not part of LL's IPs then deny or return garbage results. If LL decides to hack you then obscurity doesn't help you, if the data being passed for any given transaction is not ok to be overheard (via packet sniffing if someone happens to be in the line) then you should consider encrypting said data. Basically what is critical? If it's just to make sure that it only responds to LL then use the above, if it's the data itself encrypt it, and lastly if it's critical that no one from INSIDE 2L can access the script either consider signing the request using various methods (usually an MD5 of a padded password where the pad changes over time).