Guide to Web Application Penetration Testing

Apr 12 2017

Are you exposing your website and business to a security breach?

A lot of businesses take security for granted. Just because a particular industry or business isn’t a popular target doesn’t mean no one wants to break into their system. Hackers use very sophisticated methods and you need to take every precaution available to keep them from infiltrating your system.

Websites get attacked for a number of reasons. When hackers find out about your vulnerabilities, they can and will exploit your system for their purpose, including:

• Exfiltration of databases
• Modification of data (integrity)
• Hosting of phishing sites
• Botnet slave
• Storing of illegally obtained data
• Serving files that are of illegal nature
• Disseminating malware

Guide to Web Application Penetration Testing

But how can you tell if your website is vulnerable to hackers? The only reliable way is through web application penetration testing.

What is web application penetration testing?

It is the process of breaking into a web application through various means of attacks or threats until its weaknesses are uncovered and solutions are found. With web application penetration testing, you can discover and patch critical security vulnerabilities in your web application before they are exploited by an attacker.

Unlike a vulnerability scan or compliance audit, web application penetration testing has a few significant characteristics that set it apart:

• It goes a step further than a mere vulnerability scan by actively attacking security flaws,  intelligently chaining vulnerabilities, and dynamically analysing the existence of real danger and threats against the organisation’s internal and sensitive data; client-side devices; and other attacks possible through the existence of vulnerabilities in the web application.
• Although automated tools are used, the process focuses on the human factor of how hackers analyse and synthesise information, and what motivates them.
• It answers the question, “How effective do my web application security defences measure up against an active, skilled and determined, persistent human attack?”
• Commonly discovered vulnerabilities include SQL Injection which can be used to compromise a database, and Cross Site Scripting (XSS) which is targeted at the clients visiting the target website.

Isn’t compliance assessment enough? Why is web application penetration testing necessary?

Being 100% compliant does not ensure safety for your organisation. It can still leave your website with plenty of security gaps that hackers can identify and infiltrate. To fill those gaps, web application penetration testing needs to be done.

If your organisation has invested a lot in web security, then web application penetration testing will reveal how well or how poorly your security controls, configuration, application development and secure coding processes are followed and implemented according to policy.

The test is a series of deliberate attacks launched against the same target, seeking to uncover the weaknesses in your application’s chain of defenses through exploitation. Success is often the result of incorporating data from different parts of the web application and synthesising this into an effective exploitation technique.

Web application penetration testing best practices

These guidelines are meant for your protection since a penetration test involves processes that are designed to simulate a full blown attack on the target website. So here are the best practices for web application penetration testing:

• Written permission to conduct the test along with details of the scope, the manner and time it will be conducted must be obtained.
• Make sure all stakeholders understand what to expect during the course of the test.
• Keep notes and screenshots to help write detailed reports regarding discovered vulnerabilities and their solutions with reference to risk.
• Create good rapport with various divisions of the organisation to avoid miscommunication especially during critical testing periods.
• Makes sure you have agreed and obtained the right internal contacts to support the web application penetration test if required.

For more detailed info read Definitive Guide to Penetration Testing

Tips for successful web application penetration testing

Just as important as possessing the right tools and skills is knowing why and who will conduct the web application penetration test. These tips will help to keep everyone on your team on track and focused on your goals. You’ll learn how to get the most out of your own team and hired experts as they work together toward improving your organisational security.

• Identify your objectives

Defining scope is one of the most important parts of the engagement to get right. The agreed scope determines exactly what is to be tested and what is not. The scope must be aligned to the business requirements of the web application penetration test.

The main goal of web application penetration testing is to learn how and to what extent discovered vulnerabilities could be exploited by a hacker and thus put your business at risk. The outcome of a web application penetration test will also focus and what countermeasures may be put in place to either prevent or reduce the risk of a threat, or remediate a vulnerability chain completely.

It’s important to note that if a certain loophole is found to be no threat at all, then attempting to exploit it any may turn out to be a waste of time, money and resources. This is why managing time wisely during a penetration test is crucial.

Don’t use up all of the time allocated to a penetration test attempting to exploit a red herring and then missing the juicy stuff you could have discovered in that time.. Go for the low hanging fruit first.

