Earlier quoted context omitted.
> Anyway, CSP clearly isn't useless... but try deploying it on your average Wordpress blog sometime. What issues have you found with this?
Not OP, but my guess is random plugins stop working with strict (i.e. secure) policies, if they weren't written with CSP in mind.
An XSS on Facebook via PNGs and Wonky Content Types
41–48 of 48 posts
Re: An XSS on Facebook via PNGs and Wonky Content Types
#42Am I missing something, or the attack assumes you can convince a victim to go to the given URL through other means? Like spreading through IM, E-mail...
Re: An XSS on Facebook via PNGs and Wonky Content Types
#43Pretty clever, but I'm wondering how this would be exploited. To insert an XSS attack on facebook.com, he would have to be able to change the extension in url in the facebook page of an uploaded image to .html, right? Don't see a way of doing that. Am I missing something, or the attack assumes you can convince a victim to go to the given URL through other means? Like spreading through IM, E-mail...
Re: An XSS on Facebook via PNGs and Wonky Content Types
#44Hmm, I wonder if there is anything interesting you could do by creating a Service Worker for the CDN domain. It seems that the CDN will serve arbitrary files with a text/javascript Content-Type, which is the requirement to set one up. Once created, AFAIK, such a worker remains attached to the domain until an occasional attempt by the browser to refresh it fails, and it can intercept and modify any requests from webpa…
ServiceWorkers are scoped to the basename of the path they are served from, so you could only intercept a small subset of all possible CDN URLs. In the example, this would be resources under `/hads-ak-xat1/t45.1600-2/`. But you probably can't create a ServiceWorker here anyways as you need a route that returns valid Javascript of your choosing with a Content-Type `text/javascript`. Usually when I've seen an opportuni…
As I said, the text/javascript Content-Type is another one the CDN is willing to serve if you change the extension. I'm silly and didn't think of the fact that unlike HTML, a JS file can't be random binary garbage with a payload embedded somewhere in the middle. However, I am not sure that some allowed image format doesn't allow putting, say, // close enough to the beginning of the file that it will work. It seems like it might be possible with the JPEG header, but of course it depends on the post processing done. (Or maybe there is some way to upload non-images?)
Re: An XSS on Facebook via PNGs and Wonky Content Types
#45Pretty clever, but I'm wondering how this would be exploited. To insert an XSS attack on facebook.com, he would have to be able to change the extension in url in the facebook page of an uploaded image to .html, right? Don't see a way of doing that. Am I missing something, or the attack assumes you can convince a victim to go to the given URL through other means? Like spreading through IM, E-mail...
Re: An XSS on Facebook via PNGs and Wonky Content Types
#46Earlier quoted context omitted.
ServiceWorkers are scoped to the basename of the path they are served from, so you could only intercept a small subset of all possible CDN URLs. In the example, this would be resources under `/hads-ak-xat1/t45.1600-2/`. But you probably can't create a ServiceWorker here anyways as you need a route that returns valid Javascript of your choosing with a Content-Type `text/javascript`. Usually when I've seen an opportuni…
The default scope is the basename, but you can customize it, can't you? As I said, the text/javascript Content-Type is another one the CDN is willing to serve if you change the extension. I'm silly and didn't think of the fact that unlike HTML, a JS file can't be random binary garbage with a payload embedded somewhere in the middle. However, I am not sure that some allowed image format doesn't allow putting, say, //…
"Service Workers are restricted by the path of the Service Worker script unless the Service-Worker-Scope: header is set" [1]
I do wish the spec required a 'Content-type: text/service-worker', as that would effectively eliminate accidental ServiceWorkers as a threat.
[1] https://infrequently.org/2014/12/psa-service-workers-are-com...
Re: An XSS on Facebook via PNGs and Wonky Content Types
#47Earlier quoted context omitted.
The default scope is the basename, but you can customize it, can't you? As I said, the text/javascript Content-Type is another one the CDN is willing to serve if you change the extension. I'm silly and didn't think of the fact that unlike HTML, a JS file can't be random binary garbage with a payload embedded somewhere in the middle. However, I am not sure that some allowed image format doesn't allow putting, say, //…
I seem to remember trying this (passing {scope:'/'} in the register call), and it doesn't work. Some googling seems to agree: "Service Workers are restricted by the path of the Service Worker script unless the Service-Worker-Scope: header is set" [1] I do wish the spec required a 'Content-type: text/service-worker', as that would effectively eliminate accidental ServiceWorkers as a threat. [1] https://infrequently.or…
https://slightlyoff.github.io/ServiceWorker/spec/service_wor...
Re: An XSS on Facebook via PNGs and Wonky Content Types
#48Man, I work as a frontend engineer at one of the big tech companies and I understood like 25% of this post. And that's not meant to be a criticism, I'm just reflecting on my total ignorance of most security vulnerabilities. I know about and having implemented some measures against XSS / CSRF, but it's clear there are dozens of attack approaches I'm not even aware of. I feel like I have some homework to do.