Frameworks Make Coding Easy and App Security Hard
Creating secure software should not require that developers become specialists in security. Mike Milner tells us why frameworks make coding easy and app security hard.
Join the DZone community and get the full member experience.
Join For FreeIt is easier than ever to write web applications, but educating developers on security issues hasn’t kept pace with the evolution of the threat environment. Therefore, relying on developers to be infallible when it comes to web app security is an expensive, and losing, proposition.
The truth is that creating secure software should not require that developers become specialists in security. The most effective way to secure web applications is to make security a fundamental part of the software—to modify the application framework so that apps automatically defend themselves against common vulnerabilities. There are challenges inherent in this process, but this simple change in approach can fundamentally improve application security.
Problem 1: Frameworks Make Coding Easy and Security Hard
Example 1: Rails Helpers and safe_buffers
The framework does some basic work to keep you secure. Unfortunately, it also makes it very easy to unintentionally bypass your own security. Safe buffers are designed to protect against cross site scripting. Unfortunately, in older versions of Rails, it is possible to add an unsafe string to a safe buffer and, therefore, send untrusted content that appears to the system to be safe.
Example 2: Rails Directory Traversal
In the last decade, directory traversal (also called path traversal) has been one of the top five vulnerabilities in applications built on the Ruby on Rails framework. This vulnerability enables users to gain access to files located outside the directories within an application to which a user legitimately has access—potentially including critical system files or source code.
The main way to prevent against directory traversal and abuse of safe buffers is educating developers about situations in which framework security isn’t enough, provide automated tools to add defenses, and implementing defense in depth.
Application Defense in Depth
As the above examples indicate, while it is easy to build a web application, securing the application, and the network it runs on, is not. Hackers know that web apps can be the best way into an organization and they take advantage of the vulnerabilities that apps introduce into a system. According to Verizon [1], 40% of all confirmed breaches in 2015 were the result of attacks on web applications.
Application defense in depth means using layers of defense within the application and the application layer protocols. If an attack makes it through a layer—from inside or outside your inner trust boundaries—it cannot compromise the system.
The Trouble With WAFS
Web application firewalls (WAF) do a reasonable job protecting traditional web applications and fighting against cross-site scripting (XSS) and SQL injection (SQLi). The problem is that WAFs can be complicated to setup and easy to bypass (because they only protect network traffic routed through them). They protect from outside an application, so they have no visibility into what is happening inside the application and cannot protect against a threat coming from within. They also can protect only against known vulnerabilities and attack signatures. Once a threat evolves or a hacker finds a workaround, the application is again vulnerable.
Security Is a Framework Responsibility
The threat environment evolves rapidly, and software development cycles are shortening and becoming even more iterative, as companies release early versions to be tested in the marketplace. Because of that, it is difficult for developers and security teams to keep up to date with security needs. Thus, the most effective security comes from within an application framework, rather than a gatekeeping program or a security protocol that layers on top of an application or one that needs to be constantly updated to adapt to new threats.
Perfect Code Is a Pipe Dream
No matter how accomplished the developer, it is almost impossible to keep up with the rapid changes in the threat environment and the security protocols required for effective defense. And the truth is that most developers don’t learn much about security unless they have to. Even with a top-notch development team, sophisticated processes, strong quality assurance practice, and robust testing, applications are still released with significant (sometimes already identified) vulnerabilities.
Building Self-Defending Frameworks
The most effective security comes from within. These apps are aware of the look and feel of normal operations and can identify unusual or malicious behavior and protect themselves when that happens. Because of this, they do not need constant updating to address new or evolving threats.
Problem 2: Application Dependencies
Applications require third party components, leaving them vulnerable because of poor secure coding practices. This enables attackers to choose from many different attack vectors and disguise them from traditional network protection appliances.
Problem 3: HTML Is a Horrible Mishmash
Unlike more traditional development environments that require consistency checking and compilation, modern script-based technologies like HTML5, CSS, and JavaScript are much more forgiving when it comes to writing executable code. If adoption of these technologies is not followed with a significant improvement in quality assurance, the result is often erratic and vulnerable code.
Web applications are a magnet for vulnerabilities like cross site scripting (XSS), which is one of the most prevalent vulnerabilities. It is easy to introduce into the template;
and tedious to remediate, because each vulnerable field (potentially thousands in a single application) requires custom remediation code.
Problem 4: Generalizing the Approach
Over and over again, new zero day vulnerabilities are found in different parts of the vast technology stack. And most of the time these vulnerabilities are fueled by some critical and inherent weaknesses in the technology. SQL injection is a good example and has been one of the top application risks for many years, because of deeply rooted security weakness in
database software.
Problem 5: String Building
Some prevalent code patterns, like search functionality or report generation, can be challenging to secure because they must combine a user friendly interaction with preventing unauthorized access to data.
Today, Security Is an Afterthought
The hard to hear truth is that the speed of development means that securing applications is often not top of mind when developing new web applications. For some organizations, it’s because they don’t have the resources or expertise. For others, it is due to a misdirected belief that web applications can be secured with other programs and protocols.
To be most effective, developers and organizations need to consider security at every step of the application lifecycle, including oversight and sufficient training, to enable security to matter from start to finish:
Design
- designing security features
- using secure coding standards
taking advantage of the security features in languages and application frameworks
Test
- including static, dynamic and interactive analysis (SAST, DAST, IAST)
- penetration testing
- bug bounties
Repair
- fixing breaches
- remediating vulnerable code
- patching
- runtime application self-protection.
Conclusion
True security for web applications requires a new understanding of where the threats come from and how vulnerabilities affect their operation. To truly improve application security, organizations must focus on understanding and controlling what is inside their influence—the application and its execution. The most efficient and effective way to do that is to enable applications to automatically defend themselves.
More Security Goodness
If you want to see other articles in the guide, check out:
Published at DZone with permission of Mike Milner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Fun Is the Glue That Makes Everything Stick, Also the OCP
-
Measuring Service Performance: The Whys and Hows
-
How To Use the Node Docker Official Image
-
Hibernate Get vs. Load
Comments