OAuth Attack Vectors
portswigger.net
portswigger.net
I spent a while complaining every time I saw one and nearly always got brushed off.
Then I realised that even large companies do this. The most recent example was Microsoft doing it in the Windows Gamebar!
So I give up. If anyone wants to harvest passwords just release a few apps that claim a legitimate need to login to Google, Facebook, Amazon or anything else you want access to.
EDIT - what's the correct thing to do? Launch the user's browser where there is a slightly higher chance that they will be able to spot that things aren't legit. And if they are using a password manager that will refuse to fill in the site and is much more likely to alert them.
The two simple rules:
1. Never enter your password in a 3rd party app
2. Always use a password manager
are simple to explain to non-technical users and fairly robust.
Some sites allow and encourage the user to customize their login page. The attacker the must reproduce the unique login page for each user.
Unless I'm misunderstanding you? The webview is equivalent to "show the login page in a sandboxed browser" - there is no memory of any customization.
Sure, it's a bit more work than setting up a random HTML form, but if you're already running a somewhat targeted attack it may be worth it.
It's also not clear to me why the apps don't launch the system browser. The IntelliJ IDEs do this. Added bonus is the sign-on is actually... single, since I'm probably already logged in to the service.
Even a command-line tool, awscli, is able to figure out how to launch a browser, use whatever session is active, populate the device code on the form, etc. All I have to do is click the button "yup, I actually asked for this happen". And this is running on Linux without a fancy DE or anything.
MS Teams however, does it in its own browser, restarts five times, etc.
It seems to me that this idea of simplification (the user doesn't even have to switch apps!) has been pushed too far, to the point of actually making things more complicated for the user and in the process decreasing security.
People are awful at recognizing phishing. Straight up.
That population includes me. I'm in danger of being phished by 3rd party apps.
> People are awful at recognizing phishing. Straight up.
Yes - which is why password managers are a key part of the solution. They match on URLs and require an extra step to bypass.
The reason password managers make websites safer as opposed to apps is that the match the url and fill in the credentials automatically. If you are being phished, the urls won't match and the password manager will usually warn you if you try and force it to fill in the credentials.
For a webview inside an app - they don't autofill anything and it's always manual - meaning the user has to be vigilant.
But that has nothing to do with OAuth. A malicious app can already phish you by impersonating another app.
Yes but that requires a host of other things to go wrong first.
My point is basically "Don't enter your credentials into any app". There might be exceptions for 1st party apps but these are much less common and the OS already has protections in place (of varying levels of effectiveness).
Reminded me of Mint which did the same when I looked at it a few years ago.
The financial system is so far behind tech wise its crazy, maybe even irresponsible.
For example, Plaid now will open the banking app on a mobile device to continue authorization.
And 2FA codes. And TOTP codes. From what I’ve seen users have been trained to enter credentials everywhere and constantly.
Edit: Clicked and it's about OAuth2, but also OpenIDConnect (an extension to OAuth2, but actually a distinct protocol)
> From a pentesting point of view, whenever you test an OAuth application, there is a good chance that the target server also supports OpenID
Again playing very loose with the terminology. OpenID (no "Connect") is yet another completely unrelated protocol.
Precision is great, but some assumed terminology will happen in forums that frequent the terms.
The whole time I was there I was gaslighted about some protocol level implementation concerns I had
Part of their job was posting on hackernews about how awesome and perfect Oauth2 was
Oauth2 and Json Web Tokens!!!11!
They didn’t actually know better but were also not open to their own employee’s questions
Everything that proves them wrong always make me think of them
Everything has its place
The federation ecosystem is so full of needless complexity. Simple is secure.
> /openam/.well-known/webfinger?resource=http://x/dsameuser)(sunKeyValue=userPassword=A*)(%2526&rel=h...
Rofl. I get that its an injection vuln so you dont expect users to be able to trigger this, but why tf would wildcard searching of passwords be implemented in the first place in ldap.
I guess the app/server is quite badly configured, like having your app run as dba.
To provide a more complete answer to your question: there's really nothing special about a password field as far as an LDAP server is concerned. It's just a field like any other; it can have rules applied to it, as well as processes, to alter what data is ultimately stored but it depends on people implementing the rules. There are standards, etc., but it's rare anyone follows them properly.
Having worked with it extensively at one point in my career my impression is that few people really understand how LDAP works at its core. People associate it with authentication because that's mostly what they use it for but it can effectively work as a data store for anything you want to keep a directory of. Another common use is device registrations and ownership (in AD this is Machine accounts). It's a very flexible system that could be used to replace any kind of structured data store if you want it to.
This all leads back to the fact that while you can apply some rules to the structure of the LDAP and to individual fields, it's not as though the LDAP knows or cares that an attribute called "password" should have special treatment when it comes to querying if you don't tell it that.
Ultimately the software should be performing a bind (authentication) to the LDAP as the user, rather than trying to look the user up using queries while bound as a superuser or some other high-privilege user.
It would be possible to achieve the same thing in a privacy-preserving way, and without breaking current deployments; EL PASSO https://arxiv.org/pdf/2002.10289.pdf is an example of it.
But looks like there is no (commercial?) interest in improving user’s privacy.
On the other hand, the implementations offered by Google, etc..
It's kinda like deciding on a data layer. You have to do it, you have to get it right, but it's not a feature your end users are going to love.
Agree overall but I don't think you can ever get either "data layer" or "auth" "right" forever, it's a constantly evolving thing that changes over time. What's "right" today is not necessarily "right" tomorrow.