|
|||||||||||
|
RE: Fail Open Authentication and Parameter Injection
From: Ramirez, Manuel N (CORP, DDEMESIS) <Manuel.Ramirez(at)ddemesis.ge.com>
Date: Tue Mar 25 2003 - 17:09:26 EST
As you know the application is the first point of contact with the end users and it's amazing to see how programmers of important companies forget to remove very sensitive information from within the source code, unauthorized connections to personal devices, bad words/information about the company, personal information, deprecated methods or functions with regards to the programming language, fixed connections to databases, LDAP servers, etc. that can be seen when decompiling binary files, extra functionality than only is activated when the programmer enters "certain" information, etc, etc. It's really amazing what you can find when reviewing the applications' source code line by line. I think all depends on the security needs every company has. To tell you the true, I prefer to expect the unexpected and be paranoid, that way I have sweet dreams.
Regards,
-----Original Message-----
Mads wrote:
I don't understand why people think code reviews are so time consuming and expensive. Whether you're pentesting or code reviewing, the goal is to find security holes in the software as quickly as possible. Yes, you can "complete" a penetration test in a short amount of time. But what did you really learn? That some (very) small subset of the possible attacks either works or doesn't work? I'm convinced that reviewing/searching/scanning the *code* is far more cost-effective than external scanning or penetration testing. You can complete a code review quickly too. You keep the standard short and don't search too hard. In the end, I believe you'll find more of the most important security holes faster by looking at the code. Imagine that you need to verify that an application implements a business rule without a security flaw. No matter what, you have to figure out how it 'ought' to work. Once you've done that, how are you going to verify it? If you choose to pentest, someone will bang on the site from the outside and attempt to make it malfunction (they also have to detect that it broke, which ain't trivial). If you choose to review the code, you can identify where the rule is implemented, analyze the code, and make findings. I'll put my money into code review every time. --Jeff
Jeff Williams
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:49 EDT |
||||||||||
|
|||||||||||