a web application which we learnt that is vulnerable for clickJacking issue. we are using IE8. upon surfing i found that we can install "No Script" but looks to be that it is more related to mozilla while we are using IE8. Even if its possible in IE8, then still is there any better option?
i have found the answer as follows.
Open IIS, RightClick on "Websites" and select properties.
2. Select Http Headers tab.
3. Click on Add
4. Give the values as "x-frame-options" and "Deny"
or
4. Give the values as "x-frame-options" and "SAMEORIGIN".
The proper Clickjacking defense is a two pronged approach:
On the server, since ours is Apache Web Server, you add following line in Apache Web Server’s httpd.conf file
X-Frame-Options: DENY
Then using some javascript code in our jsp's:
<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>
I got the code from this link: OWASP Clickjacking Defense Cheat Sheet
I used this for the before/after to ensure the problem was indeed fixed.
OWASP How to test for Clickjacking
Related
I use adminer in a docker container.
For testing services, I use the URL mydomain.tld. To address this container directly, I could expose a port and map, for example, port 8081 to the adminer port 8080.
Addressing this container directly via http://mydomain.tld:8081 works without problem, everything is as it should and the Login dialog looks like that:
However, this approach exposes user and password, so it should not be used.
Using the same docker container via https, however, I get a faulty page. In this case the container is called via the address https://mydomain.tld/adm which is forwarded by the web server addressing mydomain.tld at port 443 to the adminer container to serve the request. The approach is straightforward. The result is identical to the former. Why does this not work?
I used nginx as a proxy and connecting to the adminer container was fine. Now I use yaws and pass through the call to the adminer container.
Obviously the js and css files are not applied by the browser, be it Opera, Chrome, UR, Vivaldi, Edge or Firefox, although the source code is correct and fine. No browser shows errors in the console except Firefox (error messages translated by Bing, emphasis by me), but these errors are obviously attributed erroneously:
Stylesheet https://mydomain.tld/adm?file=default.css&version=4.8.1 was not loaded because its MIME type, text/html, is not text/css.
The script of https://mydomain.tld/adm?file=functions.js&version=4.8.1 was loaded even though its MIME type (text/html) is not a MIME type valid for JavaScript.
These error messages are not correct, as can be seen in the source code: The MIME type definitely is text/css, rel is stylesheet and script should be Javascript anyway.
<link rel="stylesheet" type="text/css" href="?file=default.css&version=4.8.1">
<script src='?file=functions.js&version=4.8.1' nonce="ZDA0ODE4Y2ZhZWY1NzkyZTUxNzg3MGZlNTdlNTcxM2M="></script>
Why does Firefox interpret them as text/html (as do probably the other browsers, too)?
Granted, the respective URLs using GET variables do not look like standard files, but they should work nevertheless and they actually do work either way as can be shown by several methods:
As mentioned, the same source code works well when the container is called via html and port 8081.
A click on these links in the HTML source of the https version loads the files without problem in any browser, as it should.
Likewise the developer tools network analysis shows HTTP code 200 for all of them, even in Firefox.
This proves in my eyes that the code received by the browser is OK, no problem here. Either way the source code is identical, except for the path.
I even manipulated the output of the adminer container to provide for the full path, but, as was to be expected, this didn't change a thing, as also proven by the following scenario:
Use the source code of either output in a local file. Here the references cannot be augmented by the browser, so we have to add the full path manually. By switching the path FULL_PATH between the http and https version I can reproduce the behavior from a local file:
<link rel="stylesheet" type="text/css" href="FULL_PATH?file=default.css&version=4.8.1">
<!-- http://mydomain.tld:8081/ works; https://mydomain.tld/adm/ works per click, but not in browser-->
This file is not even https, as it is called from a local file, only one link is.
Why don't the browsers open these files in the https case as would be natural despite developer tools telling all is OK? What is the problem here? Is there a hidden switch preventing to render these files with https?
How can I debug this more intelligently in order to find the reason and a remedy? I ran out of ideas by now.
See also yaws crashes with httpc:request for URL served by docker container for how the html content is produced.
Why does Firefox interpret them as text/html (as do probably the other browsers, too)?
If you look in the "Network" tab of the developer tools, I'm pretty sure that you're going to see that these files are served with a Content-type: text/html HTTP response header, so the browser treats them as HTML instead of CSS and Javascript.
Looking at the Yaws documentation, it seems like your out_adm function needs to return {content, "text/css", Content} or {content, "text/javascript", Content} [{header, {content_type, "text/javascript"}}, {html, Html}] (as per Steve Vinoski's comment) instead of {http, Content} in order to respond with the correct header.
In the end, the workaround was superfluous and the solution was easy: use Yaws with revproxy = / http://adm:8080 in yaws.conf using a new server instruction abc.mydomain.tld.
Nevertheless, there was a lot to learn. Thank you both for your efforts.
I am using ASP.NET platform to create a web page. Inside the page i have used some images/icons. For security purpose i have used “X-Content-Type-Options: nosniff” in web.config file. When i deploy the web page in IE, some of the images/icons isn't rendered. But, the same page working fine in Firefox and Chrome.
When i remove the statement “X-Content-Type-Options: nosniff” from web.config everything is working fine in IE. But, for security purpose i must use that statement. At the same time the missing images/icons need to be rendered in IE.
So, can anyone help me how to fix the issue with the statement “X-Content-Type-Options: nosniff".
Thanks in advance,
The nosniff only applies to "script" and "style" types. Also applying nosniff to images turned out to be incompatible with existing web sites.
So "X-Content-Type-Options nosniff" would bypass the problem for images and here comes the browser role which fail to render the image if the type mentioned by the server is not matching the real file extension.
Refer to:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options.
and this:
https://msdn.microsoft.com/en-us/library/gg622941(v=vs.85).aspx
IE uses MIME information to determine how to handle files sent by a Web server. For example, when Windows Internet Explorer receives a .jpg file, the user sees the file in an Windows Internet Explorer window. The MIME Handling Restrictions feature helps prevent script injection attacks against Web servers by ensuring that any content delivered with an IMAGE MIME is not treated as HTML or XML.
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/dd565640(v=vs.85)
Add following line before saving bitmap
Response.ContentType = "image/gif";
I have googled around for the answer to this question, but haven't come up with anything. Maybe the search terms I used were too generic... Anyway, here goes:
I am discovering the joys of web design and ASP.NET, and the nightmare of trying to get things to display in the same way in IE and all the other browsers.
I am working in VS2010 and debugging my website using IE8. What I really don't get is why the website once I publish it looks different in IE from the way it looks in debug mode... I mean small things only, like border in gridviews disappearing in the published site, simple html horizontal rules aren't the same either.
It also messed up my list menu pretty bad, but I managed to fix that with the *display: inline; hack. The weird thing is that it doesn't need it in debug mode, but needs it for the published website.
I am hosting the site on my own machine, running Win XP Pro and hosting through IIS with .NET 4.0... Could the issue be IIS related?
Any help would be much appreciated, because those differences are just ridiculous and are driving me to desperation. I wish everyone over here would use Chrome or Safari, but unfortunately IE still rules in Japan...
This works for me, overrides the setting in ie
META Tag in HEAD element of your web page (or better in master page)
<meta http-equiv=“X-UA-Compatible” content=“IE=8” />
link here to info
http://blogs.msdn.com/b/askie/archive/2009/03/23/understanding-compatibility-modes-in-internet-explorer-8.aspx
I find it better to override compatibility in the HTTP Reponse Headers in IIS, adding header:
X-UA-Compatible: IE=Edge
The IE=Edge part will set compatibility to use the highest mode available, will apply to all users, and also apply to all pages in the site whilst only having to put the header in one place.
I've seen similar behavior related to trusted sites/intranet sites/internet sites security settings. When you run in debug mode is the URL you are using different from when you publish it? I've seen sometimes when I debug using a URL like http://localhost/xxx and when I access the same site straight from IIS using a URL like http://machinename.domain.com/xxx that one resolves to a trusted site or local intranet and the other to internet and it changes the appearance based on the IE settings.
For those using ASP.NET MVC, you can add kgp4death's
<meta http-equiv=“X-UA-Compatible” content=“IE=8” />
to the head element in your _Layout.cshtml.
I think you did not have given the correct path in the <script src="path">. Please check your path and also check the related file u must place this file in the project folder
I hope this suggestion solve your problem
We have a web page containing an iframe containing a page sharing an authentification cookie with it's parent page. For example the iframe page is on the domain foo.domain.com and the page containing the iframe is on foo2.domain.com. Both share a cookie from domain.com. Authentification works great, but the problem is with ASP.NET in IE7, we always get a javascript error:
Access is denied.
ScriptResource.axd
We are using ASP.NET 3.5, we use Ajax Control Toolkit also (latest version 3.0.30930.0). The problem doesn't occur for IE8. No problem in Firefox and Chrome also.
Anyone encountered this problem before?
If there's a DNS redirection IE7 can have issues, e.g. if http://site.domain.com is really http://www.domain.com/site, the transparent DNS redirect has issues in IE7, but not the other browsers you mention. IE7 treats this as a cross-domain script and blocks...you just get Access Denied.
Is this the case, or something similar with redirects or different domains? If you can test the main page as just domain.com/ do you get the error? IE7 treats a child differently than a sibling.
In JavaScript you might need to change the document domain. It's possible IE7 is looking at the domains all the way to the server level: foo.domain.com != foo2.domain.com. IE8, et al, are likely taking the document domain at face value of *.domain.com.
Here's a quick related blog article on it: http://jszen.blogspot.com/2005/03/cross-domain-security-woes.html.
To copy the code though, adding the following to both pages should get it rolling again.
<script type="text/javascript">
document.domain="example.com";
</script>
I am trying to run a simple ASP.Net Web Application/Site on Vista Box. Unable to run any JavaScript when I hit F5. However when I deploy the same to local IIS and call the application using IE8 this application works and the JavaScript executes.
Another observation, when I copy the URL (example: http://localhost:XXXXX/yyy/Default.aspx) to a new tab within the same instance of IE8, this same happens. JavaScript do not run.
But when I browse the same application using another instance of IE8 the application runs well, meaning JavaScript executes properly. where do I set it or override it. Please help
I am suspecting that its something to do with the Instance of VS2008 running on vista home premium, so in all the above failure cases I was running VS2008 as an Administrator.
Please help and let me know how to resolve this. Thanks in advance.
Had the same problem. Settings in IE9 had been modified.
Tools ==> Internet Options ==> Security Tab ==> Intranet icon ==> Custom Level Button ==> almost all the way down to the bottom, Scripting ==> Scritpting of Java Applets ==> Enable radio button.
In my case, it had been switched to Prompt. Stopped Cassini from executing Javascript.
And thank you to Mr. Matthew Ward for pointing it out to me! Almost all of the options are locked out for us, so I have no idea how this changed.
Odd thing is, running against the IIS server on my box, the javascript worked.
Couiple thoughts
1) your instance of IE8 might have JS turned off
2) path issues (as suggested by Jared)
3) the "local path" issue; some browsers block Js that appears to be running from disk (might be a setting in your IE 8 to fix.
My blind guess would be that there is some problem with the path to your javascript files. If you could post the .aspx file that has the javascript that isn't running it would help a lot.
UPDATE: Thanks for the comment with the html, you should consider adding it to your question.
This problem sounds like a timing related issue to me (and your html doesn't seem to have any issues) so here is what I think will help:
1) Move the following code to the bottom of the page.
<script type="text/javascript">
$(function() {
$("#accordion").accordion({ collapsible: true });
});
</script>
2) Don't use relative URLs for your script/css tags. So your <script> tags should look like:
<script src="/Scripts/jQuery/jquery-1.3.2.js" type="text/javascript"></script>
<script src="/ui/ui.core.js" type="text/javascript"></script>
<script src="/ui/ui.accordion.js" type="text/javascript"></script>
3) consider using a minified version of Jquery and the other script files to reduce load times for them. Also, you might want to consider using a CDN hosted version of Jquery (from google, or microsoft).
If none of these suggestions work I would suggest posting the HTML for the entire page into your question.