New security Vulnerabilities
-
essrichard
- Posts: 24
- Joined: Wed Apr 29, 2015 12:10 pm
Re: New security Vulnerabilities
I see there is a new update available now, 5.2.3 - is this the one that should address these issues? I am having trouble finding any kind of release notes for the new version - are those posted anywhere for users to review?
Re: New security Vulnerabilities
Former Nagios employee
-
essrichard
- Posts: 24
- Joined: Wed Apr 29, 2015 12:10 pm
Re: New security Vulnerabilities
Okay we went ahead and updated to 5.2.3 and rescanned. As you predicted, Nessus is still complaining about the clickjacking, so is there a more official response we can get from you giving the reason why this particular detection is now a false positive in addition to "Fixed possible clickjacking by forcing login page to be the top frame element -SW".
All other items are no longer being detected, so just want to say thanks a ton for the quick turnaround on this request.
We really appreciate it!!
All other items are no longer being detected, so just want to say thanks a ton for the quick turnaround on this request.
We really appreciate it!!
Re: New security Vulnerabilities
Clickjacking is pretty hard to automatically test, so Nessus and others will usually flag it. There are two mitigations [1]:
1.) Sending the proper X-Frame-Options HTTP response headers that instruct the browser to not allow framing from other domains. This is very easy to implement and very easy to test, but our software does require that some pages be able to be included in others so this is not something which we can set globally.
2.) Employing defensive code in the UI to ensure that the current frame is the most top level window. This basically means some Javascript that says "If I (a web page) am not the top-most window in the browser, redirect to my address so that I am". Commonly known as a "frame buster" [2]. This allows us a little more control and was, of the two options, easier to implement in a short amount of time. The problem with this is that a scanner is not typically going to know what a given piece of Javascript actually does, so it has no way of testing to see if it works.
We opted for 2.) and my manual testing seemed to reveal that it worked properly. However, as with any mitigation there are bound to be ways around it. There are frame-buster-busters, and frame-buster-buster-busters (I am not making this up [3]) so arguably the first option is going to be more secure. But even that can be worked around [4]. CSP (Content Security Policy) [5] looks pretty promising but is a bit more complicated to set up. So for these reasons, I cannot 100% guarantee that this has been mitigated (you can never really make this guarantee, and anyone who tries to is either lying or misinformed). What I can say is that I am reasonably sure this will defend against your average attacker. Anyone who is determined enough will find a way (this is the sad truth of security) but this should work to keep most threats at bay.
[1] https://www.owasp.org/index.php/Clickjacking
[2] http://javascript.info/tutorial/clickjacking
[3] http://meta.stackexchange.com/questions ... ter-buster
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=725490
[5] https://appsec-labs.com/portal/anti-clickjacking/
1.) Sending the proper X-Frame-Options HTTP response headers that instruct the browser to not allow framing from other domains. This is very easy to implement and very easy to test, but our software does require that some pages be able to be included in others so this is not something which we can set globally.
2.) Employing defensive code in the UI to ensure that the current frame is the most top level window. This basically means some Javascript that says "If I (a web page) am not the top-most window in the browser, redirect to my address so that I am". Commonly known as a "frame buster" [2]. This allows us a little more control and was, of the two options, easier to implement in a short amount of time. The problem with this is that a scanner is not typically going to know what a given piece of Javascript actually does, so it has no way of testing to see if it works.
We opted for 2.) and my manual testing seemed to reveal that it worked properly. However, as with any mitigation there are bound to be ways around it. There are frame-buster-busters, and frame-buster-buster-busters (I am not making this up [3]) so arguably the first option is going to be more secure. But even that can be worked around [4]. CSP (Content Security Policy) [5] looks pretty promising but is a bit more complicated to set up. So for these reasons, I cannot 100% guarantee that this has been mitigated (you can never really make this guarantee, and anyone who tries to is either lying or misinformed). What I can say is that I am reasonably sure this will defend against your average attacker. Anyone who is determined enough will find a way (this is the sad truth of security) but this should work to keep most threats at bay.
[1] https://www.owasp.org/index.php/Clickjacking
[2] http://javascript.info/tutorial/clickjacking
[3] http://meta.stackexchange.com/questions ... ter-buster
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=725490
[5] https://appsec-labs.com/portal/anti-clickjacking/
Former Nagios employee
-
essrichard
- Posts: 24
- Joined: Wed Apr 29, 2015 12:10 pm
Re: New security Vulnerabilities
This is great - thanks again for all the help.
Re: New security Vulnerabilities
Does this provide enough information for you @essrichard? Do you mind if I close this thread out now?
Former Nagios Employee
-
essrichard
- Posts: 24
- Joined: Wed Apr 29, 2015 12:10 pm
Re: New security Vulnerabilities
Yes, i think we are good for this quarter. Thanks!
Re: New security Vulnerabilities
Glad we were able to help. We'll lock this thread now and feel free to open another should you require assistance with anything else.
Be sure to check out the Knowledgebase for helpful articles and solutions!