For example:
- instead of saying 'application should encode XYZ value', you should say 'XYZ value is not encoded'
- instead of saying 'application shouldn't be vulnerable to XSS or SQL injection', you should say 'application is vulnerable to SQL injection'. In this case, SQL Injection is a feature of the application, and while the application allows SQL Injection, the application is working as designed (whether that is intended or not is a different story).
When we describe vulnerabilities, we describe features, because vulnerability is a feature of an application.
If an application has a direct object reference vulnerability (OWASP Top 10), then that is a feature that allows User A to access user B data (by design, using the capabilities of the application).
For each of these cases, you should open risk tickets, since those risks represent existing features. Sometimes you open multiple risks for the same issue, allowing technical and business audiences to understand what is going on (SQL Injection doesn't mean a lot to management, but 'Access and modify all customer data' does).
I remember a funny story where we found SQL injection in a pentest, and when we presented the findings, the business responded: '... well, that is not a critical issue, we have good backups, so that SQL injection is not dangerous'. When we asked 'what if we can drop all tables?' , they said 'We can recover from that very fast, no problem.'
We argued 'well ... we can modify data' and they came back with, 'We have read-only access and we can protect it from there.'. But finally, when we stated 'we can log in as any user with a typical SQL Injection payload of: or 1=1' , that connected the dots, and the business said 'we will fix that ASAP'
The reason that example clicked was because we showed them how to bypass the business logic of the application using the SQL Injection 'feature'. They could tolerate, to a degree, data corruption or content changes. However, they reacted when they saw that the SQL Injection could bypass the application's business logic and break their non-repudiation capabilities (i.e. they would lose the ability to understand what a user did on the site).
