llHTTPRequest + XML-RPC = DDOS

Has anyone tried using llHTTPRequest to talk to XML-RPC? I'm concerned that this might be a possible security hole -- and, for the record, I have emailed the Lindens and they did not ask me not to post about this.

Basically -- and I apologize for forgetting who mentioned this idea, feel free to take credit where it's due -- I saw a post where someone speculated that you could get around the requests-per-owner-per-sim by giving out "bugs" to people, so they were owned by different people... Well, it dawned on me this would work even better if you sold items that people rezzed in different areas, like furniture or trees.

If I started selling chairs, then people set these out in various areas, and they were all listening for XML-RPC requests (catalogued somewhere), then someone could use llHTTPRequest to start a daisy-chained conversation between my chairs. Each llHTTPRequest triggers an XML-RPC response which triggers an object owned by another person to fire off an llHTTPRequest, and so forth. It might be enough to crash the system, but if nothing else it could definitely create a lot of lag between all the sims.

I say all this with the purpose of asking -- and, look, this is me, I don't want anything code broken for security -- if maybe llHTTPRequest should be blind to the Second Life XML-RPC gateway. Any similar external attack can be blocked by IP, but blocking sim's by IP (iptable, ipfilter, etc.) might affect asset server performance.

Or am I barking up the wrong tree? (If I've missed something, please say so.)

In preview, at least, it is not possible to access secondlife.com via llHTTPRequest(). Presumably this goes for any site in LL's IP space, and presumably this behavior will not change when 1.9.1 goes live.

Someone has already pointed out in another thread that llHTTPRequest will not work if you point it at any of LL's servers. I could be wrong, but I suspect that stops this issue in it's tracks.

Edit... damn. You musta beat me by a matter of seconds...

Ah! Thank you all for replying. I apreciate it.

So much for lightweight direct object<->object communication
==Chris

Well, I guess this is kind of a moot point now, given what Kelly said, but I'd just like to point out that many LSL tools that we have can be used for evil purposes. If you really want to, you can set up a distributed email bomb, or crash the grid with spirals that orbit people, or spam with particles, etc etc etc. It's always been possible. It's also against the rules, and doing stuff like that will get you banned.

Sometimes it's best to simply recognize the possible evil things that people can do, and watch out for and punish them, rather than try to lock down or nerf the new APIs that are offered and attempt to anticipate any possible evil use beforehand.

I don't think that would have been very lightweight. O2O is already implemented -- that's how llInstantMessage works -- we just need an even that allows scripts to catch IM's.

Fair enough, but not that much more work. You guys already have the major components in place: a system for handling agents locations, a table for keeping up with non-av agent locations, and a system to measure the number of calls per-prim-per-owner-per-sim to prevent over-abuse. I'll retract and apologize for saying it's already implemented, but would it be that much work to alter what you have?

I should note that something like this might be used to abuse the system in a similar way to my original post. However, if O2O, say, only worked between objects owned by the same person, it would be a mite easier to prevent internal DDOS attacks.

One of the many reasons people would like O2O is to facilitate updates, so an object owned by a consumer would need to communicate with an object owned by the creator/store-owner. I think if it were implemented then it would need to be throttled/progressively delayed in some way to avoid over-use.

However, on the note of objects, iirc objects have completely unique keys for the entire grid correct? ie - an object in sim A cannot EVER have the same key as an object in sim B? In that event, something somewhere must delegate which keys a sim may assign to new objects.
On this note, it should be possible to look-up an object quite quickly already;
- I'm sending an IM to object with key 'A'
- I look up the server responsible for handing out blocks of keys to sims
- It tells me key 'A' is in the block 'A - M' which was given to the Sim 'UrObjectizHere'
- The message is passed onto that sim, which then attempts to trigger an IM event

The main concern then is making sure this remains speedy, though if a server is indeed dedicated to nothing more than handing out keys then it may not be so big a deal. If it is a problem then keys could be split off further, ie you contact the main server which has blocks of keys all the way from 'A' to 'Z', the key you want is '3', it passes you onto another server right away instead of trying to look-up the key itself.


My final point however, HTML requests are still very much a desirable feature, even if O2O IM's were added, as it allows you to process data that is otherwise difficult, or slow to do in SL. Imagine keeping a list of keys for people who have bought your product, imagine next that it's a very popular product. LSL can't keep a list bigger than 16k (if you can even reach that), and if it does, it becomes SLOW to find things within it. Meanwhile, if you passed this onto your own server, you can store it in a database along with other details (name, time bought, object bought etc) that make it easier/faster to look up the ones you want later on. You can have a database of much larger size (my host is a reasonable speed, and costs me like $4 a month for 3gb of file-space!) with more processing involved, without lagging SL by trying to do it with an in-world object (that may comprise of a large number of scripts in order to cope!).
That alone is a huge advantage and would allow things like lotteries to be implemented much more efficiently. Really what we need next is an LSL function for handling encryption more efficiently and that's set so long as throttling/progressive delay of calls is handled well enough. I think the main concern isn't DDOS against LL, but rather DDOS against other sites using SL, but that could maybe be handled as well.