AppSec as a Requirement in the Development Process
We’re now well underway for the year 2020. People from time-to-time will make predictions about what is to come and when we look back, one has to laugh at how wrong they were. If you had asked me in 2005 if I thought we would be dealing with SQL injection 15 years later in 2020, I would have told you no, it will surely be solved by then. At the time I was still a student at Georgia Tech and wrote on this blog about SQL injection and presented a paper on application layer detection at the ACM South Eastern Conference. “Surely we were going to solve this security risk” I would have said. unfortunately, we have not.
While things have gotten better. There are far fewer SQL injection vulnerabilities introduced, not because programmers as a whole have become more secure in their work, but because our frameworks have much better defaults. A modern Ruby on Rails 6 application is by and large not going to have SQL injection vulnerabilities unless the developer goes out of their way to work around the protections provided by ActiveRecord. This is very different from the PHP-style of the mid-2000s where SQL strings were routinely, dangerously concatenated and intermingled with HTML markup. It should be noted that PHP now has much better defaults steering developers towards using prepared statements to avoid SQL injection vulnerabilities.
SQL injection was an Open Web Application Security Project’s OWASP Top 10 vulnerability list when it was first published 17 years ago in 2003 and it remains on the latest OWASP Top 10 today. Some things have changed over the years, but the list has remained remarkably consistent.
Web applications rapidly became the defacto method for delivering line-of-business software-as-a-service (SaaS) for the last 20 years. Today, a web application is behind nearly every new commercial SaaS offering and mobile application. We all trust our data to other company’s publicly accessible servers that are always available over the public Internet. The effective network security perimeter maintained by a network based firewall is extinct. The perimeter is now the place where authentication and authorization decisions are made, which ultimately means in most places the web application’s access control logic is the only security perimeter. This trend is unlikely to reverse.
My prediction for this decade, between now and the year 2030, is that we will continue to deal with web applications putting ever more of our data on the Internet with marginally effective security perimeters. Developers will continue to make many of the same security mistakes except those that are mitigated by our application frameworks and automatically enforced development practices. I also fully expect that we will continue to see SQL injection vulnerabilities in the wild.
My recommendation on how to increase the security of your web applications in light of this prediction is to remember that security cannot be bolted on at the end of the development process. Ensure that your developers are educated about common security vulnerabilities and that security is a fundamental part of your software development process.
In this 2020s decade, application security (AppSec) must be a requirement in software development. Developers who are educated about security vulnerabilities and work with a process where security is fundamental, deploy better, safer, more secure applications to production.