You are not logged in.
Pages: 1
I can't understand the security based on session_signature. After the user log-in each request must contain ?session_signature=xxxxxxxxxx. But....I can simply copy the link to other browser and run the same link without authentication. Even someone can sniff the network to intercept my requests and open the same page. Shouldn't we put the session_signature in header to hide it by SSL?
Offline
Even someone can sniff the network to intercept my requests and open the same page. Shouldn't we put the session_signature in header to hide it by SSL?
That's not how it works. If your connection from the browser to the server is secure (TLS) then nobody will be able to "sniff" your session_signature.
Edit : And if you don't like that the session signature ends up in the URL you can override TSQLRestServerAuthenticationDefault (or check the other already available classes) and put session info in the header or cookie etc...
Last edited by pvn0 (2020-01-24 14:04:31)
Offline
You are not right, all web urls and query parameters can be easily read by network administrator.
Last edited by radexpol (2020-01-24 14:13:24)
Offline
But is described in the documentation that is how it works. So it's not a issue.
All the APIs I work with, pass authentication via URL.
Look for "REST Authentication Methods" in google.
Offline
OK, lets look at first google link:
https://blog.restcase.com/4-most-used-r … n-methods/
Basic Authentication:
"With this method, the sender places a username:password into the request header."
Bearer Authentication:
"Similarly to Basic authentication, Bearer authentication should only be used over HTTPS (SSL)."
API Keys:
"Many API keys are sent in the query string as part of the URL, which makes it easier to discover for someone who should not have access to it. Please do not put any API keys or sensitive information in query string parameters! A better option is to put the API key in the Authorization header."
So, where did you see the authentication data sent by plain text via url?
Offline
OAuth (2.0) described on this page can use a token passed in url.
I repeat. All the external APIS I that use (including large companies) use tokens in the URL.
And the title is still wrong. This is not a security issue of framework.
This is an option that you have.
Last edited by macfly (2020-01-24 14:59:40)
Offline
Putting the signature in header won't change anything, in terms of security.
Without TLS, the whole request/answer content are in plain, so without it there is no security.
We usually put a small nginx reverse proxy in front of the mORMot server.
It is easier to work with free certificates (Let'sEncrypt), and make proper redirection and have the best security/stability.
Online
You are not right, all web urls and query parameters can be easily read by network administrator.
But I am . If your network admin is able to sniff your url parameters, this means either your connection between the browser and the server is not secure (not protected by TLS or other encryption), or your certificates have been compromised.
Offline
The fact that the URI is in the local logs is not a huge security issue. If someone can read the logs in real time, then it is certain that you have bigger problems to solve than the mORMot server content!
Anyway, there is an expiration time for our URI signature, so e.g. if the logs are compromised, e.g. during backup, and someone is able to get the URI with signatures, the replay won't be feasible since the server will reject the expired URI signatures.
Your network admin will be able to sniff whatever he§she wants, not only the URL parameters. From the TCP point of view, there is no difference between the headers, the URI and the HTTP body, as they appear in the above layer.
A network admin can add its own root certificate - and he/she certainly does in any big corporations, just for proper content sniffing or proxying.
Most Windows AntiVirus software add their own root certificate to inspect the Web stream...
Don't try to find out if a signature in the header is less secure than within the headers. It is not.
And our signature is likely to be more secure than a regular JWT (especially if you don't use crc32c as hashing but sha256 or sha3), since every URI is signed, whereas the JWT only sign itself.
Only if you secure the TCP layer using TLS, or fully encrypt the data at application layer (this is what we offer with encrypted websocket frames payloads, without the necessity of TLS), you will have proper security.
Online
Pages: 1