I am trying to wrap a login section of our page in an iframe which has been created with SSL and display it on several pages across our companies website (kind of like a login widget).
However I keep getting an error on the page rendering the iframe indicating that:
Refused to display in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.`
The login widget and webpages that I want to display it on are hosted under the same domain, is this an issue?
I have searched around and nothing seems to be able to avoid this problem. Does anyone have a solution to this issue?
<iframe sandbox="allow-same-origin allow-forms allow-scripts" src="https://<sitename>/loginiframewidget.aspx"></iframe>
At the moment these are what I have in my web.config
<httpProtocol>
<customHeaders>
<add name="access-control-allow-headers" value="content-type" />
<!--<add name="Access-Control-Allow-Origin" value="*" />-->
<add name="Content-Security-Policy" value="frame-ancestors 'self' mysite.com.au"/>
<add name="X-Frame-Options" value="ALLOWALL"/>
</customHeaders>
</httpProtocol>
And the headers that appear in Chrome Dev Tools on the page are:
There are security issues with this implementation anyway.
The first is that you can't be sure the content of the unencrypted page hasn't been altered on transmission and has pointed the src of the iframe elsewhere.
The second is that even if a user logs in with SSL, their session ID in the cookie is being sent in the clear and is easy to spoof.
Would you consider running the entire site in SSL? These days servers cope with this better than you'd think, and you wouldn't need iframes any more.
Try setting the frame-ancestors directive of the Content-Security-Policy header, and the X-Frame-Option header for older versions of IE.
http://caniuse.com/#feat=contentsecuritypolicy
You can add these through IIS, or add them into your web.config file:
<system.webServer>
...
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="frame-ancestors 'self' mywebsite.com" />
<add name="X-Frame-Options" value="ALLOW-FROM http://mywebsite.com" />
</customHeaders>
</httpProtocol>
...
</system.webServer>
The headers should now be sent down to the browser:
No means big No, you just can't do it, you can't access SSL resources on non SSL page, and is your client willing to expose everything on internet? Allowing frame options will still not work because browser will not allow you to cross SSL boundaries.
HTTP is not at all secure, this is the reason, every site in google is now under SSL, because non SSL content can be altered by ISPs and Firewalls, in fact ISPs, Firewalls and other routers are continuously injecting scripts on page to monitor traffic.
Explain your client that today running an authenticated session under non HTTPS is equivalent to locking doors of home but leaving all windows open !!!.
With keep alive, SSL negotiation any way happens only once and performance is very negligible, you can improve site speed by outsourcing CDN to CloudFront or any other CDN with their subdomain SSL.
OAuth - But Recommended only under SSL anyway
You can implement your own OAuth Provider and use it to distribute OAuth tokens that can be used to validate in your website at server side. Your site can use secondary tokens issued by OAuth provider to validate user and you can redirect users to OAuth Provider which can run under SSL. This way, you can allow users to do limited non secure things under authentication on non SSL pages. Just like how you can use Facebook/Google login etc under non SSL sites as well.
Related
I have a web app that uses a external login service (oauth) for authentication and needs to be redirected to SSO server for login.
my problem is after first login browser saves a cookie related to SSO and second time dose not ask for username password just simply bounces back from SSO to main web app
i tried removing cookies manually it work! but when i tried doing it with a piece of code like:
foreach (var cookie in Request.Cookies.Keys) Response.Cookies.Delete(cookie);
it also will be deleted but just looks like it's been deleted and wont ask for user credential's just bounces back
It seems your problem is not with the cookies, the page is loaded from browser cache when you load it 2nd time.
You need to disable browser caching for your index.html page, that will load new page every time browser requests the server for page. For that add meta tag in index.html header.
<meta http-equiv="Cache-control" content="no-cache, no-store">
<meta http-equiv="Pragma" content="no-cache">
no-cache and max-age=0, must-revalidate indicates same meaning.
(Pragma & Cache-Control is one and the same thing but from the different HTTP specification. See the answer here:Difference between Pragma and Cache-control headers?)
Or you can append date to script tag for fetching js
<script src="js/config.js?v="+ new Date() type="text/javascript"></script>
By doing this whenever front-end will send query it will append new datetime, which tell that the cached js is different than request, and prevents from loading cached version of page, now after you new page is loaded(not from cache), an auth request will happen and after successful login your page will be redirected.
If you are concerned about performance while loading it every time on navigation, you must use a Framework like Angular, which is single page application so it will load only once when reloaded, and continue same while you navigate.
You can add those meta tag in index.html or
If backend is IIS server, add a web.config file(I have not tried with other servers)
In the root web.config we specify that we don't want to the index.html to cache by setting the cache-control, Pragma and Expires request headers as well as the max-age to 0.
<location path="index.html">
<system.webServer>
<staticContent>
<clientCache cacheControlMode="DisableCache" cacheControlMaxAge="0.00:00:00" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache, no-store, must-revalidate" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="-1" />
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
For more details on caching check these
IIS Client Cache: https://learn.microsoft.com/en-us/iis/configuration/system.webserver/staticcontent/clientcache
Cache-Control HTTP Header :
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
Pragma HTTP Header:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma
Expires HTTP Header:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires
I'm not a backend developer, so I apologize ahead of time if I do not provide enough information. I am just trying to find some resources that will help my backend developer understand what I am trying to do.
I am trying to make an AJAX GET request to an rss feed inside of web application that was built using ASP.NET Web Forms. However, the request gets blocked because of Cross Origin Security. I want to enable CORS for the route that is associated with our RSS feed (/page/rss/{id}).
I was able to enable CORS in our webconfig using:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" values="*" />
<add name="Access-Control-Allow-Methods" values="GET" />
<add name="Access-Control-Allow-Headers" values="Content-Type" />
</customHeaders>
</httpProtocol>
But, that enables it for the entire project which is not what I want. Our routes are defined in an XML file like this:
<namespace.routing>
<routings>
<route name="publishedPage" url="page/{PageName}" page="~/Default.aspx" />
</routings>
<defaults>
<default url="http://blog.example.com" domain="example.com" page="page/homepage" />
</defaults>
</namespace.routing>
So, how would one go about enabling CORS on a specific path in ASP.NET Web Forms? If someone could point me in the direction of some resources that would help us that would be great. If you need anymore information I'm happy to provide it. Thanks!
I'm not sure how you are returning your rss endpoint, but if you have access to the HttpContext object, you can use it to supply the CORS headers directly.
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Origin", "*");
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Methods", "Get");
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Headers", "Content-Type");
Depending on how old your app is, you might need to use AddHeader instead of AppendHeader.
The problem I am facing is that I only want the clients (end users) to present a certificate on specified pages within the MVC/WCF application.
When I set the IIS options "Client certificates = Accept" the site always requires a certificate when browsed, shouldn't be this way when setting the option to "Required" ?
Googled for a while but web.config configurations to override the IIS certificate check and only do certificate check on certain pages does not turn up many results.
In a simplified way what I want to accomplish is:
User browses Home page
Reads some news articles
Goes to a page that requires authentication
Make the user/client present a certificate
Here on I will make some checks to the certificate programatically (this bit I have solved)
I don't provide any code cause I don't have any, everything I have is the certificate option in IIS.
Figured out the answer.
Location tag and in the applicationHost.config allow override the "access" section
applicationHost.config
<section name="access" overrideModeDefault="Allow" />
Application web.config
<location path="PathToSvcFile.svc">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="true"/>
</authentication>
<access sslFlags="Ssl, SslNegotiateCert"/>
</security>
</system.webServer>
I created a WebService in C#. All GET methods are working without any problems.
Now I need to provide some POST methods. When calling it via C# it works without any problems. Then I tried to write a small html page with JavaScript to call my methods. But there I get a CORS error ("Preflight channel did not succeed").
I already added the following part to my web.config file:
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="*" />
<add name="Access-Control-Allow-Methods" value="*" />
</customHeaders>
Sadly it is still not working. What am I doing wrong?
So what you have here is not really a valid way to handle CORS requests. The problem is that this will add the CORS headers to all responses, but browsers will use an OPTIONS request in order to check for CORS headers. This would work if you also implement OPTIONS requests for all of your API end points.
The better option is to use one of the CORS frameworks, such as this one: Enabling Cross-Origin Requests in ASP.NET Web API 2 for ASP.NET WebAPI 2. This type of framework will intercept the OPTIONS request for you and supply the appropriate response without the need for you to manually create 2 routes per endpoint.
I have removed the x-powered-by using <httpProtocol>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
<remove name="Server" />
</customHeaders>
</httpProtocol>
This hides the X-Powered-By but the server (IIS info ) is still not getting removed
It would be good if there is a way where I can remove all the info in the Response Header
How can i do it?
I believe you need UrlScan to remove the IIS info.
The particular setting you need to configure is: RemoveServerHeader
By default, a Web server returns a header that identifies what Web
server software it is running in all responses. This can increase the
server vulnerability because an attacker can determine that a server
is running IIS and then attack known IIS problems, instead of trying
to attack an IIS server by using exploits that are designed for other
Web servers. By default, this option is set to 0. If you set the
RemoveServerHeader option to 1, you prevent your server from sending
the header that identifies it as an IIS server. If you set
RemoveServerHeader to 0, this header is still sent.