Application Security Testing

Frequently Asked Questions - Application Security Testing

• How do I prepare for a web application penetration test?

  Web applications would only require the website URL and the user accounts to access the website. We always recommend testing against a non-production environment to ensure availability is maintained for your production website. No denial of service attacks are ever conducted but each application is built differently resulting in different responses to attacks. If production is your only environment, we take the proper precautions and work with your team to reduce the likelihood of any downtime.

• Why perform security testing on web applications?

  Nearly every organization has an online footprint which often includes a web application, data breaches and hacks are all over the news each and every week, when it comes down to business securing your online presence means protecting your brand. Web application security testing is performed to help identify security weakness, ideally before an attacker can, and then fix the weaknesses to prevent an attacker from doing harm. Read more on 5 Reasons Why Hackers Target Your Website here.

• What should I test in a web application?

  While ideally every aspect of a web application should be tested, realistically time and budget are two important factors. The web application itself needs to be tested for common vulnerabilities such SQL injection, cross-site scripting (XSS) items in the OWASP Top 10, the servers and infrastructure hosting the web application also need to be tested as the application is only as secure as the server(s) it is hosted on. Authentication and session management, payment processing and business logic are all critical areas that should be tested.

• Why do you need credentials to the web application? Why can’t you just “hack in?”

  Assessing a web application's security involves testing the entire features and capabilities, not just if a hacker can access the application without authorization. While it is rare or nearly impossible to find a perfectly secure web application, there is no guarantee that an application’s authentication process can be hacked, or the methods might be out of the scope of the test, such as phishing users and/or developers. As such, providing testers with credentials ensure the application can be tested in its entirety.

• Why do you need so many accounts?

  Often web applications will have more than one type of users such as a read-only or regular user and a super-user or admin. Typically a minimum of two sets of credentials for each user role is provided for testing. This allows the tester to accurately test that the vertical permission controls (e.g. preventing read up’s) and horizontal permissions controls (e.g. impersonating other read-only users) are functioning as intended.

• Why do you recommend whitelisting on Web Application Firewalls and similar countermeasures?

  While web application firewalls (WAF), rate-limiting, DDOS prevention and countermeasures, when properly implemented, configured and tuned, are great solutions in preventing or increasing the difficulty of attackers exploiting vulnerabilities in web applications they do not fix the underlying vulnerabilities. Whitelisting testing activities allow thorough and unimpeded assessment of the application itself in order to identify underlying vulnerabilities. Once vulnerabilities have been identified they can be addressed and remediated.

• Why does testing take so long?

  Web applications come in all shapes, sizes with different intended purposes and technologies they are built upon. As such, applications with large amounts of functionality, and multiple different user roles/permissions can generally take a greater amount of time to test than small applications with limited functionality and minimal user roles. Certain web application technologies can require different tool sets, and research in order to effectively evaluate. Some vendors take less time to perform a test because they run an automated tool and pass the generated report off as a penetration test, however, this is far from a proper penetration test and is sure to miss vulnerabilities. For more on automated vs manual testing read here, and for more on choosing the right pentesters click here.

• What can our developers and admins do to help streamline testing?

  The majority of penetration tests we perform against web applications lean more towards a white-box test than a black-box test as developers and admins can often help answers about the application that arise during testing such as how certain features works, and help to unlock accounts if they get locked. This can lead to more effective and efficient testing. Some of the best admins and developers we work with have provided snippets of source code where needed and even script tasks such as unlocking the test accounts every hour in order to prevent testers from being locked out, which often happens for one reason or another.

• How do you write effective test cases for Web applications?

  Web applications vary widely in their intended usage and service offering, we often develop key test cases working alongside our clients, often our clients draw attention to key test cases they would like to be tested such as altering the check-out price on goods on an e-commerce site, viewing bank statements and records that belong to other users, or making sure low privilege roles cannot perform admin functions such as modifying or resetting user accounts. In addition to key test cases clients bring up, Packetlabs relies on years of experience and expertise to develop thorough test cases that cannot be tested with automated tools, and that is often overlooked by clients or other penetration testers.

• What types of results can I expect?

  Packetlabs creates a professional, custom-tailored report for each client with the unique results of the web application assessment. The report contains an executive summary with a high-level overview of the critical issues identified, the methodologies we used to conduct the test, the scope of the assessment, a technical finding section that describes each of the findings, with steps to reproduce, evidence where required, and steps on how to remediate the vulnerability. Finally, the report is concluded with a unique list of strategic and tactical security recommendations, and appendices are included when necessary.

• How can I verify the vulnerabilities are fixed?

  Most penetration tests have retest agreements in which time is dedicated specifically for testing if vulnerabilities identified during testing have been remediated. Before finalizing an agreement to conduct a web application penetration test, retesting will be discussed to figure out how much time can be allotted to retesting, and when retesting may occur.