|
| Windev web application exposed on web through waf |
| Started by windev4life, Sep., 15 2025 11:16 AM - No answer |
| |
| | | |
|
| |
| Posted on September, 15 2025 - 11:16 AM |
Hello,
There is no post related to WAF regarding Windev. As a network & security administrator, I find challenging to enforce proper hardening or even a strict WAF security policy for web applications exposed on web. More especially for the parameters. It might be because my team doesn't communicate enough with the developers, but the dynamics and "nameless" aspect of the parameters make it impossible.
When trying to integrate these applications behind an WAF, the policy building process becomes inconsistent. The embedded forms and shifting parameter names force either wide regex exceptions or a complete disablement of metacharacter enforcement. This means the policy ends up being permissive and fails to deliver any real protection.
From my point of view, a WAF should rely on a positive security model: well-defined URLs, parameter sets, expected data types and length, and strict character enforcement. With Windev apps, this model breaks down because the generated HTML is not always compliant (nested forms, dynamic fields, unconventional delimiters), making the parsing unreliable.
The outcome is that either the application works with a weak, exception-heavy WAF policy, or the policy remains strict and blocks legitimate traffic. Both are unsustainable in production.
I am curious if other network/security admins have faced the same situation with Windev apps. How do you handle parameter enforcement? Do you normalize traffic before the WAF (through reverse proxy/iRules), or simply accept the limitations and rely on signatures instead of positive security?
Any feedback, lessons learned, or even confirmation that this is a known limitation would be appreciated.
Best regards, |
| |
| |
| | | |
|
| | | | |
| | |
|