[This was originally published on the OSVDB blog.]
PoC aka ‘Proof of Concept’. Please, stop and read those words.. actually think about what it means. The term was originally used to label code that demonstrated that a concept or idea was actually valid. ResearcherX would say that SoftwareY contained an exploitable overflow in FunctionZ. Since code can be tricky and input sanitized in a number of places, the researcher would write up exploit code that demonstrated and proved (the ‘proof’ in PoC) his concept was actually valid. This was working code that at least demonstrated a segfault, denial of service, or actually run an arbitrary (even harmless) command.
These days, PoC is a stupid catch phrase used to label any URL that supposedly demonstrates an exploit. Researcher1 finds a cross-site scripting vulnerability in SoftwareY and releases the following PoC:
That does not prove your concept. That does not prove there is a vulnerability. That does not necessarily let anyone else figure out how to exploit it short of full source code analysis. Yes, most XSS vulnerabilities are trivial to reproduce, especially with a cross site scripting cheat sheet out there. However, some XSS vulnerabilities may take some tricky encoding, restrict specific types of characters, or otherwise make exploitation difficult. Assuming that 99% of the XSS vulnerabilities disclosed are trivial to replicate, i’ll concede the above as a proof of concept. That said, the next time you find yourself typing this:
Please, don’t bother. Just because you pasted a ‘ character into the application and saw some pretty SQL error syntax doesn’t mean it is vulnerable to SQL injection. If you are going to use “PoC” anywhere in your “advisory”, prove your claim it is vulnerable. With the amount of vendor disputed vulnerabilities, it is the least you can do if you want anyone to take you seriously.