I wanted to set Content Security Policy (CSP) to my with page, which has a paypal button, which has gif image serves from https://www.paypalobjects.com I included it to my img-src whitelist.
<input type="image" src="https://www.paypalobjects.com/en_GB/SG/i/btn/btn_buynowCC_LG.gif" border="0" name="submit" alt="PayPal – The safer, easier way to pay online.">
But the image is then temporarily redirect to random domains like https://akamai.mathtag.com, https://ak1s.abmr.net
How should I set CSP such that img-src includes redirect domains as well. I do not know all the redirect domains.
Please note, Paypal states that you should only hotlink the checkout button and not save it anywhere else:
PayPal requires that you use the PayPal Check out button and the PayPal mark image hosted on secure PayPal servers.
Obtaining an Express Checkout Button and PayPal Mark
It is unclear how enforced this is.
CSP requires that you know the domains you are referencing content from, which is one of its weaknesses.
In order to get around that, there's a few things you could do:
Remove the img-src whitelist from CSP altogether. This sounds sub-optimal, but unless someone is able to directly compromise your server ( in which case they could modify the CSP header anyways ), or they are able to exploit a Cross-Site Scripting attack on your site, the img-src is not a huge concern. I would worry more about the script-src section, which, if implemented properly, would likely prevent unauthorized images from being loaded anyways.
Create a whitelist based proxy for CSP purposes. Basically, the browser requests the image from your server, and your server then retrieves the images on the backend, following through the redirects, caches the image, and returns it to the user.
As SilverlightFox said, you could also store the image directly on your servers. This could be problematic if you ever need to access other images that don't comply with such a strict CSP. Also, if the buy button image changes and you are unaware of it/haven't updated it, that could create suspicion amongst potential customers who had seen the new buy button elsewhere.
Hope that helps!
Related
I recently did a CTF challenge where we needed to do an XSS attack on a site with a Content Security Policy ... script-src 'self' ... . This was made possible because the website offered the possibility to upload images, which we used to upload a file containing Javascript code with a GIF header like GIF89a=alert(document.cookie)//;.
All we had to do after successfully uploading that image was call that image with something like http://website.com/<script src=url_to_our_image> and the code was executed despite the CSP.
Now my question: How could you prevent that? I assume you want to keep CSP at ... script-src 'self' ... (you want to trust your own scripts, right?). But what other option would then be left to prevent such an attack? Blacklisting some content of the image, so that it cannot contain code? (I heard that blacklists a generally a bad idea)
I'm looking at buying an airline ticket, and I'm having to enter my credit card details in a http:// page, that looks like this:
If I look at the source code, this is actually an iframe with an HTTPS source, so this actually secure, but a non-tech-savvy user has no way of knowing that. Obviously, this is horrible (even for tech-savvy users).
Now, my question is, if I was the site offering this iframe (Verified by Visa in this case), is there a way that I could force modern browsers to not allow my page to be used as an iframe on http:// pages, but still allow it to be used as an iframe on https:// pages? Is there a technique that Verified by Visa really should be using here?
I'm looking at buying an airline ticket, and I'm having to enter my credit card details in a http:// page
Ouch! Someone's breaking the PCI-DSS terms of their merchant agreement huh.
If I look at the source code, this is actually an iframe with an HTTPS source, so this actually secure, but a non-tech-savvy user has no way of knowing that.
Indeed. You'd have to look at all the source code, including every piece of script on the parent page, to ensure that there is nothing interfering with the iframe (eg via clickjacking) and that the image you see in the browser page actually is the secure iframe. And ensure there were no other tabs open from the same domain with a reference to the window to cross-document-script into it... a non-starter.
if I was the site offering this iframe (Verified by Visa in this case), is there a way that I could force modern browsers to not allow my page to be used as an iframe on http:// pages, but still allow it to be used as an iframe on https:// pages?
I believe you could do it using Content Security Policy Level 2, eg with the header:
Content-Security-Policy: frame-ancestors https:
However support is patchy: at the time of writing, even the latest IE and Safari don't support it, and obviously it didn't exist at the time 3-D Secure implementations were being written. Still, if it just complains some of the time that would be enough to let an unwitting merchant know they'd messed up their payment integration.
One other thing they might have been able to do back then would be to check the Referer header for an http: address. Still not reliable (and maybe tricky to make work for all possible flows including redirect and pop-up, and in-between redirections) but could have helped.
Hello I would like to implement a payments on my web site.
I have a requirements that to do it in iframe with hidden address bar.
But in this case user would't be abble to see that we are using HTTPS protocol for sending data and e.t.c
Does is it good practice or it is looks like security issue ?
I don't think it is a good idea to hide HTTPS information from end users. If you look at any web security for dummies kind of guide, they all say that when you enter private/financial information etc make sure your address bar display the lock etc.
Even though you may in your HTML that you are using HTTPS, do you really expect users to "view source" your HTML and/or use Fiddler etc? No right?
So, do the right thing- show HTTPS URL.
BTW, from security perspective, if the first page you serve is NOT over SSL, someone could just modify HTML and inject a malicious HTTPS link with valid cert. That is why it is very important to have SSL enabled on your whole website.
No wonder HTTP 2.0 is going to be all SSL :)
Technically you don't need HTTPS if you are using iFrames for checkout. Ofcourse the 3rd party website is always protected... BUT since you cannot explain this to your customers/clients, so you have to have a HTTPS even you are using iFrames even it is secure but to make your customers feel actually that they secure you should have SSL (HTTPS).. Or I know many of your customers will simply leave your website... SO YOU DO NEED IT... YES
From ha.ckers.org/xss.html:
IMG Embedded commands - this works
when the webpage where this is
injected (like a web-board) is behind
password protection and that password
protection works with other commands
on the same domain. This can be used
to delete users, add users (if the
user who visits the page is an
administrator), send credentials
elsewhere, etc.... This is one of the
lesser used but more useful XSS
vectors:
<IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">
or:
Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser
I allow users to post images in the forum. How can this be protected against?
I'm using Java Struts but any generic answers are welcome.
If you follow the rules of the HTTP specification, such a kind of attack will make no harm. The section 9.1.1 Safe Methods says:
[…] GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
So all requests that change data on the server side should only be allowed via POST. And even there you should only allow those requests that your system has authenticated by generating tokens that are only valid for a specific form/action.
This attack is simply an HTTP GET request made to any URL. You cannot reliably block it by prevent certain <img> tags.
Instead, you need to make sure that your website has no targets (URLs that respond to GET requests and change things)
If there aren't any "juicy" URLs that respond to HTTP GETs (not POSTs) and change data, the attacker will have nothing to attack. (<img> tags cannot be used to create HTTP POSTs)
Cross-site scripting is one reason why you should not allow forum users to post images by linking to images outside your site.
Image posting should be provided by allowing users to upload the image file to your site and using internal relative URI.
By injecting an <img> tag someone can bypass referer based XSRF protection for a GET request. The reason why is because the referer for the GET request produced by the <img> has the same referer as the host its self. So this would bypass code checking to see if the referer and the host where different.
You shouldn't allow people to put html on your page. In this case you should let users upload them and then host images locally. If you really want people to put IMG tags on your site, make sure the URL isn't pointing to your server, because this what an attack would do! Also don't use referer based XSRF protection, use token based. <img> tag injection cannot bypass token based xsrf protection.
No one seemed to mention that the threat in allowing people to post images is not to you, it's to other sites.
If you allow people to post images but your site has no XSRF vulnerabilities, your site is not in danger; other sites with XSRF vulnerabilities are, as your users will unknowingly make requests to the other site via the embedded image when they visit your site. The malicious <img> tag will look something like this:
<img src="http://my-bank-website.com/withdraw_money.php?amount=100000&account=mandy-the-hacker" />
Note that this is not a real image, but the browser will not know that, so it will make the request anyways, transferring $100,000 to mandy-the-hacker's account, assuming the user is currently logged on to my-bank-website.com. This is how XSRF vulnerabilities work.
The only way to prevent this is to force users to upload images, rather than providing URLs for them. However, the malicious user could still just provide a link to the XSRF vulnerability, so removing the ability to provide URLs doesn't really help anything; you are not really harming the other site by allowing <img> tags, they are harming themselves by not using user-specific tokens in forms.
We have our site integrated as an iframe into another site that runs on a different domain. It seems that we cannot set cookies. Has anybody encountered this issue before? Any ideas?
Since your content is being loaded into an iframe from a remote domain, it is classed as a third-party cookie.
The vast majority of third-party cookies are provided by advertisers (these are usually marked as tracking cookies by anti-malware software) and many people consider them to be an invasion of privacy. Consequently, most browsers offer a facility to block third-party cookies, which is probably the cause of the issue you are encountering.
From new update of Chromium in February 4, 2020 (Chrome 80).
Cookies default to SameSite=Lax. According to this link.
To fix this, you just need to mark your cookies are SameSite=None and Secure.
To understand what is Samesite cookies, please see this document
After reading through Facebook's docs on iframe canvas pages, I figured out how to set cookies in iframes with different domains. I created a proof of concept sinatra application here: https://github.com/agibralter/iframe-widget-test
There is more discussion on how Facebook does it here: How does Facebook set cross-domain cookies for iFrames on canvas pages?
IE requires you to set a P3P policy before it will allow third-party frames to set cookies, under the default privacy settings.
Supposedly P3P allows the user to limit what information goes to what parties who promise to handle it in certain ways. In practice it's pretty much worthless as users can't really set any meaningful limitations on how they want information handled; in the end it's just a fairly uniform setting acting as a hoop that all third parties have to jump through, saying “I'll be nice with your personal information” even if they have no intention of doing so.
Despite adding SameSite=None and Secure in the cookie, you might not see the cookie being sent in the request. This might be because of the browser settings. e.g, on Brave, you have to explicity disable it.
As more and more people are switching to Brave or block third party cookies using browser extensions, you should not rely on this mechanism.