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 Injection
Buffer Overflow
Format String Error

Upon investigating I found some exceptions in the application log as below

[font=courier new]
java.lang.RuntimeException: Invalid window size received from client
at com.vaadin.server.Page.init(
at com.vaadin.ui.UI.doInit(

Caused by: java.lang.NumberFormatException: For input string: “…..............................\Windows\system.ini”
at java.lang.NumberFormatException.forInputString(
at java.lang.Integer.parseInt(

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?

Please suggest.


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

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.