Cybersecurity research and web application penetration testing in one

Performing web application penetration testing is a very good approach to improve the web application security. The most common type of web application penetration testing is a black box model where the team conducting the test knows very little about the target web application. This makes the test more similar to a real-life attack scenario. The downside of this is the penetration testing team has to guess or rather enumerate the existing paths, parameters, application structure, and more, which usually takes time. In addition, some vulnerabilities exist in very deep parts of the source code that are executed under specific conditions. Black box penetration testing has a very little chance of uncovering such vulnerabilities.

The White Box Penetration Test is the solution to this shortcoming. Before the web application penetration testing begins, the penetration testers get access to the application’s source code, documentation, and very often the operating systems, on which the application is running on. This gives them a huge advantage over black box testing. Penetration testers can extract existing API endpoints, parameters, formats, etc. without spending time on running tools that guess these parameters. They can review web application logs after executing attacks to speed up the exploitation process. They can look at the source code to fully understand and bypass implemented protections.

Not every web application penetration testing team can perform white box penetration testing because it requires an understanding of the source code, the interaction between the web server and the web application, the log format, and more.

In addition, open-source applications can benefit greatly from white box penetration testing because the source code and the test environment can be easily controlled by the penetration testers. There is no need to perform the penetration testing on your production environment and risk disrupting your business.

Also, in this series, we’ll be releasing a tool that detects vulnerabilities in CakePHP applications in a way that none of the popular vulnerability scanners currently do. The research and development of this tool was commissioned by the Luxembourg Armed Forces.

Stay with us for a solution that is dedicated to finding vulnerabilities in CakePHP applications!

In this article you will find:

• CakePHP as a target of cybersecurity research
• Detecting CakePHP web applications in web application penetration testing
• Understanding CakePHP by performing cybersecurity research
  • CakePHP cybersecurity research starts with understanding the architecture
  • CakePHP directories you should focus in web application penetration testing
• Cybersecurity research of open-source web applications

CakePHP as a target of cybersecurity research

In our cybersecurity research we will focus on web applications based on Cake PHP framework. A web application framework is a set of libraries, functions, classes and plugins that a web developer can use almost out of the box without coding them from scratch. This could be access control, presenting results in various formats like HTML, JSON, XML, accessing database, session management, and much more.

Examples of other web application frameworks include:

• Laravel
• Symfony
• Java Spring
• Django
• Flask
• .NET MVC

From the CakePHP webpage:

CakePHP is an open-source web, rapid development framework that makes building web applications simpler, faster and require less code.

On Github Cake PHP currently is watched by 560 people, is forked 3 500 times, and has over 8 600 stars.

