OK, so in building an x domain sso bit of logic we have reach an unknown.
To use JSONP or window.postMessage & MessageChannel (MessageChannel) for windows bastard child IE10.
The logic is (apparently fairly std). One master domain, 2 other domains (site2 and site3).
Logging into site1
user posts a form to master domain.
master domain, logs user into master and redirects back to site1.com/sso?token=uhytchvgjb
site1/sso decrypts token and logs user into site1
This logic works fine and makes sense. Now enter "in-context login". ie, js lightbox popup, login, convert page to logged in state.
The above 3 steps can be done in an iframe but then i would need to deploy the use of postMessage to alert the parent window of a successful login. However upon researching, postMessage is not ie friendly (shocker). So I would have to use MessageChannel, but then then seems like extra work for one annoying browser.
Is it possible to use jquery ajax and jsonp? ie, loggin into site1
user posts via ajax data to master domain
master domain authenticates details and logs in current user and returns in the response a token to the client.
the client on receipt of response passes token back to site.com sso check and returns a success to client
client then converts page to logged state or redirects to rel logged in page.
The above seems sensible and feasible. The question is, if the JSONP method was used, would the client be logged into the master domain or not?
Yes.
When JSONP request will be sent to secondary website, response may contain setcookie headers.
Session cookie can be set for secondary website this way. So, session may be started for it too. And logged-in flag can be set.
Related
first of all before this gets marked as duplicate with CORS and X-header comments, let me prefice this by saying.. This question is strictly intended for LOCAL environments only.
I have written a website with .NET as backend that uses cookies and session-strings to maintain the authentication between the client and the website. However, a customer of ours want to disable authentication all together for all their users. Here is where the problem arises, our system rely on the fact that usernames and auth-data is sent along in most of our data-requests. So, the customer has agreed to use a static page with the username and password statically programmed (so that they wont have to login every time, but mearly open a chrome/firefox-shortcut on their desktop). This static page will redirect and pass along this static information to the "real" loginpage and sign in the user.
Illustration:
What are my options here?
Here's a screenshot of the req-headers in a successful login-post.
Thanks.
You want to serve your site from the backend and distribute a link to your site. Your client then bookmarks the link (or pins it to their home screen).
Serving static HTML files has fundamental limitations and you will hit a brick wall sooner or later (e.g. AJAX calls require the site to be served from some domain).
From here, there are a couple of options to do what you want.
The orthodox route is to delegate credential storage to the underlying OS. That is, just program the input forms as usual, issue Cookies as usual, and make sure the form HTML is such that the browser offers to save the credentials.
An alternative solution more in the vein of your initial proposal is to create what are known as signed URLs. You may create cryptographically signed URLs (e.g., http://localhost/your/site?hmac=<your_signature>) and hand that your client. Once you handle that URL in your server and verify the signature is valid, you may respond with a 301 redirect to your site, issuing the authentication cookie in the redirect response.
For background material, you may want to read about Post/Redirect/Get and Message authentication codes.
I'm building 3D-secure payment gateway but seem to be having trouble with iframes provided both by the 3rd party service provider as well as the previous developer.
A user enters their card details at our site (let's call this "domain.com") which is running on port 443 and https. The information is then passed to a 3rd party iframe where 3d secure card processing is done, it does a few cross origin redirects and then redirects back to our domain (let's call this payments.domain.com) which runs on a completely separate port, 9443. This was not implemented nor is it controlled by me. I'd need to grab a few parameters to verify card details from this redirected URL.
I've successfully managed to submit a form to the iframe, get an OTP from my bank, but where I fall flat is with the catching of the iFrame redirect url. I can see the cross origin redirects and even get a response (albeit a 401) from our domain.
I've tried hooking into the iFrame element's contentWindow.location.href but I get an undefined value. I'm also unable to use postMessages as I don't control the site where the redirect comes from. I've considered proxying the iFrame but I have no idea where to start.
Please help!
Consider this scenario:
I hit a AngularJS based UI url which is SSO protected in a new browser window, for eg. https://somedev.domain.com
This makes a GET request to the above url. Now, the browser prompts me for a username and password for authentication, because of the redirect from https://somedev.domain.com to https://sso.domain.com
I enter the details, on success of which https://sso.domain.com responds by setting a cookie on the browser and sends back user details of the logged in user like Username in a response header and the UI page is loaded.
Is there a way in AngularJS to intercept this response and get the details of the logged in user?
PS. I can access the set cookie using $cookie.
This is largely dependent on what technology you use for SSO. OAuth has a mechanism by which a key is returned to the originating page which can be used to access the authenticating service in order to retrieve the users information.
Based on limited knowledge of your environment, the most universally acceptable solution would to to utilize the angular-cookies.js module and access the cookie directly using $cookies. I'm assuming the cookie will not include any user information, as these are often times just session identifiers, but you can then use the cookie session identifier to make a request to the SSO server and request the user information.
Please note, the SSO server will need to generate cookies which are generic to a domain, meaning they do not specify a subdomain.
I'm making a google-chrome-extension for a certain website, and want the browser_action to display the number of notifications a user has received on said website.
Currently, I am using an ajax request to retrieve the HTML from the website/messages page, and then I am using jQuery to count the number of "#unread > li" elements in that HTML (each one representing a new message.)
Now, I take this number and display it on the browser_action icon.
All works perfectly, the correct amount of messages are notified, BUT the user must be logged in on the site (not my site) for it to work properly, otherwise they will think that they have no messages.
I was thinking that I could detect if the user is logged in, and if not display a red ! exclamation mark on the icon. Then, when the user clicks to show the pop-up, it asks them to log in.
However, I have no idea how to actually log the user in to the website using this method: how do I send the credentials across? Or does the website have to support a request like this?
TL;DR
How can I log a user into a website I don't own remotely?
Disclaimer: I've never done a google chrome extension, but based on the rest of your question, it sounds like it's just working with JavaScript like any other web page, so I'll go ahead and answer it.
In any case, working with cookies in JavaScript can be somewhat of a pain:
https://developer.mozilla.org/en-US/docs/Web/API/document.cookie
http://www.perlscriptsjavascripts.com/js/cookies.html
I'm assuming that your server side already works with and expects cookies, so I won't try to suggest any alternatives. That being the case, your server is what needs to validate the cookie, so, IMHO, might as well set the cookie on the server side. If the server handles it, on the JS side, you simply post the username/password to a server-side page, e.g.
$.post("/user/login",{"Username":"foo","Password":"bar"},callback);
That server-side page validates the username/password and then, if successful, generates the cookie and sends a response back to the JavaScript (e.g. {"IsSuccess":true}). Upon receiving a successful response rather than an error, you just start calling the other web services to retrieve your data assuming you are logged in and build out the page.
Assuming that your web services will return HTTP error codes that help you determine a problem with the session, if you get a 401 error code, you take the user back to the login page. If you get a 403 error code, you let the user know they can't access that data...etc., all depending on your app.
Ultimately, JavaScript doesn't know whether a user is actually logged in, so you have to rely on the server to send you information in a way that is understandable so that you can direct/prompt the user as necessary.
[Edit: 2014-11-21]
You didn't answer my other question: what do you get back? If they don't set the cookie themselves at the login, then you need to get back the session token from the response they send...if they don't send you a session ID, you're SOL. If they do send you an session token/session ID, then you need to know what to name it (e.g. PHP uses something like PHPSESSID as the cookie name, but it can be whatever the coders of that domain decided on). Beyond that, you have to be able to set the cookie for THAT domain name (3rd party cookie). This may have mixed results depending on the user's settings--if they block 3rd party cookies--however, since this is a google extension and not a website, maybe it's able to bypass that kind of restriction. I know that FireFox's developer toolbar is able to manipulate cookies for all domains, so it would be a reasonable assumption you would be able to as well.
Just want to get input from people who know. I was considering CSRF vulnerabilities, and the seemingly the most popular method I know to fight against it. That method is to create a token in the returned html and adding a cookie with the same value. So if a script tries to do a post they would have to guess the token thats embedded in the web page for it to be successful.
But if they're targeting a specific website why can't they just use a script that
Calls a get on the page (the cookie will be returned even though the script can't access it)
Parses the html and gets the token
Calls a post with that token in it (the cookie that came back will be sent back)
They've successfully submitted a form without the users knowledge
The script doesn't need to know the contents of the cookie, it's just using the fact that cookies get sent back and forth all the time.
What am I missing here? Is this not possible? I think this is pretty scary if you think about it.
Below this line is not required reading to answer the question :)
This vulnerability banks on the fact that authentication is done based on cookies, which I think is the main way authentication is currently occurring.
Another solution I can think of is making authentication be on the page level. So
when they log in the returned html will have that token in it. every link that they click contains that token so when the web server gets a request it has a way to identify the user/session. The problem with it is that if they use any navigation other than that they will be 'unauthenticated'(e.g. type in a url) , also it doesn't look nice in the url because it would probably look something like this:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
But I do understand that if safety is more important, then a pretty URL is second place.
I don't know everything about cookies but what if user agents were a little more careful with their cookies?
For example, what if the cookies sent depended on the tab? We all surf using tabs by now, right? so what if the scope of the cookie was the tab? so if i have my banking site open on tab 1 and i'm surfing on tab 2, any scripts calling gets/posts on
tab 2 will only send the cookies accrued in tab 2.
Or what if cookies were stored / domain. So while I'm on example.com any cookies that come back go into the example.com cookie collection. and then when i'm on www.mybankingsite.com all the cookies get put into the mybankingsite.com collection. So if I go to example.com and it runs a script that calls a get/post the user agent will only send example.com cookies. This is different than sending the cookies of the requested domain. E.g. if a script calls a get of mybankingsite.com within a web page of example.com the user agent will not send the mybankingsite.com cookies.
I know i have no control over what user agents do, but I'm just exploring possibilities
So I think the problem here becomes the attacker's attempt to get the page's contents. To get the authenticated user's page, the attacker needs to be able to send a request on their behalf and read the contents. AJAX won't send cross-domain requests, iframes won't let you read the response. I am struggling to think of other ways in which an attacker would get the contents first.
A more likely hack is using clickjacking to have the user just submit the form. This technique doesn't seem too likely. (caveat: it's security, we can always be wrong.)
Does anyone care to share some code on this issue as I just hacked my own site (Not in production) with CSRF. All I had to do was the following
At: www.badguy.com/ write the following html
img src="www.goodguy.com/secure/user/delete/5">
What this does
So the admin goes to to www.badguy.com/ and the the image makes a request to
www.goodguy.com/secure/user/delete/5 from the users browser so the admin unknowingly just deleted a user. If you create a loop your in some trouble. Expect I never delete data just change its status :) but still I don't like the looks of this.
The CSRF token has to be unique per session. If a malicious server requests the same page, they will get a different token. If they try to request the contents of the page via JavaScript on the client's machine, the same-origin policy will prevent them.