Skip to content
This repository has been archived by the owner on Nov 15, 2017. It is now read-only.

Scope issue #109

Closed
insanitybit opened this issue Dec 31, 2013 · 3 comments
Closed

Scope issue #109

insanitybit opened this issue Dec 31, 2013 · 3 comments

Comments

@insanitybit
Copy link

Go to:

http://isecpartners.github.io/fuzzing/vulnerabilities/2013/12/30/vlc-vulnerability.html

Click on the * to decide scope.

Options are:

http://isecpartners.github.io

http://*.isecpartners.github.io

Ideally it would be: http://*.github.io , at least that makes sense to me?

Or at least, that should be included.

Seems like a behavior issue, when there is a domain and a subdomain the subdomain should be *'d as an option.

Example of it done properly: movies.netflix.com

Options:

https://*.netflix.com

https://movies.netflix.com

I hope this is clear enough.

@gorhill
Copy link
Owner

gorhill commented Dec 31, 2013

I use Mozilla's Public Suffix List (which is used by browser vendors), and github.io is listed as a public suffix:

// GitHub, Inc.
// Submitted by Ben Toews <btoews@github.com> 2013-04-18
github.io

This essentially means that browsers should not set cookies on github.io, the same way they should not set cookie on com. I want to keep HTTPSB consistent with the PSL.

@insanitybit
Copy link
Author

Interesting, thank you.

@gorhill
Copy link
Owner

gorhill commented Dec 31, 2013

For the record, I guess a better explanation is simply that as per PSL, foo.github.io is not the same owner as bar.github.io, so they can't be made to share rules.

Incidentally, this can be entered in the Rule manager:

https://*.github.io
    whitelist
        * github.io

or even

*
    whitelist
        * com

But this currently won't be reflected in the matrix, because the httpsb.js/evaluate() code, which decides what is allowed/blocked, stops at domain-level, but it could trivially be changed to not stop at domain level but go up all the way to TLD, which means the above rule would become effective -- although not viewable/changeable in the matrix.

Is this something we want in HTTPSB? Doubtful: I picture a malicious recipe which whitelist a whole TLD (say .com) being imported by a naive user, and this naive user doesn't understand why now all is whitelisted for every .com he visits, and no way to see the faulty rule in the matrix.

So I will close this one because of all the above, but if you think this is a feature to have you can reopen it and we can debate more about how this could be implemented without impacting security of less geeky users.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants