BOOK THIS SPACE FOR AD
ARTICLE ADWith the advancement of technology, traditional web applications are being replaced by more modern web applications. The limitations of traditional Multi Page Application (MPA) and the performance issues they create have led to the rise of the new-generation Single Page Application (SPA). MPA applications retrieve different HTML pages for each resource from the server, loading a new HTML document with each page transition. However, SPA applications update the web interface in real-time using Virtual DOM and render only the necessary components without reloading the entire page, instead of fetching separate HTML pages from the server for each resource.
Page Loading:
MPA: A new HTML file is fetched for each page, and the page is completely reloaded.SPA: The page is not reloaded entirely; only the necessary parts are updated.Performance:
MPA: There may be longer loading times during page transitions.SPA: Initial loading time might be a bit longer, but it provides faster interactions afterward.User Experience:
MPA: The user experience might be slightly interrupted due to page reloads.SPA: The user experience is seamless and fast, as only content is updated.Development Complexity:
MPA: Requires more server-side processing, and there is usually a separate workflow for each page.SPA: Requires more complex client-side management, but the server-side workload is lighter.Single Page Applications (SPA) use the virtual DOM structure to provide high performance and enhance the user experience. Traditional web applications recreate the entire DOM with each page load, resulting in time delays. However, SPAs are loaded only once, and after that, the page content is dynamically updated using the virtual DOM. The virtual DOM creates a lightweight copy of the real DOM and calculates the changes within the application. Then, only the necessary changes are reflected in the real DOM. This approach allows for the creation of highly interactive and responsive user interfaces. By utilizing this efficient update method, SPAs do not need to reload the entire application on every page transition, offering a faster and uninterrupted user experience.
Applications with a virtual DOM structure send all JavaScript code to the browser when the page is first loaded. This is one of the key differences in SPA (Single Page Application) applications. While traditional web applications may have different JavaScript code for each HTML page, in SPA applications, a single JavaScript file manages the entire application. When the SPA is first loaded, the JavaScript code for the entire application is stored in the browser, and the same code is used on subsequent pages.
This becomes especially important in pentesting processes. In SPA applications, not only is the HTML content sent to the client every time the page is loaded, but also the entire application logic is delivered. This can make it easier for attackers to understand the internal workings of the application and exploit potential API vulnerabilities. Analyzing JavaScript code during a pentest is a critical step that should not be overlooked.
The JavaScript code in SPA applications may contain important information such as API requests to the server, user authentication, and security measures. If these codes are not properly audited, hidden endpoints, API keys, or security vulnerabilities can be easily discovered. Below are some examples of what can be obtained from the JavaScript code in SPA applications:
In black-box pentest scenarios, credentials for the application are typically not provided to the pentester. Therefore, obtaining the application’s endpoints without logging in becomes an important step.
As an example, let’s analyze the application at https://crapi.cyprox.io. This application is developed with React Native. When we visit the application, we are greeted with a login page.
When the form is filled with any information, a request can be detected being sent to the https://crapi.cyprox.io/identity/api/auth/login endpoint.
Assuming we don’t have any credentials for this application, we can analyze the JavaScript code to extract the endpoints contained within the application.
From the browser’s Debugger tab, we can search for the API domain and endpoint that the website is making requests to and gather useful information.
In the Debugger tab, searching for a specific value like identity can help us obtain the base endpoint information.
By searching for the api/auth/login value, we can access the JavaScript code where the endpoints are defined. In the Crapi application, the endpoints are defined in the APIConstant.js file. This file clearly shows the endpoints the application uses. Additionally, endpoints that have been commented out can also be checked. This method allows you to gain information about the API endpoints without logging into the application. Such analyses are a crucial step in pentesting as they provide valuable information to discover hidden endpoints and identify potential security vulnerabilities.
The obtained endpoints or Postman/Swagger collections can be tested using Cyprox.
Some web applications use the body-signature methodology in HTTP requests. With this methodology, the body of the sent HTTP request is not visible in clear text and is transmitted in an encrypted form. In this case, the encrypted data needs to be decrypted. As in the example above, by analyzing the JavaScript code and performing reverse engineering, the encryption method and the key values used for encryption can be identified. Such analyses, by deciphering encryption algorithms, can reveal security vulnerabilities during data transmission and uncover critical security flaws.
Some web applications use API Keys in HTTP requests. These keys are typically used for authentication and authorization processes, ensuring that requests are directed correctly. However, API Key values may sometimes be present in the client-side JavaScript code, either openly or in an encrypted form. By analyzing the JavaScript code and using reverse engineering techniques, the API Key values used by the application can be identified. These keys are often hardcoded in the code or stored using a specific encryption method. Such information can be exploited by an attacker. Therefore, it is crucial to securely store and manage API Key values.