Deal With Components With Known Vulnerabilities
It is important to research components in your stack to be aware of all vulnerabilities and methods of mitigation. Document all modules, APIs, and libraries used, as well as known vulnerabilities. Document mitigation used.
Avoidance is another strategy. A vulnerable component can be replaced by a less vulnerable one or an alternate functionality.
When new vulnerabilities arise, have a process for change control, and continued documentation on vulnerability management.
Here are a few tips on what to look at to ensure that your web application does not fall victim to this risk:
Know and document the versions of every framework component including the firmware for the server's network card! Every component counts because you can get into a lot of trouble with these small component exploitable vulnerabilities.
We talked about zero-day vulnerabilities and how these new issues can give rise to more attacks on the components with those vulnerabilities. Make sure that you patch them!
It's a big job!
You have to look at your physical components, applications, OS, APIs, libraries, and languages used.
I cannot stress enough, how important it is to continually document all your components and their versions as they change so you don't get caught in a preventable breach!
Identify Your Environment
Sometimes you can use all your secure programming practices but end up having your web application in an environment that is not secure.
This can open the web application to other attacks that can cause it to fail. It is very important to have the right security configuration for the environment that houses your web application to ensure that it has availability and integrity.
We want to keep our web applications secure and would like to believe that once we have done so, we are okay. Unfortunately, there are a lot of other factors to consider. The environment housing the web application can cause vulnerability.
Outside of the web application server and firewall is the physical server itself. Typically, the cloud services that provide this space have compliance measures already in place. Ensure that the compliance standards for the cloud service being used are up to par with the security policy requirements of the web application. Security configuration of the physical server and firewall for the cloud platform requires strict configuration.
Access control for the outside environmental components such as cloud platform and server administration are other ways that a hacker can gain unauthorized control of the web application. These factors must be configured properly and documented.
Secure Your Environment
After you are aware of the components in your environment, you must ensure that the configurations are up to par with diligence. Security misconfigurations are one of the biggest vulnerabilities, and the proper handling of them is a critical piece in maintaining the security of your web application.
Although you won't be working directly with a lot of outside components, it is important to be aware of them. It may benefit your colleagues. That is why you are an OWASP superhero!
So let's talk about what you should know after you put your cape on.
Ready?
Let me start with an example:
Let's say the platform that your web application is housed on has an admin console. Your boss insists that the platform has a reputation for being secure and uses a popular cloud service that is known for security! Your boss also says that its all set up and you just have to set your web application up on the platform and you're good to go. It's all secure!
WRONG.
The site gets hijacked, and guess what? They had full access to your web application because they were able to get into the admin console. Apparently, some of the default credentials were not deleted, and since these credentials are already known to hackers, they sit and wait for the next web app to pop up with the default settings!
What went wrong? You secured all your code using OWASP best practices!
None of that matters if they have access to all of your source code because they can log directly into the admin console.
What is the lesson to be learned here?
Secure all of your external applications!
But there is more.
Network Services - You want to look at your web server infrastructure and ensure that best practices are used to secure your services. You have FTP, Database or LDAP servers that can be compromised by the wrong folks! Authentication systems should follow best practices, and administrative tools for all your components should be secured. A few good questions to ask would be:
Are there firewalls for all the applications and servers? Are they hardened against intrusion?
Are only the necessary ports opened with limited rulesets for source and destination points? Do the firewalls limit the type of traffic on the open ports?
Also, is there any detection set in place to pick up on anomalies in web traffic?
Web traffic should be monitored for little oddities here and there. Imagine if someone started running port scans to look for open ports periodically. There are tools that can detect that such events are occurring to warn the administrators that there is a possible attempt to hijack the site! They need to be on it!
Application and platform: We talked about the default username and passwords for the servers, applications, and databases. We also went over detecting and logging possible events. Those need to be protected too! Make sure they do not reveal basic information about your site such as the usernames, files, IP configurations, stack traces, and basic PII for the business and people.
All administrative aspects such as directory and configuration files for all of the applications must be protected from prying eyes. Make them inaccessible! Keep source code and the file structure safe by ensuring that the web server is locked down.
All of your applications are housed on operating systems. Ensure that applications have minimal access to the operating system because hijacking the operating system is a surefire way of gaining control of your application.
You've also got access tokens, authentication passwords, and encryption keys! Keep them protected because if you have secured your site using HTTPS for all of your requests, it will all be for naught if a bad actor already has access to your SSL key! Doh! With that, they can decrypt everything! 😱
Exception handling and Error codes: Exceptions and error codes reveal a lot about your application, your source code, how the network is run, your database file structure, file directories and more. The malicious players scan for this type of information. Sure, it's not too harmful for them to find out a couple of small things, but imagine if they put so many pieces of the jigsaw puzzle together, that they know the ins and outs of the entire platform and the applications running on it! A stack trace can be useful when you are debugging your application; however, if it's used maliciously, the amount of information it can reveal may be dangerous!
I know that is a lot to handle, but as the OWASP superhero, it is your duty to effectively deflect these issues with knowledge and information.
It's your turn to be the champion of security and spread the knowledge to keep your web application secure from common vulnerabilities!!!!
Let’s Recap!
When designing a web application, assess components with known vulnerabilities.
Components can have new vulnerabilities throughout the life cycle of the product.
Always patch and recode areas with new vulnerabilities.
Your job is not done after writing secure code.
Ensure that firewalls and platforms are protected and configured securely.
Connect with DBAs to make sure the database is protected.
