Add "X-SecondLife-Region-Hostname" Header to llHTTPRequest
Ash Qin
Background
With Second Life's transition from traditional data centers to AWS, many content creators and service operators had to disable IP-based filtering for external script communications. AWS's dynamic and ambiguous IP allocation makes it impractical to define a reliable range of Second Life simulator IP addresses.
This change has introduced security challenges for external systems interacting with in-world scripts. Some scripts cannot be updated because they were distributed by creators who are no longer active, while others remain unchanged due to user hesitation. Reasons include lack of technical knowledge, extensive modifications, or accidental use of outdated versions.
The Problem
Without a reliable way to verify that an HTTP request originates from a legitimate Second Life simulator, external services are vulnerable. If an attacker discovers the URLs and payloads used by in-world scripts, they can replicate the requests, potentially tricking external systems into treating them as legitimate in-world interactions.
Proposed Solution
A simple but effective solution is to add a new HTTP header to
llHTTPRequest
:X-SecondLife-Region-Hostname
- This header would return the value of llGetEnv("simulator_hostname")
, providing a hostname in the format:simhost-0dd08effbc13e71c9.agni.secondlife.io
Security Benefits
External systems can verify the request's authenticity by:
- Ensuring the hostname ends with .secondlife.io, confirming it originated from a Second Life simulator.
- Performing a DNS lookupon the hostname (e.g.,simhost-0dd08effbc13e71c9.agni.secondlife.io) to retrieve an IP address.
- Comparing the resolved IP addresswith the IP address that initiated the request. If they match, the request is valid.
Impact
This change would allow external systems to restore security measures for scripts that cannot be modified, ensuring continued protection without requiring manual updates from creators or users. By leveraging an existing environment variable, this solution is lightweight, practical, and easy to implement.
Log In
RestrainedRaptor Resident
Or, your LSL script could open up its own HTTP server for a challenge-response sequence. I believe you can do that right now without any new headers.
Also, checking that the incoming IP matches that of one of SL's simulators might not be enough if the attacker is also using AWS. Just saying. Better to do explicit verification by having a two-way conversation, or some kind of cryptography-based authentication (like a secret key stored in the LSL script) in the request body.
Ash Qin
> Or, your LSL script could open up its own HTTP server for a challenge-response sequence. I believe you can do that right now without any new headers.
Can you explain how to do that in the context of the scenario presented in the original post:
"This change has introduced security challenges for external systems interacting with in-world scripts. Some scripts cannot be updated because they were distributed by creators who are no longer active, while others remain unchanged due to user hesitation. Reasons include lack of technical knowledge, extensive modifications, or accidental use of outdated versions."
> Also, checking that the incoming IP matches that of one of SL's simulators might not be enough if the attacker is also using AWS.
I think with a sufficiently small DNS cache, it's unlikely an attacker would manage to grab a previously used IP address in time considering the huge IP ranges they could get under AWS.
> Better to do explicit verification by having a two-way conversation, or some kind of cryptography-based authentication (like a secret key stored in the LSL script) in the request body.
Can you explain how to do that in the context of the scenario presented in the original post:
"This change has introduced security challenges for external systems interacting with in-world scripts. Some scripts cannot be updated because they were distributed by creators who are no longer active, while others remain unchanged due to user hesitation. Reasons include lack of technical knowledge, extensive modifications, or accidental use of outdated versions."
RestrainedRaptor Resident
Ash Qin In LSL it is possible to make your prim register for a HTTP endpoint using
llRequestURL()
, and handle incoming requests with the http_request(key id, string method, string body)
event. If you want an example, I can give upload an example script or give you an object.Ash Qin
RestrainedRaptor Resident, can you explain EXACTLY how to do this within the context of scripts that cannot be updated for reasons such as they were distributed by creators who are no longer active, legacy update scripts that no longer function (like Hippovend), others remain unchanged due to user hesitation due to lack of technical knowledge, extensive modifications, or accidental use of outdated versions etc.
RestrainedRaptor Resident
Ash Qin Ah... Well if the scripts are no-mod then you're out of luck. It's not a magical drop-in solution for existing systems with no security.
Nexii Malthus
Ash Qin these responses don't align with the request of the proposal. If the creators are no longer active, etc then there is no one to update these to use your proposed new functionality. Who is this for exactly? The workarounds by RestrainedRaptor are pretty valid approaches, but in your context there is
no one who can update these systems
, so there is nothing that can be done to resolve the legacy content issue, because everything hinges on changing or adding something, not reversing the situation (moving from AWS back to own datacenter).Ash Qin
Nexii Malthus I'm sorry that it's not clear to you.
> these responses don't align with the request of the proposal.
The proposal literally states:
Some scripts cannot be updated because they were distributed by creators who are no longer active, while others remain unchanged due to user hesitation. Reasons include lack of technical knowledge, extensive modifications, or accidental use of outdated versions.
> Who is this for exactly?
I have been a ghost scripter for many years and still actively maintain backend services for many products, even if the creators are no longer active.
Further, there are circumstances where I can update things, but I have no sound, valid path for validating pre-existing situations without a decent form of verification, regardless.
> but in your context there is no one who can update these systems
The proposal literally states:
This change would allow external systems to restore security measures for scripts that cannot be modified, ensuring continued protection without requiring manual updates from creators or users. By leveraging an existing environment variable, this solution is lightweight, practical, and easy to implement.
Ash Qin
RestrainedRaptor Resident I never said anything was magically going to be resolved. I proposed a method of verification.
Nexii Malthus
Ash Qin so you are the creator of said backend service, and you are active. So the background/problem was phrased in a confusing way, because it made it sound like there is no one to update anything or who the change was really for. Here is a rewrite:
"I operate a backend service that many people have created products around over the years that then end users rely on.
Before the simulators were moved to AWS I used to rely on IP whitelisting to reliably tell if a request came from Second Life.
However, now that sims are on AWS I can't verify if communications come from Second Life anymore, which can leave a backend service vulnerable.
I need some information sent from Second Life that I can use to trace and verify that it actually came from Second Life. Such as a hostname on a known and verified domain name that I can perform a DNS lookup on, and then checking if the resolved IP from the lookup actually matches with the IP in the request."
This puts the problem more into perspective that this is from your perspective as a service operator receiving HTTP requests from scripted objects. The way the proposal was written I thought the proposal was focused centrally around content creators who are not active anymore who ran their own backend services -- rather than content creators who are now inactive who happened to be using a backend service which is still maintained.
Ash Qin
There is potential scope in future to make this further secure by enabling DNSSEC on secondlife.io too if there are any additional security concerns regarding DNS.
Ash Qin
I have learned that all requests are coming through some other aws instances and not directly from regions. I'd like to amend this request to instead ask that these outgoing clients have DNS entries under a verifiable domain such like
seocndlife.io
and that X-SecondLife-Request-Hostname
points to that instead.