OLdev (Community Member) asked a question.
Hi,
In our client side SPA app, the JS code sends request to the server using an HttpService with url that consists of 2 components: a) a base URL which is returned from a function, b) a hard coded part of the query string, c) a variable part of the query string which is usually the key/id of the view/edit model. Below is an example of such code:
httpService.post(getBaseUrl() + '/QueryData' + + model.editItemModel.key).then(function(response){
// code to handle response
});
Apparently Veracode does not like that the url has variables in it, and flags this as insufficient input validation URL Redirection to Untrusted Site ('Open Redirect') CWE ID 601. Honestly, I do not understand why it is considered 'URL Redirection' since we do not redirect users to any other urls, it is an AJAX request actually.
The question is, what would be the best way to resolve this issue? is encodeURI() good for this? I checked on this stackoverflow question and it seems that it may not be enough:
https://stackoverflow.com/questions/60693283/did-anyone-worked-on-cwe-601-veracode-flaws
In this case, is there a guaranteed way that will surely get rid of this security issue and make Veracode scan clean? Thanks.
.png){kind=logo}
Hi @OLdev (Community Member) - I've been able to collect some helpful tips and resources via my colleagues.
We have this page, which has some resources for CWE 601: https://community.veracode.com/s/article/allowlist-helps-fix-cwe
Ideally, you want to validate getBaseUrl() to ensure it’s redirecting to the intentional URL or location. If getBaseUrl() is considered trusted—meaning it comes from properties or environment—you could discuss this with your security team to mitigate any risk. Validating getBaseUrl() is needed if you don’t trust the value or it’s not within your control.
The second part is anything else that’s being appended to getBaseUrl() , in this case model.editItemModel.key. You can URL-encode this value to sanitize it, but that doesn’t fully address the risk of an open redirect—it’s more defense-in-depth. Ideally, you want to create an allow-list of valid paths for where this redirect can go. It’s not actually an open redirect in the typical sense if you trust getBaseUrl().
Hi, unfortunately allow list will not be helpful to us in this case, since the url is actually internal url and we are not sending HTTP request to a different domain. If we will add every API path to allow list, the list will be way too big.
Regarding getBaseUrl(), yeah it uses a hard coded value along with a key which comes from a service. I believe nothing is actually dangerous, so I wonder if using encodeURI() on the getBaseUrl() will address the issue.
Hi @OLdev (Community Member) - Using encodeURI() on the output of getBaseUrl() can help ensure that the URL is properly formatted and that special characters are encoded, which is a good practice to prevent issues related to malformed URLs. However, it does not directly address security concerns such as injection attacks or unauthorized access.
@SamHouston (Veracode)
I understand, though there is actually no security flaw as all the keys come directly in the view model which is generated on the server, there is no user input in these parameters.
With this being said, do you think creating a dedicated function to validate the URLs and/or the keys such as model.editItemModel.key will make security scan come back clean? I am not sure encodeURI() will make Veracode happy either, seems it sometimes does and sometimes does not. If nothing works, the only last resort we have is to change the API to not accept dynamic key/id as parameter, but this will require changes to almost 80 API controller code which we do not want to unless there is no other way.
Unfortunately we're beyond my personal technical expertise @OLdev (Community Member) and I think it may be quicker to schedule a 'Scan Results' consultation call with our team: https://docs.veracode.com/r/t_schedule_consultation