During the development life cycle of a web application many things need to be tested, but what does testing actually mean? The Merriam-Webster Dictionary describes testis as:
- To put to test of proof.
- To undergo a test
- To be assigned a standing or evaluation based on tests.
For the purposes of this document testing is a process of comparing the state of a system or application against a set of criteria. In the security industry people frequently test against a set of mental criteria that are neither well-defined nor complete. As a result of this, many outsiders regard security testing as a black art. the aim of this document is to change that perception and to make it easier for people without in-depth security knowledge to make a difference in testing.
There is No Silver Bullet
While it is tempting to think that a security scanner or application firewall will provide many defenses against attack or identify a multitude of problems, in reality there is no silver bullet to the problem of insecure software. Application security assessment software, while useful as a first pass to find low-handing fruit, is generally immature and ineffective at in-depth assessments or providing adequate test coverage. Remember that security is a process and not a product
Think Strategically, Not Tactically
Over the last few years, security professionals have come to realize the fallacy of the patch-and-penetrate model that was pervasive in information security during the 1990's. the patch-and-penetrate model involves fixing a reported bug, but without proper investigation of the root cause. this model is usually associated with the window of vulnerability shown in the figure below. The evolution of vulnerabilities in common software used worldwide has shown the ineffectiveness of this model.
Vulnerability studies have shown that with the reaction time of attackers worldwide, the typical window of vulnerability does not provide enough time for patch installation, since the time between a vulnerability being uncovered and an automated attack against it being developed and released in decreasing every year.
Test Early and Test Often
When a bug is detected early within the Software Development Life Cycle it can be addressed faster and at a lower cost. A security bug is no different from a functional or performance-based bug in this regard. A key step in making this possible is to educate the development and AQ teams about common security issues and the ways to detect and prevent them. Although new libraries, tools, or languages can help design better programs (with fewer security bugs), new threats arise constantly and developers must be aware of the threats that affect the software they are developing. EDucation in security testing also helps developers acquire the appropriate mindset tio test an application from an attacker's perspective. This allows each organization to consider security issues as part of their existing responsibilities.
Understand the scope of Security
It is important to know how much security a given project will require. The information and assets that are to be protected should be given a classification that states how they are to be handled (e.g., confidential, secret, top secret). Discussions should occur with legal council to ensure that any specific security requirements will be met.
Develop the Right Mindset
Successfully testing an application for security vulnerabilities requires thinking "outside of the box." Normal use cases will test the normal behavior of the application when a user is using it in the manner that is expected. Good SEcurity testing requires going beyond what is expected and thinking like an attacker who is trying to break the application. Creative thinking can help to determine what unexpected data may cause an application to fail in an insecure manner. It can also help find what assumptions made by web developers are not always true and how they can be subverted. One of the reasons shy automated tools are actually bad at automatically testing for vulnerabilities is that this creative thinking must be done on a case-by-case basis as most web applications are being developed in a unique way (even when using common frameworks)
Understand the Subject
One of the first major initiatives in any good security program should be to require accurate documentation of the application. the architecture, data-flow diagrams, use cases, etc, should be written in formal documents and mde available for review. The technical specification and application documents should include information that lists not only the desired use cases, but also any specifically disallowed use case. Finlay it is good to have at least a basic security infrastructure that allows the monitoring and trending of attacks against and organization's applications and network (e.g., IDS systems)
The Devil is in the Details
It is critical not to perform a superficial security review of an application and consider it complete. This will instill a false sense of confidence that can be as dangerous as not having done a security review in the first place. It is vital to carefully review the findings and weed out any false positive that may remain in the report. Reporting and incorrect security finding can often undermine the valid message of the rest of security report. Care should be taken to verify that every possible section of application logic has been tested, and that every use case scenario was exported for possible vulnerabilities.
Use Source Code When Available
While black box penetration test results can be impressive and useful to demonstrate how vulnerabilities are exposed in a production environment, they are not the most effective or efficient way to secure an application. it is difficult for dynamic testing to test the entire code base, particularly if many nested conditional statements exists. if the source code for the application is available, it should be given to the security staff to assist them while performing their review. It is possible to discover vulnerabilities when the application source that would be missed during a black box engagement.
An important part of a good security program is the ability to determine if things are getting better. it is important to track the results of testing engagements, and develop metrics that will reveal the application security trends within the organization.
Good metrics will show:
- If more education and training are required;
- If there is a particular security mechanism that is not clearly understood by the development team;
- If the total number of security related problems being found each month is going down
Document the Test Results
To conclude the testing process, it is important to produce a formal record of what testing actions were taken, by whom, when they were performed, and details of the test findings, It is wise to agree on an acceptable format for th e report which is useful to all concerned parties, which may include developers, project management, business owners, IT department, audit, and compliance.
The report should be clear to the business owner in identifying where material risks exist and sufficient to get their backing for subsequent mitigation actions. The report should also be clear to the developer in pin-pointing the exact function that is affected by the vulnerability and associated recommendations for resolving issues in a language that the developer will understand. The report should also allow another security tester to reproduce the results. Writing the report should not be overly burdensome on the security tester themselves. Security testers are not generally renowned for their creative writing skills and agreeing on a complex report can lead to instances where test results do not get properly documented. Using a security test report template can save time and ensure that results are documented accurately and consistently, and are in format that is suitable for the audience.
No system is 100% immune from penetration, For that purpose the pentesters always search and investigate to find solution and patches to make the digital world more secure.