[Opensim-dev] Patch for New llHTTPRequest Internal Header Values

Mike Higgins mike at kayaker.net
Tue Nov 12 17:34:56 UTC 2019


This is NOT redundant to HTTP_CUSTOM_HEADER. The purpose of having data 
added to the header after the LSL call is to add a small amount of 
assurance that the information was not just made up by the LSL scripter. 
For example, if the script says "I'm running on OSGrid", that could just 
be a left over constant string that someone forgot to change when they 
took the script from one grid to another. If the grid name is added by 
the system, you have a little bit more confidence that it is correct.

On 11/11/2019 4:26 PM, Cinder Roxley wrote:
> As Mike stated, this seems redundant to HTTP_CUSTOM_HEADER. There is
> already a mechanism for adding an entry if that is what you desire.
> Certainly for the stated use case, it’s already possible. I don’t see how
> adding additional entries to every llHTTPRequest() would be widely
> beneficial especially at such a broad scope.
>
>
> On November 11, 2019 at 11:48:38 AM, Mike Higgins (mike at kayaker.net) wrote:
>
> There is no such thing as perfect security, but there is utility in
> increasing the difficulty of breaking the security. Eventually the
> difficulty exceeds the value of the information and you are secure
> enough. Adding values to the header in the OpenSim code instead of in
> the script adds just a little bit more difficulty and therefore a little
> more security.
>
> Here is an example use: It is common in grids to fly around in an
> airplane and have it crash (or the viewer crashes, or the region crashes
> or the grid crashes) and you leave the vehicle behind. I have a
> transponder script that occasionally reports the vehicle position to a
> database on an external server. When you log back on, you can ask that
> server to tell you where your vehicle is so you can go clean up any mess
> you may have left on someone else's land. The prim that finds the
> vehicle for you uses your UUID to look up your vehicle transponders in
> the database. No need to log on, no passwords, automatic authentication
> just takes you to your vehicles.
>
> Is it worth the trouble for someone to build a stand alone grid or
> modify the sources of OpenSim in order to maliciously find out where
> your crashed vehicles are? No. Is it useful to find your own crashed
> vehicles and clean up your own messes? Yes. Adding information to the
> HTTP Request header will allow more useful functions like this.
>
>
> On 11/11/2019 6:56 AM, mike.dickson at utopiaskye.com wrote:
>> There is already a mechanism to add Header entries in llHttpRequest
>> (http://wiki.secondlife.com/wiki/HTTP_CUSTOM_HEADER) . And I don't think
>> it's reasonable to consider anything on the header trusted or secure just
>> because its in the header. I'd argue there's little utility to adding a
>> bunch of data to the header that can't be trusted implicitly and it may
> bulk
>> up the message to the degree that the data gets split across packets and
>> delivered less efficiently. But my main argument against the approach
> would
>> be that information in the header is somehow secure or trustable. It's
> just
>> not.
>>
>> Mike
>>
>> -----Original Message-----
>> From: opensim-dev-bounces at opensimulator.org
>> <opensim-dev-bounces at opensimulator.org> On Behalf Of Haravikk
>> Sent: Monday, November 11, 2019 5:26 AM
>> To: opensim-dev at opensimulator.org
>> Subject: Re: [Opensim-dev] Patch for New llHTTPRequest Internal Header
>> Values
>>
>>
>>
>>> On 10 Nov 2019, at 23:36, Mike Higgins <mike at kayaker.net> wrote:
>>>
>>> These values turn out to be incredibly useful for authentication,
> commerce
>> and other cryptographic uses. For example, it is extremely difficult for
> an
>> avatar to spoof her own UUID. So this value can be used to uniquely
>> authenticate that the person using a prim is in fact who she claims to
> be.
>> I'd caution against using this is a sole factor in authentication; the
> whole
>> point of OpenSimulator is that anybody can setup and run a simulator, and
>> the code is open source, so it would be entirely possible to send false
>> requests from a malicious server (or CURL or similar if you know what
> you're
>> doing), there's also no guarantee that an avatar's UUID is unique between
>> grids (it should be, but it also may not be, e.g- if data was imported,
> or
>> someone changed their UUID on purpose).
>>
>> You would also need to establish that the request comes from a
> trustworthy
>> grid, and there isn't currently a way to do this as such, as again a
>> malicious request can pretend to come from any grid it likes, unless you
>> have a list of all valid IP's for that grid, you can't verify it. I
>> discussed a possible method to check that a simulator actually belongs to
>> the grid it says it does via a grid-level API, but have never found the
> time
>> to sit down and learn enough about the OpenSimulator code to implement
> it.
>> If you're interested, I covered this in a pair of wiki articles:
>> http://opensimulator.org/wiki/User:Haravikk_Mistral/RegionVerification
>> <http://opensimulator.org/wiki/User:Haravikk_Mistral/RegionVerification>
> and
> http://opensimulator.org/wiki/User:Haravikk_Mistral/ExpandedGridInfoAvailabi
>> lity
>>
>> So yeah, if you want validation I strongly recommend something more than
>> just checking the headers in an HTTP request at present; an initial
> password
>> then a persistent session token is still my preferred method, so a user
>> should only need to enter their password (and it should only be held by
> the
>> script) during initial setup of a device, or if they let the session
> expire.
>>> [Network]
>>>
>>> OpenSimHeaders = true ;add new information to llHTTPRequest header
>>>
>>> ;OpenSimHeadersGrid = false ;if false, don't include grid info in header
>>>
>>> ;OpenSimHeadersRegion = false ;don't include region info
>>>
>>> ;OpenSimHeadersParcel = false ;parcel info
>>>
>>> ;OpenSimHeadersPrim = false ;extra prim info
>>>
>>> ;OpenSimHeadersScript = false ;script info
>>>
>>> ;OpenSimHeadersDesc = false ;descriptions (prim and script)
>>>
>>>
>>> Complete list of new header values added:
>>>
>>>
>>> X-Opensim-Grid-Login-Uri
>>>
>>> X-Opensim-Grid-Name
>>>
>>> X-Opensim-Parcel-Flags
>>>
>>> X-Opensim-Parcel-Group-Key
>>>
>>> X-Opensim-Parcel-Key
>>>
>>> X-Opensim-Parcel-Name
>>>
>>> X-Opensim-Parcel-Owner-Key
>>>
>>> X-Opensim-Prim-Creator-Key
>>>
>>> X-Opensim-Prim-Description
>>>
>>> X-Opensim-Prim-Group-Key
>>>
>>> X-Opensim-Prim-Owner-Mask
>>>
>>> X-Opensim-Prim-Sit-Text
>>>
>>> X-Opensim-Prim-Text
>>>
>>> X-Opensim-Prim-Touch-Text
>>>
>>> X-Opensim-Region-Key
>>>
>>> X-Opensim-Region-Size-X
>>>
>>> X-Opensim-Region-Size-Y
>>>
>>> X-Opensim-Script-Creator-Key
>>>
>>> X-Opensim-Script-Description
>>>
>>> X-Opensim-Script-Name
>>>
>>> X-Opensim-Script-Perms-Mask
>> I'm generally in favour of these though; personally I wonder if we should
>> just include grid info as standard, since it's such a crucial part to
>> OpenSimulator, shouldn't present a security threat (unless your login URI
> is
>> unsecured somehow, in which case you have bigger problems) and it's
> useful
>> for basic verification of an HTTP request.
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


More information about the Opensim-dev mailing list