Another CPS question


Status
Not open for further replies.
G

Gristle

Guest
Ok, say evilsite.com is trying to be a MITM to goodsite.com

The user is logging in with same-device login, so they have the benefit of CPS.

My understanding that CPS works because the SQRL client causes the web browser to do a 302 redirect to the goodsite CPS URL, hence bypassing evilsite. However, if evil site has JavaScript running, can't they prevent the redirect from happening and instead go to the CPS URL in the background on their own and maintain MITM of the current browser session? In other words, how are you 100% certain that the browser's evil site JavaScript will respect the SQRL client's request to redirect? I would understand if the SQRL client creates a url that the user taps on to tell their OS to initiate a new browser tab, completely out of band of evilsite's tab, but that's not how it's designed.

Can someone please explain how/if this attack is mitigated?
 
Last edited by a moderator:

PHolder

Well-known member
May 19, 2018
1,207
202
they prevent the redirect from happening and instead go to the CPS URL in the background on their own
So you mean the evil site is running a variation of the "standard" SQRL Javascript, right? If not, then it would be unclear how the evil script would get the CPS URL. So assuming you mean the former, then I think the [correct functioning] SQRL server would reject the CPS nonce coming from an IP which is not the SQRL client. (Because presumably if they capture the URL, they need access to it on their end for it to remain a MITM.)
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
Ok, say evilsite.com is trying to be a MITM to goodsite.com

The user is logging in with same-device login, so they have the benefit of CPS.

My understanding that CPS works because the SQRL client causes the web browser to do a 302 redirect to the goodsite CPS URL, hence bypassing evilsite. However, if evil site has JavaScript running, can't they prevent the redirect from happening and instead go to the CPS URL in the background on their own and maintain MITM of the current browser session? In other words, how are you 100% certain that the browser's evil site JavaScript will respect the SQRL client's request to redirect? I would understand if the SQRL client creates a url that the user taps on to tell their OS to initiate a new browser tab, completely out of band of evilsite's tab, but that's not how it's designed.

Can someone please explain how/if this attack is mitigated?
I'd be glad to. :)

The secret here is that the way CPS works is that the browser's login page JUMPS TO the little web server in the same-machine SQRL client. If you look at your browser's "busy" spinner while the SQRL login prompt is on the screen (you need to disable the screen darkening) you'll see that the browser is WAITING for the authentication to complete. This whole browser JUMP to the SQRL client completely disconnects ANY sort of JavaScript -- malicious or benign -- since the browser has completely left the website it was on.

The authentic website's CPS reply contains =both= a guaranteed authentic URL and the CPS nonce to uniquely identity the user to the website and then to the SSP API service so that it can identify the user to the website.

And... one slick trick is that any incoming query to the SQRL client's little web server, which includes an "Origin:" header, is instantly dropped like a hot rock. This prevents any possibility of shenanigans by malicious JavaScript that might be attempting to fake a CPS browser jump in order to obtain the CPS URL for itself. ALL forms of automated queries of any sort contain the "Origin:" header so that the recipient can determine the requesting agent's origin domain... and this is completely unspoofable and outside of any possible JavaScript's access... for exactly that reason. :)
 

PHolder

Well-known member
May 19, 2018
1,207
202
"Origin:" header, is instantly dropped like a hot rock.
275

EDIT: I would note that I get this same result if the Origin: null is sent, which has the following meaning in the standard:
Whenever a user agent issues an HTTP request from a "privacy-
sensitive" context, the user agent MUST send the value "null" in the
Origin header field.

NOTE: This document does not define the notion of a privacy-
sensitive context. Applications that generate HTTP requests can
designate contexts as privacy-sensitive to impose restrictions on
how user agents generate Origin header fields.
From 7.3 of https://tools.ietf.org/html/rfc6454#section-7
 
Last edited:

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
EDIT: I would note that I get this same result if the Origin: null is sent, which has the following meaning in the standard:
Yeah. Thanks, Paul. I never knew what they meant. But I do know that we have NEVER seen that "Warning Will Robinson!!" dialog you reminded us of. So we know that a jump to an HTTP web page =never= includes the "Origin:" header whether null or not. :)
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
I am obviously not techy enough, so my questions are:

1. Is CPS an inherent mechanism caused by the specs, or does the client need to do something properly for this to happen?

2. How can I test that I get duly warned by the client?
 
Last edited:
G

Gristle

Guest
I am obviously not techy enough, so my questions are:

1. Is CPS an inherent mechanism caused by the specs, or does the client need to do something properly for this to happen?

2. How can I test that I get duly warned by the client?
CPS is built in to the SQRL spec, and clients need to conform to the spec, plain and simple. If a SQRL client were to deviate from the spec, login just wouldn't work. I suggest reading the spec pages on this topic. They are very enlightening!

Not sure what warning you are talking about. If you are using same-device login, there is no burden on the user to do anything. They are protected. The only risk is when the user is using the QR code to login cross-device. In that scenario, the user must make sure the domain shown to them from the SQRL client matches the site they are truly intending to log in to.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
I am obviously not techy enough, so my questions are:

