The 3 Most “Resistant and Persistent” Application Security Vulnerabilities!!

My team tests at least 5 applications a week on average. We constantly work with Web Apps, Web Services, Mobile Apps and now, IoT driven applications, which have a pretty large web services layer supporting it. We work with multiple product engineering teams, especially developers, to help them fix those niggling security problems.

Recently, I had a question that I wanted answered in substantive terms. “Which vulnerabilities are most resistant and persistent across all the apps that we test?” This is a pretty expansive question. We test scores of apps, that have a larger set of vulnerabilities. I was looking for application vulnerabilities that either haven’t been fixed over time or have been fixed at a given time, but have resurfaced elsewhere. These vulnerabilities, I would put into the “Resistant, Persistent” category. I loaded our sanitized vulnerability metadata onto an Elastic Search Server. And armed with my python scripts for analytics and aggregation, I crunched some numbers and I have tried to drill down to the 3 Most Resistant Application Security Vulnerabilities, from January of 2015 to the present day.
1. Cross Site Scripting (XSS):

There’s nothing new about Cross Site Scripting. Its been a permanent fixture on the OWASP Top 10 as far back as I can remember. One would think that Cross Site Scripting (XSS) would have been fixed or at least marginalized by this point. However, unlike SQL Injection, Cross Site Scripting has continued to enjoy relevance and multiple leases of life. This is simply owing to the fact that the application attack surface has increased significantly with tons of third party Front-End JavaScript libraries, inconsistent output encoding, dependencies on CDNs, etc. Cross Site Scripting has proven to be a formidable vulnerability to fix. Nearly every client we test seems to have at least one or more significant Cross Site Scripting flaw. This, despite the fact that modern web frameworks come with “batteries-included” approaches to validation and output encoding. So, if you’re app is using any of the above elements that I just mentioned. You need to probably look for this highly resistant and persistent security flaw.

2. Insecure Direct Object Reference (IDOR):
These really are Authorization Flaws. Using these flaws, an attacker can bypass permissions management controls and gain unauthorized access to sensitive information from other user accounts or other data sets. The major manifestations of IDORs happen in two ways. First (uncommon) type where the attacker is able to manipulate model data and gain access to privileged functionality. Second (common) type where attackers can identify primary key/identifier values and attempt to gain access to other user accounts or elevate privileges. The reasons for this vulnerability being “resistant and persistent” is due to the following factors:
There’s a lot more impetus given to authentication than authorization in the design/architecture of an application. What’s worse is that authorization is a highly design centric activity that is usually done poorly. It’s not granular enough, it’s not comprehensive enough and its coverage is inadequate. So, its doomed to fail.

• With Web Services (where’s there’s no UI Control) this is rampant because developers just don’t expect/realize that there are these bugs in the system.
• These vulnerabilities cannot be tested directly with Automated Vulnerability Scanning tools like AppScan, Burp, etc. They have to subjected to manual/scripted security testing with special impetus on authorization testing.
• The other (probably smaller) reason is that developers don’t design primary keys to be truly random. Some of them are basic incremental integers (1,2,3) or what they think is random (20171121001), which I am sure by now, you realize is anything but.

Direct Object Reference flaws can be deadly. They need to be understood and addressed the right way.

3. Cross Site Request Forgery (CSRF/XSRF):

Cross Site Request Forgery is really an attack against Authentication. In short, an attacker is making the user do things the user never intended to do on your application. This could be anything from forcibly changing the user’s password to adding an unauthorized rule on a firewall web console. Most of the web apps we test, CSRF is a common finding. The effects of a CSRF are only aggravated with XSS on the same application. To developers who think that CSRF only works on browser based web apps, think again. Web Services can equally be affected by CSRF Attacks.

Disclaimer: What I have written above, is in no way a comprehensive list of application vulnerabilities. These are just the 3 applications that my team and I are seeing more frequently than others in modern applications. These vulnerabilities happen to be both resistant and persistent because they seem to either stay unmitigated (for long periods of time)