## 5 Experimental Methodology
### API Injection on NRF  
API injection stands as a prevalent attack vector, wherein malicious input is injected into an API to execute unintended actions or access confidential information. This breed of attack manifests through various channels, encompassing SQL injection, command injection, and payload injection among others.  
Figure 3: UE authentication procedure: The messages exchanged between UE and AMF during the identification, authentication, and SMC procedure.  
SQL injection revolves around infusing malevolent SQL commands into an API endpoint responsible for interacting with databases, aiming to gain unauthorized access to sensitive data or manipulate existing information.  
Command injection transpires when malicious commands are injected into an API endpoint capable of executing system commands, facilitating the execution of arbitrary code on the server.  
Payload injection ensues when harmful payloads are injected into an API endpoint that processes untrusted data, ultimately leading to the execution of arbitrary code on the server.  
The implications of API injection are grave, encompassing data breaches, illicit access to confidential information, and service disruptions. Mitigating this threat necessitates the implementation of robust input validation, fortified authentication, and access control mechanisms.  
Given the 5 GC's reliance on REST API requests (HTTP/2), the NFs of the SBA become susceptible to the entire gamut of web application attacks, thereby expanding its attack surface. Consequently, the adoption of automated tools like network vulnerability assessment tools becomes indispensable. In our tests, we employed the **Burg Suite** tool, but for Open5 GS experiments an additional ad hoc \"translator\", named **5 GHTTPModifier**, was also necessary, due to the lack of support (by Burp Suite and similar tools) for active scans on HTTP/2 servers that do not support TLS, such as Open5 GS. In more detail, 5 GHTTPModifier takes an XML file containing requests for a specific API as input, and then transforms them into legitimate requests for Open5 GS. The tool ensures proper request forwarding and logs response data. In the case of AOI, the direct utilization of Burp Suite was possible using HTTP.1. For this HTTP version, Burp Suite does not require TLS usage.  
Burg Suite is equipped to assimilate an API schema (defined in OpenAPI) as input and initiate an active scan on the specified target, subsequently generating a comprehensive report detailing the identified vulnerabilities.  
**Burg Suite** encompasses an extensive array of vulnerability tests, with a comprehensive list available at _portswigger.net/kb/issues_. Notable tests include OS command injection, SQL injection, File path traversal, PHP code injection, Server-side JavaScript code injection, and HTTP request smuggling. Moreover, the tool undertakes injection attempts across various elements of a request (such as parameters, body, headers, cookies, etc.), or at predefined points.  
The testing methodology we adopted for API injection entails the following steps:  
1. Parse the API schema definition (OpenAPI 3.0.0) using Burp Suite.
2. Initiate an automated scan for each API service in the OAI testbed, injecting malicious parameters/payloads at various junctures of the HTTP requests, including headers, body, and URLs.
3. Analyze the scan results for the OAI testbed and export them as an XML file, which serves as the input for the **5 GHTTPModifier** tool.
4. Execute the **5 GHTTPModifier** tool for each output obtained from the previous scan in the Open5 GS testbed.