0

Given in OAuth 2.0 or some other Web Application or even REST API server. How would you protect users from using a malicious client or a compromised browser?

For OAuth client secret can be placed in an existing application and extracted Risk of keeping OAuth2 client_secret in application

Even with the use of a redirect_uri, the malicious client can simply take it and still redirect to their own site.

With a normal web app, a XSRF token is still generated on the server and passed to the client and the user can still enter their credentials.

A compromised client can also ignore the CORS checks and send whatever it wants as the Origin header.

I'm sort of leaning towards that the only prevention is to tell users make sure you get your clients/apps/browsers from a trusted sources and it is not really something that can be addressed technically.

|improve this question
  • 1
    Maybe I'm missing something, but a malicious client can just capture the user/pass and then the user is compromised. There is no need for it to do anything fancy beyond that (XSRF, Origin spoofing, etc.) – TTT Dec 5 '17 at 20:20
  • No you’re not missing anything. – Archimedes Trajano Dec 5 '17 at 20:26
  • I am mulling over it but the onus is really on the user to be careful what to trust – Archimedes Trajano Dec 5 '17 at 20:31
  • The malicious client doesn't even need to communicate your server. It can just ask the user "Hey, what's your ArchimedesApp password?" and if the user enters their password then the attacker knows their password. Nothing you can do technically can prevent that. – user253751 Dec 6 '17 at 2:10
2

I'm not sure there as a good answer to this question.

Given in OAuth 2.0 or some other Web Application or even REST API server. How would you protect users from using a malicious client or a compromised browser?

The usual question here is "How do I protect the server / other users from a compromised client?". That's a tricky question, but there are answers through designing the app with malicious users in mind.

Your question is different. If I'm understanding your question properly, your user has willingly given their account credentials (in whatever form those are, username/pass, OAuth2 token, wtv).

Example scenario: Let's take "malicious client" to be a version of Firefox that I modified the source for, built into a binary, and got you user to install. There's some code in there to trigger once the user logs into facebook.com. Once the user logs into facebook, the attacker has now become the victim as far as the facebook servers are concerned. Moreover, the attacker now controls both what gets sent to the server and what gets displayed to the user. That's infinite power.

Law #1 seems to apply:

Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.

I agree with you; other than training users not to install sketchy software, there's not much you can do to protect them.

The good news is that for a well-built application, the compromised user is only hurting themself, the rest of the userbase remains un-compromised, but that's outside the scope of your question.

|improve this answer
  • My guess is that this would also apply to phishing links that look like the site but the users go to it by email. And the phishing site acts like a reverse proxy. – Archimedes Trajano Dec 6 '17 at 12:48
  • Yeah, I guess philosophically, installing applications or visiting websites are both ways of running client code on your machine. In both cases the user needs to be careful where that code came from. – Mike Ounsworth Dec 6 '17 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.