Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Security Issues in Vaadin Framework
I was trying to do the security testing for my application which is built on Vaadin framework version 7.4.3. I am using OWASP ZAP tool for proxy and I tried to do an active scan to one of the request of my applicaiton intercepted by ZAP. The tool is trying to penetrate the vaadin client specific parameters like v-rtzo,v-tzo,v-browserDetails,v-ch,v-sw,v-dston etc..
In this process the tool has detected below list of issues
Remote OS Command InjectionBuffer OverflowFormat String Error
Upon investigating I found some exceptions in the application log as below
java.lang.RuntimeException: Invalid window size received from client
Caused by: java.lang.NumberFormatException: For input string: "..\..\..\..\..\..\..\..\..\..\..\..\..\..\..\..\Windows\system.ini"
Similar instances in many places, Based on the exception stack trace it seems that the vaadin client parameters are not getting validated for their type, like size or width. I have following doubts on this.
Are these issues valid and applicable and do i need to fix them?
Is so how would i handle them?
how do I setup ZAP to test vaadin website.were ZAP able to crawl through site. How did you configure ZAP to login to website.?
In OWASP wiki, Java platform is marked as not affected by Buffer Overflow vulnerability, until the application uses native code or OS-level calls. Of course, if the application uses low-level OS-specific calls or native calls, it's better to check those pieces of the code. The framework never does that. See https://www.owasp.org/index.php/Buffer_Overflows#Platforms_Affected
Framework never executes anything like 'Runtime.exec', and Remote OS Command Injection looks like false-positive for the framework. If you still have concerns, it's better to check if the rest of your application is vulnerable or not.
Format String Error description notes only ANSI C functions of `printf` family, and the nature of Java code execution and Java memory model is the protection against that type of attack - arrays sizes and varargs sizes are always checked by JVM, java code never has any access to memory addresses etc.
As the conclusion, all three reported issues look like false-positives, at least for the Vaadin framework itself.