Open Source Vulnerabilities in Web Development
You just got an email: one of your web applications got broken. Your customer data has leaked, and the cryptography keys are gone. Authorities are on their way to your company. Are you ready for Mexico? That’s when you suddenly wake up. That was a nightmare, but it could come true. So if your web application is already in production, it’s time for a security audit.
There are many philosophies and practices to develop a web application — the K.I.S.S. (Keep It Simple, Stupid), Security-By-Design, Privacy-By-Design, and so on. All these strategies and practices were made to keep you focused during the web application development phase.
For example, the advent of GDPR in Europe broke the development process and practices of many developers and companies. Developers didn’t always focus on privacy and security, whereas now, these principles are routinely considered during the development process.
In this article, we will read about the different ways you can improve the security of your software. We will also discuss tools like and how you can use them to design a more robust security framework for your app development process.
Vulnerabilities Are Right behind the Corner
There are many approaches to securing a web application, even without a security engineer. Depending on your resources, you can do this in one of the following 5 ways. You can implement them in some combination, or you can go with all of them.
- Design review: While architecting the application you should also consider all the possible threats to your application and design the system to be resilient.
- Whitebox security review (code review): Unless you’re a security engineer and you’re projecting and coding your project all alone, this step should be performed in pairs, with a security engineer looking for flaws in your code. Even if you’re a security engineer, getting a second opinion is not a bad idea.
- Blackbox security audit: Get your source code and put it away. Then run the web application and check whether it is secure during use. You can even let someone else do this. Letting other people audit your application will improve the auditing by excluding the unconscious biases you’ll have while testing.
- Automated tooling: This is one of my favorites. There are many tools designed to scan your code for the more common errors, patterns, or security-related problems even while you are developing your project.
- Coordinated vulnerability platform: This method is simple but powerful. Once you’re done with your testing and auditing, you can pay a highly specialized company of white-hat hackers to attack your web application and produce a report about its bugs/holes and problems.
Now you know what steps you can take to get your software secure, but what if you want to try writing a “less bug software”?
Knowledge is Power: Resources and Tools
Let’s get deeper into the first step for a second, the design phase. During designing, you can check some famous resources like the OWASP (Open Web Application Security Project) Top Ten to know which are the most common risks in web application security. For example, the first risk in web application security, according to the OWASP Foundation, is injection flaws.
Let’s take a break and analyze what injections are using the SQL language. According to the 2020 StackOverflow developer survey, SQL is one of the most common query languages used nowadays, making it the third-most professionally used language (statistics extracted based on 47,000 professional developers).
Consider a snippet of code like this:
As you see, inputs are directly passed to the SQL engine without proper binding or escaping. Using an error-based attack, an attacker can uncover sensitive information about the architecture your code is running on or store a reverse shell using the SQL procedures to store files!
This is obviously the worst-case scenario, but you don’t want to be anywhere near a situation like this. If you didn’t know about this kind of injection, run to the first terminal next to you and fix this as fast as you can!
Now move to another kind of validation. Let’s take a look at Static Application Security Testing (SAST), representing the fourth point of our checklist. This method consists of using tools for security testing your code or your entire project.
Let’s look at some examples. If you have a composer project, you can use a tool like Local PHP Security Checker. It is a command-line tool that audits your application dependencies and checks if something you rely on is broken or has known flaws or bugs (it’s not always on you, your dependencies can be your flaw too).
Or you can use something like Phan to audit your application and check for things from deprecation to unsafe access. And if you’re using a framework, you should check out specialized tools like Larastan for Laravel.
If you have been in the coding world long enough, you’ve probably understood that this whole validation process can fastly become a nightmare on big projects where more than 3 developers talk to each other and use the same coding styles and conventions. And even if you use a git repository with a strong commit policy, it can be easily bypassed with a forced push ignoring hooks.
So, if you cannot check local policies or move the policy to somewhere else, you can use free apps like WhiteSource Bolt to scan your code push after push and automatically get an issue open once a common bug pops out from your code. Bolt is a free tool meant to help you find and fix open source vulnerabilities. Polyglot developers will probably be most enthusiastic about this tool because it supports lots of languages.
If you’re an embedded software developer writing C code by day and a web developer writing PHP code by night, you can use one tool and get audited for your whole repositories.
Conclusion
Now that you know some of the best practices that you can adopt to secure your web application, it’s all on you. Remember: spending more time on security during the development process can significantly decrease the time you spend later on production. Don’t lose sight of the problems you can face by not fixing common issues that are fixable with a static analyzer.
Always put security first when designing softwares, especially web applications, for you and for a better internet!
