[Security] XSS Cross Site Scripting Attack in Tabox Latest Release about tabox HOT 8 CLOSED

Hey @hamza-avvan ! Thank you for opening the issue and submitting a PR!
I believe that since this is a local file hosted on your computer, this sort of attack is not relevant (since you can already run any JS code you want locally through the address bar with javascript:<code> )
In any case, I have actually already addressed the problem in v3.5.9 (not yet pushed to GitHub) but thank you again for noticing and helping fix it!

from tabox.

Well executing code directly is not possible now on latest browsers (you can check) and we can't ask someone to execute javascript code on his/her browser address bar for us, but it's about transparency whether the victim knows what happening in the background and since this XSS is in the context of Tabox plugin an attacker can steal user(s) information (if user logged in using OAuth to sync) without their consent as it can be used to target anyone who has installed this plugin. Btw have you checked the payload on your browser?

Payload

chrome-extension://bdbliblipiempfdkkkjohnecmeknnpoa/deferedLoading.html?url=javascript:alert(1)

I believe that since this is a local file hosted on your computer, this sort of attack is not relevant

I believe every plugin has an id (bdbliblipiempfdkkkjohnecmeknnpoa) assigned by chrome web store so we can use that id as pointer to that specific plugin in a browser just like a domain.

If you search this id bdbliblipiempfdkkkjohnecmeknnpoa on google it'll show results of your tabox plugin. And if we check the payload carefully we'll find this id after chrome-extension://<ID>

from tabox.

In any case, I have actually already addressed the problem in v3.5.9 (not yet pushed to GitHub) but thank you again for noticing and helping fix it!

Glad you tried to fix it. I love this plugin and I always use it to keep track of my sessions. It's amazing. By looking at the hard work you've done I got excited to contribute to the Tabox plugin. Thanks.

Besides, I've also proposed a fix regarding this issue. The idea is to check if the provided url starts with http/https which I hope would suffice to protect against this vulnerability.

from tabox.

Yes I saw your PR, I believe it did the opposite - if a url did contain 'http' it blocked it.
Any way, I needed to come up with something a bit more robust as tabs can contain pages that are not http - like Chrome apps and urls on the user's local file system (i.e file://c:/folder/file.txt ).

Thanks again for contributing and I am glad you like the extension! Please feel free to suggest other improvements / features!

from tabox.

You're right I've tested it with different values and it did opposite. And yes, there can be other schemes like file:/// or app:// I wasn't taking all that scenarios into account. I've updated deferedLoading.js according to it. Please check it and if there's still any issue, I'll love to fix it.

What I've done to improve it:

1. Decode & trim value provided in url param.
2. Remove line breaks (\n), carraige return (\r) & tab characters (\t) from url if present.
3. Replace url with (#) if url starts with javascript:

Why decoding & trimming url?

Decoding on client side is necessary because encoded characters passed to url parameter automatically get decoded by browsers hence bypassing the logical check present on deferedLoading.js:6

Why removing line breaks & other stuffs?

As mentioned above browsers (Chrome) automatically decode most special characters like line breaks or tab if provided into url javas%09cript:alert(1) which is then passed to an attribute (href)
%09 -> Tab character

Why replacing javascript: with # ?

Why doing all this where we can simply remove javascript: in the first place. It's because the word can be nested within it self.
Let's take an example: javajavascriptscript:alert(1). If we remove javascript from the string it would be left with javascript:alert(1).

from tabox.

Thanks for the update! It is similar to my current solution, except i only check for 'javascript:' in the beginning of the url, to avoid blocking valid URLs that might have that somewhere in the url (like: www.exmple.com/article/use-javascript:-in-something).

from tabox.

I believe that's what it params.url.indexOf("javascript:")==0 will do.

As you can see it passes the URL (www.exmple.com/article/use-javascript:-in-something) you provided as a test case but caught the javascript payload. So it didn't block your url. Please share if there's more confusion.

from tabox.

This is now resolved in v3.5.9.

from tabox.