To keep applications safe, developers must strike a balance between creativity and security frameworks. Correlating business logic with security logic will pay dividends in terms of safety.
Web applications are the most common vectors used by attackers to carry out breaches. Web applications were the point of entry for roughly 70% of all breaches studied, according to Verizon's "Data Breach Investigations Report".
After performing over 300 Web application penetration tests, developers continue to make the same security mistakes that lead to vulnerabilities. They frequently do not use secure frameworks and instead attempt to write their own security code and authentication processes.
It's worth noting how much pressure developers are under to get products to market as soon as possible. They are rewarded based on how many features they can introduce as quickly as possible, rather than how securely they can introduce them. This results in security shortcuts and, in the long run, vulnerabilities in Web applications.
Five Lessons for More-Secure Apps
Pen testers act as the devil's advocate, reverse engineering what application developers create to demonstrate where and how attackers gain access. The findings have highlighted common fundamental errors. Here are five lessons that software development companies can learn to improve the security of their applications.
Attackers continue to use cross-site scripting (XSS): For a long time, XSS has been a popular Web application vulnerability. It was removed from the Open Web Application Security Project (OWASP) top 10 list in 2021 due to advancements in application development frameworks, but it is still visible in nearly every penetration test we conduct.
Although it is frequently thought to be low risk, XSS risks can be severe, including account takeover, data theft, and complete compromise of an application's infrastructure. Many developers believe that using a mature input validation library and setting proper HttpOnly cookie attributes is sufficient, but when custom code is used, XSS bugs still find their way in. Consider WordPress sites: an XSS attack on an administrator is critical because the credentials allow the user to load plug-ins, which then execute code-like malicious payloads on the server.
Automated scanners don't go far enough: If you only scan Web applications with automated tools, vulnerabilities are likely to slip through the cracks. These tools employ fuzzing, a technique that injects malformed data into systems, but this technique can result in false positives.
Scanners aren't always up to date with modern Web development and don't always produce the best results for JavaScript single-page applications, WebAssembly, or Graph. Complicated vulner
abilities necessitate a handcrafted payload to validate, rendering automated tools ineffective.
Although human analysis is required for the most accurate and detailed analysis of vulnerabilities and exploits, these scanners can be used as a supplement to quickly find the low-hanging fruit.
When authentication is homegrown, it's usually too weak
When it comes to Web application security, authentication is everything: When developers attempt to create their own forgotten password workflow, they frequently do so in an insecure manner.
Pen testers frequently have access to other users' information or have excessive privileges that are not appropriate for their role. This causes horizontal and vertical access control problems, allowing attackers to lock users out of their accounts or compromise the application.
It all comes down to how these protocols are implemented. For example, Security Assertion Markup Language (SAML) authentication is a single sign-on protocol that is becoming more popular as a means of increasing security, but if it is implemented incorrectly, you will have opened more doors than you have closed.
Attackers target flaws in business logic: Developers examine features to see if they meet the needs of the customer. They frequently fail to consider how an attacker might use that feature maliciously from the other side of the lens.
A good example is an e-commerce website's shopping cart. It is business-critical, but it is frequently insecure, resulting in serious vulnerabilities such as zeroing out the total at checkout, adding items after checkout, or replacing products with different SKUs.
It's difficult to blame developers for focusing on the primary use case and failing to recognise other, usually malicious, uses. Their performance is determined by how well they deliver the feature. Executives must consider the other side of the coin and recognise that business logic should correspond to security logic. The most important business features, such as a shopping cart or authentication workflow, are probably not suitable for a junior developer.
There's no "out of scope" in a good penetration test: Because of the number of resources and assets that go into them, web applications can quickly become complex. Back-end API servers that enable the main application's functionality must be considered.
It's critical to share all of those external assets, as well as how they connect to what the developers built, with penetration testers. The developer may regard those assets as "out of scope" and thus not responsible for them, but an attacker would not respect that line in the sand. Nothing is "out of scope," as penetration tests demonstrate.
A Question of Balance
When software development companies are aware of some of the most common risks, they can engage with security auditors more effectively and make penetration tests less painful. No company wants to limit the creativity of its developers, but by balancing creativity with security frameworks, developers understand where they have leeway and where they must adhere to the guardrails that keep applications safe.
