Security Snake Oil Inc.
-
So I am trying to find out what kind of attacks we have to protect against and
- “SPI app should be using OAuth 2 code flow with PKCS” …. except any explanation of what attack that actually protects against describe hijacking of redirection from web browser to native app on mobile (another app registers for the same URL), and so is not applicable. I haven't seen description of such attack against a web app, but everybody mentions it should use the defence anyway.
- “JSON results should be prefixed with
)]}', to prevent this attack” … except the linked attack only ever worked on lists, only worked on ancient browsers where the application probably won't run at all (seriously, angular app on Firefox 2?) and it still does not explain where the weird prefix came from.
Sounds quite a lot like cargo cult? How much security advice out there is actually cargo cult?
-
@Bulb said in Security Snake Oil Inc.:
How much security advice out there is actually cargo cult?
How much isn't might be easier to enumerate.
-
Almost all of it.
Someone comes up with some rule that seems reasonable at a time. And it maybe is. So it gets adopted.
But then, even if majority starts thinking that rule is bullshit or no longer applies, no one will speak up about it and put their reputation on the line to remove it.
Because the upside of that move is all in the reduced opportunity cost, which is diffuse and difficult to quantify. You personally get nothing out of championing it. The downside, on the other hand, is direct, evocative and the blame directed squarely at you. Why didn't you think of the children!?
So you stay silent. So does everyone else, in a prisoner's dilemma kind of situation. That's why we have shit like bank password policies accumulate like fat in our veins, slowly snuffing us out.
Your SPA rules seem to be in the same vein.
-
@Bulb With regard to the first point, you want to guard against ways for credentials to leak out of your SPA "somehow" (the literature describes a native app intercepting data intended for a web app by using an app handler registration, which is equally viable on both mobile and desktop now, but anything that has the possibility of sockpuppeting your application in a frame or raiding its cookie jar works). The best way we have for that right now is to have an identity server issue short-lived, single-purpose digital certificates, and your API validate those certificates, rather than getting involved with any long-lived or broad-scoped credentials at any point. Hence, OAuth 2. (I think PKCS is technobabble in this context; while technically OAuth 2 tokens fit the definition of PKCS, nobody treats them that way, and in context PKCS is only mentioned under very specific circumstances that are unlikely to apply to you.)
With regard to the second point, that string is guaranteed to cause a syntax error in almost any context (argument list, array, object, single-quoted string) so if an attacker can't get at the contents of your JSON result (due to same-origin policy) there is no prefix they can add that would let them evaluate it. They can evaluate it as a double-quoted string, but they won't get anything back from that. You're right that it's obsolete though.
A lot of security advice is outdated and obsolete, as the attacks guarded against are no longer workable and newer attacks actually take advantage of the flaws in the advice. But at the time the advice was sound, and it's only later developments that rendered it unsound.
-
@TwelveBaud said in Security Snake Oil Inc.:
I think PKCS is technobabble in this context
It might just mean “use HTTPS”, which it should definitely do if it isn't and it needs to check the server identity. No point in having a cryptographically secure channel to any old random attacker.
-
@dkf said in Security Snake Oil Inc.:
No point in having a cryptographically secure channel to any old random attacker.
Hey, at least it keeps other old random attackers from snooping the data. That's something right?
-
@TwelveBaud said in Security Snake Oil Inc.:
by using an app handler registration, which is equally viable on both mobile and desktop now
I'm guessing that by "now" you mean "ever since more than ten years ago" on Windows. Pluggable application handlers ("custom schemes") have been a thing for a long, long time on Windows.
-
@Steve_The_Cynic Yes, but intercepting (with the OS' blessing) HTTP/HTTPS calls to domains they're interested in wasn't a thing until Windows 8.1 for Metro apps, and like a year ago the same capability was extended to desktop apps.
-
@TwelveBaud said in Security Snake Oil Inc.:
wasn't a thing until Windows 8.1
See: staying with Windows 7 is good for security.
-
@dkf said in Security Snake Oil Inc.:
@TwelveBaud said in Security Snake Oil Inc.:
I think PKCS is technobabble in this context
It might just mean “use HTTPS”, which it should definitely do if it isn't and it needs to check the server identity. No point in having a cryptographically secure channel to any old random attacker.
Yeah, I recently tried to MiTM a particular app so I could reverse engineer the protocol (for the purposes of enhancing user experience, of course), and was moderately dismayed that it verified the CA. Whomp wah.
-
@Tsaukpaetra said in Security Snake Oil Inc.:
@dkf said in Security Snake Oil Inc.:
@TwelveBaud said in Security Snake Oil Inc.:
I think PKCS is technobabble in this context
It might just mean “use HTTPS”, which it should definitely do if it isn't and it needs to check the server identity. No point in having a cryptographically secure channel to any old random attacker.
Yeah, I recently tried to MiTM a particular app so I could reverse engineer the protocol (for the purposes of enhancing user experience, of course), and was moderately dismayed that it verified the CA. Whomp wah.
Just the CA chain, or was it using a pinned certificate, where it has the (public part of the) actual server certificate and verifies that the one it receieved was that one?
And if it's verifying the CA chain, is it using the system repository of root CAs (so you could wedge your CA in there)?
-
@TwelveBaud said in Security Snake Oil Inc.:
@Steve_The_Cynic Yes, but intercepting (with the OS' blessing) HTTP/HTTPS calls to domains they're interested in wasn't a thing until Windows 8.1 for Metro apps, and like a year ago the same capability was extended to desktop apps.
That's ... Um. There aren't enough different WTF emoji here to express how bad that is, on mobile or PC. (Links that trigger the local App Store (or whatever it is on your phone) to open the page for an app, by returning the right MIME type from the web request, well, OK, if you insist, but basing it on the domain ??????????)
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
@Tsaukpaetra said in Security Snake Oil Inc.:
@dkf said in Security Snake Oil Inc.:
@TwelveBaud said in Security Snake Oil Inc.:
I think PKCS is technobabble in this context
It might just mean “use HTTPS”, which it should definitely do if it isn't and it needs to check the server identity. No point in having a cryptographically secure channel to any old random attacker.
Yeah, I recently tried to MiTM a particular app so I could reverse engineer the protocol (for the purposes of enhancing user experience, of course), and was moderately dismayed that it verified the CA. Whomp wah.
Just the CA chain, or was it using a pinned certificate, where it has the (public part of the) actual server certificate and verifies that the one it receieved was that one?
And if it's verifying the CA chain, is it using the system repository of root CAs (so you could wedge your CA in there)?
There's two things to check if you're being paranoid. One is that the leaf certificate is for the server you think it is (hostname matching). The other is that the root CA is the one you expect. You don't normally worry too much about the intermediates if they check out mechanically (the sort of thing the security library probably auto-checks for you), but ensuring that the root of trust is right is pretty important. And stops all MITM fuckery (unless someone is playing very naughty games).
From the other side, you can usually easily see where a system is talking to using a proxy, and pretty much everything has to support those, but what they're saying is shrouded. The “I'm going to spy on everything” approach that some places take is absolutely disgusting and the very thing that HTTPS should prevent.
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
basing it on the domain ??????????)
It's been a thing on Android for ages, where it's part of the app descriptor (and so is subject to verification as part of the app store system).
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
basing it on the domain
Indeed. Care to explain why a link to https://twitter.com should not open the Twitter app if it has been configured by the user to do so?
To clarify, on Android, which I believe is the only place that domain-based works all the time (as opposed to desktop, which doesn't?), when you install an app that describes itself as capable of handling a URL, you are given the option to pick it as the default. The app can't just steal every link without permission from you.
-
@dkf said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
@Tsaukpaetra said in Security Snake Oil Inc.:
@dkf said in Security Snake Oil Inc.:
@TwelveBaud said in Security Snake Oil Inc.:
I think PKCS is technobabble in this context
It might just mean “use HTTPS”, which it should definitely do if it isn't and it needs to check the server identity. No point in having a cryptographically secure channel to any old random attacker.
Yeah, I recently tried to MiTM a particular app so I could reverse engineer the protocol (for the purposes of enhancing user experience, of course), and was moderately dismayed that it verified the CA. Whomp wah.
Just the CA chain, or was it using a pinned certificate, where it has the (public part of the) actual server certificate and verifies that the one it receieved was that one?
And if it's verifying the CA chain, is it using the system repository of root CAs (so you could wedge your CA in there)?
There's two things to check if you're being paranoid. One is that the leaf certificate is for the server you think it is (hostname matching). The other is that the root CA is the one you expect. You don't normally worry too much about the intermediates if they check out mechanically (the sort of thing the security library probably auto-checks for you), but ensuring that the root of trust is right is pretty important. And stops all MITM fuckery (unless someone is playing very naughty games).
Just matching the hostname means exactly nothing. A faked-up certificate made by a competent MitM device will have the right hostname. Full-whack certificate pinning checks the whole certificate, serial number, dates, fingerprint, etc., including the CA chain, normally by having a copy and simply comparing all the fields. (If you received the one you expect, you can trust it to provide you with a replacement for when it expires. If you can't trust it for that, then you can't trust anything on the server and you might as well give up and go home.)
As for those naughty games, well, the alphabet soups have an incentive to play those, but TLS is designed to make the presence of the MitM visible, and full-whack pinning helps a lot. It's just slightly impractical for general web browsing.
From the other side, you can usually easily see where a system is talking to using a proxy, and pretty much everything has to support those, but what they're saying is shrouded. The “I'm going to spy on everything” approach that some places take is absolutely disgusting and the very thing that HTTPS should prevent.
Prevent or make visible. What's dangerous is an MitM device that can snoop the cleartext without any possibility of anyone knowing it's there.
-
@sloosecannon said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
basing it on the domain
Indeed. Care to explain why a link to https://twitter.com should not open the Twitter app if it has been configured by the user to do so?
If the user has configured it, sure, I guess so, although I'm not sure that popping up a box at install time asking for permission counts as "configured by the user". It smells too much of "Oh, here's another box asking me something and getting in the way of me using the app, press Yes / OK / Confirm / Allow."
-
@cartman82 said in Security Snake Oil Inc.:
That's why we have shit like bank password policies accumulate like fat in our veins
The funny thing is that because they REQUIRE a special character, you know that at least one isn't NOT a special character, reducing the possible combinations as much as they increase them for that one character.
Ultimately it increases the possible combinations, but only because the special characters are allowed, not because they are required.
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
A faked-up certificate made by a competent MitM device will have the right hostname.
Sure, that's a different security check. It's the CA root pinning that stops what you're talking about, since the public root CAs don't let their sub-CAs do that sort of shenanigans.
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
It smells too much of "Oh, here's another box asking me something and getting in the way of me using the app, press Yes / OK / Confirm / Allow."
What you actually get is, at the time that the link is followed, a pop-up asking you what you want to open the link in and whether you want this to be a permanent choice. It defaults to asking you every time.
-
@dkf said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
A faked-up certificate made by a competent MitM device will have the right hostname.
Sure, that's a different security check. It's the CA root pinning that stops what you're talking about, since the public root CAs don't let their sub-CAs do that sort of shenanigans.
Well, the intelligence services for the country whose laws the CA is subject too can probably get any certificate they want signed. That'll have the same chain of trust, but a different final certificate because private cryptographic material differs.
-
@dkf said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
A faked-up certificate made by a competent MitM device will have the right hostname.
Sure, that's a different security check. It's the CA root pinning that stops what you're talking about, since the public root CAs don't let their sub-CAs do that sort of shenanigans.
May I direct your attention to a long-since defunct outfit called DigiNotar? They did, indeed, do a certain amount of those shenanigans.
If you want to do certificate pinning, you do it properly or not at all, and "properly" means that you compare the whole certificate, not just the ultimate root.
EDIT: I should point out that DigiNotar is defunct because the browser makers killed it, not because its parent CA killed it.
-
@dkf said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
It smells too much of "Oh, here's another box asking me something and getting in the way of me using the app, press Yes / OK / Confirm / Allow."
What you actually get is, at the time that the link is followed, a pop-up asking you what you want to open the link in and whether you want this to be a permanent choice. It defaults to asking you every time.
It still smells of "I can't run this thing, yes, of course I allow it," which has exactly nothing to with actual informed consent.
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
@Tsaukpaetra said in Security Snake Oil Inc.:
@dkf said in Security Snake Oil Inc.:
@TwelveBaud said in Security Snake Oil Inc.:
I think PKCS is technobabble in this context
It might just mean “use HTTPS”, which it should definitely do if it isn't and it needs to check the server identity. No point in having a cryptographically secure channel to any old random attacker.
Yeah, I recently tried to MiTM a particular app so I could reverse engineer the protocol (for the purposes of enhancing user experience, of course), and was moderately dismayed that it verified the CA. Whomp wah.
Just the CA chain, or was it using a pinned certificate, where it has the (public part of the) actual server certificate and verifies that the one it receieved was that one?
And if it's verifying the CA chain, is it using the system repository of root CAs (so you could wedge your CA in there)?
I can't easily divine the specifics, but it definitely wasn't pulling from the system or user stores.
-
@xaade said in Security Snake Oil Inc.:
The funny thing is that because they REQUIRE a special character, you know that at least one isn't NOT a special character, reducing the possible combinations as much as they increase them for that one character.
I don't think so - after all, you do not know at which position the special character is at.
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
@sloosecannon said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
basing it on the domain
Indeed. Care to explain why a link to https://twitter.com should not open the Twitter app if it has been configured by the user to do so?
If the user has configured it, sure, I guess so, although I'm not sure that popping up a box at install time asking for permission counts as "configured by the user". It smells too much of "Oh, here's another box asking me something and getting in the way of me using the app, press Yes / OK / Confirm / Allow."
Ah, my phrasing on that was poor. "When you install" is not saying it pops the box up then, I meant to say it pops the box up the next time you click a link (due to installing the app)
Here's an example:
-
@xaade said in Security Snake Oil Inc.:
@cartman82 said in Security Snake Oil Inc.:
That's why we have shit like bank password policies accumulate like fat in our veins
The funny thing is that because they REQUIRE a special character, you know that at least one isn't NOT a special character, reducing the possible combinations as much as they increase them for that one character.
Ultimately it increases the possible combinations, but only because the special characters are allowed, not because they are required.
The real security improvement is allowing a password to be about 100 characters long and encouraging people to use most of it.
I believe in password strength bars. I don't believe in restrictions.
-
@Shoreline My university has password requirements, all of which are lifted if it exceeds 16 characters. I think that's a good middle ground.
-
@TwelveBaud said in Security Snake Oil Inc.:
a native app intercepting data intended for a web app by using an app handler registration, which is equally viable on both mobile and desktop now
All the systems allow an app handler for a custom scheme, but the redirect somewhat obviously does not go to that. As far as I can tell, iOS only allows handlers for web pages if the web page allows it via some manifest, so no luck there. Android does allow it, subject to a dialog (unless the page has specific manifest), but I had the impression browsers generally don't run all page opens through intents, so if you are already in a browser it wouldn't follow that (I am thinking about checking, but it's been a while since I last built anything for Android so I don't want to waste time setting up the build env for this). I don't think desktop browsers check for handlers of schemes they understand either.
@dkf said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
basing it on the domain ??????????)
It's been a thing on Android for ages, where it's part of the app descriptor (and so is subject to verification as part of the app store system).
You mean you'd trust play store verification to actually do anything‽ It didn't trigger for opening links inside the browser though, only from other apps, and I hope it didn't start.
I guess that people don't want to rely on browsers remaining sane and not searching for app handlers on all page opens, so using PKCS is a precaution in case it happens that is already implemented for native apps that do rely on the handlers so it is cheap to add.
@TwelveBaud said in Security Snake Oil Inc.:
but anything that has the possibility of sockpuppeting your application in a frame or raiding its cookie jar works
I don't think PKCS would help with those. For frames the correct policy needs to be set and anything that can raid the local storage (it's not a cookie in either OAuth) owns the app completely, so no benefit of PKCS there either.
@TwelveBaud said in Security Snake Oil Inc.:
You're right that it's obsolete though.
… it was dropped from the latest documentation, too.
-
@xaade said in Security Snake Oil Inc.:
@cartman82 said in Security Snake Oil Inc.:
That's why we have shit like bank password policies accumulate like fat in our veins
The funny thing is that because they REQUIRE a special character, you know that at least one isn't NOT a special character, reducing the possible combinations as much as they increase them for that one character.
Ultimately it increases the possible combinations, but only because the special characters are allowed, not because they are required.
There was a joke, already 20 years ago. like:
… admin sends out an email to all users:
The new password rules require that
- passwords are 8 to 12 characters.
- there must be a lowercase letter, uppercase letter, a digit and a special character (
!@#$%^&*(){}[]:;'"<>,.). - the digit must come after a letter
- the special character must not be at the end
…
…
So everybody please pick one of the following passwords carefully constructed to fulfil the requirements:
Az5!@[A]uBh9,-(z)apI6:Q{t}aF3q"d<t>i
Thank you for your cooperation,
Sincerely,
Your BOFH
-
@TwelveBaud said in Security Snake Oil Inc.:
raiding its cookie jar
I've never heard this before, somehow, but I love it
-
@pie_flavor said in Security Snake Oil Inc.:
@Shoreline My university has password requirements, all of which are lifted if it exceeds 16 characters. I think that's a good middle ground.
A friend of mine likes to use an all-text password. It's seven words from an obscure poem in a foreign language.
-
@Mason_Wheeler said in Security Snake Oil Inc.:
@pie_flavor said in Security Snake Oil Inc.:
@Shoreline My university has password requirements, all of which are lifted if it exceeds 16 characters. I think that's a good middle ground.
A friend of mine likes to use an all-text password. It's seven words from an obscure poem in a foreign language.
A decent choice for a password you're going to have to memorize.
-
A lot of security guidance is cargo cultism because do you really want to be the guy that argues with the security department? Particularly when it's the security department of a client or prospect.
I just use 'password2'. Only 'password1' is in the default guess list.
(Yes that is a joke.)
-
@Steve_The_Cynic said in Security Snake Oil Inc.:
@dkf said in Security Snake Oil Inc.:
@Steve_The_Cynic said in Security Snake Oil Inc.:
It smells too much of "Oh, here's another box asking me something and getting in the way of me using the app, press Yes / OK / Confirm / Allow."
What you actually get is, at the time that the link is followed, a pop-up asking you what you want to open the link in and whether you want this to be a permanent choice. It defaults to asking you every time.
It still smells of "I can't run this thing, yes, of course I allow it," which has exactly nothing to with actual informed consent.
Aside from the flat design "is this plain text a button?" brainworm, it's pretty clear what it's asking and what the options are.
-
@hungrier Sorta
- When you try to phish enough users this way, some will take the bait even if by simply misclicking.
- I don't see how, but maybe somebody could make the user click, some time in advance, the always option with some trick like this (see here for more detailed discussion).
-
@Bulb But does it really matter? The biggest pay-off you could possibly get from "tricking" someone into clicking wrong in that popup would be to open
[somedomain]URLs in an app that they've already got installed. It doesn't send credentials or anything like that, unless maybe your URL is brain-dead and includes login details
-
@Bulb said in Security Snake Oil Inc.:
I don't see how, but maybe somebody could make the user click, some time in advance, the always option with some trick like this (see here for more detailed discussion).
Simulating clicks requires an even more convoluted system, including switching to the settings app and several other steps. In fact, being able to interact with any other app (aside from passing an intent) is pretty hard to do in general
-
@hungrier said in Security Snake Oil Inc.:
@Bulb But does it really matter? The biggest pay-off you could possibly get from "tricking" someone into clicking wrong in that popup would be to open
[somedomain]URLs in an app that they've already got installed. It doesn't send credentials or anything like that, unless maybe your URL is brain-dead and includes login detailsThe application is of course the attacker's application, masking as BonBon Crush Epic or something like that. So it does send the credentials out (there is no legitimate app for this site anyway).
@sloosecannon said in Security Snake Oil Inc.:
Simulating clicks requires an even more convoluted system, including switching to the settings app and several other steps. In fact, being able to interact with any other app (aside from passing an intent) is pretty hard to do in general
It isn't about simulating clicks, but about making user aim the finger to click something and redirecting them to the right site at the right moment. Yeah, clicking the always is two clicks, so it's unlikely to work in this case. But given enough tries, some users will probably misclick.
-
@Bulb said in Security Snake Oil Inc.:
The application is of course the attacker's application, masking as BonBon Crush Epic or something like that. So it does send the credentials out (there is no legitimate app for this site anyway).
The user would still have to have the app installed in the first place (which is hard to do by accident), and if they already have the app installed it's much easier to get it to do nefarious things just by asking for permissions at install time, without the need to hijack URL association. And again, unless your website's common urls are in the form
http://morons.com/index.php?username=you&password=hunter2, there's no credentials being given to the app. All it gets is something like Intent.OPEN(some url).
-
@sloosecannon said in Security Snake Oil Inc.:
@Bulb said in Security Snake Oil Inc.:
I don't see how, but maybe somebody could make the user click, some time in advance, the always option with some trick like this (see here for more detailed discussion).
[...] In fact, being able to interact with any other app (aside from passing an intent) is pretty hard to do in general
Which is often a requirement for a sand-boxed security system
-
@bobjanova said in Security Snake Oil Inc.:
A lot of security guidance is cargo cultism because do you really want to be the guy that argues with the security department? Particularly when it's the security department of a client or prospect.
I've done that plenty of times.
In my current gig, the customer held a security rules edumacation for all the devs. I picked holes in pretty much all their opinions on security, and even pointed out a couple of instances where their references said that you should do the exact opposite of what they wanted everyone to do.
Not that it mattered, they persisted in their idiotic rules, and I kept ignoring them.I get away with it as well, as the systems I build for this particular customer are the only ones that gets green lit by their penetration testing consultants on the first try.
You'd think that that made them realize I actually know what I'm talking about, but no.
-
@hungrier said in Security Snake Oil Inc.:
The user would still have to have the app installed in the first place (which is hard to do by accident), and if they already have the app installed it's much easier to get it to do nefarious things just by asking for permissions at install time, without the need to hijack URL association.
Negative. It still lives in the sandbox that is separated from the browser and there is no permission that would allow directly exfiltrating information from the browser.
@hungrier said in Security Snake Oil Inc.:
And again, unless your website's common urls are in the form http://morons.com/index.php?username=you&password=hunter2, there's no credentials being given to the app.
You should really look up how OAuth2 works. There is a redirect from the authentication server's page back to the application that contains a one-time code to be redeemed for authorization and refresh tokens and because it is a redirect and there are very limited options where to put a token in a redirect, it does live in query parameter. And this one redirect is the one that happens to be possible to hijack.
-
@Bulb said in Security Snake Oil Inc.:
@hungrier said in Security Snake Oil Inc.:
The user would still have to have the app installed in the first place (which is hard to do by accident), and if they already have the app installed it's much easier to get it to do nefarious things just by asking for permissions at install time, without the need to hijack URL association.
Negative. It still lives in the sandbox that is separated from the browser and there is no permission that would allow directly exfiltrating information from the browser.
Absolutely. However, if it's some nefarious app it could get direct access to things like location, contacts, audio recording, etc with its own permissions.
@hungrier said in Security Snake Oil Inc.:
And again, unless your website's common urls are in the form http://morons.com/index.php?username=you&password=hunter2, there's no credentials being given to the app.
You should really look up how OAuth2 works. There is a redirect from the authentication server's page back to the application that contains a one-time code to be redeemed for authorization and refresh tokens and because it is a redirect and there are very limited options where to put a token in a redirect, it does live in query parameter. And this one redirect is the one that happens to be possible to hijack.
To take advantage of that, the malicious app (and likely the user themself) would have to thread a very fine needle: First, the user would refuse to "always" open
morons.comlinks in the malicious app (or even the legit app), to get to the oauth login, and only after that, to open the oauth redirect in the app. Or the malicious app would have to install itself in the window of time while the user is logging in.Also, I may be misremembering, but IIRC there's another verification that the client using the code to get its token is indeed the original client that requested the login, specifically to prevent url hijacking like you described
-
@hungrier You really seem to have no idea how OAuth2 usually works.
The user goes to
https://morons.comand clicks login. They are redirected tohttps://login.microsoft.com/some/path?with=query, which is, notably, outside of themorons.comdomain (not that it matters too much). That authenticates the user and then produces a redirect withlocation: https://morons.com/auth?code=ebea7b2db19af9ac, which should then redeem the code for a bearer token. But the nefarious application registered itself forhttps://morons.com/auth, so the user gets dialog whether to open it in the app or again in the browser. And if they misclick, the credentials gets stolen.The dialog is surprising and does not seem to make much sense, so it is quite likely that some less technical user does. Now it is a lot of work to hack such an uninteresting application as I am currently working on. But on some high profile ones it is definitely imaginable someone will try.
-
@Bulb I've been up to my ass in authentication for the past few months for work, thanks. I know the general lifecycle, and that's why I said the nefarious app would have to register itself while the user was logging into the oauth provider (MS, Google, whatever), so as to not intercept the initial request to
morons.com. I'm not 100% sure about registering domain handler apps in Andriod, but I think it's for domain only, not prefix, however if I'm wrong about that then maybe it would work the way you described.But my initial point still remains that the user has to install some malicious app, and once you have that it's far easier to have the non-technical user click the
Chase Bank Not Chinese Hackershortcut and enter their information directly into the app.
-
@hungrier The application can register only specific path, so it can intercept the redirect back without triggering on the initial entry.
-
@hungrier The UI only shows domains, but the registrations are for full URL patterns.
-
@TwelveBaud said in Security Snake Oil Inc.:
@hungrier The UI only shows domains, but the registrations are for full URL patterns.
Which implies the “always” part of the UI is a lie.
-
@Bulb Um, there's one small snag to your scheme: You cannot register a link between a website and an application without access to the website itself. Android will check if this URL exists and has the proper content:
https://domain/.well-known/assetlinks.jsonIf it doesn't, your app can register app-links all it wants, they simply won't be presented as a choice.
