Dinis Cruz is a security consultant who specializes in penetration testing, ASP.NET application security, source code security reviews, reverse engineering, and security curriculum development.
DDJ: Dinis, what's the most challenging part of writing secure .NET applications?
DC: The main point that I would like to make is my wish that we would all take sandboxing -- most specifically, Partially Trust on ASP.NET -- much more seriously. At this moment, our main security model is one based on the nonexistence of malicious code and vulnerabilities in the applications and libraries used on our servers and desktops. I prefer the world where there WILL be vulnerabilities and malicious code in our servers and desktops that cannot be exploited (or are, at least, easy to identify when activated) due to the sandbox used to execute it.
Unfortunately, the big players who can move markets -- Microsoft and Sun, in this case -- don't view that as a priority and their paying clients are not being attacked enough to demand serious solutions from them.
I have been defending this idea for three years now, and I still believe that this approach will solve a lot of the current security problems. (My sandbox concept is focused on the assets and takes into account both server side and client side execution environments.)
I have to say that I really have a problem with blaming the developers. I do a lot of security training for developers and, in most cases, those guys are much more intelligent and knowledgeable than me. The problem is that our current development models reward features, performance, reliability and speed to market with security being one of those "Oh yeah, and it has to be secure."
So, I think the one single mistake the programmer can make is to agree to program in a non-sandboxed and non type-safe environment where one mistake can be fatal. The reason why such critical-impact errors occur is that our current application environments are not designed to protect that applications assets. For example, in the web world: an SQL Injection on the Login Page, or a bank details page which asks the user which account he wants to see and doesnt check if the user is authorized to see that account, or an airline system which uses a price for a ticket purchase submitted from a user-supplied html form, or XSRF vulnerable pages, and the list goes on.
One of the areas which I have been trying to get some of the big players in the market to change their paradigm (for example Microsoft) is in the use of Sandboxing technologies. We need to create run-time execution environments (for example, the environment where the web application server side code is executed) that limit what the code can do to those assets (for example, why should every single line of code in an application be able to manipulate the database, access all data, change the user identify, attack the internal network, etc.)
This also takes us to a problem of complexity where developers (and even system architects) are not able to list the attack surface of their application (i.e., all inputs and types of data that can be submitted). Add to that mix the use of Frameworks (from .NET to Ruby on Rails) that contain their own types of vulnerabilities, and you have a powerful cocktail where one mistake can lead to catastrophic consequences.
DDJ: When it comes to writing secure applications, which platform is a bigger challenge -- Java or .NET?
DC: I think the key is not in which framework or technology you use, but rather in the answers to the following questions:
- How much do the key players (from developers, to architects, to clients) understand the security implications of what they are doing?
- Is creating a secure application a key requirement?
- Is there a dedicated security team?
- How much clout (and budget) does that security team have?
- Can the application's features be changed based on their security implications?
- What are the REAL consequences of a security incident? (i.e., will it be a marketing/damage control exercise, or will that company actually lose customers and revenue?)
- Can the clients make their purchase decisions based on how good (or bad) the products security is? (i.e., are the clients aware of the efforts and cost required to write a secure application?)
- Finally, the main one: Does it make more commercial sense to: (a) create a "secure" product; or, (b) create a product that has a lot of "security features" but is quite insecure? Note that, in most cases, the answer is (b).
The answers to those questions will have more impact on the security of the website/application than the framework or operating system chosen. That said, I am a big fan of Frameworks since they can create development environments where the developers are making the right decisions by default (of course, if those Frameworks don't implement and enforce Sandboxes, then the developers are able to bypass those "secure techniques" and manipulate the assets directly.)
DDJ: Can you tell us about the OWASP Project? What's that about?
DC: OWASP (http://www.owasp.org) is a worldwide open community of security professionals who care about web application security. My journey with OWASP started with an email that I sent to Mark Curphey in October 2003 about my research on the security implications of running ASP.NET code in Full Trust. Mark replied with the challenge "Hey!, why dont you publish this material on OWASP and manage the OWASP .Net project?", which I accepted and have since dedicated considerable amount of energy to it. OWASP is a very empowering, open organization where motivated and focused individuals can find their place and shine. OWASP was a perfect match for my values and professional objectives.
In OWASP I found a place where I could publish my research and ideas to a like-minded community, develop open source tools, participate in conferences and meet potential employees.
Talking about financial return, a lot of people think that I am employed and paid by OWASP. That is not accurate because all OWASP yearly profits are injected into OWASP for projects like the Autumn of Code (36,000 USD invested) and Spring of Code (125,000 USD invested). That said, I can claim that 100% of my paid consulting projects done during the last 3 years were directly related to people I met via OWASP.
So, currently I am on the OWASP board (together with Jeff, Dave and Andrew) and take the role of "Chief OWASP evangelist"; I don't like the "evangelist" title, but it gives me a lot of flexibility in OWASP to create new projects and initiatives.
I think OWASP is on a tipping point where it needs to make the transition to a much more professional organization whereby the quality of OWASP projects is significantly increased together with the value delivered to OWASP community (members, users and project/chapter leaders, etc.).
I do think that OWASP is part of a new generation of Open Source projects that is focused on quality and value, and doesnt spend much time talking about and defending its Open Source roots.
The bottom line is the fact that OWASP tools and documents are (and always will be) available for free is not an excuse to accept low quality deliverables in certain areas. For example, one of the "services" that OWASP wants to provide is security reviews and guidance to software developed and published by OWASP members. At the moment, no one knows how many security vulnerabilities exist in OWASP tools; and, the fact that they are open source doesnt make a difference since the number of application security professionals with the skills and time to review those tools is just about zero (as it is in most Open Source projects).
DDJ: Can you recommend web sites that application developers who have questions about security might go?
DC: Being very involved in open communities like OWASP, especially actively participating in or leading their projects, is one of the best ways to stay current, work on interesting challenges and learn new techniques. Regarding mailing lists, I would say the best Web App security lists are WASC and the Secure Coding List. I also subscribe to Full Disclosure, using a separate email address, which I try to read once a week. For blogs I would recommend OWASP, Jeremiahs, Ha.ckers, GnuCitizen and SecuriTeam.
