Hi,
Is there a way to embed the login and/or the account creation on normal pages?
I would like to have the possibility to login in a sidebar as long as the user is anonymous. So that there are no extra clicks to login.
I'm sure if there isn't, there is a very good reason for that and I would like to understand that reason.
Ad
Hi Ad,
There are some security considerations if you're going to do that:
* We disable site and user .js on Special:UserLogin, so a malicious admin can't add password sniffing javascript to the login page * We disable framing the page to prevent various redressing attacks * If your site is mixed http/https, there is special handling on that page to ensure the user enters/submits their password over https. * If you're using CentralAuth or another SSO system, then we check if you're logged in on Special:UserLogin, to work around some browser cookie policies.
So it's *usually* not a good idea to create your own login widget. But if you're running your site entirely under https, have a limited number of admins, add XFO headers on all pages, and don't use any SSO system, then go for it!
On Tuesday, September 29, 2015, Ad Strack van Schijndel < ad.strackvanschijndel@gmail.com> wrote:
Hi,
Is there a way to embed the login and/or the account creation on normal pages?
I would like to have the possibility to login in a sidebar as long as the user is anonymous. So that there are no extra clicks to login.
I'm sure if there isn't, there is a very good reason for that and I would like to understand that reason.
Ad _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 2015-09-30 8:48 AM, Chris Steipp wrote:
- We disable site and user .js on Special:UserLogin, so a malicious admin
can't add password sniffing javascript to the login page
Note that you can make use of pushState to render this protection moot for anyone who clicks the login link instead of directly visiting UserLogin page. Which is practically everyone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
Is there a bug filed for that? On Sep 30, 2015 12:13, "Daniel Friesen" daniel@nadir-seen-fire.com wrote:
On 2015-09-30 8:48 AM, Chris Steipp wrote:
- We disable site and user .js on Special:UserLogin, so a malicious admin
can't add password sniffing javascript to the login page
Note that you can make use of pushState to render this protection moot for anyone who clicks the login link instead of directly visiting UserLogin page. Which is practically everyone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Bug? There is nothing that can be fixed.
You just have to accept that as long as the login page is on the same domain as site scripts, there is no way to stop those scripts from controlling the login page.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-09-30 9:33 AM, Tyler Romeo wrote:
Is there a bug filed for that? On Sep 30, 2015 12:13, "Daniel Friesen" daniel@nadir-seen-fire.com wrote:
On 2015-09-30 8:48 AM, Chris Steipp wrote:
- We disable site and user .js on Special:UserLogin, so a malicious admin
can't add password sniffing javascript to the login page
Note that you can make use of pushState to render this protection moot for anyone who clicks the login link instead of directly visiting UserLogin page. Which is practically everyone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Can you provide any documentation on the details of this exploit?
On Wed, Sep 30, 2015 at 12:50 PM, Daniel Friesen <daniel@nadir-seen-fire.com
wrote:
Bug? There is nothing that can be fixed.
You just have to accept that as long as the login page is on the same domain as site scripts, there is no way to stop those scripts from controlling the login page.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-09-30 9:33 AM, Tyler Romeo wrote:
Is there a bug filed for that? On Sep 30, 2015 12:13, "Daniel Friesen" daniel@nadir-seen-fire.com
wrote:
On 2015-09-30 8:48 AM, Chris Steipp wrote:
- We disable site and user .js on Special:UserLogin, so a malicious
admin
can't add password sniffing javascript to the login page
Note that you can make use of pushState to render this protection moot for anyone who clicks the login link instead of directly visiting UserLogin page. Which is practically everyone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
As an alternative, please send details of the exploit to the security list, or just file a security bug. On Sep 30, 2015 13:03, "John" phoenixoverride@gmail.com wrote:
Can you provide any documentation on the details of this exploit?
On Wed, Sep 30, 2015 at 12:50 PM, Daniel Friesen < daniel@nadir-seen-fire.com
wrote:
Bug? There is nothing that can be fixed.
You just have to accept that as long as the login page is on the same domain as site scripts, there is no way to stop those scripts from controlling the login page.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-09-30 9:33 AM, Tyler Romeo wrote:
Is there a bug filed for that? On Sep 30, 2015 12:13, "Daniel Friesen" daniel@nadir-seen-fire.com
wrote:
On 2015-09-30 8:48 AM, Chris Steipp wrote:
- We disable site and user .js on Special:UserLogin, so a malicious
admin
can't add password sniffing javascript to the login page
Note that you can make use of pushState to render this protection moot for anyone who clicks the login link instead of directly visiting UserLogin page. Which is practically everyone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
There is a slight difference in the ux if you're using pushState vs actually going to the page, so I think it would be noticed. But agree, I should probably have said "make it more difficult".
On Wed, Sep 30, 2015 at 9:50 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Bug? There is nothing that can be fixed.
You just have to accept that as long as the login page is on the same domain as site scripts, there is no way to stop those scripts from controlling the login page.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-09-30 9:33 AM, Tyler Romeo wrote:
Is there a bug filed for that? On Sep 30, 2015 12:13, "Daniel Friesen" daniel@nadir-seen-fire.com
wrote:
On 2015-09-30 8:48 AM, Chris Steipp wrote:
- We disable site and user .js on Special:UserLogin, so a malicious
admin
can't add password sniffing javascript to the login page
Note that you can make use of pushState to render this protection moot for anyone who clicks the login link instead of directly visiting UserLogin page. Which is practically everyone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Visai nemoku jusu kalbos prasau siusti laiskus Lietuviu kalboja! 2015 rug. 30 20:22 "Chris Steipp" csteipp@wikimedia.org rašė:
There is a slight difference in the ux if you're using pushState vs actually going to the page, so I think it would be noticed. But agree, I should probably have said "make it more difficult".
On Wed, Sep 30, 2015 at 9:50 AM, Daniel Friesen < daniel@nadir-seen-fire.com> wrote:
Bug? There is nothing that can be fixed.
You just have to accept that as long as the login page is on the same domain as site scripts, there is no way to stop those scripts from controlling the login page.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-09-30 9:33 AM, Tyler Romeo wrote:
Is there a bug filed for that? On Sep 30, 2015 12:13, "Daniel Friesen" daniel@nadir-seen-fire.com
wrote:
On 2015-09-30 8:48 AM, Chris Steipp wrote:
- We disable site and user .js on Special:UserLogin, so a malicious
admin
can't add password sniffing javascript to the login page
Note that you can make use of pushState to render this protection moot for anyone who clicks the login link instead of directly visiting UserLogin page. Which is practically everyone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi Chris,
Thanks for your answer! One thing I don't understand is about the XFO headers. Do we have to add them or is it a condition that we don't have them.
Ad
Op 30 sep. 2015, om 17:48 heeft Chris Steipp csteipp@wikimedia.org het volgende geschreven:
Hi Ad,
There are some security considerations if you're going to do that:
* We disable site and user .js on Special:UserLogin, so a malicious admin can't add password sniffing javascript to the login page * We disable framing the page to prevent various redressing attacks * If your site is mixed http/https, there is special handling on that page to ensure the user enters/submits their password over https. * If you're using CentralAuth or another SSO system, then we check if you're logged in on Special:UserLogin, to work around some browser cookie policies.
So it's *usually* not a good idea to create your own login widget. But if you're running your site entirely under https, have a limited number of admins, add XFO headers on all pages, and don't use any SSO system, then go for it!
On Tuesday, September 29, 2015, Ad Strack van Schijndel < ad.strackvanschijndel@gmail.com> wrote:
Hi,
Is there a way to embed the login and/or the account creation on normal pages?
I would like to have the possibility to login in a sidebar as long as the user is anonymous. So that there are no extra clicks to login.
I'm sure if there isn't, there is a very good reason for that and I would like to understand that reason.
Ad _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Thu, Oct 1, 2015 at 2:12 AM, Ad Strack van Schijndel < ad.strackvanschijndel@gmail.com> wrote:
Hi Chris,
Thanks for your answer! One thing I don't understand is about the XFO headers. Do we have to add them or is it a condition that we don't have them.
You should add them.
MediaWiki will set X-Frame-Options: DENY by default on API results and edit pages, but if you have a login box on every page, then you'll need to set that from your webserver for every page (or you could add a patch to mediawiki to do it).
Ad
Op 30 sep. 2015, om 17:48 heeft Chris Steipp csteipp@wikimedia.org het volgende geschreven:
Hi Ad,
There are some security considerations if you're going to do that:
- We disable site and user .js on Special:UserLogin, so a malicious admin
can't add password sniffing javascript to the login page
- We disable framing the page to prevent various redressing attacks
- If your site is mixed http/https, there is special handling on that page
to ensure the user enters/submits their password over https.
- If you're using CentralAuth or another SSO system, then we check if
you're logged in on Special:UserLogin, to work around some browser cookie policies.
So it's *usually* not a good idea to create your own login widget. But if you're running your site entirely under https, have a limited number of admins, add XFO headers on all pages, and don't use any SSO system, then go for it!
On Tuesday, September 29, 2015, Ad Strack van Schijndel < ad.strackvanschijndel@gmail.com> wrote:
Hi,
Is there a way to embed the login and/or the account creation on normal pages?
I would like to have the possibility to login in a sidebar as long as the user is anonymous. So that there are no extra clicks to login.
I'm sure if there isn't, there is a very good reason for that and I would like to understand that reason.
Ad _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org