Previous
Signs That Your Systems May Have Been Compromised
In September 2021, the Open Web Application Security Project® (OWASP) published its Top 10 for 2021, a list that represents a broad consensus on the ten most serious web application security concerns. Examining these vulnerabilities and their implications for application development and DevSecOps helps security professionals and developers remember common flaws to look for when testing an application and what pitfalls to avoid when designing web apps from a developer's perspective.
There are three new categories (Insecure Design, Software and Data Integrity Failures and Server-Side Request Forgery (SSRF) in the Top 10 for 2021, four with naming and scoping modifications and some consolidation. Due to improved frameworks/technology and security awareness, some issues highlighted in 2017 have ranked lower on this year's list. Injection and Cross-Site Scripting (XSS) are now merged under the heading Injection for this year. At the same time, Sensitive Data Exposure, Broken Access Control, Security Misconfiguration, Using Components with Known Vulnerabilities, and Insufficient Logging & Monitoring all ranked higher for this year's listing.
Each institution is responsible for ensuring that its users and systems are as protected and well equipped as possible. In doing so, let's look at the top 3 issues, taking a closer look at each to review its application.
Broken Access Control
Access control enforces policy such that users cannot act outside of their intended permissions. Therefore, it is considered broken when it typically leads to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's capabilities.
Consider an eCommerce application that allows its users to add items to a shopping cart before purchasing. Each cart has an assigned URL, e.g., https://exampleshop.com/cart/1234, where '1234' is the userID parameter for the user's cart. If a user changes the number from '1234' to another ID- '5678', then the shop will show the user's cart with that ID. This is a common example of broken access control, which can be devastating depending on the sensitivity of the information shown. Ideally, the application should have rejected that request because user '1234' should not have access to user '5678's cart.
Prevention:
There are several ways to address broken access, including:
Rate Limiting - This essentially means that APIs should limit the number of requests coming in once it looks suspicious, for example, an automated attack.
Session tokens should be invalidated when logged out.
The application should be designed so that only the owner/authorized user can create, update, view, or delete an item and reject another user's attempts.
Injection
OWASP defines Injection as a vulnerability that allows an attacker to relay malicious code through an application to another system. This can include compromising both backend systems and other clients connected to the vulnerable application, leading to unauthorized authentication in the form of SQL injection (where the attacker needs to find a parameter that the web application passes through to a database interaction). An attacker can then embed malicious SQL commands into the parameter's content to trick the web application to forward a malicious query to the database to compromise the application. A notable example of this is the 2007 attack where hackers used SQL injection to break into the 7-Eleven network, stealing an undetermined amount of customer's card data.
Prevention:
Ideally, to prevent SQL injection, it must be understood that any data being entered into a system by a user should not be trusted. Data should not be made part of a query going to a database but instead must be passed using a more secure manner known as prepared statements. Prepared statements is a parameterized and reusable SQL query which allows for the SQL commands and user provided data to be separated.
Cryptographic Failure
Cryptographic failures refer to weak or lack of secure cryptographic methods protecting data at rest or in transit, often leading to sensitive data exposure. When we think of cryptography, we think of encryption, which is the process of scrambling data so that it is not clear or in plaintext.
Storing passwords, for example, is considered 'data at rest.' Passwords should ideally be hashed (scrambled using hashing algorithms) and stored in a database; nonetheless, developers still keep passwords in databases exactly as the user typed them in. When this happens, the users' passwords are exposed in cleartext for all to see in the event of a database breach.
Cryptography in transit speaks to encryption as data is moving. A good example is a website using HTTP vs HTTPS, where the S stands for secure. A site that uses HTTP (Hypertext Transfer Protocol) does not use encryption, which might lead to sniffing, which is when a user on the same network can see what data is being sent to the site. When a website uses HTTPS (Hypertext Transfer Protocol Secure) and a properly configured TLS certificate, data passing to that website appears scrambled to anyone trying to sniff it out.
Prevention:
Hash passwords in databases
Configure website with proper TLS certificates
Remove sensitive information when no longer needed
Encrypt all sensitive data at rest
Do not use outdated protocols
At Symptai, we provide application protection for the software that powers your business and innovation. We assess the web application to identify any security vulnerabilities that may exist and ensure the application does not weaken the company information security posture or create risk exposures. We go as far as using the Application Security Verification Standard (ASVS), an OWASP developed checklist that denotes what to look for when doing a security review of a web or mobile application.
Security is everyone's job. While you don't have to be a web developer/app developer for these to matter to you, having basic knowledge can make a tremendous difference, allowing even the ordinary person browsing an application to identify a potential issue and report it to relevant personnel using the proper legal medium. However, bare in mind that intentionally looking to identify weaknesses or vulnerabilities in an application without prior permission is considered illegal and is not advised by myself or Symptai Consulting Ltd. To learn more about our penetration tests, and how Symptai can help you and your organization, contact us at info@symptai.com.
Sources:
https://hdivsecurity.com/owasp-broken-access-control
https://auth0.com/blog/a-tour-through-the-owasp-top-10/#-2--Cryptographic-Failures
