Logical vulnerabilities, inspiration

Logical vulnerabilities are much more dangerous, and they are often semi-harder to find compared with technical holes, and nobody can deny it. These days, everyone boasts on his penetration testing skills, having security projects have become common-place. Furthermore, scanning a web application by a vulnerability scanner such as Acunetix is widespread. If we pay more attention, and being more realistic, we end up a professional penetration test doesn’t only comprise automatic scanning. However, a scanner would be a big help in crawling and even digging application for technical vulnerabilities in back-end components, notably within a black-box tests of giant applications. Honestly, I personally can’t resist leveraging scanners in a penetrate testing.
It’s been a while that I’m finding myself as an instructor in some of my free times which I’ve used to waste. In addition, I’ve been working on a commercial software for roughly 2 months, detecting and exploiting securities flaws automatically, of-course technical ones. A day when I was deeply working through analyzing of diverse vulnerabilities, an idea came cross my mind that what if a scanner is capable of discovering logical imperfections? Although it can be said that it would be impossible, there will be many approaches. In the other side, I’ve repeatedly seen newbies and apprentices have trouble finding vulnerabilities within a web application, specially when it comes to logic.
As a consequence of all statements above, ultimately I decided to code a small PHP portal dealing with MySQL, interacting with external users, potentially suffering from various vulnerabilities which cannot be found by scanners!
I know there are some vulnerable web applications for learning such as DVWA and Mutillidae (Second is rather preferred). Despite being famous, I’m not really comfortable with them since they are so limited to well-known vulnerabilities which are discover-able by scanners.
Back to the coding topic, in the term of developing, I’m intensively careful about obeying separation of concerns. It’s indispensable to know where to inject malicious inputs and where a vulnerability occurs. As a case in point, the interaction between Database and Authentication or Session management and Access control layers is handled unsafely, or an attacker may access errors occurred directly instead of seeing them through Presentation layer as develops wants. Also there would be further circumvention in each layer:


Since the application is being written by OOP techniques, it more likely seems to real world application, and white-box auditing won’t be as easy as other applications (DVWA which it’s too easy to find a vulnerability). I want to include specific diagram of application’s functionality once development term is finished. Moreover, I’m putting all of my effort to include real vulnerabilities I’ve personally found so far (Or valuable CTF web section questions).
To sum up, I think the application I’m coding tremendously leads security newcomers to better understanding of layers interaction, complicated vulnerabilities and finding logical flaws. I know this update is too long to read, whereas I couldn’t resist, be safe.