Am 20.07.2011 15:02, schrieb Anthony Lieuallen:
On 07/19/11 22:28, LWChris@LyricWiki wrote:
.. I've got no idea why that script is a "big security risk"..
He said right in the first post of that discussion:
"you broadcast your private data (e.g. password) in a cross-domain
fashion to all iframes and frames on that page"
If you use this script, any frame on the page can see the value that
you are retrieving. Likely a privacy risk long before a security
risk. A problem, but a much smaller potential problem than unsafeWindow.
I was not that much into this topic to really know what "broadcast in
cross-domain fashion" meant, I could only suppose what that meant for
me, you know :D But now I understand. Say, some advertisement website or
FB has an iframe on the page. If they defined eventListeners for
messages they hear the message "The variable 'wgUserlang' has the value
'de'.", and they know something was requesting that variable. Well, then
there's no problem. They could as well ask "parent.wgUserlang" to get
that value and as I said, it's just a language, nothing too private.
It's only used on one domain and nearly all its pages. That domain is
100% trusted (lyrics.wikia.com, I'm one of the admins there)...
And you 100% trust that there's no vulnerabilities (XSS?) in any of
the programs running anywhere on that domain?
Hmm, I don't know if you've visited the domain, but it's a MediaWiki, so
I'm pretty sure the database wrappers are already quite good.
Furthermore Wikia Inc. is a very large company, with lots of developers,
so I think they are aware of injections etc. But I'm not too sure there
are no iframes like from FB, bleh (you simply cannot like FB if you're
concerned in privacy).
Long story short, security is a Hard Problem.
It definitely is :D Well, after all it seems like I could use that
script. However I'm kind of unhappy to @require such a complex thing
just for one lousy variable that is required once in the script's
lifetime. That's definitely overhead. You know what? I'm just happy to
be a lot smarter regarding security issues with Greasemonkey now, and
I'll refrain from accessing variables until I need it for better reasons
than just determining one default value. I'll set the default value to
English, and some users will have to change the script-interface
language once instead of my script automatically detecting that the
preferred language is available. It's convenient but not that important.
And maybe some day Greasemonkey will implement a safe alias feature to
retrieve the initial values of hardcoded CDATA variables without
unsafeWindow, so that you don't have this problems unless you want to
read dynamically changed values. Do you think it's worth a try to
suggest that alias at greasemonkey-dev? They do not seem to be as
responsive as this group regrading suggestions and feature requests.
Thanks, Chris
--
You received this message because you are subscribed to the Google Groups
"greasemonkey-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/greasemonkey-users?hl=en.
