I asked my penetration tester to prove the vulnerabilities with an exploit. But he says that isn't always necessary. Huh?
The penetration tester is probably right. There are several cases when it's enough to find evidence of a hole, and not go all the way to construct an exploit.
A penetration tester works against time. The more time he has to find holes, the deeper he can go. In many cases, when he finds a hole, it takes just a few more minutes to construct an exploit. But sometimes, constructing the exploit could take hours, as he has to make several guesses and refine the inputs. That's when the pen tester might chose to skip the exploit, when he's certain that the vulnerability exists.
Here's an example. When an application throws an ODBC error message for a single quote, it means the app is vulnerable to SQL Injection. Usually, it's easy to construct the exploit. At times, the pen tester will have to enumerate the database to construct a meaningful exploit. [See David Litchfield's paper "Web Application Disassembly with ODBC Error Messages" for details.] It might take a few hours. But that ODBC error message is evidence that the app is vulnerable to SQL Injection, that the code needs to be fixed.
Since most penetration tests have a fixed deadline, the time taken to construct an exploit is time taken away from finding holes. It's best for the customer to let the pen tester move on and find more holes, instead of investing more time in refining the attack.
If you suspect that the hole is really not exploitable, it's best to ask the penetration tester how he would construct an exploit. Can he point you to a good reference paper that shows how the exploit can be constructed if there's enough time? Most good penetration testers will oblige you happily.