A web application penetration test is also a good time to test current controls and countermeasures provided by vendor security products to see whether they are still effective or whether to consider looking elsewhere for more suitable vendor products and solutions such as; web application firewalls, load balancers and hosting providers.

Also consider that compliance standards such as PCI requires that web application penetration testing is performed at least annually or whenever there is a significant change to the web application.

• Test relevant components

Don’t test components outside of the scope as defined in the penetration testing pre-engagement process. Make sure that you are keeping within the agreed scope and be sure to follow the rules of engagement as agreed with the client.

The time allocated to performing a penetration test is limited, so be sure that you are utilising time wisely by allocating portions of the allotted time to specific parts of the web application based on relevance. Do this in such a way that you don’t use up all of your time testing only some components and missing other important components.

One way to manage what components are tested is to follow an industry standard web application penetration testing framework such as OWASP.

It is also worth reviewing the results of any previous penetration test to understand what its weaknesses have been in the past and check if they are still present.

• Severity of risk dictates remediation priority

As mentioned previously, not all vulnerabilities are to be treated the same way. The degree of attention required for a particular vulnerability depends entirely on the risk appetite of the target organisation and the amount of risk that the risk owner is willing to accept on a given system.

Following is a good rule of thumb for remediation priority of discovered vulnerabilities:

• Critical-risk vulnerabilities – Urgent attention required. Remediate as soon as possible
• High-risk vulnerabilities – Remediate within 1 month of reported discovery
• Medium-risk security flaws – Remediate within 2 months of reported discovery
• Low-risk vulnerabilities – No deadline. Remediate only once all other higher risks have been addressed.

Understanding the risk rating means you can determine which vulnerabilities to remediate first and in what order. Critical risk vulnerabilities should be addressed ASAP, whilst some low risk vulnerabilities may be accepted by the business and not addressed at all.

• Build hacker personas

Exploitative penetration testing must be carried out realistically to yield accurate results. As a pen tester, you need to put yourself in the shoes of a hacker persona. That way you begin to think and act like a real hacker, armed with a particular set of skills, a goal and a motive.

Is your persona a company insider with access to critical data? Or, are they simply outsiders who know nothing about your organisation except your IP address or perhaps a few pieces of random information?

Motive is an important element in building hacker personas. This includes;

• Money or business advantage – they may be after your intellectual property or items such as credit card numbers that they can turn into cash.
• Cultural, political or religious ideology – they may want you to bend to their cause or stop operations altogether. This is often referred to as hacktivism
• Revenge by an ex-employee or ex-business partner – you may have angered someone you formerly were in close association with. Disgruntled employees commonly fall within this category.
• Some hackers are also motivated by peer recognition. They may deface a website in order to impress their peers and become members or hacker groups.
• The accidental hacker. This is normally the innocent employee who unknowingly or inadvertently compromises and gains elevated access to a system due to, for example, poorly configured security controls, or lack of security policy knowledge.

Rank personas according to which types the company is most concerned about. Profiling hackers this way helps to narrow your focus and equips you to be better prepared for a real attack.

• Consult with relevant stakeholders

In real life situations, it’s not always obvious which data or applications are at risk and to what extent. For this reason a pen tester should spend time consulting with with a wide array of stakeholders such as business owners, developers, engineers or other relevant stakeholders during the pre-engagement process. These people will be able to inform you on details of the following:

• The logic behind the application.
• The type of risk or level of threat the business is exposed to.
• Where critical data is stored and how it is processed.
• Which application interfaces with which type of data.
• Which applications to keep continuously running.
• The worst case scenario happen should a successful attack occur.

• Research exploits

Enumerate and gather as much information about the web application as you can. The more you know about your target the better chance you have of defeating its defences. This can be achieved initially by downloading the entire website and, and analysing its source contents. Spidering is a good way of achieving this using tools like Burp Suite and OWASP Zap proxy.

Once you have gathered as much information as possible, and have mapped out all of the applications input vectors, you can then begin to research exploits based on this. All input vectors should be tested thoroughly for things like SQL injection and XSS using fuzzers. Exploits which are identified as relevant should be downloaded and tested on the target system.

You will often find yourself writing your own exploits in bash shell or Python script to overcome the limitations of exploit frameworks. Writing your own exploits will enable you to launch targeted and customized attacks during a web application penetration test. Each layer of security that you’ve disarmed may help unravel succeeding layers of defenses. In some cases you will have to chain multiple vulnerabilities to obtain access, download a database, or exfiltrate other sensitive information.

• Set testing boundaries clearly

One thing that must be clear to everyone is that web application penetration testing is not an actual attack but a mere simulation. For this reason boundaries must be set as to…

• What is permissible
• What cannot be done (such as compromising a client’s device)
• Who will perform the tests and when
• Whom to send all communications and reports

This is true whether you are conducting it in-house or hiring an external team to do the testing for you.

In most cases a company would initially conduct white box testing where the process and results are open for everyone to see. Here, transparency is important so that everyone is aware what the other is doing and why. This type of test also saves a lot of time for a penetration tester and enables them to spend more time testing things with the foreknowledge of how it works and what frameworks it may be using.

Later on the company might want to conduct a more covert procedure where the attacks are done without any foreknowledge of the web application. This is called black box testing. The penetration tester is not given any information about the web application or its security components prior to commencing the penetration test – just as if he/she were a real life hacker.

Black box testing may also be performed when the application source code is not available.

• Never lose sight of your goal

A real attacker would leverage all avenues of attack to unravel your IT infrastructure and get to the information they want. So should you.

The idea is to relentlessly exploit various attack angles, either individually or in unison with other tests until you’ve obtained the data you seek. All within budgeted time constraints.

For example; you don’t just think “I’ll break into the system using only “method A.” …  What about “method B”? or “C”? or whatever else is available to you? All possibilities of infiltrating the system must be attempted in order to thoroughly test the necessary components of the web application for security flaws. It makes no sense limiting your tests when real-world hackers are taking advantage of any number of paths available to them.

Be creative. Think outside the box. But as mentioned before, don’t get tunnel visioned and become stuck on a red herring. It’s also a good idea to take a break for 10 minutes here and there during a penetration test too. It’s amazing how much your mind will reward you for giving it a rest.

• Provide detailed and actionable reporting

Once relevant vulnerabilities have been fully tested and exploited, the next step is to provide actionable reporting to help management take actions to enhance organisational security.

This report must be detailed enough to thoroughly explain the threat, vulnerability, and risk, including detailed step by step instructions with screenshots showing exactly how you achieved the compromise.

• Decide between in-house and external testers

An organisation has a lot to benefit from leveraging its in-house staff if it has the skillset. Aside from saving on costs and the fact that they already are familiar with your system, an in-house team makes it very convenient to do web application penetration testing regularly or whenever the organisation sees the need during the course of the application development process.

It is also recommended that specialised web application penetration testing professionals are hired externally to provide more expertise and a more objective point of view. This also ensures organisational independence for the penetration test, which is not only good practice in order to avoid a conflict of interest, but a requirement by PCI compliance.

Organisational independence does not always mean using external consultants however. It may be a separate in-house team which is organisationally independent. However it is considered better to hire penetration testing consultants externally from companies whose core competency is penetration testing. The expertise, skill set, and quality of the outcome is generally greater when it is the core competency of the company hired. This reduces the costs internally too.

Conclusion

Web application penetration testing is a necessary investment for any organisational web application or company that values its reputation or existence. As the threat landscape changes over time, web security has to be understood as an ongoing process. The moment you become complacent, and view web application security as a once off, your web applications will become vulnerable to hacking attacks again.

Although web app pen test is aided by a set of tools and methodologies, a competent pen tester does not rely on them alone, but uses creativity, logic and experience in finding problems with web applications.

This is where Core Sentinel a penetration testing company is able to assist. We stay one step ahead of the bad guys by constantly researching the latest web application vulnerabilities. With many years of experience, our OSCE-certified penetration testers will identify the flaws in your web application and work with you to make sure they are fixed to ensure a successful secure lifecycle of your web application.

Other articles you might like:

Introduction to Mobile Application Penetration Testing

Black Box vs. White Box Testing: Key Differences Every Organisation Should Know

Definitive Guide to Penetration Testing