Updated with clarifications
Hello,
When our users go to http://mysubdomain.server.com/login they get redirected to https://secure.server.com/login?subdomain=mysubdomain. So the actual login page is located on the secure.server.com subdomain.
The problem is that if the user logs in with the credentials meant for subdomainA and tells Firefox to remember the password, the browser will autocomplete the login form even if the user visits the login page meaning to log into subdomainB.
Firefox assumes that the login form on secure.server.com/login?subdomain=subdomainA is the same with the one on secure.server.com/login?subdomain=subdomainB.
At first, I thought Firefox remembers passwords based on a combination of the URL and the name attribute of the form, but I've tried changing the name based on the subdomain (name="login-<subdomain_name>"), and it still doesn't work.
How can I make Firefox remember passwords for subdomainA and for subdomainB separately, and not together?
I couldn't quite decipher what your setup is, but you can enable login manager debugging and check what Firefox does. You can also inspect signons.sqlite in your profile to see what pieces of data are stored with the login.
I thought that for web forms it keyed off the form's submit URL, but my memory is shady on this.
[edit]
source (nsLoginManager.js) says it only uses the form's action and the page's URL, and it uses not the action/page URL itself, but (see _getPasswordOrigin) the scheme+host+port combination.
If they're actually entering data into http just to be redirected to https after login, isn't that a bad scenario? You're already sending the most sensitive piece of data unencrypted across the wire.
I believe a better solution would be to redirect them to the https site and do login there...is there something I'm missing with your setup? Do they login again on the secure site?
AFAIK domain name (complete) is the current basis for remembering login. It wasn't always so, though. I'm not sure about protocol or port number, but a.domain.com is different from b.domain.com and domain.com, but same as a.domain.com/somewhere.
Related
In implementation of Login, I want to make sure if a user is already logged in one tab of the browser and opens the same web site in another tab, he gets redirected to homepage rather than the log in page. It's an ideal scenario as it happens in all the web site. I am achieving the same by storing logged in unique user token in local storage. Is it the best way to achieve it? Kindly guide! is it safe? If not how to go about it?
Just consider everything on the client as tainted or possibly manipulated.
So basically you should always check on the server side if the client has a valid session and only then deliver the homepage to it.
I would use a cookie set by the server side - just a random id bound to the actual client session on the server.
So the client could mess with that, but would have a hard time to guess another (also random) session id.
The cookie should be cleared by the server if the user logs out.
Then I would check on every call if he has a valid session id and if not directly send him to the login page by a redirect. Additionally you could then send him from the login page to the homepage whenever he is already logged in.
I have very little experience with APIs which is something that I'm trying to change so I'm trying to get started with the Tumblr api. I've installed the tumblr_client gem (documentation here) and am following the instructions. I've created an application on a new Tumblr account and have the necessary OAuth information (consumer_key, consumer_secret, ect.) Actually getting it to do something is proving difficult, so like a good little programmer I'm trying to get the console going to explore a bit.
This requires a bit of setup, so I'm following the instructions here:
The first time that you go to use the irb console, if you have no
.tumblr file, it will walk you through the process of generating one.
You will be prompted for your consumer_key and consumer_secret (which
you can get here: http://www.tumblr.com/oauth/register) and then sent
out to the site to verify your account. Once you verify, you will be
redirected to your redirect URL (localhost by default) and copy the
oauth_verifier back into the console. Then you're all set!
I'm prompted for my key and secret, then I go to the URL where I'm supposed to give authorization. Tumblr gives me a popup which reads "Is it alright for this application to access some of your data and make posts to your account? You are logged in as example#example.com" and the options to cancel or allow. I hit allow and it just takes me into the account itself, at no point am I ever given any kind of verification code that I can put in to get the console working.
At this point I'm stuck and can't go any further so I'm activating the network. Any ideas as to where I'm going wrong?
Did you specify a redirect or callback url at any point in the oauth config process? It's probably done on tumblr's API website. This url would be your app's endpoint to which Tumblr sends a request to with the user's data. By the way, oauth can sometimes be confounding to set up. You won't be able to use localhost as a callback url, for example, though you can get a temporary domain name with a free local tunneling app.
edit To go into more detail on some of these points ...
callback url: To reiterate, this cannot be localhost. Setting the correct callback url will get you unstuck from your current predicament. Instead of redirecting to the tumblr homepage, you want the confirmation page to redirect to your app. Anyway, I think you're totally sensible to want to test it out before you deploy. But unless you deploy or use a local tunnel, your local application doesn't actually have a URL that can be reached from anywhere except your computer.
local tunnelling services: ngrok, localtunnel. To give an example with ngrok: Say you have a Rails server running on port 3000. Then in another terminal you run ngrok 3000 and you get a url which exposes your local server to the real internet. Note that this changes every time you restart ngrok (unless you pay them). In your application, you should make a unique route for the callback. Say you have a route which matches /oauth_callback to the oauth_callback controller action. Then the route you'd provide as your callback url would be http://MY_CUSTOM_NAME.ngrok.com/oauth_callback.
The controller action: I don't specifically know how Tumblr sends user data to the callback. Perhaps the information is in the headers or maybe it's in the body. It might be JSON or XML. Whatever it is, you can explore the data by placing a breakpoint in your controller action. You can inspect the params, headers, etc. I'd expect that they'd give you some token credentials and probably a user name/email as well.
The general answer you can find everywhere is to use the Signal authenticationRequired(QNetworkReply*, QAuthenticator*), then fill the login credentials into the given QAuthenticator object.
However, this does not work in my case as that signal is never emitted. Reason: The server does not return an authorization failure but redirects me to a login page instead. So my program will just download that page.
I have found out how to catch this by checking the attribute QNetworkRequest::RedirectionTargetAttribute of the QNetworkReply.
So I can detect the redirection and ask the user for auth info.
But... where do I go from there? How do I set the authentication data? Can I manually set a QAuthenticator to my QNetworkRequest or my QNetworkAccessManager? I didn't find a way to do that anywhere, just via the above-mentioned signal/slot mechanism which does not work because it does not trigger.
Any help would be greatly appreciated!
From documentation,
http://qt-project.org/doc/qt-5/qauthenticator.html
QAuthenticator supports the following authentication methods:
Basic
NTLM version 2
Digest-MD5
Since you are getting redirected to a login page, and you haven't indicated if any of the above authentication methods even works, I will assume that it does not because things like Basic authentication is sent on every request to the server. Login pages generally authenticate the client and use some sort of a cookie for future authentication. To do this,
Detect login page
Pass proper credentials to the server (based on what the form wants)
In the QNetworkReply to the login page, look for cookies (Set-Cookie headers).
Pass the relevant cookies back with your requests.
If it works, you are no longer redirected to login page.
For information on cookies, you can get overview via Wikipedia, but for implementation, you need to look at the RFC 6265,
If this is incorrect, and you can use basic authentication, then that information is passed in the URL itself. Set username and password in your QUrl and if it works, you will not be redirected. http://qt-project.org/doc/qt-5/qurl.html#setPassword
I'm working on AJAX login form. On submit it sends login data to back-end. If there is a problem with login, appropriate response is returned. When login data valid, back-end creates a session for user and sends back a URL where user should be redirected. I want to return URL, because it changes depending on multiple user settings (language, personal/business, etc.).
Am I overlooking any security issues with this approach? Is it possible for attacker to redirect user to malicious website when browser trusts URL returned from AJAX call?
No, that's a pretty standard method for handling login via an asynchronous handler (assuming that you're doing this over HTTPS, if not, all bets are off).
And yes, it is possible for an attacker to redirect a user, if you allow the attacker to set where the redirect goes.
So that means that you should validate any user-inputted (and hence potentially attacker set) URLs that you're going to redirect to make sure they are safe. Basically make sure the URL is on your domain, and make sure that it's a valid URL. You can go deeper (check for XSS style attacks, etc), but you usually shouldn't have to as long as you're practicing good security practices in the rest of the application.
But then again, that's just basic application security Filter-In, Escape-Out. So filter the inputted URL, and you should be fine...
I've trying to add a messageboard to my Codeigniter web site. Everything has gone well except for one little part: I'd like my log in from the main site to carry over to the messageboard. Since the messageboard is not able to run in Codeigniter, I made a subdomain to run the messageboard in. This means that the main site and the messageboard do not share cookies. The messageboard is Phorum-powered, so there's a hook that I can use to sign in if I have the user_id of my user. In other words my problem basically boils down to being able to run a function on one domain that can get the user_id variable stored in the session of another domain.
Here are things the I've tried:
Setting up a controller in codeigniter that uses ci->session to echo the user_id. Then in the messageboard, I used CURL to fetch me the output of the codeigniter controller. This doesn't seem to work because CURL doesn't carry cookies or sessions or something, so codeigniter can't access it's session when called through CURL.
Same thing but with file_get_contents. File_get_contents is disabled on my server.
I'm pretty much out of ideas. Does anyone know a function I could write that would get me a CI session stored user_id from a different domain?
Here are two things you can try:
1) host the forum in a subdirectory of your code igniter project. So your two websites will have the url http://mysite.com/ and http://mysite.com/forum. Now that they share the same domain, you can access the session.
2) In your forum login page, display the message "auto-signing in". On that same page add an iframe in the html with the src="http://mysite.com/autologin/tokenid", but hide it with css. The autologin page will have CI session information, which you can temporarily make available to the world via a hard to guess tokenid and by echoing $_SESSION['user_id']. Remember to expire this page when you are done with it. Then refresh the forum's login page and use CURL to grab the publicized session information at http://mysite.com/autologin/tokenid. This is full of security flaws, so do it only as a last resort.