Thursday, 25 October 2012

'About' page broken due to ClickJacking protection

We're just about to release TeamMentor 3.2 when a final round of QA noticed that the About page was not working:


As you can see by the screenshot and the issue opened (Fix about page which was broken due to ClickJacking protection) this was caused by the fixed applied to the ClickJacking vulnerability reported in TeamMentor.

So here is another nice example the TAX we developers have to pay due to security changes (the app was working great before the fix).

Also, note how the 'security vulnerability' information that I received made no reference to the problems that would be caused by applying the fixes!  

Saying 'Enable the X-Frame-Options' is much easier than saying 'Enable the X-Frame-Options and here are the site effects on YOUR app of that change' 

And this is the key message that I try to give to security professionals in my "Making Security Invisible by Becoming the Developer's Best Friends" presentations. 

Providing information about a security vulnerability and some pointers on how to fix it, is not good enough!!!! Since that is JUST a small part of what is needed to fix that issue. 

Usually more important is 'What are the side effects of applying that fix'

For another similar example see the Couple XSS issues and XSS-By-Design (in TeamMentor) post. 

4 comments:

Dinesh Shetty said...

When i found the application to be vulnerable to clickjacking, the best thing that would solve it which i knew worked well was X-Frame options and frame busting code which are err.. kind of difficult to bypass compared to some other techniques i knew.

From a GreyBox perspective, it would be difficult to judge which section of the code base would get effected due to the applied patch. Agreed..If i would have been a part of the development team or atleast have gone through the code base for some days (unlike me.. i just looked around for a day i guess :P ) i would have actually knew the exact spot where issue would arise.

QA process post the application patch would be the only way which i assume that one can know where the code breaks and then the patch can be modified accordingly.

Every patch would effect the application somwhere or the other depending upon the style of implementation..Expecting a person to know the sideeffects for every single application would not be possible as the way in which the implementation would be done would be different and the output would be different.
Maybe going ahead with my solutions i would add in the possible sideeffects.. atleast the ones which i know that the team might encounter.

Dinis Cruz said...

And you did as good of a job as 99% of the AppSec industry does today (even when they spend a lot more time on it)

But because nobody is doing something, doesn't mean that it shouldn't happen :)

And if you look at the main thread of my thinking over the last couple years, it is all about changing the dynamics of the current relationship between security and developers.

For example, the current model is broken because it is very hard to understand the side effects of security fixes (and recommendations)

Which is why we need to change the model, and create an environment where security teams and developers are speaking in the same language.

In a way what I'm trying to do with TeamMentor is to create a real-world example of how that can work (and why it is so worth when it does).

It wont be easy, but it will be a great ride :)

Dinesh Shetty said...

I have gone through your blog post on making security invisible in the past too and i could not agree more on that fact ..i've always supported the things that you have mentioned.

Infact i've always had more of a thought process that developers and security team should work together through the SDLC rather than the management paying in $$ to an external consultant to test its security for a couple of days just before they are going live. The re-coding would be a real pain and as you mentioned, which section were effected by the patch would not be clear till the final QA phase.
The external consultant would not know the architecture as much as the developer would, unless he was present through the complete lifecycle.

Maybe some time down the line we can actually see a phase where developers do not hate the security guys like they do now :D ..

Dinis Cruz said...

Well ... I think we are on the right path.

As application security becomes more and more important, and more developers get involved, there will be a much bigger demand for 'quality deliveries' from the security teams and tools.

This is also why (for me) it all starts and ends with Unit/Integration tests.

I.e. we should be talking in Unit tests which should:
- first 'document' the reproducible steps of a particular security vulnerability,
- then allow for testing 'if the fix worked' and
- finally 'be part of the QA cycle' so that the issue is not re-introduced.

For example, my work (as a dev) would had been much more productive (and faster) if when you send your vulnerability reports, you sent scripts instead of PDFs :)

Check these posts for more details on 'how much I like PDFs' :) :

http://diniscruz.blogspot.co.uk/2012/04/no-more-pdfs-with-security-findings.html

http://diniscruz.blogspot.co.uk/2011/12/o2-in-seattle-and-please-hack.html