Ask HN: How do security researchers know where to look for vulnerabilites?

Even nowadays, I regularly see people leave their systems open to these super basic input validation vulnerabilities because they only think about doing things right on the surface area, but then they'll have some batch process that analyses log files as a one-off script that is vulnerable if the user has a malicious http header or something like that.

Another way would be to try and think how a particular thing was written and figure out ways you can break it. I found plenty of buffer overflow vulns in custom TCP servers this way, but you can also find less serious things that let you do things you're not supposed to.

For example, an ecommerce business that would let you add an optional service charge allowed negative numbers (to deduct money from the order).

Another online shop had test item ids with negative prices in the database.

Am I wrong? I'm not in the field, so I don't really know. I have lots of questions. Is it common for security consultancies to do only white box reviews or this wouldn't be a good decision business-wise? Is it common to charge for fixes to found vulnerabilities during an audit? What if the flaw is in open source library?

It is really a hard question, because it depends on several variables. I would say that the most important is the information gathering, if you would like to find a vulnerability in a system. There are several cases when you know that a vulnerability is present just by checking the version numbers. If you would like to find vulnerabilities in bigger systems, you should always search for older unmanaged functions that might be present. This is how a security researcher managed to find a critical vulnerability in a Google service that was used by probably nobody. If I am given the task to search for vulnerabilities in a standalone system, I always search for the functions that are not crucial for the system to work, because they tend to be less tested. If you have the possibility to upload files, then you could find a vulnerability with almost 100 percent certainty. So I would recommend you to spend a significant amount of time testing it. An other good indicator for potential vulnerabilities is when the user input is reflected in any manner. If you have access to the list of the used components, always check, if they have any known vulnerabilities this could be a really handful input, if the vulnerable features of that component are used by the system. If you can turn on options that make the system act in a different way, then you should always test them, because most of the automated scanners are going to miss those vulnerabilities that are only present in certain cases.

One of the best heuristics I had when approaching a system for the first time was to start poking at non-core features that were probably bolted on late. Things like management portals whether web or console, user customization settings, anywhere arbitrary files can be fed into the system. Those areas usually very fruitful and what I learned there helped understand and contextualize later research and discoveries in the core components.

As for charging, I've never been paid based on findings, but based on time. If they fix while I'm testing that is great work by their team, but I'd prefer a stable test env so it's a bit annoying.

Libraries can be an interesting area, I focus my testing on code the client controls and only note known vulns in libraries they use. I have found issues in libraries before and we report it to the client, and work with them to disclose to the vendor if they want.