Great to see someone initiating a security package. Unfortunately security doesn't seem to be getting as much attention from HQ as it requires, but perhaps a package can help.
Like you I'm already doing a lot of this as part of my base install.
Here are a few more items to consider:
XSS
Certificate validation
Cipher validation
Log server support
Log archival
CSRF
Check for vulnerable/outdated installed packages
Flag if running vulnerable Umbraco version
Password expiration
Check for information leaks (e.g. via e-mail)
Re-route /umbraco folders (constitutes information leak)
I like some of those ideas a lot, though you need to be careful with logging that the logging itself doesn't not end up resulting in a severe performance impact on a site.
In older versions of Umbraco (4?) all 404s were logged by default to the umbracoLog table and this resulted in some sites with literally millions of rows of data - you'd be surprised how many 404s a site can generate, especially when it gets hit by search spiders.
Likewise, I've enabled 500 error emailing on sites in the past, but again found that sites generate a surprising amount of 500 errors, especially at times when the application pool recycles etc. If you're not careful you can almost DDOS yourself!
Good luck, but beware that too much logging can affect performance.
@Dan - good points, but that's why I suggested writing to a log server. I'm the Application Delivery Engineer of an enterprise environment, so I'm thinking about apps from that perspective.
However, after contemplating this a bit more I wonder if it's actually necessary to log 404s (and even 500s) in the Umbraco logs (or a separate database).
Wouldn't it make more sense to utilize the IIS and Windows logs?
Speaking of (D)DoS, would you happen to know if the Image Cropper now limits the size of the cache folder? If not this would constitute a vulnerability.
PS
Shouldn't Umbraco have a Security group? There are probably other members who have a security background. As far as I know there is no formal Security effort for Umbraco. It's just a matter of time before security breaches happen and that would most likely hurt Umbraco.
In addition, the security/privacy landscape is changing and new approaches are being implemented. However, Umbraco probably isn't ready for this. For instance, HTTPS-everywhere is becoming a standard, but updating Umbraco still requires disabling HTTPS for the backoffice in the config before updating. That is going to be a problem.
This has been a problem since earlier versions. When I checked recently (v7) and attempted to upgrade with HTTPS required for the backoffice the update failed (hung).
Granted, this issue would be of greater impact to installs that don't have a DEV (or Test/UA) environment, but that would seem to a significant percentage. In addition, even those non-Prod environments often have stringent security requirements in a corporate environment.
From your response it would seem that this issue has been resolved, so I'll try it on a 7.2.6 install that still needs to be upgraded to 7.2.8 and report back.
@Sebastiaan - yes, the flag umbracoUseSSL is what I'm referring to. In the past this had to be set to false or the update would fail. Like I said, I don't know if that's still the case in 7.2.6.
@Seb - I can confirm that I don't have to disable SSL for an upgrade to work via NuGet :)
I upgrade locally then push and deploy from Git and it all works fantastically.
@Dan Re: Logs - Perhaps rolling logs with window of x number of days would help keep things manageable.
@Arie - Good stuff, keep it coming. External logs would be wonderful too, but then we'd have to deal with a cost or dependency.
Re: the IIS and windows logs. It's a possibility but I think it would be hard to start finding certain IP's that need to be blacklisted if we didn't log to a simple table. Just spitballing. Also, I primarily use Azure and there's really no Event Viewer, etc AFAIK. There are the standard access logs though.
Keep the comments coming as I think we can begin to shape some basic functionality.
Re: Image Processor (Cropper) - I could see someone requesting every conceivable height/width combination via a script to put massive loads on the caching/cropping process. I think we need James to weigh in.
We could counter the above by throttling by IP (unless they use a proxy). In general, DoS is tough to thwart if someone is determined regardless.
However, hardening this feature also means it breaks the UI experience because even if you create static crops in the backoffice (w image cropper), you'll still need to whitelist the crop size.
I definitely recommend you white-list your crops to avoid someone filling up your hard drive by requesting all possible crop sizes for all of your images.
@Seb - Hmmm. The best part (IMHO) of ImageProcessor is being able to dynamically create crops on the fly. Am I wrong to infer that it's not-secure to do that then? :) Or do I have to figure out where in my code I've made a dynamic crop and put in the static restrictions in my config?
No it's not a good idea to allow just any crop. Unless you have unlimited disk space and loads of processing power.
This goes for Imagegen as well. Also, it has not been a problem (so far) for either package. But it definitely could be, and I see no possible solution for this apart from setting some limits in a config file.
I didn't see any options in the config files to limit the crops. Even so, it would seem to me that the only way to address this issue is by limiting the folder size (evicting older entries). Years ago I used an image optimizer that had this feature, but I haven't seen it in ImageProcessor (yet).
@Sebastiaan: the documentation link for ImageGen you supplied seems to be rather dated (2008/v2.0.1).
Rolling the cache folder would help but would still cost processing power during the 'churn' of images being created/deleted.
I'd like to develop a IP throttler that can hopefully detect a threat from bad guy IP's and possibly shut them off for a cool down period (sort of like a API rate limiter).
I think a very good starting point would to have something like uGoLive back in the core. Perhaps with a few levels of severity - eg. errors, warnings and just recommended. You can then quickly get an overview of what ought to be changed or adjusted in the configuration.
If something like this is added back to the core, package developers could also build on top of it, listing stuff that could be improved for a particular package.
Side note, for some reason I can't reply to a sub-comment (doesn't give me the option).
@Seb - Not that I'm trying to implicate the core, but without the crops statically configured, is it not OOTB at least somewhat open to DoS?
An ordinary downloader of Umbraco certainly won't know about this and seasoned Umbracians may not realize it either.
And for any follow-on readers, this isn't a witch hunt for ImageProcessor or the core, just a point for building a case to create a package which makes the developer aware of such things and offer counter-measures. A DDoS usually succeeds if they throw enough resources at a target.
Same problem here not being able to reply to sub-comments :-|
You're right that this topic wasn't intended to be a discussion about security in general (and ImageProcessor in particular), which is why I suggested to start a Security Group :-)
This seems to be underscored by the furious back-and-forth about Umbraco security.
Soooo... a suggestion to HQ:
How about a Security Group/Effort? There are quite a few people on the board who have either good ideas about security, a lot of experience with it, or are certified (e.g. Kevin and myself) - and are not malicious hackers.
Back to the package Kevin has initiated (which is more along the lines of uGoLive if I understand Kevin's intent).
ImageProcessor: check configuration to ensure limits are enabled.
FYI: you should now have a reply button on subcomments and an edit button to go with it so you actually have a chance of being able to edit immediately after replying without having to refresh the page! (refresh browser cache if you don't see these)
So, I really LOVE this idea, it's been on my hitlist to work on whenever I have some free time and I have a half finished documentation page on this as well. Unfortunately, there's only so many hours in the day, so I'm happy someone else is enthusiastic about it!
A package is nice but we really want this to be in core, front and center in each install.
We discussed this exact same thing at the codegarden retreat a few months ago as well: putting a uGoLive-like system back in the core so we can show our own check AND have people drop in their own checks. I've asked Shannon to make a description of what we'd need to have and where it should live in the core.
Of course this would be of no benefit to older installs but it should be trivial to build a separate dll and dashboard for older installs that can detect the same installed checks and run them.
Keep the ideas coming and I'll post back when we have a description of how we want to deal with this in the core!
excellent topic and I would love to join in. I passed my CISSP-exam this year and have been thinking about security a lot since I started my CISSP-course.
We had a few security audits from external companies (passed them all eventually) and reported most of the issues directly to HQ (Sebastiaan / Shannon). All of them got fixed, because most were small bugs to fix.
Examples of security issues that have been fixed lately:
Fixed somewhere in 7.2.x:
maxInvalidPasswordAttempts didn't work anymore (Brute-force blocking)
Add login attempts to /umbraco/ in the log-files
Include IP-adresses to the log-files
Passwords are shown in plaintext within the change password functionality
So I don't think there is focus on security from HQ, but you just have to help them to pointing them in the right direction ;)
Furthermore there is a lot of settings that could be set in Umbraco, but it's not that well documented. For example "Enforce password complexity for backoffice users" can be set in the web.config, you just have to know where.
About security and Umbraco we should take care that we only build stuff in Umbraco that is software related and not so much an IIS or server issue. There are tools in IIS to do stuff like IP-white/blacklisting and block SQL Injection attempts. I do think that we need to document how you could to that, but I don't think it should be in Umbraco.
Issues that I'm currently thinking of and aren't in the core right now:
We got an issue reported from a security company that there's an XSRF-vulnerability on the login page of /umbraco/. I didn't had enought time to look into it.
Password history/aging
Send an email when a login is detected from a new device (http://issues.umbraco.org/issue/U4-6878)
You don't have to enter your old password to change your password on the dashboard in /umbraco/. You can set allowManuallyChangingPassword to false in the web.config, but then the User-section also requires an old password to reset a password, and that is something you don't want.
As I said, I would really love to help when we're getting something up and going about security. Whether is in the form of a package, HQ-support, documentation or anything else!
Why? This practically forces people to use a simple password that can be remembered. It's much better, IMO, to have a secure password saved by the browser or password manager than it is to rely on users remembering the password. If I want my browser or password manager to remember my password, that should be my choice and not imposed.
"Websites that attempt to enforce autocomplete="off" break the ability
for users to use secure passwords"
We do get regular reports from (large) companies doing pen-tests on Umbraco and we fix what's needed regularly.
So there's plenty of people looking at it from different angles. More eyes is obviously always better but it seems pretty well covered at the moment.
I propose we build a dashboard that tests common things very much like uGoLive from v4/6.
Custom Errors = On
Permissions Check
ImageProcessor crop config restrictions (prevent scripts from requesting all images at all sizes)
Backoffice SSL = On
Password Complexity = On (need help with this one)
DB identity check?
Tougher things like blacklisting bad IP's will come later and possibly in a different package. It should really be handled at the network or transport layers. The trick is to detect who's the bad IP.
I'll ping Matt Brailsford to see if he's up for taking this on or passing it on as he's the project owner for uGoLive.
In the spirit of keeping things simple (for now), please add simple checks we can do. If the solution requires things we can't/shouldn't do programmatically, we'll just add some help text to guide the dev.
On our internal checklist there is also the following stuff:
In web.config the attribute "useLegacyEncoding" is set to "false", the "minRequiredPasswordLength" is "8" characters (although this is trivial, but the default of four is really short) for the memberproviders
The minRequiredNonalphanumericCharacters for the UsersMembersShipProvider is set to "1".
/umbraco/ is in your exclude list in your robots.txt
Could you check whether a custom 404 page is configured in umbracoSettings.config and that the Id exists? Whilst not a security thing, as such, it's essential for going live.
For security, should disableAlternativeTemplates be set to "false" in umbracoSettings.config since this potentially allows an attacker to use an alternative template to render content in a way that wasn't intended? For instance, imagine you have a template only used by protected pages and has some hardcoded content that is sensitive, but someone invokes this with the home page...
I'm also curious about disallowedUploadFiles setting. Should this contain other stuff like executables types, or is it safe to assume IIS will block those anyway?
... I have yet to properly document this and it doesn't necessarily need to be for v8 (could be sooner) but would be awesome if a community member did it :) My plan is to document how this task would work and it would be 100% pluggable. People could create plugins to add to the "checklist" and each plugin describes what their item can do (i.e. can it be fixed with a button, does it require some other input... the plugin will provide this functionality).
I think this would be an amazing addition and we could see some really great stuff being added as packages. Anyways, I'll update that task soon with a full detailed list of what would need to be implemented and mark it as an up-for-grabs task.
For the error logging, I'd look at using something like ELMAH, rather than rolling something yourself. It's a nice system (and can support sending emails as well as logging to DB/Disk). I also find it very handy for spotting things like attempted SQL injection and XSS attacks.
Raygun is a good paid for alternative as well, that has a very nice dashboard for monitoring stuff.
I promise I'm poking Shannon for an update on that issue with some requirements. :-) So hold the thought for a little longer.
With regards to the security group, I'm all ears. I currently can't really imagine what that would look like or how it would work so I'm here to listen to your suggestions and together we can come up with something that's practical!
FYI: We've been getting great tips from, among others, Jeffrey for the last few months and those have almost all been incorporated into the next Umbraco releases. So we're happy to improve whatever we need to improve, feel free to talk to us so we can come up with practical improvements and implement them!
I'm looking forward to hearing some details from Shannon :D
Anyways, wouldn't it make sense to create a new thread, issue on the tracker or repo for this for the further discussion?
I generally like the way uGoLive is structured, but also have some ideas of my own - which may or may not make sense based on what Shannon comes up with.
Since I'm not sure whether I can use the uGoLive name (or whether it makes sense to use the old name), and it might up being renamed anyways if added to the core, I've called the project Preflight for now.
It seems that the old uGoLive supported groups as well, but I don't recall ever seeing it in use.
Also, uGoLive works by classes implementing the ICheck interface. I'm still relying on that interface, but I plan to make it work a little different.
uGoLive works by automatically finding implementations of the ICheck inteface, and then creating a new instance of each class. That means that one class equals one check - you can't use the same solid class for multiple checks.
In the code I've pushed up on GitHub, checks should be added manually, and the same class could be initialized for various checks (of the same type). I believe this gives some greater control, and doesn't require that much work anyway.
As a quick example, you could execute the following during startup:
// Get the "umbraco" group (it should already exist)
PreflightGroup umbraco = PreflightContext.Current.Groups.GetGroup("umbraco");
// Add our custom check to the "umbraco" group
if (umbraco != null) {
umbraco.Checks.Add(new RectifyCheck());
}
// Create a new group for "My Package"
PreflightGroup myPackage = new PreflightGroup("My package", "my-package");
myPackage.Checks.Add(new ExampleCheck());
// Add the group to the Preflight context
PreflightContext.Current.Groups.Add(myPackage);
Having better control over which checks are added and shown, you could remove some of the default check if you don't want them to be shown, or just rearrange their order.
The code currently lets you run a given check, but I haven't implemented logic for rectifying yet. The code also doesn't contain any checks at the moment.
Since you mention Dynamic IP Restrictions, thought I'd share some notes I wrote down for myself a while back (the short version being that DIPR doesn't handle throttling in a way I would like).
Throttle Requests. When a search engine (or similar bot) hits a site, it can crawl dozens or hundreds of pages at once, which can bring it to a standstill.
If we throttle those requests, we can reduce the impact on typical users.
Wouldn't want to return a non-200 response, as we want search engines to see valid pages. This is a deficiency in IIS 8's Dynamic IP Restrictions capability.
Also, we'd only want to throttle dynamic pages... search engines can crawl the static content as they please, as there is virtually no impact on the CPU. Something I'm not sure Dynamic IP Restrictions is capable of.
The UI mockup looks good and you are definitely on the right track with the details on this task. If you can please keep all implementation discussion about this on the issue tracker that'd be great!
Any questions, changes, concerns about the implementation details can also be kept on the tracker.
Topic author was deleted
Security Essentials Proposal
Hot on the heels on getting my CEH, I'm contemplating creating a "security essentials" package that would help harden Umbraco installs.
Key features:
Looking for feedback as I'm already doing a lot of this stuff in my projects.
Congratulations on getting your CEH!
Great to see someone initiating a security package. Unfortunately security doesn't seem to be getting as much attention from HQ as it requires, but perhaps a package can help.
Like you I'm already doing a lot of this as part of my base install.
Here are a few more items to consider:
I like some of those ideas a lot, though you need to be careful with logging that the logging itself doesn't not end up resulting in a severe performance impact on a site.
In older versions of Umbraco (4?) all 404s were logged by default to the
umbracoLogtable and this resulted in some sites with literally millions of rows of data - you'd be surprised how many 404s a site can generate, especially when it gets hit by search spiders.Likewise, I've enabled 500 error emailing on sites in the past, but again found that sites generate a surprising amount of 500 errors, especially at times when the application pool recycles etc. If you're not careful you can almost DDOS yourself!
Good luck, but beware that too much logging can affect performance.
@Dan - good points, but that's why I suggested writing to a log server. I'm the Application Delivery Engineer of an enterprise environment, so I'm thinking about apps from that perspective.
However, after contemplating this a bit more I wonder if it's actually necessary to log 404s (and even 500s) in the Umbraco logs (or a separate database). Wouldn't it make more sense to utilize the IIS and Windows logs?
Speaking of (D)DoS, would you happen to know if the Image Cropper now limits the size of the cache folder? If not this would constitute a vulnerability.
PS Shouldn't Umbraco have a Security group? There are probably other members who have a security background. As far as I know there is no formal Security effort for Umbraco. It's just a matter of time before security breaches happen and that would most likely hurt Umbraco. In addition, the security/privacy landscape is changing and new approaches are being implemented. However, Umbraco probably isn't ready for this. For instance, HTTPS-everywhere is becoming a standard, but updating Umbraco still requires disabling HTTPS for the backoffice in the config before updating. That is going to be a problem.
Time to start a Security group?
Huh? How's that?
This has been a problem since earlier versions. When I checked recently (v7) and attempted to upgrade with HTTPS required for the backoffice the update failed (hung).
Granted, this issue would be of greater impact to installs that don't have a DEV (or Test/UA) environment, but that would seem to a significant percentage. In addition, even those non-Prod environments often have stringent security requirements in a corporate environment.
From your response it would seem that this issue has been resolved, so I'll try it on a 7.2.6 install that still needs to be upgraded to 7.2.8 and report back.
No, this has not been "resolved", I still don't know what this means. :-)
Have you set:
<add key="umbracoUseSSL" value="true" />in appSettings?@Sebastiaan - yes, the flag
umbracoUseSSLis what I'm referring to. In the past this had to be set tofalseor the update would fail. Like I said, I don't know if that's still the case in 7.2.6.Let us know in the issue tracker if this is still the case with repro steps.
Comment author was deleted
@Seb - I can confirm that I don't have to disable SSL for an upgrade to work via NuGet :)
I upgrade locally then push and deploy from Git and it all works fantastically.
@Dan Re: Logs - Perhaps rolling logs with window of x number of days would help keep things manageable.
@Arie - Good stuff, keep it coming. External logs would be wonderful too, but then we'd have to deal with a cost or dependency.
Re: the IIS and windows logs. It's a possibility but I think it would be hard to start finding certain IP's that need to be blacklisted if we didn't log to a simple table. Just spitballing. Also, I primarily use Azure and there's really no Event Viewer, etc AFAIK. There are the standard access logs though.
Keep the comments coming as I think we can begin to shape some basic functionality.
Re: Image Processor (Cropper) - I could see someone requesting every conceivable height/width combination via a script to put massive loads on the caching/cropping process. I think we need James to weigh in.
We could counter the above by throttling by IP (unless they use a proxy). In general, DoS is tough to thwart if someone is determined regardless.
Re. updating with SSL (TLS, hopefully :-) ) enabled, exactly my point. Many people don't use NuGet/Git) nor use a non-Prod environment.
Re. logs: may need a size limit also.
Re. DoS: regular DoS isn't that hard to combat. DDoS is much more difficult.
ImageProcessor (and ImageGen) can be configured to allow only certain crops.
http://imageprocessor.org/imageprocessor-web/configuration/
https://our.umbraco.org/FileDownload?id=95
Comment author was deleted
Update to this, the syntax isn't on the documentation. After pinging James, you can find the syntax here:
https://github.com/JimBobSquarePants/ImageProcessor/issues/49#issuecomment-129658079
However, hardening this feature also means it breaks the UI experience because even if you create static crops in the backoffice (w image cropper), you'll still need to whitelist the crop size.
I definitely recommend you white-list your crops to avoid someone filling up your hard drive by requesting all possible crop sizes for all of your images.
Comment author was deleted
Oh and one other fleeting thought.
I think most (maybe all) features need to be enable/disable-able to satisfy needs according to taste.
i.e. Email 500 errors? enable/disable Log 404's? enable/disable Throttle users by IP to x number of requests per hour? enable/disable
Comment author was deleted
@Arie - Good point regarding non-NuGet users.
@Seb - Hmmm. The best part (IMHO) of ImageProcessor is being able to dynamically create crops on the fly. Am I wrong to infer that it's not-secure to do that then? :) Or do I have to figure out where in my code I've made a dynamic crop and put in the static restrictions in my config?
Kind of defeats the purpose of the feature?
i.e. myImage.GetCropUrl(height: 100, width: 200);
No it's not a good idea to allow just any crop. Unless you have unlimited disk space and loads of processing power.
This goes for Imagegen as well. Also, it has not been a problem (so far) for either package. But it definitely could be, and I see no possible solution for this apart from setting some limits in a config file.
I didn't see any options in the config files to limit the crops. Even so, it would seem to me that the only way to address this issue is by limiting the folder size (evicting older entries). Years ago I used an image optimizer that had this feature, but I haven't seen it in ImageProcessor (yet).
@Sebastiaan: the documentation link for ImageGen you supplied seems to be rather dated (2008/v2.0.1).
http://imageprocessor.org/imageprocessor-web/imageprocessingmodule/resize/
https://github.com/JimBobSquarePants/ImageProcessor/issues/49
Re: ImageGen: Correct, that was an old link; https://our.umbraco.org/FileDownload?id=10776 is better.
Comment author was deleted
Rolling the cache folder would help but would still cost processing power during the 'churn' of images being created/deleted.
I'd like to develop a IP throttler that can hopefully detect a threat from bad guy IP's and possibly shut them off for a cool down period (sort of like a API rate limiter).
Everything is a tradeoff of course :/
I think a very good starting point would to have something like uGoLive back in the core. Perhaps with a few levels of severity - eg. errors, warnings and just recommended. You can then quickly get an overview of what ought to be changed or adjusted in the configuration.
If something like this is added back to the core, package developers could also build on top of it, listing stuff that could be improved for a particular package.
Comment author was deleted
Yep, I miss that little plugin :)
Comment author was deleted
Side note, for some reason I can't reply to a sub-comment (doesn't give me the option).
@Seb - Not that I'm trying to implicate the core, but without the crops statically configured, is it not OOTB at least somewhat open to DoS?
An ordinary downloader of Umbraco certainly won't know about this and seasoned Umbracians may not realize it either.
And for any follow-on readers, this isn't a witch hunt for ImageProcessor or the core, just a point for building a case to create a package which makes the developer aware of such things and offer counter-measures. A DDoS usually succeeds if they throw enough resources at a target.
Same problem here not being able to reply to sub-comments :-|
You're right that this topic wasn't intended to be a discussion about security in general (and ImageProcessor in particular), which is why I suggested to start a Security Group :-) This seems to be underscored by the furious back-and-forth about Umbraco security.
Soooo... a suggestion to HQ:
How about a Security Group/Effort? There are quite a few people on the board who have either good ideas about security, a lot of experience with it, or are certified (e.g. Kevin and myself) - and are not malicious hackers.
Back to the package Kevin has initiated (which is more along the lines of uGoLive if I understand Kevin's intent).
FYI: you should now have a reply button on subcomments and an edit button to go with it so you actually have a chance of being able to edit immediately after replying without having to refresh the page! (refresh browser cache if you don't see these)
@arie: I love the idea and I'll see if we can get this going places ASAP. #h5yr
Here's an existing discussion (from 2013) touching on some of the OWASP issues. Some of these could be incorporated in the package as simple checks.
https://groups.google.com/forum/#!topic/umbraco-dev/UTuAYCGEYbE
So, I really LOVE this idea, it's been on my hitlist to work on whenever I have some free time and I have a half finished documentation page on this as well. Unfortunately, there's only so many hours in the day, so I'm happy someone else is enthusiastic about it!
A package is nice but we really want this to be in core, front and center in each install.
We discussed this exact same thing at the codegarden retreat a few months ago as well: putting a uGoLive-like system back in the core so we can show our own check AND have people drop in their own checks. I've asked Shannon to make a description of what we'd need to have and where it should live in the core.
Of course this would be of no benefit to older installs but it should be trivial to build a separate dll and dashboard for older installs that can detect the same installed checks and run them.
Keep the ideas coming and I'll post back when we have a description of how we want to deal with this in the core!
Hey guys,
excellent topic and I would love to join in. I passed my CISSP-exam this year and have been thinking about security a lot since I started my CISSP-course.
We had a few security audits from external companies (passed them all eventually) and reported most of the issues directly to HQ (Sebastiaan / Shannon). All of them got fixed, because most were small bugs to fix.
Examples of security issues that have been fixed lately:
Fixed somewhere in 7.2.x:
In 7.3: - http://issues.umbraco.org/issue/U4-6736 - http://issues.umbraco.org/issue/U4-6624
So I don't think there is focus on security from HQ, but you just have to help them to pointing them in the right direction ;)
Furthermore there is a lot of settings that could be set in Umbraco, but it's not that well documented. For example "Enforce password complexity for backoffice users" can be set in the web.config, you just have to know where.
About security and Umbraco we should take care that we only build stuff in Umbraco that is software related and not so much an IIS or server issue. There are tools in IIS to do stuff like IP-white/blacklisting and block SQL Injection attempts. I do think that we need to document how you could to that, but I don't think it should be in Umbraco.
Issues that I'm currently thinking of and aren't in the core right now:
As I said, I would really love to help when we're getting something up and going about security. Whether is in the form of a package, HQ-support, documentation or anything else!
Regards Jeffrey,
p.s.: Seen http://stream.umbraco.org/video/11666249/securing-your-umbraco => Good stuff...
Comment author was deleted
Good stuff Jeff. I agree we should only handle application layer stuff (if possible) in Umbraco/IIS and handle other issues down the stack.
My only concern is how can we also help casual Umbraco users?
Also Azure/UaaS might create new barriers to getting to the lower layers of the stack. i.e. some options are limited to full IIS/OS access (I think).
And congrats on your CISSP. Not sure if I can get ROI on pursuing that one at this point :/
Why? This practically forces people to use a simple password that can be remembered. It's much better, IMO, to have a secure password saved by the browser or password manager than it is to rely on users remembering the password. If I want my browser or password manager to remember my password, that should be my choice and not imposed.
https://www.appsecconsulting.com/blog/new-policy-on-autocomplete-vulnerabilities
Google realised this and from Chrome 34 they ignore the automcomplete='off' setting anyway.
Security experts also realise this:
http://www.troyhunt.com/2015/07/its-not-about-supporting-password.html
Although the last link is about deliberately breaking password managers that are not built into the browser (which seems particularly stupid indeed).
I'm going to discuss the change to autocomplete=off once again, I personally think the argument about it weakening the passwords is a really good one.
Comment author was deleted
Wonder if Troy can be afforded to provide a pen-test/assessment ;)
We do get regular reports from (large) companies doing pen-tests on Umbraco and we fix what's needed regularly. So there's plenty of people looking at it from different angles. More eyes is obviously always better but it seems pretty well covered at the moment.
Comment author was deleted
I'm only kidding :)
Comment author was deleted
To keep things on topic (mostly):
I propose we build a dashboard that tests common things very much like uGoLive from v4/6.
Tougher things like blacklisting bad IP's will come later and possibly in a different package. It should really be handled at the network or transport layers. The trick is to detect who's the bad IP.
I'll ping Matt Brailsford to see if he's up for taking this on or passing it on as he's the project owner for uGoLive.
In the spirit of keeping things simple (for now), please add simple checks we can do. If the solution requires things we can't/shouldn't do programmatically, we'll just add some help text to guide the dev.
On our internal checklist there is also the following stuff:
Could you check whether a custom 404 page is configured in
umbracoSettings.configand that the Id exists? Whilst not a security thing, as such, it's essential for going live.For security, should
disableAlternativeTemplatesbe set to "false" inumbracoSettings.configsince this potentially allows an attacker to use an alternative template to render content in a way that wasn't intended? For instance, imagine you have a template only used by protected pages and has some hardcoded content that is sensitive, but someone invokes this with the home page...I'm also curious about
disallowedUploadFilessetting. Should this contain other stuff like executables types, or is it safe to assume IIS will block those anyway?@Kevin on the note of making a checkllist thingy, we'd like this to be part of the core based on this task here:
http://issues.umbraco.org/issue/U4-3805
... I have yet to properly document this and it doesn't necessarily need to be for v8 (could be sooner) but would be awesome if a community member did it :) My plan is to document how this task would work and it would be 100% pluggable. People could create plugins to add to the "checklist" and each plugin describes what their item can do (i.e. can it be fixed with a button, does it require some other input... the plugin will provide this functionality).
I think this would be an amazing addition and we could see some really great stuff being added as packages. Anyways, I'll update that task soon with a full detailed list of what would need to be implemented and mark it as an up-for-grabs task.
Comment author was deleted
Awesome, thank you for the feedback. I think Anders is going to get us started.
Comment author was deleted
Anders Bjerner has gracious volunteered some of his time. I'd like to defer to him to get the project up and running :)
https://twitter.com/abjerner/status/630745139586183168
And thanks to Matt Brailsford for allowing us to re-use the uGoLive internals.
For the error logging, I'd look at using something like ELMAH, rather than rolling something yourself. It's a nice system (and can support sending emails as well as logging to DB/Disk). I also find it very handy for spotting things like attempted SQL injection and XSS attacks.
Raygun is a good paid for alternative as well, that has a very nice dashboard for monitoring stuff.
I promise I'm poking Shannon for an update on that issue with some requirements. :-) So hold the thought for a little longer.
With regards to the security group, I'm all ears. I currently can't really imagine what that would look like or how it would work so I'm here to listen to your suggestions and together we can come up with something that's practical!
FYI: We've been getting great tips from, among others, Jeffrey for the last few months and those have almost all been incorporated into the next Umbraco releases. So we're happy to improve whatever we need to improve, feel free to talk to us so we can come up with practical improvements and implement them!
I'm looking forward to hearing some details from Shannon :D
Anyways, wouldn't it make sense to create a new thread, issue on the tracker or repo for this for the further discussion?
I generally like the way uGoLive is structured, but also have some ideas of my own - which may or may not make sense based on what Shannon comes up with.
Comment author was deleted
I'm hoping to get something out of the door sooner rather than later. We can change things up as we go but waiting too long = paralysis by analysis.
(i.e. let's do uGoLive as a port as a quick win and then evolve it)
Already been playing around a little, but were waiting on further details from Shannon.
I will see if I can put it up on GitHub tonight or tomorrow. Still not working entirely though.
Comment author was deleted
Good job +1
I reeeeeeallly like the plugable part.
Put the code up on GitHub: https://github.com/abjerner/Our.Umbraco.Preflight
Since I'm not sure whether I can use the uGoLive name (or whether it makes sense to use the old name), and it might up being renamed anyways if added to the core, I've called the project Preflight for now.
It seems that the old uGoLive supported groups as well, but I don't recall ever seeing it in use.
Also, uGoLive works by classes implementing the ICheck interface. I'm still relying on that interface, but I plan to make it work a little different.
uGoLive works by automatically finding implementations of the ICheck inteface, and then creating a new instance of each class. That means that one class equals one check - you can't use the same solid class for multiple checks.
In the code I've pushed up on GitHub, checks should be added manually, and the same class could be initialized for various checks (of the same type). I believe this gives some greater control, and doesn't require that much work anyway.
As a quick example, you could execute the following during startup:
Having better control over which checks are added and shown, you could remove some of the default check if you don't want them to be shown, or just rearrange their order.
The code currently lets you run a given check, but I haven't implemented logic for rectifying yet. The code also doesn't contain any checks at the moment.
Comment author was deleted
Side note: I discovered you can throttle requests on Azure and IIS natively:
http://richardjgreen.net/windows-azure-website-dipr-dynamic-ip-restrictions/
Has anyone tried this out yet? I'll tinker with this tomorrow.
Since you mention Dynamic IP Restrictions, thought I'd share some notes I wrote down for myself a while back (the short version being that DIPR doesn't handle throttling in a way I would like).
Throttle Requests. When a search engine (or similar bot) hits a site, it can crawl dozens or hundreds of pages at once, which can bring it to a standstill.
I haven't had a chance to test out those ideas, but thought I'd write them down somewhere so that others who are interested can tinker with the ideas.
Hi All,
I've updated the requirements and implementation details here:
http://issues.umbraco.org/issue/U4-3805
The UI mockup looks good and you are definitely on the right track with the details on this task. If you can please keep all implementation discussion about this on the issue tracker that'd be great!
Any questions, changes, concerns about the implementation details can also be kept on the tracker.
Comment author was deleted
I've marked Anders as having solved this. Please consider this thread closed and jump to the link that Shannon used above :)
is working on a reply...