Menüyü Gizle
Why platform matters in web application security?
I wrote this article about 2 years ago in Turkish. Recently Whitehat released a quite nice paper about vulnerability counts per programming language/framework. That report kind of backs up this article however many took and advertised it wrongly as it sounded like “choice of framework has virtually no effect on security”. So I decided to write it in English again.
One of the oldest clichés in web application security is:
"Choice of framework doesn't matter"
I say bullshit!
Good Developers Always Develop Secure Applications
Yes, one can write a secure web application using brainfuck in 1 year and after 250 iterations. She can start by "implementing her own session handling and make it secure". That sounds funny, right? But when I say "All you need to do is implement your own CSRF protection", it doesn't sound funny because that's what everyone is keep doing. However to me it's still wrong, just like a secure session implementation a secure CSRF protection implementation should be one of the responsibilities of the framework not the developer.
Security of the Language, Security of the Framework
There is no perfect framework, vulnerabilities identified in all frameworks just like vulnerabilities identified in all applications. However just like some applications security track of some frameworks are much better. ASP.NET Request Validation Bypass, PHP Zend_Hash_Del_Key_or_index overwrite issues, Struts Validation Bypass are good examples of these vulnerabilities.
PHP is a perfect example of this. PHP itself has so many vulnerabilities (such as Zend_Hash_Del_Key_Or_Index Vulnerability, month of PHP bugs and others) even when the developer codes everything securely it still can be vulnerable. I don't even mention the terrible design issues such as GLOBALS Overwrite problems, magic quotes, providing not one but several different functions to do the very same job.
If you set a directory as protected and if your framework can't protect you because the attacker used a different HTTP Method then that's not the developer's fault, it's framework's fault.
That's why framework matters, even when you build the most solid application when your framework is weak, there is a higher possibility of getting owned.
Can framework handle unicode characters correctly? Do functions unexpectedly effected by null bytes? Does it spill out all the details when you send one character in the cookie?
All of these are problems of the framework. If you are wise enough you should choose a framework with a good track of security.
Framework Specific Issues
You won't see much RFI (Remote File Inclusion) in ASP applications because there is no easy way to introduce such vulnerability in ASP. You can't see code execution problem ( such as eval() ) in ASP.NET applications because there is no easy way to do it however in Classical ASP you have this problem. Heck, in PHP application even preg_replace can evaluate code with /e modifier. And yes that happens in real world application, PHPBB was vulnerable to this.
Framework specific problems matter.
Secure by Default - Design of the Framework
Some part of some frameworks designed in a "secure by default" way. For example it's quite rare to see HTTP Header Injection (CRLF/HTTP Response Splitting) problems in ASP.NET because by default all related .NET functions will not accept new lines. Therefore as a developer you should push your limits to introduce this vulnerability, yet if you are stupid enough you'll succeed. Developer's stupidity is something that a framework can't fix. Sorry about that.
Stupid features of a framework can hurt as well. For example Magic Quotes in PHP. Loads of application burned by that, it's such a mess. It shouldn't have been there in the first place that's why finally they decided to deprecate it.
Inbuilt Security Features
I think everyone knows that rolling your own crypto is idiotic but somehow it's OK for people roll their own CSRF protection, SQL Injection filter, XSS protection library etc. Yet all penetration testers observe that these developers keep failing miserably. That's why projects like ESAPI should be employed by more developers.
When it comes to frameworks some of the questions we need to ask;
- Does it support parameterized SQL Queries?
- Does it provide a way to separate data and the HTML and carry out the required encoding based on the output location?
- Does it provide a secure session implementation?
- Does it provide a secure authentication mechanism?
- Does it provide a secure way to execute OS commands? (separating parameters and the executable to avoid injections just like parameterized SQL Queries)
- Does it provide secure storage options? Path normalization functions?
- Does it provide a way to avoid email header injections?
- Is there any function which can protect against new line injections to write safe logs without worrying about new lines?
- Is there any inbuilt feature to apply whitelisting on inputs?
I can go on but you got the point. Unfortunately there is no framework which does all but some frameworks are clearly better.
Take a look at Secure Web Application Framework Manifesto for many other ideas and see what frameworks should bring to the table in means of security by default and as inbuilt security features.
Also ASP.NET's built-in membership feature is also is the right direction and more frameworks should do the same.
Documentation, Culture, Sample Code etc.
Documentation and culture around a framework also quite important. Take a look at Tomcat JSP examples and IIS 6 ASP examples. All of them have several serious vulnerabilities out of the box. Like it's not enough to write vulnerable applications as samples they even deployed them by default so your environment can be vulnerable by default!
For example many examples in .NET documentation uses parameterized SQL Queries which is very good thing although .NET documentation got so many other flaws and terrible code snippets in many places. Generally most of the vendors are terrible about documentation and providing secure code snippets. Some of these sample codes stripped from security checks as they stripped from error checks to increase clarity in the example. I still not a good enough excuse.
Finally when it comes to the culture there are some factors such as what are the best practices among developers. For example you can see more OS Command Injections in Perl applications than potentially any other framework because that's how Perl guys roll. Pass it to an OS command, parse the output and spill it out to the screen. This is a quite rare practice in many other frameworks*.
Required Time, Effort and Knowledge for a Secure Application
All of these discussed factors affect the required time, effort and required security knowledge to develop a secure application.
If framework provides built-in security for CSRF with one line of code than it decreases the complexity of the application, required development and testing time. Finally developers don't need to be a security expert to implement such a check.
Do you really think a junior developer would know that it's possible to do CSRF against a web service. Believe me they don't. Also they don't know that you can do XSS in CSS, they don't know if content-type is "plain/text" XSS is still possible in IE, they don't know that they need to mark cookies as secure, they don't know you can bypass many *clever* XSS protections by using XSS Tunnel or BeeF, they know jack-shit about security especially when it comes to corner cases.
They don't know and they will never know many of these and I don't expect them to know** , that's why framework should care of this stuff and that's why framework matters.
Framework Matters
Now please don't tell me that framework doesn't matter because it bloody does. However the problem is; there is no perfect framework and there won't be anytime soon although it's getting there. Right now you can still choose a better framework instead of choosing arbitrarily by claiming that all of them are same anyway.
My examples were mostly about PHP, ASP and ASP.NET because those are the frameworks that I'm pretty familiar with. You can think of many other frameworks such as Ruby on Rails, Struts or CppCMS and observe similar benefits or framework specific problems.
* Although I need to note that due to many other configuration requirements that task might not be that easy in some frameworks hence not that popular. For example .NET might require several permissions to properly run an executable from an ASP.NET script.
** OK, they need to know about "Secure Cookies" but funny enough many of them still don't. So why not mark all cookies set over SSL as secure and when their code doesn't work they can fix(!) it, at least this way it'll be secure by default and maybe developer will ask herself "What the hell is a secure cookie? and why would I need it?"
Yorumunu Ekle
4 Yorum var
I've released 
