Most developers probably know a bit about security, but naively think they know enough to keep their apps secure. I don’t like to admit it, but I was in this camp until about a year ago. Unless terms like OWASP, Cross-site Scripting, Injection, Mitigating Factors, Dynamic and Static Code Analysis, and Penetration Testing are part of your vocabulary, you are probably in this camp too.
The topic of web security has never been more relevant with the recent hacking scandals, including the Impact Team hackers who stole and posted data from AshleyMadison.com to the internet. This past week I had the chance to catch up with a web security expert colleague of mine, Sherif Koussa. Sherif has been in the security business for about eight years working for big name clients such as Wells Fargo, Desjardins, Carleton University, Discover, and various Canadian Government clientele. He is also a member of the Steering Committee for the GIAC‘s GSSP-JAVA and GSSP-NET Exams. In addition, Sherif has authored courseware for a few SANS courses and GIAC exams. If that wasn’t enough, Sherif also leads the Ottawa Chapter of OWASP and was the main force behind OWASP’s WebGoat 5.0. In other words, when Sherif talks security, I listen… and so should you. To this end, I am publishing our exchange so others can benefit from his insight.
What are the most common attacks?
This really depends on the lens you look through. From an application security perspective, OWASP top 10 seems to be still a true reflection of the vulnerabilities we find looking at different applications. Focusing more on Java-specific applications, other than injection attacks like SQL Injection and Command injection attacks, Cross-site Scripting in particular seems to be a little bit more wide spread in Java applications vs other languages like .NET, because of the lack of any automated support from the platform like what other platforms like .NET or Ruby-on-Rails have.
From a different perspective, malware seems to be an increasingly dangerous and ever complicated problem. Where attackers use common delivery methods like email attachments, email links, games, and other means to deliver their payloads, and these payloads usually attack well-known vulnerabilities that are not patched yet or zero-days which don’t have patches available yet.
Are there any languages/platforms that are particularly vulnerable?
Yes, there are platforms that offer more security protection and features out of the box. The new platforms seem to be better than older. For example, the node.js stack seems to offer more than Ruby on Rails, which seems to offer more than .NET which seems to offer more than Java, etc. However, this is not really always an advantage because there are always ways to turn off these features or work around them. So, to put things into perspective a bit, .NET comes with some protection against Cross-site scripting out of the box. It is not great but it is good enough to disable some cross-site scripting attack vectors, yet we see so many developers disabling that because it messes up some of their features. Another example, .NET offers a very simple CSRF mitigation that is simply not followed by a lot of developers. Even in Java, it is very common to find developers using PreparedStatements in 99% of the cases, but guess what, attackers will find the 1% of the statements that are using String concatenation instead of PreparedStatements and will exploit that and gain unauthorized access to sensitive information or even compromise the whole network. Keep in mind, defenders are always at a disadvantage. They have to fix all the vulnerabilities while attackers just need one vulnerability. Attackers have more time, tools and skills than developers could ever have. Developers start to have an advantage when they understand what they are protecting, what do they need to do in order that, what the platform offers out of the box and what they need to do to bridge the gap. This combined with understanding attackers ways and mindset, only now can they take back the advantage and control their applications and data rather than being controlled.
What advice do you have for IT shops who are not application security experts?
While not all IT Shops have internal application security expertise, this does not mean they can’t write secure applications. Secure code is the something comparable to quality code. To release quality bug-free code, you have to have developers who write good code but you also have to have good quality assurance engineers who test that code or a really solid extensive set of test cases, but you can’t just code and release. You can’t just depend on the quality assurance engineers to find everything. The same goes for security. Software developers have to write secure code – use prepared statements, filter and cleanse user input, etc. Then application security experts would pick up from where the developers left. The role of security experts is to find those vulnerabilities that slipped through or test your applications against the latest emerging threats and attacks. To build an internal solid security practices, a company should start by increasing awareness of security attacks and their risk on the organization. Afterward, some simple steps should be followed:
- Add low-maintenance security touchpoint to the SDLC such as security design review, a light-weight security check list or a security specific static code analysis tool.
- Gradually raise the bar for security bugs, this could happen through following a customized security guidelines or through the company’s regular code reviews.
- Appointing someone as a security champion for people to ask questions helped a lot of organizations.
These are just examples for activities that an organization could do without hiring extra staff or budget. Of course, how you go from there depends on the dynamics of each organization and where are they now and where they want to go.
Are you working on anything other than consulting?
One of the cool things we are currently working on right now is a tool that helps organizations compare the risk that comes from using different open-source components and libraries. If you are choosing a new piece of open-source, it also helps you pick the most secure software, helps you understand where the risk comes from and ultimately how to deal with it.
Lastly, can you describe a typical day in the life of a security consultant?
Part of the fun and challenge of being a security consultant is the variety of work. Most clients require assessment work, but they all have differing technology stacks (i.e. varying infrastructure, programming languages, frameworks, web vs. mobile etc). The assessment work usually includes secure code reviews (which includes static code analysis and manual code review) and dynamic assessments (which includes vulnerability scanning and penetration testing). In addition to the assessment work, I also carry out my own security research, create and update training materials, and of course, deliver these training materials.