0

I have a REST which takes a parameter dataSource as input and myService has follow logic.

@RequestMapping(value ="/save", method = RequestMethod.POST)
public List<String> find(@RequestBody String dataSource){
    return myService.doPost(dataSource);
}

We search the URL in the database by dataSource as key. Then we get an URL and create Http request.

void doPost(String dataSource){
    String url= dataBaseService.findUrlByDataSource(dataSource);
    HttpPost httpPost = new HttpPost(url)
    CloseableHttpResponse response = client.execute(httpPost);
}

So when I ran my app through checkmarx. Report says following.

However, an attacker can control the target of the request, by sending a URL or other data in dataSourceName

So, I don't pass URL directly to HttpClient (userInput -> database -> httpclient).

What to do? Change logic? Or Can I solve it on another way?

4
  • Do you have a complete example to share? I'm not sure how this works. You Store a String "dataSource" into a service. Later you try to get a URL by sending the same String? Where does the URL come from? Commented Nov 17, 2021 at 9:43
  • Url come from database. My database table has following structure (id, datasoruce, url) So from user input (datasource) , I find URL in DB Commented Nov 17, 2021 at 9:55
  • Can the user create or edit entries in the database or does anybody else has access to this table? Commented Nov 17, 2021 at 10:27
  • 1
    This lacks information. 1. Is the value of dataSource validated or restricted to a limited set. 2. Are these URLs public or not. 3. What do you expect to gain from this proxy architecture if not for '2'.
    – Beltway
    Commented Nov 17, 2021 at 12:40

1 Answer 1

1

As seism0saurus and beltway implied, the critical questions are who controls what URLs are in the DB, and how dangerous they are. If the URLs themselves are not under user (or other untrusted-actor) control, and they are all safe to request (meaning not only "not malicious" but also things like "don't cost you money every time they're requested"), then you're fine and can dismiss the finding as a false positive.

The approach you're taking (lookup table to the actual URLs) is the right one, and generally what is recommended in cases where the server needs to fetch a URL at all. Of course, there are questions about how necessary that is - presumably there's some reason the user can't fetch the URL themselves - but if that's what you have to do, and there's no way for untrusted parties to influence the list of URLs, then you're doing it right.

Given the system as you describe, this is just a false positive (FP). All static analysis tools have either false positives or false negatives, and usually both.[1] In this case, it sounds like the scanner may be configured to bias toward FPs over FNs. Depending on the environment, you should be able to either mark the finding as FP directly, or submit a supplementary doc with the scan report that explains why the finding is FP.

[1]Laugh in the face of any vendor who ever tells you that their tool doesn't have any of those, and ask to speak with somebody whose brain hasn't been rotted by sales pitches.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .