Prevent http_response and dataserver events from leaking to other scripts for SLUA | Voters

Prevent http_response and dataserver events from leaking to other scripts for SLUA

planned

WolfGang Senizen

While this caveat behavior is known and possibly relied upon by lsl scripts.
Nobody should be writing a slua script expecting this security issue to exist.
So if possible could a ll.HTTPRequest
 from slua, only trigger the http_response
 event in the slua script making the request.
Or a dataserver
 request also respond only to the requesting script.
Not in any other, script regardless of their platform runtime. 
This might be a slight pain to implement to keep the behavior for lsl on luau scripts, but I think worth it for slua
Test
Place 2 scripts in a prim save them with the following content
ll.HTTPRequest("https://secondlife.com",{},"")
function http_response(id,stat,meta,body)
    ll.OwnerSay(`{ll.GetScriptName()} = {stat}`)
end
Note that on saving of the second script you get 2 owner says, one from each script stating the response status.
Ideally this behavior should be avoided for slua.
Alternate suggestion
It was suggested it may be possible to instead add a new HTTP_*
 flag
Something like
ll.HTTPRequest(
    "https://secondlife.com",
    {
        HTTP_PRIVATE_REQUEST, TRUE
    },
    ""
)
This would not work for dataserver events though

A day ago

Harold Linden

Thanks for sending this in!
Yeah, I believe this behavior hearkens back to the days when it was reasonable (and expected) to have a separate script to do your HTTP response handling so you didn't run out of memory due to the response size.
That's usually not the case, so we should provide an interface that doesn't do this usually-unexpected behavior by _default_.

WolfGang Senizen

Harold Linden Just to make sure, Not just http, dataserver events too as those can currently (as nexii said) leak experience/notecard info etc

Harold Linden

WolfGang Senizen Yep, we're considering those as well.

Harold Linden

marked this post as

planned

Nexii Malthus

This issue also happens with dataserver events where scripts can be compiled to an experience but end up leaking details of the private experience storage to other scripts.
Dataserver events also need a way to be able to change this behaviour.
Since this would be a SLua specific improvement/change, it doesn't have to be a modification of the ll.* functions (since there's no flag we can put into a llReadKeyValue call), but rather can be something that can be tweaked in SLua only.

Journey Bunny

I like the private flag~ I can see scenarios where it would be deeply desirable (especially with script memory limitations) to have a script make a request, but for the return to possibly be meant for one of the adjacent scripts. Would be nice to keep that, but to also be able to lock it down as suggested for people who do need to protect the responses.

Bumping Pixels

I like the alternate suggestion (because I made it ha) because it'd be on the implementation side where LSL would be able to get the same benefits and share the same common expectation of how the LL functions behave and work. Since it'd be a new flag for new behavior it should have no impact on how existing scripts function.