Security review results
756 views
Skip to first unread message
st...@gibedigital.com
Apr 13, 2013, 12:41:45 PM4/13/13
to umbra...@googlegroups.com
Hi,
We've been developing Umbraco sites for a large multinational. All of the sites must go through a security review before they can be put live. There are several things that have come up in every security review for Umbraco sites. I'd like to update the Umbraco core to add some security settings that would enable all Umbraco users to lock down their sites. This would be my first contribution to the Umbraco project so I wanted to run my ideas by everyone to see if they are appropriate for core. I also thought it would be helpful to share the Umbraco specific results as these tests can be fairly expensive to have done.
FYI: I've blanked out the URLs, I'm not working on xxx.com :)
The issues that have come up for every project in priority order are:
1. Cross-Site request forgery
The website administration area at http://www.xxx.com/umbraco is vulnerable to cross-site request forgery (CSRF) on all pages that cause actions such as updates and deletes. A CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim.
Example is the following link, which is for updating content:
POST http://www.xxx.com/umbraco/editContent.aspx?id=<<ID>>
Please see the following OWASP reference for more information:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery
Impact: High
The integrity of information may be affected.
Likelihood: Low
The victim needs to be logged in and the attacker needs to have knowledge of the website. The attacker needs to get the victim to visit a website under the control of the attacker or that is vulnerable to cross-site scripting.
Recommendation
Restrict actions to POST methods and add a hidden key field to forms that validate requests. The hidden key should be unique to the page request and validated on post back. Please see the above OWASP link for more information.
The following links have recommendations for CSRF and ASP.NET:
http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2
2. No Account Lockout on Umbraco Administration Area
The Umbraco administration area has no account lockout following multiple login failures. This leaves the web application susceptible to brute force attacks.
http://www.xxx.com/umbraco/login.aspx
Impact: Medium
A successful brute force attack will lead to the exposure of website content and personal details.
Likelihood: Medium
An attacker will require knowledge of user names. Users will also need to use fairly weak passwords such as dictionary words or common names.
Recommendation
Lockout accounts for a short period of time, say 5 minutes, if the account has multiple login failures, such as 5 in a row. Assign a failure count to the user record rather than the user’s session.
3. The administration functionality is not separate from the front end website
The administration functionality for the website http://www.xxx.com appears to be available on the same domain as the website, as shown:
http://www.xxx.com/umbraco
As a result, any scripts or cookies used by the main websites will also be valid for the administration system, although actual processing will depend on server-side and application configuration. This means that any web application security flaws affecting the website will also affect the admin system.
Impact: High
Any vulnerabilities affecting the main website content will also affect the administration system.
Likelihood: Low
An attacker would need to exploit an existing security flaw in the website to successfully attack the administration functionality.
Recommendation
Consider separating the website administration from the website presentation, ideally through the use of separate domains. Also consider restricting access to this functionality, so that only internal or trusted IP addresses are permitted.
4. Login page allows password auto-completion
Risk: Low
The website administration area at the following URL has a login page that allows password auto-completion on indicated field.
http://www.xxx.com/umbraco/login.aspx
passw
Impact: Medium
A user who can automatically login to this website is more vulnerable to exploitation through cross-site scripting or if they leave their computer unattended.
Likelihood: Low
An attacker can only exploit this through another vulnerability such as cross-site scripting or physical access to the user’s PC.
Recommendation
Add an attribute named 'autocomplete' to the password field on the login page that is set to ‘off’. Please note that this may not work in some browsers.
5. Website Administration Area Supports Concurrent Sessions
The website administration at http://www.xxx.com/umbraco allows multiple simultaneous logins, using the same valid credentials, each being granted a separate session.
Impact: Medium
There is little accountability if logins are shared, as audited actions cannot be tied to an individual person. As there is no alerting or prevention of concurrent sessions then users may be unaware if their account has been compromised.
Likelihood: Low
Valid credentials would be required to generate a valid session.
Recommendation
Institute server side controls to prevent concurrent sessions. There are a number of mechanisms which can be used. For ASP.NET consider use of the property "System.Web.Security.MembershipUser.IsOnline". Further information can be found at the following URL:
http://msdn.microsoft.com/en-us/library/system.web.security.membershipuser.isonline.aspx
6. The site includes the X-AspNetMVC-Version, X-AspNet-Version, X-Powered-By and Server HTTP headers
The staging IIS web server at the following URL shows the versions of IIS and components installed in its HTTP headers.
Impact: Low
The version information can be useful information to an attacker when searching for vulnerabilities. Unnecessary system information is exposed.
Likelihood: Medium
This information is presented in HTTP headers so a simple scan or banner grab would obtain this information.
Recommendation
Use URLScan to stop IIS from showing its version number in returned HTTP headers. URLScan is a free tool developed by Microsoft, designed to harden IIS and improve its security. More information about URLScan and its features can be found on the following link:
http://www.iis.net/download/urlscan
Also update global.asax and web.config to disable these headers
We've been developing Umbraco sites for a large multinational. All of the sites must go through a security review before they can be put live. There are several things that have come up in every security review for Umbraco sites. I'd like to update the Umbraco core to add some security settings that would enable all Umbraco users to lock down their sites. This would be my first contribution to the Umbraco project so I wanted to run my ideas by everyone to see if they are appropriate for core. I also thought it would be helpful to share the Umbraco specific results as these tests can be fairly expensive to have done.
FYI: I've blanked out the URLs, I'm not working on xxx.com :)
The issues that have come up for every project in priority order are:
1. Cross-Site request forgery
The website administration area at http://www.xxx.com/umbraco is vulnerable to cross-site request forgery (CSRF) on all pages that cause actions such as updates and deletes. A CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim.
Example is the following link, which is for updating content:
POST http://www.xxx.com/umbraco/editContent.aspx?id=<<ID>>
Please see the following OWASP reference for more information:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery
Impact: High
The integrity of information may be affected.
Likelihood: Low
The victim needs to be logged in and the attacker needs to have knowledge of the website. The attacker needs to get the victim to visit a website under the control of the attacker or that is vulnerable to cross-site scripting.
Recommendation
Restrict actions to POST methods and add a hidden key field to forms that validate requests. The hidden key should be unique to the page request and validated on post back. Please see the above OWASP link for more information.
The following links have recommendations for CSRF and ASP.NET:
http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2
2. No Account Lockout on Umbraco Administration Area
The Umbraco administration area has no account lockout following multiple login failures. This leaves the web application susceptible to brute force attacks.
http://www.xxx.com/umbraco/login.aspx
Impact: Medium
A successful brute force attack will lead to the exposure of website content and personal details.
Likelihood: Medium
An attacker will require knowledge of user names. Users will also need to use fairly weak passwords such as dictionary words or common names.
Recommendation
Lockout accounts for a short period of time, say 5 minutes, if the account has multiple login failures, such as 5 in a row. Assign a failure count to the user record rather than the user’s session.
3. The administration functionality is not separate from the front end website
The administration functionality for the website http://www.xxx.com appears to be available on the same domain as the website, as shown:
http://www.xxx.com/umbraco
As a result, any scripts or cookies used by the main websites will also be valid for the administration system, although actual processing will depend on server-side and application configuration. This means that any web application security flaws affecting the website will also affect the admin system.
Impact: High
Any vulnerabilities affecting the main website content will also affect the administration system.
Likelihood: Low
An attacker would need to exploit an existing security flaw in the website to successfully attack the administration functionality.
Recommendation
Consider separating the website administration from the website presentation, ideally through the use of separate domains. Also consider restricting access to this functionality, so that only internal or trusted IP addresses are permitted.
4. Login page allows password auto-completion
Risk: Low
The website administration area at the following URL has a login page that allows password auto-completion on indicated field.
http://www.xxx.com/umbraco/login.aspx
passw
Impact: Medium
A user who can automatically login to this website is more vulnerable to exploitation through cross-site scripting or if they leave their computer unattended.
Likelihood: Low
An attacker can only exploit this through another vulnerability such as cross-site scripting or physical access to the user’s PC.
Recommendation
Add an attribute named 'autocomplete' to the password field on the login page that is set to ‘off’. Please note that this may not work in some browsers.
5. Website Administration Area Supports Concurrent Sessions
The website administration at http://www.xxx.com/umbraco allows multiple simultaneous logins, using the same valid credentials, each being granted a separate session.
Impact: Medium
There is little accountability if logins are shared, as audited actions cannot be tied to an individual person. As there is no alerting or prevention of concurrent sessions then users may be unaware if their account has been compromised.
Likelihood: Low
Valid credentials would be required to generate a valid session.
Recommendation
Institute server side controls to prevent concurrent sessions. There are a number of mechanisms which can be used. For ASP.NET consider use of the property "System.Web.Security.MembershipUser.IsOnline". Further information can be found at the following URL:
http://msdn.microsoft.com/en-us/library/system.web.security.membershipuser.isonline.aspx
6. The site includes the X-AspNetMVC-Version, X-AspNet-Version, X-Powered-By and Server HTTP headers
The staging IIS web server at the following URL shows the versions of IIS and components installed in its HTTP headers.
Impact: Low
The version information can be useful information to an attacker when searching for vulnerabilities. Unnecessary system information is exposed.
Likelihood: Medium
This information is presented in HTTP headers so a simple scan or banner grab would obtain this information.
Recommendation
Use URLScan to stop IIS from showing its version number in returned HTTP headers. URLScan is a free tool developed by Microsoft, designed to harden IIS and improve its security. More information about URLScan and its features can be found on the following link:
http://www.iis.net/download/urlscan
Also update global.asax and web.config to disable these headers
Message has been deleted
Steve Temple
Apr 13, 2013, 3:34:13 PM4/13/13
to umbra...@googlegroups.com
For this 2, 4, 5 and 6 look fairly simple to implement
1. Any ideas?
2. adding some sort of short lockout period after x attempts, or adding a captcha that displays after a number of failed attempts would make brute force cracking more difficult. I imagine this would require a change to the db structure though. Also a configuration setting to enable or disable this would, I assume, be required.
3. This can be restricted through the web.config, so that would probably suffice
4. This would be a minor change to the login page
5. I was thinking adding an option to disable concurrent logins with the same login. The user could then be prevented from logging in, or the logged in session automatically logged out when the same user is logged in.
6. It would make sense to turn these off in the default web.config & global.asax / WebBootManager as they server no real purpose, or could be controlled through config setting if backwards compatibility required
Webmonger
Apr 14, 2013, 8:34:15 AM4/14/13
to umbra...@googlegroups.com
Hey
We've also had these issues requested by a security company when doing a pen test.
1. this can be fixed by switching on a flag in the web.config. I cant remember exactly which setting it is but it's to do with request validation and may be that validateRequest="true" will fix it.
2. Umbraco Core change - I think there are some other things that could be added to this request like password reset after 3 months etc...
3. There are a couple of options here. Put /umbraco on another site admin. or umbraco. You have the option to restrict the IP address that accesses the /umbraco folder on you're firewall or maybe via IIS
4. Yes, You can do this yourself by editing the /umbraco/login.aspx I believe.
5. Not come accross that one, your idea sounds like a good idea.
6. Yeah you can do the first 3 via the web.config, but for the server type you have to create an HttpModule. You can see an example class here http://blogs.technet.com/b/stefan_gossner/archive/2008/03/12/iis-7-how-to-send-a-custom-server-http-header.aspx
Hope this helps you out :)
Jon
We've also had these issues requested by a security company when doing a pen test.
1. this can be fixed by switching on a flag in the web.config. I cant remember exactly which setting it is but it's to do with request validation and may be that validateRequest="true" will fix it.
2. Umbraco Core change - I think there are some other things that could be added to this request like password reset after 3 months etc...
3. There are a couple of options here. Put /umbraco on another site admin. or umbraco. You have the option to restrict the IP address that accesses the /umbraco folder on you're firewall or maybe via IIS
4. Yes, You can do this yourself by editing the /umbraco/login.aspx I believe.
5. Not come accross that one, your idea sounds like a good idea.
6. Yeah you can do the first 3 via the web.config, but for the server type you have to create an HttpModule. You can see an example class here http://blogs.technet.com/b/stefan_gossner/archive/2008/03/12/iis-7-how-to-send-a-custom-server-http-header.aspx
Hope this helps you out :)
Jon
sniffdk
Apr 14, 2013, 4:02:37 PM4/14/13
to umbra...@googlegroups.com
Nice and detailed, interesting, lot of stuff to consider :)
Damiaan Peeters
Apr 14, 2013, 6:10:08 PM4/14/13
to umbra...@googlegroups.com
Hi
1) Owasp website also tells how to use the viewstate how to solve this: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Viewstate_.28ASP.NET.29
quote: "However, if the current session ID is added to the ViewState, it then makes each Viewstate unique, and thus immune to CSRF. " Don't know how easy it is to implement, and if it is already done or not.
@WebMonger: I thought the RequestValidation option only allows or prevents the server from accepting content containing un-encoded HTML. I can't remember this is linked to CSRF, is it?
2) feel free to write or extend your own membershipProvider ;-)
3) a few options already available. Shield this directory using reversed proxy, only allow certain ip's on this directory, ... We did this for ***** and it passed security audits.
4) no comments, I love this feature :-)
5) combined comments from point 2 and 4 ;-)
6) you can remove most of these headers on the (reversed) proxy server and on IIS itself. Umbraco has no contol over it (The already removed the umbraco version from the headers...)
Kind regards
Steve Temple
Apr 14, 2013, 6:44:35 PM4/14/13
to umbra...@googlegroups.com
Hi,
I guess my main question really is: Are some of these this something that people would consider building into the standard Umbraco distribution, that way when Umbraco sites are deployed by people that aren't developers have more secure sites, I'm thinking of 2, 4, 5 and 6 in particular. Also whether if I did write some updates to address these would that be of any benefit to use in Umbraco core.
1) I think it might be changing enableEventValidation to true might resolve this, but I need to investigate some more
2) I am looking into writing an alternate membershipProvider over the next couple of weeks that will add this
3) Setting location specific options in web.config do allow this to be addressed
4) Autocomplete should really be disabled by default on production servers, although admittedly it is convenient!
5) This seems like a fairly sensible suggestion, although I know currently most of my clients share the same login, but wouldn't be tricky to set them up with individual logins
6) Again I guess my point is should they just be turned off by default in the distribution so that non developers who implement Umbraco sites don't show these anyway
Ove Andersen
Apr 15, 2013, 3:46:46 AM4/15/13
to umbra...@googlegroups.com
At the very least, we should put these security considerations on the wiki.
On Saturday, April 13, 2013 6:41:45 PM UTC+2, Steve Temple wrote:
A lot of developers don't know about these kinds of things, and it would be nice to have a list with potential issues and solutions.
On Saturday, April 13, 2013 6:41:45 PM UTC+2, Steve Temple wrote:
j...@screenmedia.co.uk
Apr 15, 2013, 7:17:13 AM4/15/13
to umbra...@googlegroups.com
On Sunday, April 14, 2013 11:10:08 PM UTC+1, Damiaan Peeters wrote:
I've just checked the code (Had no access over the weekend) :)
Barry Fogarty
Apr 15, 2013, 7:54:22 AM4/15/13
to umbra...@googlegroups.com, j...@screenmedia.co.uk
1 and 2 sound like a good idea to add to the core and have as the default setting.
Would be great to have an advanced security extension to uGoLive which could address the other points - and point users to Wiki pages with instructions on e.g. disabling autocomplete if they are interested in fully locked down security. The uGoLive project is already set up to allow for community contribs:
5 sounds like a nice-to-have option. I would also like to see a feature in the core that allows an editor see if someone else currently has the same page open for editing. Would be good to have these as production only (debug = false) features, to avoid any extra friction during dev.
Shannon Deminick
Apr 25, 2013, 7:07:30 PM4/25/13
to umbra...@googlegroups.com
Some good news is that we are in the process of fixing these in the core:
* Login page allows password auto-completion
* The site includes the X-AspNetMVC-Version, X-AspNet-Version, X-Powered-By and Server HTTP headers
Will be part of 4.11.8+, 6.0.5+, 6.1+
Steve Temple
Apr 25, 2013, 7:31:50 PM4/25/13
to umbra...@googlegroups.com
Awesome, that's great news,
I've developed an extensions to the membership provider that locks accounts for a specified period after a specified number of minutes, all set using the standard membership provider parameters. I plan on releasing this as a module as soon as I find some time.
Cheers,
Steve
Barry Fogarty
Apr 26, 2013, 8:09:56 AM4/26/13
to umbra...@googlegroups.com
Excellent stuff. Steve drop a message here please when you have released your enhanced membership security module, I would very be interested to take a look - thanks for sharing!
Steve Temple
Jun 12, 2013, 11:14:37 AM6/12/13
to umbra...@googlegroups.com
Hi, I've finally found time to publish this, let me know any feedback: http://our.umbraco.org/projects/website-utilities/lockout-membership-provider
Reply all
Reply to author
Forward
0 new messages