String querystring = "SELECT u FROM User u WHERE u.login = '" + login + "'";
Query query = entityManager.createQuery(querystring);
List<User> resultList = query.getResultList();
The Log contains information about the use of rule s3649
The file with vulnerability isn’t excluded.
But Sonarqube says that the code isn’t vulnerable. How is it possible? the same code is provided in Sonarqube’s example for SQLi. What are we doing wrong?
Maybe we are missing something?
Sorry for my late answer. We knew that it is a false negative because it is exlpoitable. We use Hibernate for queries. Here goes the context:
public class UserService {
...
public User findByLogin(String login) {
Query query = entityManager.createQuery("SELECT u FROM User u WHERE u.login = '" + login + "'");
List<User> resultList = query.getResultList();
...}
...
}
and than we have a controller in which we do the following:
import my.project.services.UserService;
...
public String search() {
if(StringUtils.isEmpty(getLogin()))
return INPUT;
try {
user = userService.findByLogin(getLogin());
...
}
tell me please if we need to provide more information and these pieces of code aren’t enough. Thank you!
What is the source exactly (the original source)? The code you provided does not show what calls UserService.findByLogin. Which web frameworks/libraries are you using?
What is the exact type of entityManager? Is it a @PersistenceContext (javax.persistence)?
To be able to reproduce the false negative, I need to see the chain of calls from the source to the sink.
Thank you for your reply. I apologize for the confusion; it’s clear now that my previous explanation wasn’t sufficient. While I can’t share our full code, I found a very similar project online that has exactly the same flow as ours for this particular code. Is it okay if I share a link to the vulnerable code on GitHub here?
Hi,
the project here has a service UserService with method findByLoginUnsafe. IIt is very similar to our code. We ran SonarQube on it and got the same result – SQL injection wasn’t detected.
I see that the vulnerable source (login) is in a Struts 2 action. Unfortunately, we do not support Apache Struts. This is why we are not detecting the issue. We currently do not have plans to support it.