OWASP Security Threats
OWASP or the Open Web Application Security Project is a nonprofit foundation that works to improve the security of software. They have a lot of good resources on how to improve the security of your web application and I wanted to go through some of their information and help digest it.
Since this is just a start, we are going to cover the OWASP Top 10 threats at a very high level, and then in later blogs discuss each in more detail. The goal here is to edicuate on the general attack vectors and some very basic defenses. OWASP has a lot more information that I have linked for each section.
Injection
Injection attacks have been around for a while and are well known, but still are a common flaw in modern applications. They typically take the form of putting malicious SQL (or NoSQL, OS, LDAP) code into a field and submitting it. The server then runs this code and returns the resulting information or performs the requested actions. XKCD has a funny take and Computerphile does a couple of good introductions to the topic. SQL injection is very easy to exploit and it is relatively easy for attackers to discover them. It is important to ensure that the system is configured protect against it. Common procausions include server side input validation (though since text fields often require special characters this cannot be a perfect defence), escape special characters depending on the interpreter being used or using Object Relational Mapping (ORM) to help isolate the database from user inputs.
Broken Authentication
Setting up authentication can be tricky. Everything has to be properly configured and designed. If an authentication system is poorly built or implemented attackers can access keys, tokens, or even passwords and user data. Typical attacks include credential stuffing, brute force, and automated attacks and typical mistakes include storing plain text passwords (yes, despite everything, this still happens), weak credential recovery systems, and session tokens that are static or persist after logout.
A typical rule of thumb is unless you really know what you are doing (and a google education does not count) don’t roll your own Auth system. There are lots of options out there but the key is, the more critical your information is, the more important it is for you to seek out a professional.
Sensitive Data Exposure
If (or perhaps more accurately when) attackers can gain access to your system, it is important that they cant get sensitive information. The best defence is to limited the amount of sensitive data being stored to the absolute minimum. Beyond that, encrypting all sensitive information to make it more difficult for the attacker to get anything of value as well as using up to date protocols for storage and transmission is a good first step.
XML External Entities (XXE)
If your site utilizes XML there is a chance that the XML processor allows the specification of an external entity, a URI that is referenced and evaluated during XML processing. This type of attack can extract data, execute remote requests from the server, scan the server, perform DoS attacks among others.
To prevent attackes it is recommended to utilize less complex data formats such as JSON when possible. When XML is used ensure that all processors and libraries are kept up to date and the system is configured properly.
Broken Access Control
Access control enforces policies so that users cannot perform actions outside of their intended permissions. When access control fails this allows users to gain control over data that was not intended. Best practices is to deny access by default (allow only by exception) except on public resources. Also implement access control once and then reuse it through the application. This will keep the code DRY and make errors and vulnerabilities less likely. A couple of other easy to implement features include invalidating JWT tokens on the server after logout and rate limiting APIs to help prevent automated attacks.
Security Misconfiguration
Security misconfiguration is perhaps the most common threat largely due to the possibility of human error when moving from development or testing environments to production or when rolling major system upgrades. Since many security configurations have to be done manually and almost every level of the application will have some configuration there is an increased probability of errors occurring.
To help ensure a correctly configured application some processes can be followed. Implementing a repeatable hardening process to ensure that all new environments are properly locked down and configured identically (with different credential for each environment), this should be automated if possible. Also, it is best to minimize the application as possible (see Using Components With Known Vunlerabiltes) and to set up periodic reviews to check that the application configuration is correct and up to date.
Cross-Site Scripting (XSS)
Nearly as common as security misconfiguration, Cross-Site Scripting is when an application allows untrusted data in a new web page without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser with can hijack user sessions, store user data, deface sites, or redirect users. Fortunately, automated tools can detect vulnerabilities and using the latest versions of modern frameworks such as Ruby on Rails and React JS can protect applications.
Insecure Deserialization
When incoming data is deserialized it is possible to inject malicious code. This can result in attackes such as remote code execution and can give an attacker full control over the system. Luckly explotiation is more difficult than other attack vectors since off the shelf exploites usually require modifications for specific systems. Best practice is to only accept serialized objects from trusted sources and/or only allow premitive data types.
Using Components with Known Vulnerabilities
Most systems are built using many preexisting components. While this greatly speeds up development as teams don't have to “reinvent the wheel” for every problem, it results in an application where the teams don’t fully understand the application components. If a critical component has an identified vulnerability and is not kept up to date it becomes a relatively easy way to attack a system. To mitigate developers should continuously trim unused depentedencies and components as well as implement montering tools to check for known weekaness or out of date components.
Insufficient Logging & Monitoring
The general lack of detailed logging and monitoring of deployed systems means that attackes are much more likely to inflict significatant damage. Most successful attackes start with vulnerability probing, if the probing is not detected and allowed to continue, it is very likely that attackers can find a vulnerability. To mitigate the risk it is important that all login, access control failure and server-side input validation failures are logged with sufficient context to identify suspicious activity. Additionally these logs should be kept and be auditable for any high value transactions as well as have automated monitoring and alerting so that action can be taken in the case of identified vulnerability probing.
Ok, that was a LOT of information, and covered at a dangerously high level. I highly recommend reviewing owasp.org and looking into each of these in more detail. There is a reason that there is an entire field around cyber security and I am not an expert. For those of you managing deployed applications, hopefully there is nothing too new here, but it is always worth a refresher. If you have any questions or want to discuss further, feel free to reach out to me.
