Breaks a portion of Amazon.ca
Closed this issue · 20 comments
Good day.
Today I tested Keepa, so I was on Amazon a lot, and discovered that the section called "Customers who bought this item also bought" which appears just below the item being viewed is sometimes broken: Instead of showing a list of items from left to right, we can only see 1/2 of one item on the far left, the rest of this section is blank.
Ran on a clean profile with just Keepa and my user.js and everything works. Loaded-up the test profile again (where I am testing Keepa) and started disabling addOns, and the 1 addOn that consistently makes the breakage disappear when disabled is CSS Exfil. The test profile has a number of addOns, like NoScript and uBlock and Privacy Badger, Violent Mokey, etc., but disabling CSS Exfil is what makes the problem go away.
Hope you can reproduce.
Thank you.
Thank you for the report! Yes, was able to replicate it here as well. Unsure what's causing it at the moment, but I'm sure I'll be able to fix it. Will reply when I have more information. I'll try to get out a fix for this asap.
Hi There! Nice that you were able to reproduce. Today, in getting here to Github, I passed by the addOn's homepage where you have vulnerability tests, and noticed that you have a badge of how many methods your addOn blocks - I appreciate that, nice going! But also, I had never seen that badge before, so it means CSS methods for getting user information are not very common at the moment - So you can take your time fixing it ;-) Best Regards,
I may handle how you say, still deciding what to do.
The error on amazon.ca seems to only present itself when I reload the page with the element visible. If I stay on the top of the page and wait until loading is finished then everything looks OK. My guess is that there is some goofy javascript on the page that is looking for visible elements and styling accordingly.
The 'load blocker' in my plugin, which delays the load of certain CSS rules until after they have been sanitized, is causing the issue. Removing one of the blocking CSS rules fixes the issue, which also has the effect of reducing some protection.
BTW - If you want to see a site with a large badge number, check this one out! https://no-csp-css-keylogger.badsite.io/
Most of the attacks in the wild are PoC, so I wouldn't expect to see them frequently in the wild. But, the plugin is there for the odd chance you land on a site injecting malicious CSS.
Hi Mike.
I tried to see if staying at the top of the page would change things, but was unable to reproduce. It's hard to reproduce, you have to reload and reload. I'm not surprised it's caused by some code waiting for stuff to appear on the page; web pages today are just too complex.
Alright, so we cannot prevent it - How about a Whitelist? When we click the addOn's icon, instead of just having a choice of enabling or disabling the addOn completely, we could have a choice of Whitelisting the domain? To be complete you would have to add a page where users can edit the Whitelist (argh, more work) but it's the obvious solution.
Wouldn't be a bad idea to make the icon go greyscale when CSS Exfil is disabled or when the domain is Whitelisted - I noticed earlier that I had disabled CSS Exfil yesterday via the icon, and did not remember having done it and there was no feedback to tell me...
Thank you.
Best Regards,
I may have a solution for the issue :-) I was playing around with a few edits today and believe I found a happy medium where I can use the load blocker but remove it sooner than I was doing previously. The edit will work for whatever the issue is on amazon.ca. I've also noticed it makes a couple other things more smooth on page load -- things I didn't really notice before until I really started looking. I want to do a little more testing, but if all goes well I'm expecting to release an update tomorrow (Thu).
I'm planning on a whitelist feature. Maybe a little different than you suggest, but one where individual resources on a page can be whitelisted. The code to make this happen will be related to another feature that I plan to release quite soon after some bugs are worked out, which will scan resources injected dynamically into the DOM. I'm planning on that being a 1.1 release soon.
I agree, I need to change the icon status when it's disabled. I'll plan for that as part of the 1.1 release as well.
One question. Are you using Chrome or Firefox as your browser? I've personally been testing with Chrome thus far. I'll likely test/roll the same edit into Firefox if it works the same, but I also haven't been able to replicate the amazon.ca issue with Firefox.
BTW - This URL seems to often cause the issue for me (in Chrome). Don't ask me how I found the link (haha). I just clicked around the homepage a bit following products until one caused the issue :-)
Ah! My bad, I never considered this was a universal Web Extension! I am using Firefox 52 ESR, and will be doing so for quite a while (I have tons of XUL addOns). I'll try the new version as soon as it appears on AMO; since I can reproduce I will be able to report back (it's hard to reproduce but it eventually bugs). Actually, I have only been testing this on my test profile where I test all kinds of addOns. Let me try on a blank profile with just XSS Exfil and see if I can reproduce. I will report back.
I'm afraid of individual resource whitelists. Remember IE had this for scripts at some point? - you had to sit there and allow scripts individually for 10 minutes before the page finally loaded completely. I would rather just whitelist the entire website. Not sure how many CSS files common websites call on these days but it could be quite a lot.
Lol, funny URL, but for me what appears below the product descriptions is the "frequently bought together" thing instead of the "also viewed/bought this" section; I have not seen the "frequently" thing bug, only the "also viewed/bought" section. What I do is I search for "Broken Token" (I like game box inserts" and click on those I think will not show the "frequently bought together" thing. Sometimes I just reload and reload until it bugs...
Alright, I was able to reproduce right away with a new profile and CSS Exfil. It is possible Mozilla changed things and it no longer happens in latest FF; they've been fixing a lot of Web Extension bugs since FF52 came out. It pains me to not be able to upgrade, but I have too many XUL addOns still waiting for an equivalent WE. Even if I could find an equivalent WE for all of them (I have like 70 active addOns) it would take me about a month to go through the list and test replacements; not looking forward to that, lol.
PS: If you want to upload an unsigned XPI here, I can test...
Regards,
I've had some time to dig into this further and working on this particular bug has led me to find another in Firefox.
I'm running Firefox 52.0.6 currently. Something changed with one of the recent point releases of Firefox which broke the load blocker in some cases. This means that although the plugin will sanitize the CSS, there is a potential for data to be exfiltrated. This only appears to happen in Firefox and was not the case previously.
The 'load blocker' is some CSS that attempts to generally override styles on the page while sanitization is happening. It's removed once all the CSS has been scanned. Firefox is particularly aggressive about pre-loading images and the preload starts even before the content is loaded on the page (and the DOM becomes available). This occurs even with prefetch disabled in the options. In any case, on some pages now, potentially malicious CSS can be loaded before it can be sanitized. It doesn't happen everywhere, but something that I need to fix. Whatever happened between Firefox point releases renders the load blocker useless as Firefox determines that it's lower priority CSS in specific cases, since the CSS is general and not targeted at a specific element.
They implement CSS specificity according to this document:
https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
I actually found a fix, one that I was using prior to the load blocker: hide the body element, disable all stylesheets on the page, show body, and re-enable each as they are sanitized. This works really great actually and as far as I can tell it also fixes the amazon.ca issue. There is a downside though. Some pages will appear un-styled completely for a fraction of a second. Personally I wouldn't mind this much for the security, but I can see it being a turnoff for others.
So, I'm trying to figure out a palatable workaround.
I may have found a good solution that improves the page rendering. I'm not going to rush out a fix for this, if that's OK with you. I want to test this a bit in action for a few days. I may roll this into the larger 1.1 release since functionally it's a big change, even though it's not too much extra code. I've also coded the disable status for the icon, which will be in the next release.
Thanks for that, I didn't know about specificity (now I know # rules override everything else). All these addOns I am using (NoScript, uBlock, CSS Exfil, etc) - web pages are so complicated now, I don't know how you guys manage to understand it all lol. Hey take your time, no rush, appreciate your work. Make sure to close this issue once you release 1.1, and I will get an email and go grab it :-)
Good day.
Still working on a fix for this? Been a little while ;-)
Regards,
Thanks for checking in! The fix that I had tried ended up being really problematic so I never released it as an update. Performance suffered and it messed a bit with page rendering. I'm currently running the latest release version myself (1.0.8) in my browser. I'll be getting something out, but I'm not exactly sure when. Since the end of March, I've been slammed with 'real' work during the day and my evenings have been consumed working on OSCP certification. When I get a few spare cycles I'll see if I can straighten out the mess in the development branch. I may also reconfigure the code to make a quick release that includes the other improvements I had added (e.g. enable/disable icon state).
Wow, OSCP sounds really hard! And I quote some website "clear and practical understanding of the penetration testing process through an arduous twenty-four hour certification exam." That's what I call an exam! Good luck! Come back when you have more free time, we can wait. Best Regards,
Good day! Long time!
This month I am upgrading Firefox from 52 to 77 (quite a jump) so it was time to re-visit CSS-Exfil. The bug with Amazon.ca is still here, and there is no Whitelist yet. This is probably not fixable, and that's ok, so long as we can whitelist resources or domains. Any chance of seeing that soon?
Hope you passed OSCP!
Best Regards,
You are in luck! I'll be releasing an update that handles some of the load blocking CSS differently. This was the CSS that causes the UI glitch on Amazon. I'm not 100% sure if the issue is resolved, but in my tests I don't see the issue any more with the new code. I was hoping to release this last week, but I need to test a few more things. It will be released soon though.
Yes, I passed OSCP... Just about 2 years ago :-)
Hahaha, yeah, it's been about 2 years :-) Will watch for the new release then, Thank you!
This issue has been addressed in today's 1.1.0 release. Since it wasn't technically feasible to address in another manner, the new domain settings options to either "Always Scan / Never Sanitize" or "Never Scan / Never Sanitize" avoids the issue by preventing the CSS load blocker styles from being applied, which was causing the JavaScript timing conflict.
Lol, you ended-up adding a "whitelist" - Not sure it's needed for me though, I'm having a real hard time reproducing on Amazon, seems to be working fine with everything enabled :-)
I was kicking and dragging my feet for a long while because I wanted the plugin to work in all cases rather than mask bugs with a whitelist, but in the end I added it. It wasn't due to this bug, which was pretty intermittent, but one of the other closed bugs was for a site where the plugin caused a big CPU spike, and there was no real solution. So, now we have the whitelist :-)
The nice part is that the code for the whitelist will enable a new "privacy mode" feature I'll be adding soon that will prevent the plugin from scanning cross-domain CSS - a case that's not ideal for security but better for privacy.
I'll comment via the opened bug for that - Anyway, awesome job on the new code, Amazon works flawlessly.