Penetration tests on mobile application

Penetration tests on mobile application

Whether it is your main company web site, an e-commerce site such as PrestaShop or Magento, or any other web application, this public site is exposing a part of your information system, and may thus jeopardize the security of your entire system, or your company image. Through intrusion tests on those publicly available web sites, we try to detect the technologies used under the hood, understand their behavior, and identify possible defects that could lead to vulnerabilities.

Those audits amin at assess the resilience of your web application against:

  • the theft of sensitive or confidential information
  • the modification of data
  • authentication bypass
  • propagation into your internal network
  • privilege escalation
  • identity theft
  • specific business scenarios

Test d'intrusion de site web

By systematically giving teams of two pentesters for each audit, the chances of discovering security breaches in your perimeter of interest are greatly increased by sharing the experience and thinking of the two auditors.

Context and prerequisites

A web application pentest can be applied in different contexts, depending on the nature of the threats you wish to assess.

boite-noire

The pentest in black box is used to assess threats from an attacker who has access to the application, but no account on it. So we're trying to replicate the behavior of an attacker who discovers the application, without any additional information.

boite-grise

The pentest in grey box is used to assess threats from an attacker with a admin account with high privileges on the application. So we're trying to replicate the behavior of a user of the application, or an attacker who has stolen a user's access.

boite-blanche

Finally, the pentest in white box allows to assess threats from an attacker with a user account with standard privileges on the application. This may also include specific knowledge about the operation of the application or its architecture. So we're trying to replicate the behavior of an application administrator, or an attacker who has stolen an administrator's access.

The common prerequisite is therefore to be able to access the application. If it is not publicly exposed, you can add our IP addresses to an access control list, we can use a proxy mechanism (VPN, Citrix, RDP...) or we can come to your premises.

Web application pentest process

The process of our audits and penetration tests is based on the PTES (Penetration Testing Execution Standard), and aims at performing an audit in the time optimization. Furthermore, we respect the perimeter that you impose on us in terms of targets, time range, or type of attacks.

reconnaissance

We begin with a phase of reconnaissance and fingerprinting, during which we gather as much information as possible about the application and its entry points. For recognition, we may use Google Dorks, open service search engines such as Censys and Shodan, classic network protocols and tools (whois, dig), as well as the discovery of possible subdomains. For fingerprinting, we mainly use the well-known nmap tool for port scans, but also other tools and scripts of our own design to speed up this step. We are trying to identify the technologies that make the web application work (CMS like WordPress, Joomla, Drupal, Liferay, Magento, Prestashop...), the building blocks (Apache, IIS, nginx, Tomcat...) and the programming languages (Java, PHP...).

exploitation

Once we have a synthetic mapping of the open services on the machine and a better understanding of how the web application works, we try to discover the vulnerabilities that can be found there. This is the phase that requires the most expertise, because two auditors may find different defects in different areas. Known tools such as Burp Suite allow us to manipulate the content of requests and cause bugs unexpected by the application developers, which can reveal vulnerabilities. Nous allons mettre en oeuvre des techniques pour tenter de découvrir et d'exploiter des injections SQL, des failles Cross-Site Scripting, Cross-Site Request Forgery.

redaction

At the end of the audit, we'll take a moment to discuss the key findings with you. The idea is to give you a synthetic view of the main risks to your application: what are the main impacts of the discovered vulnerabilities on the security of your data, the level required of the attacker and the complexity of the attacks to be carried out. We then continue with the writing of the report.

presentation

Once we have sent the report, we'll plan a presentation. The objective of this step is to present both a managerial vision of the audit results, but also a detailed technical vision. This is why we encourage you to invite your technical teams to this exchange, so that they can be informed of security defects and the corrective actions we recommend.

Of course, the auditors remain at your disposal even after the restitution, by email or telephone, to answer your questions or to advise you on the implementation of corrective actions. We aim to establish a relationship of trust as well as long-term accompaniment.

Focus on the audit reports

Our reports are composed of a managerial synthesis, which allows us to approach the results through a risk-based approach. Then comes the technical section, in which the vulnerabilities discovered are detailed: the operating mode used to exploit a vulnerability, with screenshots if necessary, as well as the scripts and exploitation codes we could have developed for a specific vulnerability.

Each defect is evaluated according to the ANSSI rating scale in its PASSI requirements reference frame, which is systematically included as an appendix to our reports:

Echelle de classification des vulnérabilités de l'ANSSI

Furthermore, one or more recommendations are provided for each defect, evaluated according to two subjective criteria that we indicate from our experience: ease of implementation, and impact on security. Also, where we are able to do so, these recommendations do not stop at vague pieces of advice, but specifically mention the configuration options to be specified, or the tools to be used.

Main tools used

We use tools that are mainly open-source, with a high level of quality and a strong reputation in the cyber security community. We can quote, but not exhaustively:

You've enabled "Do Not Track" in your browser, we respect that choice and don't track your visit on our website.