All Articles

Safe Penetration Testing – 3 Myths and the Facts behind them

Penetration testing vendors will often make promises and assurances that they can test your Web Applications safely and comprehensively in your production environment. So when performing Penetration Testing of a Web Application that is hosted in a Production Environment you need to consider the following myths and facts which can directly or indirectly end up causing you to do to yourself what you are trying to prevent hackers from doing to you in the first place.

(Read more:  Under the hood of Top 4 BYOD Security Technologies: Pros & Cons)

Myth 1 – Vendors promise that testing on your production environment is perfectly safe and that penetration testing will not cause any disruption to your end users.

The Facts

• During testing, the application or its host may suffer degradation in performance if it is not designed, configured and implemented adequately. This will result in end users of the application suffering a diminished user experience or even a Denial of Service situation under the wrong circumstances. This is quite often out of the hands of the testing vendor and can be neither predicted nor fully avoided if any decent level of penetration testing is to be done.

• Safe testing is usually limited to reducing the number of threads and requests made by any scanners used and will make testing take much longer than usually quoted by your testing vendor. Another way vendors claim to do safe testing is by disabling automated form fills by the scanner which results in substantially lower test coverage.

• During our testing, we have encountered quite a few cases where the target application suffered performance issues due to bad design even though automated form fill was disabled and the scan was limited to only one thread with request throttling. In one case, we found that the application was performing detailed logging which was disk intensive. The application was normally very sparsely used, but during testing, the logs quickly filled up and caused a Denial of Service.

(Read more: CISO Mantra on data sanitization)

Myth 2 – Your penetration testing vendor may tell you that your data is safe for full blown penetration testing on a production system.

The Facts

• SQL injection, Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) in some cases can only be confirmed by actually attempting to insert data into the Web Applications underlying database particularly where any forms are present on the URL where the test case is crafted to either perform a create or update function.

• Also, any application function that is designed to perform any data insertion,      updating or deletion from the database within the confines of the expected design may be executed during testing for exploits resulting in data corruption which may be undesirable. Again safe testing will mean that a      lot of test cases won’t be performed and hence vulnerabilities will be missed.

(Read more:  BYOD Security: From Defining the Requirements to Choosing a Vendor)

Myth 3 – There will be no disruption to your business during penetration testing.

The Facts

• If the target application to be scanned is linked to other servers and applications that are part of a business process chain, then they are likely to be affected. The effects could range from flooding the system with dummy emails, orders, info request forms etc. which can all potentially disrupt the business if not handled carefully.

• In one case, the target application was generating multiple synchronous back end requests for each request sent to it. This led to an amplification of requests which quickly overloaded the servers and led to a Denial of      Service.  Safe testing may be done by disabling form filling which will severely limit the coverage of the testing performed.

(Watch more : Top Myths of IPV-6 Security)

Advantages of Performing Pen Testing on a Staging Environment

What seems obvious from all the above is that wherever possible you should try to perform penetration testing on a staging or testing deployment. This has two main advantages;

• First,  you don’t impact your business directly in any way.

• Second and more importantly you do not put constraints on your Penetration Testing vendor that would not apply to a hacker. Once your testing regime is mature and you have fixed all the vulnerabilities on the staging environment you can consider doing a full Penetration Testing on your Production Environment as a final assurance check.

Adapted from the original blog written on Iviz Security website.