1. Is CPS an inherent mechanism caused by the specs, or does the client need to do something properly for this to happen?

2. How can I test that I get duly warned by the client?
1. Yes, as Gristle noted, because CPS provides SQRL's strongest built-in anti-spoofing anti-Interception protections, it is a crucial and required aspect of the SQRL specification.

2. GRC's main SQRL demo area hosts a page expressly meant for demonstrating and testing these SQRL features: https://www.grc.com/sqrl/nospoof.htm
 
  • Like
Reactions: DetlevSchm

DetlevSchm

Well-known member
Mar 4, 2019
64
5
Sorry for pestering you more.

The reason for my questions above were, that I recently added features 25 and 26 in the client feature comparison table:

Code:
|25|Opt(3): Warn MITM attack    |
|26|Opt(3): Warn non-CPS auth.  |
But this does not seem to be right.

First, these are not two different things, but the same, and can therefore be condensed to one.

Second, if the then remaining feature is an "inherent mechanism", that is, it cannot be ignored by the client, then it is not a feature
at all and should be dropped altogether from the table.
 

shanedk

Well-known member
May 20, 2018
420
112
Actually, they are two different things. CPS not running doesn't necessarily mean a MITM attack. It just means CPS isn't running for some reason. MITM warning means that the login request came in on a different IP address when it shouldn't have.

You can try both of these at: https://www.grc.com/sqrl/nospoof.htm

If you click the blue SQRL logo, it'll log in without CPS but otherwise be fine. If you click the red "Spoof with SQRL" button, you'll see a completely different alert warning you of a MITM situation.
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
Actually, they are two different things. CPS not running doesn't necessarily mean a MITM attack. It just means CPS isn't running for some reason. MITM warning means that the login request came in on a different IP address when it shouldn't have.
Yes, you are right, and I understand that, but we are not talking about the same subject:

Table entries 25 and 26 mean, in conjunction with their footnotes, that the client requests a certain server feature. But the concrete server feature is 26, and a possible "MITM attack warning" is just the result of that feature. So, 25 needs to be removed, because it is "CPS" without naming it so.

You can try both of these at: https://www.grc.com/sqrl/nospoof.htm

If you click the blue SQRL logo, it'll log in without CPS but otherwise be fine. If you click the red "Spoof with SQRL" button, you'll see a completely different alert warning you of a MITM situation.
That was the first thing I tried when Steve mentioned this page, and I could confirm that the Android client acts properly, while the Linux client just failed, without telling the cause.
 

shanedk

Well-known member
May 20, 2018
420
112
Yes, you are right, and I understand that, but we are not talking about the same subject:

Table entries 25 and 26 mean, in conjunction with their footnotes, that the client requests a certain server feature. But the concrete server feature is 26, and a possible "MITM attack warning" is just the result of that feature. So, 25 needs to be removed, because it is "CPS" without naming it so.
No, Same-IP is different from CPS. A client could conceivably implement CPS but not a Same-IP check.
 
G

Gristle

Guest
keep in mind that normal users aren't going to know (or care) what CPS is, nor will they understand (or care) what a MITM attack is. I would suggest that the benefit of SQRL is that it handles the decision making and security for you. Let the client decide what is best for the user, and then take action on behalf of the user. If the client thinks there's something fishy going on, the client should just handle it and then tell the user what they did wrong, if anything.
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
No, Same-IP is different from CPS.
I believe I am beginning to understand. You are referring to the "Client -to- Server Semantics" here, where

Code:
|25|Opt(3): Warn MITM attack    |
should correspond to

opt = noiptest

and

Code:
|26|Opt(3): Warn non-CPS auth.  |
should correspond to

opt = cps

Correct me if I am wrong, otherwise I am back in the boat :).
 

DetlevSchm

Well-known member
Mar 4, 2019
64
5
keep in mind that normal users
No, I had never normal users in mind, when I created this overview.

It was part of my internal documentation, and one day I thought it might be useful for others here in the forums, so I posted it.

If the now sticky were intended for normal users, it needed at least an overall rewording, but I do not plan to do that, though I could apply an introductory warning.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
You're exactly right about the meaning and flags for those options.
And I 100% endorse this for our internal developer / techie use.
There are no "optional" features for SQRL clients.
A SQRL client needs to be complete to be fully usable.
 
  • Like
Reactions: DetlevSchm

DetlevSchm

Well-known member
Mar 4, 2019
64
5
There are no "optional" features for SQRL clients.
I was triggered to make these distinctions by your saying "Server support for this feature is optional but strongly encouraged." while describing the "sqrlonly" option.

But, anyway, I have already dropped that from my internal table, which I am going to publish shortly. It does not appear to be a necessary distinction for this kind of overview.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
Whoa!! SERVER SUPPORT for the features are optional... but not CLIENT support! PLEASE do keep them in your table. SQRL clients MUST all be able to make the request of SQRL servers. It's whether the SQRL servers honor those requests that is optional because we have no way of enforcing it. (But in time user pressure could!)
 
Status
Not open for further replies.