HTTP requests Security

[Boudi Wahwah]

I want to send HTTPS requests to send and get data to a script because the script size is very limited. and i might need to send authentication data through POST request, And the question is:

Can anyone access the data i send by the script ? i know the data received can be accessed by any other script through http response, but not sure if someone can access the data i send by the script in POST request. Is it safe ?

I do some encryption but i never trust 2 way encryption so if it's not safe how to verify on my server that the request has been made from SL simulator and what's the best way to encrypt data ?

Thank you so much for all your efforts.

Boudi

[CmpZ]

On the wild wild web, when a browser connects to a server via httpS (emphasis on that "S"), they establish a private (encrypted) channel, then the client authenticates the server's X.509 certificate.  When the client sends its request (including POSTed data), no one else can view it due to the encryption, & it also knows who it's sending to because it authenticated the server.

It sounds like your LSL script acts as a client, requesting data from an external server.  If that's the case, then the communication should be private, & the script should be able to trust the identity of the server if you include the [HTTP_VERIFY_CERT, TRUE] flag when you call llHttpRequest.

If you control both the client (LSL script) and server & don't want to send the password over the wire, you might consider HMAC.  You can put the secret in a notecard that the LSL reads.

 

 

[animats]

11 hours ago, Boudi Wahwah said:

how to verify on my server that the request has been made from SL simulator

That's a real problem. SL does not offer some built in way to do that. I've asked for SL to implement client side certificates for outgoing HTTP, so the server could tell the request was coming from SL. Then you could trust the extra headers (SL user, location, etc.) that SL puts on outgoing HTTP requests.

Since you can't trust that, you'll need some secret in a script in your object to identify it to the server.

I did that for the logging system for my bikes. I'd originally considered having a leader board for who'd driven the most each month, and offering prizes. But, for GPDR compliance, that was taken out. Only my free test bikes ("REVIEW" or "DEMO" models) have remote logging.

Edited October 29, 2022 by animats

[bobsknief Orsini]

22 hours ago, Boudi Wahwah said:

I want to send HTTPS requests to send and get data to a script because the script size is very limited. and i might need to send authentication data through POST request, And the question is:

Can anyone access the data i send by the script ? i know the data received can be accessed by any other script through http response, but not sure if someone can access the data i send by the script in POST request. Is it safe ?

I do some encryption but i never trust 2 way encryption so if it's not safe how to verify on my server that the request has been made from SL simulator and what's the best way to encrypt data ?

Thank you so much for all your efforts.

Boudi

You got to asume that the data can be accessed (even do this should not be the case).
When you post the data from LSL make sure to send along a "encrypted salted token" that is valid only ones and validated remotely.
You can use for example MD5 or SHA1 that should also be available in the programming language of your remote server.
https://wiki.secondlife.com/wiki/Category:LSL_Encryption

To clarify, a token is something that cant nor should be decrypted (you simply use the same values to create the token and compare them).

[Boudi Wahwah]

19 hours ago, CmpZ said:

On the wild wild web, when a browser connects to a server via httpS (emphasis on that "S"), they establish a private (encrypted) channel, then the client authenticates the server's X.509 certificate.  When the client sends its request (including POSTed data), no one else can view it due to the encryption, & it also knows who it's sending to because it authenticated the server.

It sounds like your LSL script acts as a client, requesting data from an external server.  If that's the case, then the communication should be private, & the script should be able to trust the identity of the server if you include the [HTTP_VERIFY_CERT, TRUE] flag when you call llHttpRequest.

If you control both the client (LSL script) and server & don't want to send the password over the wire, you might consider HMAC.  You can put the secret in a notecard that the LSL reads.

 

 

 

good information gonna test that for sure thank you

 

19 hours ago, animats said:

That's a real problem. SL does not offer some built in way to do that. I've asked for SL to implement client side certificates for outgoing HTTP, so the server could tell the request was coming from SL. Then you could trust the extra headers (SL user, location, etc.) that SL puts on outgoing HTTP requests.

Since you can't trust that, you'll need some secret in a script in your object to identify it to the server.

I did that for the logging system for my bikes. I'd originally considered having a leader board for who'd driven the most each month, and offering prizes. But, for GPDR compliance, that was taken out. Only my free test bikes ("REVIEW" or "DEMO" models) have remote logging.

 

ye this what i expected to be available but anyway i hope they implement something like this in near future to eliminate big hassle

 

7 hours ago, bobsknief Orsini said:

You got to asume that the data can be accessed (even do this should not be the case).
When you post the data from LSL make sure to send along a "encrypted salted token" that is valid only ones and validated remotely.
You can use for example MD5 or SHA1 that should also be available in the programming language of your remote server.
https://wiki.secondlife.com/wiki/Category:LSL_Encryption

To clarify, a token is something that cant nor should be decrypted (you simply use the same values to create the token and compare them).

 

That's what exactly i wanted to hear and confirm, Thank you so much for your help! really appreciated and definitely gonna do this however its a pain.