Penetration test

Penetration Testing and Data Security

Penetration testing (often called a pen test)is conducted by a professional security expert who tries to launch attacks on a computer system. The expert looks for security weaknesses that a real hacker could use to access features and data the user cannot access.

Typically, penetration testing is done as a black box attack, where the security expert is not given access to the code or details of the server. Often, s/he is given a few user credentials to check if s/he can go beyond what these users are authorised to do. However, an alternative strategy is white box penetration testing, in which the hacker checks the configuration and the source code. The latter is commonly used for military or very high-security installations.

The goals of any penetration testing are:

  1. Determine the feasibility of any attack vectors as a mean of getting unauthorised or enhanced access to features or data
  2. Identify high-risk vulnerabilities from a combination of lower-risk vulnerabilities exploited in a particular sequence
  3. Identify vulnerabilities that may be difficult or impossible to detect with automated network or application vulnerability scanning software.
  4. Assess the magnitude of potential business and operational impacts of successful attacks.
  5. Test the ability of network defenders to detect and respond to attacks
  6. Provide evidence to support increased investments in security personnel and technology

Attack vectors / OWASP 10

OWASP is a non-profit security organisation which, from time to time, defines the most common attack vectors and what penetration testing can be done to reduce the risk of these vulnerabilities. The ten most common attack vectors are called OWASP-10, and the last list was defined in 2013

NoVulnerabilityDescription/Tests to be conducted
1InjectionInjection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without authorisation. Test for:

  • SQL Injection,
  • LDAP Injection,
  • ORM Injection,
  • XML Injection,
  • SSI Injection,
  • XPath Injection,
  • IMAP/SMTP Injection,
  • Code Injection,
  • Command Injection and
  • Buffer Overflow
2Broken authentication and session managementApplication functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens or to exploit other implementation flaws to assume other users’ identities. Test for:

  • Role Definitions,
  • User Registration Process,
  • Account Provisioning Process,
  • Account Enumeration and Guessable User Account,
  • Weak or unenforced username policy,
  • Credentials Transported over an Encrypted Channel, Testing for default credentials,
  • Weak lockout mechanism,
  • bypassing authentication schema,
  • remember password functionality,
  • Browser cache weakness,
  • Weak password policy,
  • Weak security question/answer,
  • weak password change or reset functionalities,
  • Weaker authentication in alternative channels,
  • bypassing authorisation schema,
  • Privilege Escalation,
  • Bypassing Session Management Schema,
  • Cookies attributes,
  • Session Fixation,
  • Exposed Session Variables,
  • Cross-Site Request Forgery (CSRF),
  • logout functionality,
  • Session Timeout,
  • Session puzzling
  • an unreasonably high number of transactions for a user profile
3Cross-site scriptingXSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface websites, or redirect the user to malicious sites. Test for:

  • Reflected Cross-Site Scripting
  • Stored Cross-Site Scripting
  • DOM-based Cross-Site Scripting
  • JavaScript Execution
  • HTML Injection
  • Cross-Site Flashing
4Insecure direct object referenceA direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Attorneys can manipulate these references to access unauthorised data without an access control check or other protection. Test for:

  • Directory traversal/file include
  • Insecure Direct Object References
  • Local File Inclusion Testing for Remote File Inclusion
5Wrong security configurationGood security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. Test for:

  • Fingerprint Web Server
  • Fingerprint Web Application Framework
  • Fingerprint Web Application
  • Network/Infrastructure Configuration
  • Application Platform Configuration
  • File Extensions Handling for Sensitive Information
  • Review Old, Backup and Un-referenced Files for Sensitive Information
  • Enumerate Infrastructure and Application Admin Interfaces
  • HTTP Methods
  • RIA cross-domain policy
  • Analysis of Error Codes
  • Analysis of Stack Traces
6Sensitive data exposureMany web applications do not adequately protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection, such as encryption at rest or in transit, and special precautions when exchanged with the browser. Test for:

  • Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
  • Padding Oracle (N/A for Microsoft environment)
  • Sensitive information sent via unencrypted channels Test HTTP Strict Transport Security.
  • Credentials Transported over an Encrypted Channel
7Missing function level access controlMost web applications verify function-level access rights before making that functionality visible in the UI. However, applications must perform the same access control checks on the server when each function is accessed. Attackers can forge requests to access functionality without proper authorisation if requests are not verified. Test for:

  • Directory traversal/file include
  • bypassing authorisation schema
  • bypassing authentication schema
8Cross-site request forgeryA CSRF attack forces a logged-on victim’s browser to send a forged HTTP request to a vulnerable web application, including the victim’s session cookie and any other automatically included authentication information. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. Test for:

  • Testing for Cross-Site Request Forgery (CSRF)
