I ran OWASP ZAP and the tool threw up a high vulnerability for possible SQL injection issue. Although we know for sure we do not use any sql databases as part of our application stack, I poked around and have have a few questions.
The payload that detected this “vulnerability” was as below:
I am able to go ahead and make any sort of manipulations to what comes after the cb= part and I still get the same response. I believe this is what has tricked the tool to flag this as vulnerability - where in it injected a -- with some characters and still managed to get a proper response.
How can I make sure that changing the URL parameter to something that does not exist, returns a 404 or a forbidden message?
Along the same lines, when I try to do a GET (or simply a browser call) for:
I get the auto generated JS file for accounts-base.js.
If I manipulate the hash= value, I still get the same accounts-base.js file rendered. Shouldn’t it render a 404? If not, what role does the hash play? I feel that the vulnerability testing tool is flagging such URL based manipulations wrongly and ascertaining that there is some vulnerability with the application.
Summarizing my question:
How do I make sure that manipulating the URL gives me a 404 or at the very least, forbidden message instead of always giving a 200:ok in a meteor application?
URL parameters can be attached to any URL, including this very forum post, e.g. https://forums.meteor.com/t/url-manipulation-always-returns-a-200-ok-in-meteor-getting-flagged-as-violation-in-owasp-zap/54773?asdf=asdfjkasdfj
What determines whether they are security vulnerabilities is how the app interacts with those URL params.
While it is easy for us as a developer to mark this as a false positive, it is somewhat difficult to pass this on to a client who is sometimes rigid when it comes to what the tool spits out.
For us, the tool is running when no user is logged in. Which is why it only has issues with the client side JS files instead of actual valid URL (like the blog post example you’ve made)
Now my question is, is there a way to completely do away the ?hash=some_hash that gets appended to every js file that gets loaded on the client side? I believe this happens on when meteor build is run but I don’t see an option to manipulate the generation of hash values.
OWASP ZAP is more traditionally used for LAMP-stack apps. In ZAP, you can set these findings as a “False Positive” in the “Findings” tab. If you would like to pentest your app, Burp Suite is a much better option with websocket support.
You can add URL parameters to any URL. I do not believe it is possible to prevent this, nor worth the effort from a development side.
I would also caution your client on relying on automated testing results as determining something as ‘secure’.
