I am working on an iOS app in Monotouch. Part of it is to connect to an exchange server and download a list of emails. I would like to include the ability to open the email in the OWA client as well (so I don't have to recreate a email client to provide features OWA gives me for free).
I don't want the user to have to input credentials again however. Opening OWA in safari would usually present the user with either a form or a pop up asking for username and password.
Say I have a user admin with password password1. Currently what I do is request safari to open a link in the following form:
https://admin:password1#mailserver/exchange
This passes the credentials to safari and bypasses the HTTP basic authentication that OWA would usually pop up, however it is not very safe and safari complains of a possible phishing attack.
What other options are there for performing this kind of bypass of HTTP basic authentication?
I would recommend using HttpWebRequest to download each page and set the UIWebView's text manually. Using HttpWebRequest gives you the flexibility to use whatever cookies, credentials, http headers, etc. you want.
This will be tricky, but probably the only way to safely get the credentials in there. Not sure if your OWA app will be able to handle it either.
Related
My app has an embedded WKWebView that we use to show custom user content served from the users organization. A few organizations are using HTTP authentication (NTLM) so I am working on supporting this. I've implemented the necessary delegate function (webView didReceive: completionHandler:) and create a UIAlertController with two text fields to allow the user to input their username and password. Functionally, this works and allows the users to log in to their organizations site.
However, because I'm creating the alert controller in my app, usernames and passwords are saved and suggested using the apps associated domain. While technically this makes sense, it is confusing for our users to be logging in to their website but seeing a password suggestion coming from our domain.
I haven't found any way to get the WKWebView to display its own username and password prompt. I've considered trying to inject some javascript to show the prompt, but I'm far from a javascript expert and I'm concerned about causing issues with existing javascript on our customers sites (and I don't know if it will still use the app domain anyway). Edit - tested this, the app domain is still used.
https://developer.apple.com/documentation/security/password_autofill/ seems to say that there's no way to use a different url.
Is there anyway for the username and password to be saved using the url that is being loaded in the web view instead of the apps associated domain?
Using this page: https://developers.google.com/identity/sign-in/web/sign-in
It's really easy to add a button to a page for a client side only login with Google.
On Clicking the button, the user is presented with a screen like this:
There are 2 ux_mode for this button: "popup" and "redirect":
https://developers.google.com/identity/sign-in/web/reference
My question is about ux_mode=popup specifically, where the originating page doesn't change, and all the login flow is handled in a separate popup window.
Imagine a good app is published. It seems like an attacker could clone the app, present it to a user. The user thinking it's good app would login and the attacker would have a way to grab a valid token from the user for good app.
Now I understand that in that mode (popup), the IDP (Google) will reject anything that doesn't come from an Origin that is not part of the explicit list of redirect URIs set in the configuration of the project.
But is that the only thing that prevents this? I have read again and again that one should not rely on CORS for the security. Also I'm not sure but it seems that it can be circumvented with a little bit of crafting.
Is there another aspect of the security of this login flow I am missing?
I do not know google implementation but from OAuth 2 point of view:
1/ "The user thinking it's good app" user should check the address bar and a green lock in his browser. It is considered as a users responsibility.
2/ you registered redirect uris which are checked when client is trying to get access token. So google will reject to generate and redirect users browser to malicious app with the token.
3/ browser will reject any communication between popup window and other webpages since they are not same origin. This is called same origin policy and is considered as important security feature of a browser.
In general: app location/uri/origin/domain (as you want) is what identifys your app and security is based on that.
Hope it helped.
I am writing a Reddit client that uses OAuth to authenticate the user. One of the features I would like to implement is the ability to use multiple accounts simultaneously. This requires the user to authorize my client on each account they want to use. The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
Is there a way to force the user to re-enter their credentials? I would rather not have to put some kind of disclaimer on my Add Account screen that says "Please log out of Reddit in any open browser windows".
I tried opening the Reddit login page in a WebView so the request is sandboxed, and while that worked, it gives the user access to the entire login page (including all the links that navigate to elsewhere on the site). I don't mind that experience when I'm popping an external browser, but in an embedded WebView I really just want to present a username and password box along with the OAuth validation prompt.
Note: I do kind of prefer the embedded experience because it doesn't interfere with the users existing browser cookies, I just don't like how cluttered the login page is this way and I'm not sure how to prevent the user from navigating away from login. Also, for completeness, this is a UWP app, though this problem is largely technology independent.
The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
It may be caused by the authorization server. If so, we can not do anything in our client app.
But if it is not the server issue, in UWP, there is a WebAuthenticationBroker class witch can help you to authorize your app to access the user info from Resource server by getting a token. You can try to use the class to implement OAuth authorization. You don't need to use the in a WebView so that you can authorize your app with multiple users if you can manage all the user with the token properly in your code logic.
See the Web authentication broker topic and the sample to learn more details.
The Scenario:
A web application that once a new user completes the registration, an email will be sent, containing a URL that once tapped from within an iOS device, the iOS app will be launched. This scenario is a classic scenario to make users use the mobile app.
While implementing it (using URL scheme), we start wondering how secured is this method? Theoretically - a malicious app could sign up to the same URL scheme, and according to Apple:
Note: If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme.
Implementing Custom URL Schemes by Apple
In such scenario, if a user is tapping the url inside the email, it is unknown which of the two (or more apps) will be launched - ours or the malicious one. Lets say a different app is being launched - if its really malicious, theoretically it could mimic the login page of our app and grab the user's credentials.
Are there any best practices that handles such scenario? I've read many articles regarding the issue, all of them claims that the only solution is to wait for Apple to make these url schemes unique.
example1,
example2
I would love hearing about any solution to the issue if exist,
Thanks in advance!
We have to assume the malicious app can intercept any data included in this url and that it's author has been free to reverse engineer any behavior included in your app so it can imitate your UI and any validation your app attempts to perform. However we can also assume that the malicious app is contained in its own sandbox so your app can communicate with your backend privately. The malicious app can imitate any such communication but this does allow us to construct a secret unknown to the malicious app. That gives us at least an opportunity to design some countermeasures.
One option might be:
As part of registration construct a public/private key pair and store it in your app.
Send the public key to your web backend as part of the registration process.
Encode they payload of your URL using that public key.
Now we've sent data to your app which might be redirected to a malicious app but which the malicious app cannot read. That's a partial solution. We still need to be careful to design a UI which does not encourage a user to fall for a phishing attack since the URL might still launch the imposter.
The encoded data might be a token we can use to authenticate the user and therefore never require them to re-authenticate within the app. Then there is no login screen to imitate (though a clever forgery might still be enough to trick users into divulging their credentials).
An alternative might be to use a similar per-user secret stored on the client as a salt to combine with the user's password. Their password alone might then be insufficient to authenticate so a malicious app capturing their credentials is not immediately able to access their account.
Another design could be to allow the user to customize their experience in a recognizable way. You might show their selected profile image on the sign in screen. If that selection is known only to your app then an imitator shouldn't be able to duplicate it reliably (again, no guarantee that means users will catch the deception).
All of this introduces tradeoffs; users might still be tricked into revealing information to malicious apps no matter how different they appear from your legitimate client, client side secrets can be extracted by other attacks, and you need a plan to support users who switch, lose, or upgrade devices. You have to decide if any of this actually improves the security of your users and if it is worth the cost to implement.
Try something like this:
In your email, state that clicking on the URL will launch the app and log you in for the first time then prompt user to enter their new password. Include a token in the URL which, when handled by your app, does a one-off login and put the user on a "New Password" page.
If a malicious app has also registered your custom URL and steals the link, they should (hopefully) not be able to do much with it. Even if they replicate your interface and prompt the user for a new password, it's not going to achieve anything.
edit: After thinking on this further, as long as you have an active attacker, you're pretty much screwed. The attacker could continue to emulate your app, effectively MITMing you, regardless of what you do, as long as they're able to hijack that initial URL. My solution would only work in the most basic of cases, not really reliable.
I have a need to set some context via Safari (a context token), and then read that context from a native iOS app. What are the best practices for doing this?
A couple thoughts so far:
Set the context in an HTML 5 database, but I'm not sure this will work because the database might be only accessible from Safari. Would using a WebUIView in the native app allow me to access the same HTML5 database / local storage as Safari?
Set the context in device storage, but I'm not sure this will work because I don't know if Safari can actually write to device storage.
I would suggest one of these two options:
Let the web server keep track on the user both in the app and on the website, for example by creating a user account.
or
Pass the context token to the app immediately via an URL-scheme by registering your app as a protocol handler, see more info here
Suggested way:
Send e-mail with link and context token, when user clicks link, save context token in cookie in safari, then redirect to appstore for app download.
When the user downloaded the app and opens it, present a button for the user, when the user clicks it, open a web page in safari.
Safari loads the cookie with the context token, and then triggers another link using a URL-scheme like yourAppName://contextToken=12345678. The link opens your app which reads the context token from the URL.
There is no best practice for directly sharing data between safari and a native app directly and that it is simply not intended that you should do that. All cookies and storages are sandboxed for each app and safari has its own sandbox.
Letting your server doing the job via user accounts is the best and clean way i.m.o. That is why you have user accounts. If you didn't try out the protocol handler for reading specific URLs, that could also be made handy I think.
Could you have the app hit a URL on first launch hosted by server which is redirecting the user in safari, and compare IP addresses, time, iOS version, etc to get at least an approximate match? If an approximate match is insufficient, you could, when you see an approximate match, have your app open safari to confirm their identify via cookie.
It’s easy to send messages between a UIWebView and your native up using WebViewJavascriptBridge.
In your case, though, the accepted answer’s suggestion of using a custom URL scheme (directly from email to app, post-install) makes the most sense.