SSahoo361541 (Community Member) asked a question.
Ask the Community
Get answers, share a use case, discuss your favorite features, or get input from the community.
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts.
.png){kind=logo}
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Java's CallableStatement is generally safe, if used correctly. The entire query needs to be parameterized, however. If you were to dynamically build a SQL string within the stored procedure, with concatenated parameter values, it contains the same risks inherent with dynamically concatenated parameter values in regular SQL queries.
In summary, ensure that the CallableStatment's query is entirely parameterized, and that the stored procedure is safely constructed. If you have any other questions, I would recommend you schedule a consultation call to discuss. You can check out this knowledge article (https://community.veracode.com/s/article/How-to-schedule-a-consultation-call) on how to schedule a consultation call with us.
Thank you Austin for your reply. I got the same answer while googling. In veracode scan report for our application code, it is reporting as flaw. Please let me know how can I stop in reporting as flaw.
If the static analysis is identifying the flaw it is likely because the scanner sees a portion of the SQL query that specifies the stored procedure as being dynamically concatenated and not parameterized. If a portion of the SQL query can't be paramterized because it is not a paramterizable element, then it is recommended that you validate the input with a strict whitelist and accept known-good values only. Without the scan details it isn't possible to advise why the scanner detected the finding so I would recommend a consultation to discuss further. You can check out this knowledge article (https://community.veracode.com/s/article/How-to-schedule-a-consultation-call) on how to schedule a consultation call with us.