On Thu, Jan 12, 2012 at 11:00 PM, Daniel Friesen
<lists(a)nadir-seen-fire.com>wrote;wrote:
On Wed, 11 Jan 2012 14:09:23 -0800, Chad
<innocentkiller(a)gmail.com> wrote:
On Wed, Jan 11, 2012 at 4:43 PM, Happy Melon
<happy.melon.wiki(a)gmail.com> wrote:
Yes, no user-editable scripts are run on pages
where password forms
reside,
because it is trivially easy for users to use them to introduce
password-sniffing JS attacks, either deliberately or inadvertantly. Or
that's the idea, at least; IIRC there's an open bug about gadgets
running
somewhere they probably shouldn't, etc.
Yep, you're looking at bug 10005[0]. This applies to password reset
pages,
preferences (last I checked) and user login.
-Chad
[0]
https://bugzilla.wikimedia.org/10005
That bug appears to be about user-js.
I used to be in the camp that wanted scripts to not be run on login pages
for security, and opposed ajax logins on the grounds that scripts would be
run on the page.
But awhile ago I learned about the history.pushState api. I found that
it's almost pointless to hide scripts exclusively from pages with password
forms on them. Since if a script is run on 'any' page on the wiki it's
possible to use xhr and pushState together to fake the entire page
browsing functionality, including the address bar changing as if you
actually went to the url. So it's possible to hijack the native page
browsing and make it look like the user went to the user login page when
in reality the page never changed, the whole login page was actually
loaded by xhr, and the malicious script is still running ready to swipe
your password.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
Just to point it out explicitly, scripts are not and never were hidden
completely
from any page in MediaWiki (at least not for 5+ years).
OutputPage decides what the "trust" level of queued modules must be for them
to be loaded. SpecialUserLogin and others raise this from the default
"anything"
to "not site and below". Leaving only core and extensions.
So JavaScript enhancements on the login page would work fine, as long as
it's origin
is core or extension. I believe a few ajax logins have been floating around
the net in the
past already.
I agree the thought behind it getting dated though. Aside from the malicious
way of faking the user front, one can actually make calls to the API from
any page,
directing.
Krinkle