9Using components with known vulnerabilitiesComponents, such as libraries, frameworks, and other software modules, almost always run with full privileges. Such an attack can facilitate severe data loss or server takeover if a vulnerable component is exploited. Applications using components with known vulnerabilities may undermine application defences and enable a range of possible attacks and impacts. (Heartbleed and Shellshock are examples). Test for:

  • Enumerate Applications on a Web server
10Un-validated redirects and forwardsWeb applications frequently redirect and forward users to other pages and websites and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorised pages. Test for:

  • Client-Side URL Redirect

Our strategy

At Gislen Software, we use various means to reduce the risk of hacking in software development. Certain filters or specific methodologies can fully mitigate some risks. By keeping all the software updated, other risks can be mitigated. The significant remaining risks are when third-party components are used, which are vulnerable. Commonly used, well-known third-party components are often updated frequently, but less common ones may not be.

Indirect vulnerabilities

Sometimes, vulnerabilities may be indirect. I.e., the same web server, domain, or company runs some other insecure application. While it is impossible to hack the application directly from outside, it may be possible to hack another application and access the network where files are stored for the application in question. One example of this is a hacker story of a person who managed to hack Facebook (he did this to get a bounty from Facebook, so this is legal ethical hacking) –

Verifying and hardening applications ahead of penetration testing

Clients have often asked us to verify applications before penetration testing. We have mainly done this using white box verification against the list above. The advantage of preparing for a [black-box] pen test with a white-box test is that the white-box tester has an advantage by being able to check the code or server configuration for vulnerabilities. The [black-box] penetration tester does not have that advantage, and neither has a real hacker; hence, by having this advantage, we can often reduce the risk to a level where the risk is shallow. The penetration test only verifies that we have not missed anything.

However, since we often only have access to a test environment, there is always a risk that the actual server is vulnerable to setup or configuration. Unless we are given full access to the live server, it may be hard to secure the live environment fully.

Some types of risks are not application-based. Other infrastructure, such as firewalls, operating systems, web servers, etc., are also assessed during penetration testing. Hence, if we are asked to harden an application for a pen test, this may not be sufficient to ensure that penetration testing does not find any vulnerabilities since the infrastructure itself may be vulnerable. This may include risks of DDOS attacks.

Application firewalls

Some risks can also be mitigated by adding an application firewall (in particular injections), but many OWASP 10 risks can be mitigated.


This document has outlined how penetration testing is usually conducted, the main risks, which tools can be used, and how we at Gislen Software develop and help clients secure their software applications in a way that should prepare them for successful penetration testing.


The OWASP 10 table above is a compilation of the information on the following pages with some additional comments by us:

What tools are used for penetration testing?

Tests are often conducted with the help of specific security tools; Wikipedia lists several of these.

In addition to white-box testing ahead of penetration testing, we have sometimes used tools such as:

  • NMAP (free), which is used to find open ports
  • Nessus
  • Metasploit
  • Wireshark
  • OpenSSL
  • Cain & Abel—The URL for the tool is currently linked as insecure, and some virus scanners will block it as insecure. However, the tool itself is useful.
  • THC Hydra
  • w3af

Commercial tools/services:

How is penetration testing conducted?

There is plenty of material available on how a penetration test can be conducted:

Application Firewalls which can be used to mitigate the risks:

While applications can and should be hardened before penetration testing, application firewalls can also be used to mitigate some of the risks. The OWASP site lists several such application firewalls.

There is a long list of application firewalls or appliances. Here are some found in Wikipedia

Below is a list of various application firewalls and appliances running as plugins, boxes and load balancers or even in the cloud (as proxy servers)

OWASP website includes a configuration guide for application firewalls:

  • AQTRONIX WebKnight (Open Source),
  • Qbik WinGate (Commercial),
  • Navilin
  • Untangle (Commercial)
  • Check Point (Commercial)
  • Smoothwall (Open Source)
  • Barracuda Networks Web Application Firewall/Load Balancer ADC (Commercial)
  • A10 Networks Web Application Firewall (Commercial)
  • Citrix Netscaler (Commercial)
  • F5 ASM, Fortinet FortiWeb (Commercial)
  • WatchGuard (Commercial)
  • Imperva (Commercial)
  • KEMP Technologies (Commercial)
  • Penta Security (Commercial)
  • Cloudbric (Commercial, but charges only based on traffic and only above 4GB / month)
  • PIOLINK (Commercial)
  • ProxyServerModSecurity package (Plugin for PFSense Open source firewall/ Linux-based)

Do you need help developing secure software or preparing for a pen test?

Do you need help with security testing, preparing for penetration testing, or developing secure software? Don’t hesitate to contact us at Gislen Software. We have experts with the necessary skills and experience. Whether you face technical challenges or need strategic guidance, we are here to help you reach your goals. Contact us today to discuss how we can support your needs!

Was this article helpful?