3
A Content-Type header is applicable to a response with a body per RFC 2616:
When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding.
By extension, it's not necessary if there is no response body, as you're describing.
It is a SHOULD and not a MUST, so it is RFC-...
2
While the differences between authenticity and integrity are difficult in practice, as your example of a compromised key set illustrates, as far as I understand it, this aims at the network level rather than the logic level. Thus, checking the integrity comes down to trusting the authenticity of the certificate and accepting only such cipher suites that ...
2
In this case should I worry about the XSS possibility? Should I check the inputs and sanitize them for every request?
Yes, you should worry about this foundational piece of security. Even if you can't currently envision an attack vector today, as your software evolves, you are leaving landmines in your wake that you will quickly forget about. It will become ...
2
You can point a domain name to a private IP address. As a random example, the company I work for has a domain name local.example.com that points to 127.0.0.1. Not that the details matter much, but it uses this for providing MFA to command line tools - the local application will launch a browser window with our SSO/2FA provider, and the return URL for the ...
2
if a user is on my site's login page, he would have the keys to the secure connection
I don't know what you meant by that...
Client-side protection is more of a help than a protection. If a field on the form must be an email, a client-side email validation will help the user know that the email is invalid before sending the form, and having to probably fill ...
2
Any validation done client-side shouldn't be trusted, because it can easily be ignored, bypassed or broken. It's trivial to post requests to your login form handler without using the actual page hosting the form, so that handler should always validate all input it receives.
1
Cloudflare is essentially a reverse proxy which might also cache content. If the content is then actually served from the cache or if the request is passed through the origin server can be influenced by the server itself through the use of standard Cache-Control HTTP headers. Thus, if the server wants to control access to specific content but still allow ...
1
Let's answer your main question then:
Yes, this can be done securely.
Then let's answer the obvious followup question:
No, there is no way to tell if this is done securely
This certainly can be done securely - there are a wide variety of ways for you to sign in to one site and also be securely signed into another. This is the nature of SSO, which is ...
1
As was mentioned in a comment, this is actually an extremely common pattern for web services. Specifically, using Authorization: Bearer <token goes here> is a secure way for a client to authenticate to a service, which incidentally happens to be secure against CSRF. It's slightly inconvenient for browser-oriented web apps, as it requires requests to be ...
1
How the question, is there any way to still bypass this way implementation?
As you've already said, it is a good protection against CSRF since the Authorization header is a) unknown and b) is not sent cross-origin.
These properties are no longer true though if the attacker finds a XSS in the original site, since then it might be either possible to extract ...
1
This is making a prepared statement. It won't sanitize the inputs. At a low level, it's probably using the sqlite c api, and it would look something like:
stmnt = sqlite3_prepare("INSERT INTO table (e1, e2) VALUES(?, ?)")
sqlite3_bind_int(stmnt,0,V1)
sqlite3_bind_blob(stmnt,1,V1)
while((row = sqlite3_step(stmnt) != SQLITE_DONE){
//do something ...
1
I believe he is right. It sounds like the parameter that provides the '9' is under control of the user / provided by the query string in the URL that links to this page, right?
Since the parameter is already inside some JavaScript, the attacker would not need to inject angle brackets or quotes to inject JavaScript code and cause a Cross-site Scripting (XSS)....
1
As @multithr3at3d commented, if the attacker already has local access its game over. There isn't much you can do to protect against session hijacking if an attacker has compromised your user's device. You could try to check the IP of the client when it makes a request to ensure that it is the same IP from which the session was initiated. This isn't a good ...
1
It depends on what you mean by "the best".
From the security point of view, server should not trust any data received from the client and should validate all the data. Why? Because you don't know who and why sent these data. May be user has modified your JavaScript and forced browser to send to the server the data, that you believed your script ...
1
Will security officers (CSO) in companies in general accept this or not for a 3rd party solution installed on prem?
Nobody CSO can tell you how another CSO will answer that question. Personally, as an Active Directory admin I successfully advised against implementing dozens of applications already, that provide LDAP or local authentication already.
At ...
1
Well, which is it? A user or an attacker? A user doesn't care about the key, an attacker does.
An attacker doesn't really even care about the key, but rather the password. Moreover, an attacker doesn't really even care about the password, but in fact the data in the database.
If an attacker could reasonably get the key out of the user profile (which is what ...
1
There's a small specific caveat to existing answers that I'd like to add. While Conor is right that cookies are the only form of locally stored authentication data sent along all requests, they're not the only form of locally stored authentication data used by websites. What this means is, if a site decides to keep their JWTs/Session tokens in something like ...
1
As Tom Leek points out in his excellent answer (which he penned in 2014) - with client-side hashing... 'what the client sends is password equivalent'.
This is why we now have protocols like PAKE and SRP. With PAKE or SRP, the server authenticates the client based on a password known by the client - but without the password (or password-equivalent data) ...
Only top voted, non community-wiki answers of a minimum length are eligible
