1
votes

I'm discovering ZAP and its Active Scanner. I've tried to perform an Active Scanning of a variant of the vulnerable BodgeIT Store. In the basket.jsp page, the backend code looks like this:

stmt = conn.prepareStatement("INSERT INTO BASKETCONTENTS (BasketID, ProductID, Quantity, PriceToPay) VALUES (" + basketId + ", " + productId + ", " + Integer.parseInt(quantity) + ", " + price + ")"); // add it in the basket in the DB

The quantity variable is supposed to be an integer, whom value is gotten from the client request, as a POST parameter.

ZAP discovered that, when providing a non numerical value, the backend returns an error 500 and closes the connection:

enter image description here

enter image description here

Problem is, the backend is written in Java which has bound checking mechanism, making it impossible for a developer to introduce Buffer Overflow vulnerabilities (with the language itself).

So, why does ZAP think there's a buffer overflow, just seeing this "error 500" + "connection closed"?

Edit: I've checked the scan rule for Buffer Overflow and found this : https://github.com/zaproxy/zap-extensions/blob/master/src/org/zaproxy/zap/extension/ascanrules/BufferOverflow.java#L119

Does ZAP report Buffer Overflow each time it gets an internal server error?

1

1 Answers

3
votes

Some vulnerabilities are difficult to detect with absolute certainty. In this case ZAP submitted an unusually large value and the application returned an error.

As stated in the 'Other info' this is potentially a buffer overflow. Its up to you to determine if it is or now. You've determined that it isnt, but you also might want to get the app changed so that it doesnt return a 500 in these cases.