We recently had a security test done on Umbraco, and one of the security issues came back related to /umbraco/views/common/dialogs/login.html.
The issue came back as follows:
Password in GET String or Set-Cookie Header Description: A password was found in a GET string or Set-Cookie header. This could allow an attacker who is monitoring web requests to obtain a user's password. Solution: Sensitive data, including passwords, should not be sent in URL parameters via GET requests. It is recommended that sensitive data be sent to the server via POST requests to help prevent that data being cached/stored in transit or even captured. In addition, sensitive data should only be sent over TLS-enabled (SSL/HTTPS) connections.
Now when I access this view directly, you can input credentials and it sends them in a get request like the issue mentions; but the question is, is it really a problem since it doesn't seem to initiate any sort of login or let the person know if the credentials are valid? I mean obviously someone can send someone to this page, tell them to login through here, and then sniff the login credentials in the get request if it wasn't encrypted over HTTPs.
Is anyone else concerned about this? Is there a way that access can be restricted to this page or it can be removed altogether?
Thanks for reporting. It doen't appear there is any vulnerability with this item as it can only be seen by an already authenticated umbraco user when asked to authorize an upgrade. But, of course, we'll do a full review and make adjustments if there is any potential risk.
In general, best practices dictate that the /umbraco/ path be IP restricted in your production sites. In that case, only authorized IP addresses would have access to the dialog itself. Of course, you shouldn't (and we don't) rely on IP restrictions for authentication, but it is a recommended configuration if security is a top concern for your sites.
I appreciate you taking the time to look into it. I noticed that the /umbraco/views/common/dialogs/login.html path is actually available even BEFORE an Umbraco User is authenticated. If you visit that page, you get a plain HTML login form (see screenshot attached).
So if you restrict /umbraco/ path, you're saying you recommend restricting access to the backoffice based on IP address?
Right now that would work for us, but unfortunately we're eventually be looking into several users (not only from our company), being able to let people log into the back office to edit some content. Obviously as that allowed user list grows, management of authorized IPs would become cumbersome.
@Shannon -
We simply have an Umbraco instance running in Azure, and when you append that path above to the root url of the site, you can access the login form which seems to send a get request with plaintext password if you fill out and submit the form.
Yes, restricting back office access by IP is recommended if you are looking to harden your access to the back office - there are other ways of doing this same thing of course. But this is no different for Umbraco than any other website.
This is really not a security concern... I can't see any real admin going to this URL and trying to login from there. However, in the ultra very rare case that this would ever happen, you can just change that HTML file to have this attribute in the form tag:
<form method="POST"
I'll update the core with this change too just in case.
The question is, what is the use of this login.html? I'm assuming this is the view used on the main page when you log in to the back office, correct? So removing it altogether would cause you not to have a form to log in to the back office, right?
This is an angular view file. It is never loaded in the browser as an html request unless you go to this url directly. But you would never do that because it has zero functionality when loaded that way. All of the html files in these folders are angular views and loaded by, and controlled with angular.
Anyways, you cannot remove it since it's needed by the back office angular app, but you can update the form tag in the html to be POST as mentioned above if you are worried in any way. I've updated it in the core now too.
Just to be clear, regardless of the action element on that form tag, the back office login of umbraco is always done with a POST which us controlled by angular.
Potential Security Concern with /umbraco/views/common/dialogs/login.html
We recently had a security test done on Umbraco, and one of the security issues came back related to /umbraco/views/common/dialogs/login.html.
The issue came back as follows:
Now when I access this view directly, you can input credentials and it sends them in a get request like the issue mentions; but the question is, is it really a problem since it doesn't seem to initiate any sort of login or let the person know if the credentials are valid? I mean obviously someone can send someone to this page, tell them to login through here, and then sniff the login credentials in the get request if it wasn't encrypted over HTTPs.
Is anyone else concerned about this? Is there a way that access can be restricted to this page or it can be removed altogether?
@Anthony -
Thanks for reporting. It doen't appear there is any vulnerability with this item as it can only be seen by an already authenticated umbraco user when asked to authorize an upgrade. But, of course, we'll do a full review and make adjustments if there is any potential risk.
In general, best practices dictate that the /umbraco/ path be IP restricted in your production sites. In that case, only authorized IP addresses would have access to the dialog itself. Of course, you shouldn't (and we don't) rely on IP restrictions for authentication, but it is a recommended configuration if security is a top concern for your sites.
What is the way to replicate this?
@Paul -
I appreciate you taking the time to look into it. I noticed that the /umbraco/views/common/dialogs/login.html path is actually available even BEFORE an Umbraco User is authenticated. If you visit that page, you get a plain HTML login form (see screenshot attached).
So if you restrict /umbraco/ path, you're saying you recommend restricting access to the backoffice based on IP address?
Right now that would work for us, but unfortunately we're eventually be looking into several users (not only from our company), being able to let people log into the back office to edit some content. Obviously as that allowed user list grows, management of authorized IPs would become cumbersome.
@Shannon -
We simply have an Umbraco instance running in Azure, and when you append that path above to the root url of the site, you can access the login form which seems to send a get request with plaintext password if you fill out and submit the form.
@Anthony
Yes, restricting back office access by IP is recommended if you are looking to harden your access to the back office - there are other ways of doing this same thing of course. But this is no different for Umbraco than any other website.
-Paul
This is really not a security concern... I can't see any real admin going to this URL and trying to login from there. However, in the ultra very rare case that this would ever happen, you can just change that HTML file to have this attribute in the form tag:
I'll update the core with this change too just in case.
@Shannon -
The question is, what is the use of this login.html? I'm assuming this is the view used on the main page when you log in to the back office, correct? So removing it altogether would cause you not to have a form to log in to the back office, right?
This is an angular view file. It is never loaded in the browser as an html request unless you go to this url directly. But you would never do that because it has zero functionality when loaded that way. All of the html files in these folders are angular views and loaded by, and controlled with angular.
Anyways, you cannot remove it since it's needed by the back office angular app, but you can update the form tag in the html to be POST as mentioned above if you are worried in any way. I've updated it in the core now too.
Just to be clear, regardless of the action element on that form tag, the back office login of umbraco is always done with a POST which us controlled by angular.
Thank you for all the clarifications Shannon!
is working on a reply...