According to the Cake Software Foundation (https://cakephp.org/showcase), Cake PHP is used by organizations such as BMW, Calzedonia, Hyundai, and more.

In addition, some popular open-source applications are built based on the Cake PHP framework such as MISP or PassBolt.

Web applications based on the CakePHP framework are also an interesting target because of the standard security mechanisms provided by the framework such as black-holing or CSRF protection. These protections make the job of vulnerability scanners much harder. They need to be specifically configured to scan certain areas of the application and very often the scanners are blocked by these protections.

Detecting CakePHP web applications in web application penetration testing

There is no reliable way to detect whether the framework behind the web application is CakePHP with 100% accuracy using a black box approach. The best way is to look for the CAKEPHP cookie being set by the application:

One of the indication of the usage of Cake PHP framework is the URL structure. Cake PHP is built using the MVC pattern, which often results in URL addresses being structured like this:

Note the following parts separated by a forward slash:

• Controller
• Action
• optional parameters

I’ll cover these in the next article.

Sometimes applications leave a trail of a CakePHP usage when you request a non-existent controller or non-existent action:

If you have access to the source code, you can easily see if the web application is built on Cake PHP by looking at the composer.json (if used) or by looking for the cake directory or executable.

Below is a screenshot of the composer.json file from the Cerebrates project:

Cake PHP allows developers to perform various actions such as running migrations, debugging, or upgrading from the console using the cake executable script. You can search for this script to see if your application is built on the Cake PHP framework. In the MISP server, running a quick “find” command shows the `app/Console/cake` path:

Finally, the `cakephp` directory should point to the source code of the Cake PHP framework:

Keep in mind that these paths might differ in different CakePHP web applications.

Understanding CakePHP by performing cybersecurity research

Most of the examples and explanations are based on web applications built in CakePHP 4. However, there are still some web applications that use older versions of CakePHP framework. An example of such open-source application is MISP.

The MISP is an open-source software solution for collecting, storing, distributing and sharing cyber security indicators and threats about cyber security incidents analysis and malware analysis. MISP is designed by and for incident analysts, security and ICT professionals or malware reversers to support their day-to-day operations to share structured information efficiently.

In addition, MISP is used by many international organizations including the NATO Communication and Information Agency, FIRST, and others (https://www.misp-project.org/communities/).

Therefore, I will also provide examples that are related to CakePHP version 2.

CakePHP cybersecurity research starts with understanding the architecture

To conduct cybersecurity research we will start by understanding the architecture of the Cake PHP framework.

Web applications based on Cake PHP are built based on the MVC architecture, which stands for Model-View-Controller.

You can see the execution flow in the diagram below:

This architecture is very common in web applications because it divides different groups of code into a logically related layers:

– Model is responsible for communicating with the database or some other type of registry. SQL queries or requests to key-value stores such as Redis are executed here.

– View is responsible for providing the presentation layer. Whenever you browse the application and see the generated HTML, the application has done so it in the View layer.

– Controller is responsible for most of the application’s logic, processing user input, and more.

Here I present a sample execution flow of the CakePHP applications:

– The user interacts with the view layer of the application. This is the graphical user interface (GUI) of the application.

– The user clicks on a link to view the description of a particular news page. The link is formulated as follows /news/show/3

– The request for the news page goes to the router component.

– Based on the URL path and the request method, the router decides which controller should process this request.

– The “show” action of the “news” controller is selected by the router. The router passes the control of the request to the “show” action of the “news” controller.

– The action processes the request including the user data, extracts the id of the news page to display (3), and sends a request to the model layer to extract the news page with id=3 from the database.

– The model connects to the database, extracts the news page from the database, and sends the processed response back to the controller

– The controller layer still within the “show” action parses the response from the database and provides specific data to the view layer.

– The view layer loads a specific template for the “show” action of the “news” controller, populates it in with data from the controller and sends the response back to the user.

The CakePHP framework implements CRUD (create, read, update, delete) actions by default. The default names of these actions within controllers are: view, add, edit, delete. If the action is not detected in the URL, the default action “index” is assumed.

From the security perspective, there are a few key takeaways from this structure. If you are looking for vulnerabilities that target the front-end of the web application, look at the View layer of the CakePHP application. These could be XSS vulnerabilities for example.

If you are looking for SQL injection vulnerabilities for example, it is more likely  that the vulnerability is in the Model layer.

Finally, the Controller layer is the main place where the application starts processing user input.

Keep in mind that these vulnerabilities may exist in other components as well. There are chances that you can find SQL injection vulnerabilities in Controller or other components.

CakePHP directories you should focus in web application penetration testing

Applications written in CakePHP usually follow a specific directory structure. In the root folder of the Cake PHP application, you will find folders such as:

• bin
• config
• logs
• tmp

The majority of these directories do not contain interesting information from a security perspective.

Here are some specific files that may be of interest:

– /config/routes.php – Contains defined routes to the application. Routes correspond to URL paths that the application can process and sometimes what type of middleware is associated with a particular route or group of routes.

– /logs – If you are doing white box penetration testing, you should monitor the log files in this directory and look for interesting errors or warnings that may indicate that your attacks or scans have triggered vulnerable parts of the code.

– /plugins – Plugins are pre-packaged controllers, models, and views that are reused by different projects. Plugins can be developed by the same team that develops the web application, or they can be public plugins imported from the community. . It is worth exploring this directory in the same way that you would explore models, views, and controllers (described below).

– /templates – These files are the core of the presentation layer of the application. You should examine them primarily to look for front-end vulnerabilities such as XSS.

– /webroot – Files in this directory are accessible from the URL. The exceptions are files that are protected by the web server, such as Apache .htaccess. You may find some static files that are worth examining such as JavaScript files

However, when considering security aspects, you should focus on the directory that specifically contains the web application files that are almost always part of the execution flow. In CakePHP version 3 and 4, this directory is called src. In Cake version 2, it’s called app. This directory and all of its subdirectories (with a few exceptions) contain the core source code of the application that was developed specifically for the purpose the application serves. This means the external libraries, components, or extensions written by other teams, vendors, or maintainers are usually not located in the src or app directory.

If you want to understand the directory structure better, check out one of the following:

• Cake PHP Version 4 Directory Structure
• Cake PHP Version 3 Directory Structure
• Cake PHP Version 2 Directory Structure

Below is an example of the PassBolt API directory structure:

Some of these directories are application specific. You may not find them in other CakePHP web applications.

Here is an explanation of the directories that are common to all CakePHP applications:

Command	CakePHP application administrators can run Cake commands on the operating system where the web application is hosted. An example of this would be performing migrations required for initial database setup. There is a set of default commands provided by the CakePHP framework itself, but developers can extend this set by adding their own commands. The code for the logic behind these commands is stored in the Command directory. Since this is only executed from the command line, it’s rarely of interest from a security perspective, since the main attack vector is through a web application
Console	Contains code related to the installation or setup process of the web application. This code is also executed from the command line, so we are not interested in it either.
Controller	This is the main logic of the application, where a lot of the magic happens. You will find several controllers there, each of which has its own actions. The controller-action pair, corresponds to a specific path in the application, such as /users/index. In this case the controller is users, which corresponds to the UsersController.php file, and the action is index, which corresponds to the index method inside the controller file (you can find the index method by searching for something like this: public function index()). Some of the controllers will inherit actions from others. This directory is definitely very important in a cybersecurity research or white box penetration testing of CakePHP based web applications.
Middleware	This directory contains classes that are used in various places in the code. They may be used by the CakePHP router, some controllers, models, or other components. An example of middleware is a CSRF protection class that is able to generate new tokens, disable CSRF protection for some requests like API, and check if the CSRF token passed by the user. This directory is also interesting from a security perspective because it’s used in several places in the application. It also usually does not contain much code. Analyzing the code there can lead to bypassing implemented protections.
Model	This directory contains source code that communicates with the database, such as schema definitions, database-related behaviors, and more. It’s worth focusing on database-related vulnerabilities such as SQL injection when reviewing code there.
Shell	These are usually reusable classes that are used by command line actions. Since this is also mainly associated with console-based applications, it is rarely a focus of the white box penetration testing.
View	The directory containing the presentation layer classes. Although you may find some front-end vulnerabilities there, it usually serves a secondary purpose as a “helper” for the front-end.

CakePHP framework is built with a convention over configuration pattern. This will greatly help you understand the application, as many file names, class names, method names, etc. are standardized and usually descriptive.

Cybersecurity research of open-source web applications

Want to support an open-source initiative by improving its security?

Are you using an open-source project and you want to verify its security?

The cybersecurity research of the open-source project will greatly improve its security.