OWASP’s top 10 is published every three to four years, highlighting the most critical security vulnerabilities. The last one was published in 2021 and it has the top ten vulnerabilities that a developer should be aware of. Open Web Application Security Project (OWASP) helps developers build secure web applications by identifying critical security vulnerabilities. The OWASP Top 10 document is an awareness document for developers and web application security practitioners.
Here we will be discussing the top 3 of the top 10 OWASP recommendations. Developers need to keep an eye for these top 3 security vulnerabilities when designing their backend applications. Moreover, every developer should be familiar with these three vulnerabilities. At the very least, every developer should be aware of them. These top three are:
1) Broken Access Control
2) Cryptographic Failures
Broken Access Control
Access control ensures that users cannot act outside of their permissions. Data is typically disclosed, modified, or destroyed without authorization or a business function is performed beyond the user’s authority. The following are some common access control vulnerabilities:
- Access is granted to all, rather than only to those with specific capabilities, roles, or users.
- Modifying the URL, internal application state, HTML page, or API requests to bypass access control checks.
- Allowing access to or editing someone else’s account by providing its unique identifier (insecure direct object references).
- Accessing API with no access controls for POST, PUT and DELETE operations.
- When logged in as a user, acting as an admin or acting as a user without being logged in.
- Manipulation of metadata, such as replaying a JSON Web Token (JWT), access control token, or tampering with a cookie or hidden field, to elevate privileges or to abuse the invalidation of JWT authentication tokens, is one example of metadata manipulation.
- An API can be accessed by unauthorized or untrusted sources due to a CORS misconfiguration.
- As an unauthenticated user, force browsing to authenticated pages, or as a standard user, force browsing to privileged pages.
How to prevent it?
Access control is only effective in server-side code or serverless APIs, where the attacker can’t alter the metadata or access control check.
- By default, deny all requests, except for those related to public resources.
- Ensure that access control mechanisms are implemented once and re-used throughout the entire application and that Cross-Origin Resource Sharing (CORS) is minimized.
- Instead of allowing users to create, read, update, or delete any record, model access controls should enforce record ownership.
- Domain models should enforce unique application business limits.
- Ensure files metadata (such as .git) and also that backup files are not present within web roots. Also disable web server directory listing.
- Admins should be alerted when access control fails (e.g., repeated failures).
- Rate limit API and controller access to minimize the impact of automated attacks.
It is essential to determine the protection needs of data in transit and at rest. These include – passwords, credit card numbers, health records, personal information, and business secrets, particularly if they fall under privacy laws. For all such data make sure:
- Is data transmitted in clear text? This concerns HTTP, SMTP, FTP, and TLS upgrades like STARTTLS. There are risks associated with external internet traffic. Verify all internal traffic, such as traffic between load balancers, web servers and backend systems.
- Does older code use old or weak cryptographic algorithms or protocols?
- Is there a lack of proper key management or rotation, instances of default crypto keys being used, or are weak crypto keys being generated or re-used? Do source code repositories contain crypto keys?
- Have any HTTP headers (browser) security directives been ignored, or are headers missing?
- Has the received server certificate and trust chain been validated?
- Are initialization vectors ignored, reused, or not generated properly for cryptographic operations? Are insecure modes of operation, such as ECB, being used? Is encryption used when authenticated encryption would be more appropriate?
- In the absence of a password-based key derivation function, are passwords being used as cryptographic keys?
- Is MD5 or SHA1 being used, or are non-cryptographic hash functions are used when cryptographic hash functions are needed?
- Do you still use deprecated cryptographic padding methods such as PKCS number 1 v1.5?
- Is it possible to exploit cryptographic error messages or side channel information, such as padding oracles?
- Is randomness used for cryptographic purposes despite it not being designed for this purpose?
How to prevent it?
The following should be done at a minimum level:
- Application data should be classified according to how it is processed, stored, or transmitted.
- Avoid storing sensitive data unnecessarily.
- Encrypt all sensitive data at rest.
- Make sure standard algorithms, protocols, and keys are up-to-date and strong.
- Make sure all data in transit is encrypted using secure transport protocols including TLS with forward secrecy (FS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption with directives such as HTTP Strict Transport Security (HSTS).
- For responses containing sensitive information, disable caching.
- FTP and SMTP are outdated protocols that should not be used for sensitive data transfers.
- Passwords should be hashed using strong adaptive and salted hashing functions, such as Argon2, scrypt, bcrypt, or the PBKDF2 algorithm.
- Instead of just encrypting, use authenticated encryption.
- Check independently the effectiveness of configurations and settings.
Injections include SQL, NoSQL, OS commands, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL). It is possible to attack an application when:
- Applications do not validate, filter, or sanitize user-provided data.
- Without context-aware escapes, the interpreter uses dynamic queries or non-parameterized calls directly.
- In order to extract additional, sensitive records, hostile data is incorporated into the object-relational mapping (ORM) search parameters.
- Data that is hostile is directly used or concatenated.
How to prevent it?
To prevent injection, keep commands and queries separate from data:
- An alternative is to use a safe API, which avoids the interpreter entirely, provides a parameterized interface, or migrates to Object Relational Mapping Tools (ORMs).
- Positive input validation on the server should be used.
- If there are any residual dynamic queries, escape special characters using the interpreter-specific escape syntax.
- To prevent mass disclosure of records in the event of SQL injection, use LIMIT and other SQL controls within queries.