Getting a security code overview manually - what should I keep in mind?

Question

We have a PHP application that we want to get from an external security consultant, but I don’t understand how to do this.

We indicated what tests he should perform, and the first part of his report just indicates VERY standard "problems" when using eval (), fopen (), etc. under the heading 'Input validation problems.'

I saw all these problems myself when I ran the automated security code verification tool. I do not know if:

• That the problem is in my code and the guy did a good job, OR
• he just launches these automated tools and simply filters the output to remove noise and what it is!

Questions:

• What should I ask him to do?
• How can I cross check his work so that I know that he really does a good job?

Answer 1

It's hard to find someone who is really good at this business (the company I work with to keep the services of a leading British security company), and I not only found the things that they missed - I had to explain why this is a problem).

To answer your questions, the most important thing you can do is ask him to prove that your code is vulnerable by demonstrating an attack.

It got a lot easier work than anyone attacking your site - since you already provided the source code for it (I don’t suggest that a bad idea saves a lot of expensive chaos). I would recommend that you set a copy of your live system as the target for its attacks - in addition to protecting your system, if it succeeds, it should allow you to test the security monitoring that you already have to detect attacks.

The fact that he describes the use of eval (), fopen () as input vulnerabilities is extremely odd. If it were me, I would provide a set of classification criteria (XSS, CSRF, SQL injection, MITM code injections, data leakage, network / OS vulnerabilities), as well as determining the testing area before negotiating a contract - and classify them as potential attacks on code injection.

If you have already run automated checks against your system, then you have probably investigated and rejected potential problems - so why are you paying someone to tell you about this? I would provide a list with areas that you have already viewed.

I also want him to provide detailed information about what he studied, which did not detect the vulnerability.

He should also evaluate your code for potential impacts if the system is compromised (and how). for example, to store credit cards / passwords in a recoverable form - even if your site is currently 100% secure (which CANNOT be proven), what happens when an attacker manages to translate an SSH session? Is there a host-based IDS and deployment process that agrees changes?

If you have already agreed with him to provide checks, then a little later to change the terms of the contract, but you learned a lot before you go through the process again.

Answer 2

Well, not finding important security issues in your code should not be a bad job from the “security guy” part, but it can also mean good work from the “developer” side.

Typically, security problems arise due to incorrect or invalid verification of data inserted by users of the application. I find it more interesting to review the application from the end point of view of the user, possibly without access to the source code.

About cross-validation ... The difficult question is: do more tests and find nothing else that they have not yet found? No application is 100% protected; it is a matter of time and security.