Digital security is serious business. A single breach can cause millions in damages and damage a company’s reputation for years to come.
With thousands of factors affecting web application security, though, it’s sometimes challenging to decide where to focus during development.
Fortunately, the vast majority of security threats to web applications are caused by a handful of common issues. The OWASP Top Ten is a dynamic ranking of these flaws, updated periodically in response to new threats.
Developers can use it as a checklist to cover the essentials of application security. Read on for an explanation of the OWASP Top Ten as well as some guidance on avoiding each one.
Risks on the rise
Data breaches are reaching critically high levels. 2017 set a new record for both number and severity of breaches, with 7.89 billion records compromised during 5,207 breaches.
About 69% of these were due to technical or human errors instead of malicious actors.
Misconfigured services, bad backups, failure to update software, and other mistakes leave applications open to accidental breaches or intentional attacks.
The fallout from a breach is devastating. An average data breach costs anywhere from $2.2 million to $6.9 million, with mega breaches reaching $40-350 million.
With stakes this high, companies should take preventative steps to address the most common security issues before they lead to disaster.
What is OWASP?
The Open Web Application Security Project (OWASP) is an international non-profit organization dedicated to improving software security.
It serves as a resource to support the creation, purchase, and maintenance of trustworthy applications and APIs.
OWASP doesn’t endorse specific commercial products. Instead, it identifies threats, establishes security best practices, and provides guides and tools for building better software.
Defending Against the OWASP Top Ten
Injection flaws happen when malicious outside code masquerades as part of a command or query.
The interpreter “recognizes” it and allows access to the software’s internal functions where it can bypass system boundaries, copy or manipulate data, and perform any number of unauthorized actions.
There are several types of injection flaws, including SQL, NoSQL, OS, and LDAP injection.
Reduce the risks of injection flaws by using the appropriate functions and API to help sanitize data and increase security.
Depending on the software’s purpose, restricting the type and size of file uploads adds another layer of protection.
Authentication and session management are two of the most useful defenses against outside influence, but they’re often unevenly implemented. Session IDs get exposed in the URL or aren’t rotated after a login.
Passwords aren’t hashed and salted. There’s no default application timeout set to protect against users who forget to logout on shared computers.
Attackers can exploit these weaknesses to pose as authorized users and gain access.
Always be sure to check and double-check authentication functions during testing. It’s also a good idea to use multi-factor authentication.
Sensitive Data Exposure
There’s a special responsibility to protect sensitive data like financial data, health records, and personally identifiable information (PII).
A surprising number of applications and API don’t take the steps necessary to obscure this data. It’s stored unencrypted in clear text, easily intercepted. Sometimes the data automatically decrypts when retrieved which, when paired with injection flaws, makes it easy to copy and paste outside the system.
The data subjects are left exposed to a very real risk of identity theft.
Provide extra protection for sensitive data, such as encryption at rest or in transit. Take more precautions when exchanging this kind of data with the browser, too.
XML External Entities (XXE)
This rising threat comes from XML, a useful tool for allowing different applications to access shared data. External entity references can be introduced to an XML document where outdated or badly configured processors accept them as legitimate.
XXE opens the door to a wide spectrum of exploitation: initiating denial of service attacks, accessing and sharing internal files, scanning internal systems, and even executing remote code.
XXE needs to be addressed by a skilled developer. Older XML processors tend to have a lot of vulnerabilities, so they need to be patched and updated regularly.
Use less complex data forms (like JSON) when possible. Avoid serialization of sensitive data.
Consider implementing positive server-side input validation (or whitelisting) as well as sanitization to detect and avoid hostile data within XML documents, headers, or nodes.
Broken Access Control
There should be restrictions on what authorized users can do based on internal structure and their needs. However, these restrictions aren’t always enforced by the system.
This leaves an opening for attackers to gain access to a lower level of authentication and exploit to obtain sensitive data, modify access rights, and even create their own account as a long-term point of entry to the system.
Institute a policy of “denial by default” where users are always restricted from a function unless otherwise specified. Use access controls that label ownership instead of simply accepting rights to add, alter, or delete records.
This makes it easier to tell whose account is compromised in a breach and guard against internal security threats.
Finally, ensure proper logging and monitoring of login failures to detect potential threats earlier.
This category covers a lot of technical territory, so it’s no surprise that it’s the most commonly seen issue.
Developers leave weak default configurations in place, forget steps or use shortcuts, poorly configure HTTP headers, mishandle open cloud storage, or provide sensitive information in error messages.
Mistakes like this are usually due to schedule pressures or unfamiliarity with tools.
The best remedy for security misconfigurations is emphasizing attention to detail both during and after release. Make sure all operating systems, frameworks, libraries, and applications are securely configured.
Set up a system to patch and upgrade promptly (especially after becoming aware of a vulnerability within the stack).
Use automated tools to verify security settings within different environments. Having team members double-check each other when possible provides an opportunity to catch mistakes early, as well.
Cross Site Scripting
Cross-site scripting (XSS) happens when attackers can introduce untrusted data into a new web page that serves as a trap for visitors of that page.
Attackers employ XSS to insert scripts which are treated as code by the victim’s browser.
They can then add “digital graffiti” to web applications, redirect users to a site of their choosing (usually to elicit PII or financial data), and even hijack user sessions outright.
Some developers dismiss XSS flaws as a user problem, but if it originates on a company’s vulnerable web application, they’re still responsible for its effects.
Consider frameworks that avoid XSS by design (ReactJS, for example). When that’s not an option, implement controls for framework-specific XSS vulnerabilities.
Insecure deserialization allows attackers to transfer a malicious payload using serialized objects.
It often leads to remote code execution, and even when it doesn’t serialization can be used to perform attacks such as code injection attacks, replay attacks, privilege escalation attacks.
Never accept serialized objects from untrusted sources. Use serialization mediums that only permit primitive data types.
Developers should also put integrity checks in place, including digital signatures on serialized objects to prevent hostile object creation or data tampering.
Using Components with Known Vulnerabilities
Software components like libraries, frameworks, and other software modules are by necessity given the same privileges as the supported application.
If they have security flaws, every software built using it can inherit the flaw. Outside actors exploit known vulnerabilities to steal data or take full control of a server.
Companies with lax update and patch schedules may take weeks or even months to recognize a known flaw, which leaves them open to attack in the interim.
Stay on top of stack components. Implement continuous process aimed at inventorying components and dependencies, including notes about when the component was last updated.
If a component is no longer in use, remove it to avoid vulnerabilities from unsupported tools. Subscribe to security alerts when available, and always use secure connections to download components.
Automation can help avoid human error or oversight in this process.
Insufficient Logging and Monitoring
It takes more than 200 days on average for a company to realize they have a software breach. Even then the breach is usually detected by an outside source.
The lag in detection results from insufficient logging and monitoring and weak incident response protocols that are slow to react once a breach comes to light.
Attackers have plenty of time to evade detection, erase anything which might have allowed investigators to identify them, tamper with data, or even move to other systems.
This is one of the simplest vulnerabilities to address, though it requires an ongoing commitment to consistency.
Implement automatic logging of all login, access control, and server-side input validation failures including sufficient user context to determine whether the failure is potentially suspicious.
Maintain logs for long enough to perform forensic analysis as needed. The logs themselves should be generated in an easy-to-use format.
It’s worth checking that there are audit trails and integrity control for high-value transactions, as well.
An Ounce of Prevention…
A common theme running through these solutions is awareness and prevention. When developers are aware of the risks, they can take steps in advance to avoid or mitigate disasters.
This is no place to cut corners. After all, time and money spent here can prevent millions in damages after a breach.
At Concepta, our clients’ reputations are as important to us as our own. That’s why our developers use the OWASP guidelines and industry best practices to build highly secure web applications and other software. Find out more during a complimentary consultation with one of our project managers!