Location Research Breakthrough Possible @S-Logix pro@slogix.in

Graph Neural Network (GNN)-Based Detection of OS Command Injection Attacks in OWASP WebGoat Through Source-Code Data-Flow Analysis and Controlled Attack Simulation

Description

Web applications frequently process user-supplied input to perform operations such as file handling, system information retrieval, data processing, and application administration. In some applications, server-side code passes user-controlled input to operating-system commands to perform specific operations.

OS Command Injection is a vulnerability in which insufficiently controlled input influences operating-system command execution. If an application constructs or executes commands using untrusted input without adequate protection, an attacker may manipulate the input to cause unintended command execution.

Traditional source-code reviews and security scanners can identify some command-injection weaknesses by examining potentially dangerous functions, input validation, and the flow of untrusted data. However, identifying the relationship between a user-controlled input and a potentially dangerous execution point can require examining multiple connected parts of the program.

Graph-based source-code analysis provides another approach by representing program structures and relationships as graphs. A Graph Neural Network (GNN) can learn patterns from these graph representations and classify code samples according to the vulnerability categories represented in its training data.

In this use case, OWASP WebGoat is deployed within an isolated cybersecurity laboratory using Ubuntu Linux and Kali Linux virtual machines. WebGoat contains a dedicated command-injection lesson, providing a controlled environment for investigating this vulnerability.

A publicly available, labelled source-code vulnerability dataset is used as the starting point for the machine-learning stage. The dataset is inspected to verify its programming language, vulnerability labels, source-code availability, and suitability for graph-based classification. Java source-code examples associated with OS Command Injection are required to support the intended relationship between the training data and the Java-based WebGoat application.

Joern is used to analyse supported source code and generate program-representation graphs. Python and PyTorch Geometric are used to prepare graph inputs, train the GNN, and generate predictions for previously unseen code samples.

The trained model is then evaluated against source-code samples associated with the WebGoat command-injection scenario. A controlled command-injection attack is performed against the local WebGoat application to validate the selected vulnerable scenario. The attack result is compared with the source-code analysis findings.

The project investigates whether graph-based source-code representations can help identify command-injection-related weaknesses and whether the resulting findings correspond to a controlled attack scenario.

The complete workflow is:
Public Source-Code Vulnerability Dataset
→
Dataset Inspection
→
Java Source-Code Selection
→
Source-Code Preprocessing
→
Joern Graph Generation
→
Graph Feature Preparation
→
GNN Training
→
Model Evaluation
→
OWASP WebGoat Deployment
→
Nmap Service Discovery
→
Source-Code Vulnerability Analysis
→
Controlled Command-Injection Attack Simulation
→
HTTP Traffic and Application Evidence Collection
→
Source-Code and Attack-Result Correlation
→
Detection Performance Evaluation

Existing Security Problem

Application: OWASP WebGoat

OWASP WebGoat is an intentionally vulnerable web application designed to teach web application security concepts through practical lessons. Its official lesson repository includes a dedicated command-injection lesson.

In this use case, WebGoat is deployed locally within the authorized laboratory. Ubuntu Linux hosts the application and machine-learning environment, while Kali Linux supports controlled security testing.

Existing Problem :

Web applications may execute operating-system commands as part of their functionality. If untrusted input reaches a command-execution point without adequate validation and protection, the application may become vulnerable to OS Command Injection.

A source-code reviewer may need to examine several connected program elements to understand how input travels from its origin to a potentially dangerous execution point.

For example, user-controlled input may pass through request handlers, helper functions, transformations, and validation routines before reaching a command-execution function. Analysing these relationships requires understanding more than the presence of a single function call.

Traditional pattern-based scanning can identify certain suspicious constructs, but the existence of a potentially dangerous function does not automatically establish that a vulnerability is exploitable. The surrounding data flow, input controls, and execution context must also be examined.

The security problem is:
Web Application Source Code
→
User-Controlled Input
→
Input Processing and Transformation
→
Potentially Insufficient Input Validation
→
Input Reaches a Command-Execution Point
→
Potential OS Command Injection Vulnerability
→
Manual Source-Code Investigation Required
→
Controlled Attack Validation Required
→
Need for Graph-Based Vulnerability Analysis

The proposed solution introduces a GNN-based source-code classification mechanism that examines graph representations of program structures and data-flow relationships. Controlled attack simulation is used to validate the selected vulnerability scenario independently of the model prediction.

Attack

Specific Attack: Controlled OS Command Injection Attack

The controlled attack evaluates whether input supplied to the local OWASP WebGoat command-injection lesson can influence an operating-system command in an unintended manner.

The attack is performed only against the deliberately vulnerable WebGoat instance inside the isolated VirtualBox laboratory. The test uses the application's designated lesson and a non-sensitive test environment.

The objective is to generate observable evidence of the command-injection scenario and compare that evidence with the corresponding source-code analysis findings.

The controlled attack does not target external systems or production applications. It does not involve destructive commands, persistence, credential theft, or unauthorised access.

Attack Behavior :
Kali Linux Testing Environment
→
Access to Local OWASP WebGoat
→
Command-Injection Lesson Identified
→
Baseline Application Behaviour Recorded
→
Controlled Test Input Submitted
→
Application Processes the Input
→
Application Response Observed
→
Relevant HTTP and Application Evidence Captured
→
Corresponding Source-Code Path Examined
→
GNN Source-Code Classification Reviewed
→
Controlled Attack Result Compared with Source-Code Findings
→
Detection and Validation Results Recorded

Security Concept

Graph Neural Network-Based Source-Code Vulnerability Detection

The primary security concept is graph-based source-code vulnerability analysis combined with controlled OS Command Injection attack validation.

The project investigates whether relationships between program elements provide useful information for classifying code samples associated with command-injection vulnerabilities.

Source-Code Graph Representation : The selected Java source-code samples are analysed using Joern, where supported, to generate graph representations of program structure and relationships. The graph may contain nodes representing program elements and edges representing relationships such as control flow, data flow, or other supported program connections. The resulting graph is prepared as input for the GNN.

GNN-Based Vulnerability Classification : A Graph Neural Network implemented with PyTorch Geometric learns representations from the graph structures and their node features. The model classifies code samples according to the verified vulnerability labels available in the training dataset. The model's ability to identify OS Command Injection must be established through appropriate evaluation. It must not be assumed that a model trained on generic vulnerable code automatically detects command injection specifically.

Controlled Attack Validation : The trained model's findings are compared with the source code associated with the WebGoat command-injection lesson. A controlled attack is performed against the local application to observe whether the selected scenario demonstrates the intended vulnerability. The application response, relevant source-code path, and GNN prediction are examined together. A successful attack can support validation of the selected scenario, but it does not independently establish the model's overall detection accuracy.

The assessment follows:
Public Source-Code Vulnerability Dataset
→
Java Code Selection
→
Source-Code Preprocessing
→
Program Graph Generation
→
Graph Feature Preparation
→
GNN Training
→
Model Evaluation
→
WebGoat Source-Code Analysis
→
Controlled Command-Injection Simulation
→
Application Evidence Collection
→
Source-Code and Attack-Result Correlation
→
Detection Performance Analysis

Defensive Mechanism

The security concept defines the overall vulnerability-detection strategy.

The following defensive mechanisms support the implementation.

Source-Code Inspection :

The source code associated with command processing is examined to identify input sources, transformations, validation routines, and potentially dangerous execution points.

Purpose: Identify code locations that require detailed vulnerability analysis.

Program Graph Generation

Joern is used to produce supported graph representations of the selected source code.

Purpose
  • Represent relationships between program elements for graph-based analysis.

GNN-Based Vulnerability Classification

The GNN classifies graph representations according to the categories supported by the verified training data.

Purpose
  • Evaluate whether learned source-code graph patterns help identify command-injection-related weaknesses.

Consistent Graph Preprocessing

The same graph-generation and feature-preparation process is applied to compatible training, evaluation, and target code.

Purpose
  • Maintain consistent graph inputs throughout model development and detection.

Network Service Discovery

Nmap identifies the expected WebGoat service within the authorised laboratory.

Purpose
  • Verify the intended application exposure before testing.

Controlled Attack Validation

A controlled command-injection scenario is performed against the local WebGoat lesson.

Purpose
  • Obtain practical evidence for validating the selected source-code finding.

HTTP Traffic Inspection

OWASP ZAP and Wireshark support inspection of application requests, responses, and network-level communication during controlled testing.

Purpose
  • Preserve supporting evidence of the controlled test activity.

Evidence-Based Finding Correlation

The GNN prediction is compared with source-code findings and the observed attack result.

Purpose
  • Distinguish model predictions from independently observed vulnerability evidence.

Secure Input Handling

Input validation, safe process invocation, avoidance of unsafe shell construction, and appropriate execution restrictions are recognised as relevant prevention measures.

Purpose
  • Reduce the risk that user-controlled input can cause unintended operating-system command execution.

Security Tools

Primary Vulnerable Web Application: OWASP WebGoat

OWASP WebGoat provides the deliberately vulnerable web application used for controlled command-injection testing. Its lesson repository includes a command-injection lesson.

Purpose
  • Provide the local web application.
  • Support controlled command-injection testing.
  • Generate application responses for analysis.
  • Provide the target source code for investigation.

Security Testing Platform: Kali Linux

Kali Linux is used as the controlled security-testing environment.

Purpose
  • Access the authorised local WebGoat instance.
  • Perform the controlled command-injection test.
  • Inspect application responses.
  • Support repeatable laboratory validation.

Application and AI Environment: Ubuntu Linux

Ubuntu hosts the application and machine-learning components.

Purpose
  • Run OWASP WebGoat.
  • Execute Python and graph-processing tools.
  • Support GNN training and inference.
  • Store experiment results.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated laboratory infrastructure.

Purpose
  • Host Ubuntu and Kali Linux virtual machines.
  • Separate the application and testing environments.
  • Support controlled network communication.
  • Enable repeatable experiments.

Network Discovery Tool: Nmap

Nmap identifies services exposed by the authorised laboratory target.

Purpose
  • Discover the local WebGoat service.
  • Verify the expected application port.
  • Document laboratory network exposure.

Network Traffic Analysis Tool: Wireshark

Wireshark captures and examines network packets exchanged during controlled testing.

Purpose
  • Capture authorised laboratory traffic.
  • Examine network communication and timing.
  • Provide supporting evidence for the test activity.

HTTP Security Testing Tool: OWASP ZAP

OWASP ZAP supports inspection of HTTP requests and responses during authorised web application testing.

Purpose
  • Inspect request methods, paths, and parameters.
  • Review application responses.
  • Preserve HTTP evidence for attack validation.

Programming Language: Python

Python provides the main environment for dataset processing, graph preparation, model training, classification, and evaluation.

Purpose
  • Integrate the machine-learning workflow.
  • Automate dataset preparation.
  • Process graph features.
  • Record and evaluate predictions.

Source-Code Graph Analysis Tool: Joern

Joern is used to analyse supported source code and generate code property graphs or related program representations.

Purpose
  • Parse compatible source code.
  • Generate graph representations.
  • Extract program relationships for vulnerability analysis.

Graph Machine-Learning Framework: PyTorch Geometric

PyTorch Geometric provides graph-learning components that can be used to implement the GNN classifier.

Purpose
  • Represent source-code graphs as model inputs.
  • Implement graph neural network layers.
  • Train and evaluate the graph classifier.
  • Generate predictions for unseen graph samples.

Machine-Learning Framework: PyTorch

PyTorch provides the underlying tensor and neural-network operations used by PyTorch Geometric.

Purpose
  • Implement model training.
  • Process graph features.
  • Calculate training loss.
  • Generate model predictions.

Data Processing Tool: Pandas

Pandas is used to inspect dataset metadata, labels, source-code references, and model results.

Purpose
  • oad and organize dataset records.
  • Manage training and evaluation metadata.
  • Organis classification results.

Numerical Processing Tool: NumPy

NumPy supports numerical feature preparation and experiment-data processing.

Purpose
  • Prepare numerical arrays.
  • Support feature transformations.
  • Assist with model input preparation.

Source-Code Security Scanner: Semgrep Community Edition

Semgrep can provide supplementary source-code findings for supported rules and languages.

Purpose
  • Identify suspicious source-code patterns.
  • Provide comparison evidence for manual review.
  • Support investigation of potential unsafe command construction.

Dataset Evaluation Tool: Scikit-learn

Scikit-learn provides data-splitting utilities and classification metrics.

Purpose
  • Prepare training and evaluation partitions.
  • Calculate precision, recall, and F1-score.
  • Generate confusion-matrix results.

Evidence Storage: SQLite

SQLite can store experiment metadata, graph references, model predictions, and attack-validation results.

Purpose
  • Preserve the analysis evidence.
  • Associate predictions with source-code samples.
  • Record controlled test results.
  • Support later review.

Process

STEP 01

Prepare the Isolated Laboratory Environment

  • Create the cybersecurity laboratory using VirtualBox
  • Configure Ubuntu Linux as the application and AI-analysis environment
  • Configure Kali Linux as the security-testing system.
  • Establish controlled network communication between the virtual machines.
  • Verify that the testing system can reach the authorised Ubuntu laboratory.
  • Confirm that all security testing is restricted to the local environment.
Tools: VirtualBox + Ubuntu Linux + Kali Linux
STEP 02

Deploy OWASP WebGoat

  • Obtain the official OWASP WebGoat project and follow its documented installation procedure.
  • Configure the required application components.
  • Start WebGoat using a supported local deployment method.
  • Keep the vulnerable application bound to localhost or otherwise isolated from external access
  • Verify that the application loads successfully
  • Confirm that the command-injection lesson is available in the deployed version.
  • Record the application version and configuration.
Tools: OWASP WebGoat + Ubuntu Linux + VirtualBox
STEP 03

Establish Normal Application Behaviour

  • Access WebGoat through the local browser.
  • Open the relevant command-injection lesson.
  • Perform the intended non-attack lesson operations.
  • Observe the application's normal responses.
  • Record the baseline HTTP requests and responses.
  • Preserve the evidence for comparison with the controlled attack.
Tools: OWASP WebGoat + Browser Developer Tools + OWASP ZAP
STEP 04

Identify the Laboratory Service Exposure

  • Identify the authorised Ubuntu laboratory IP address and expected WebGoat service port.
  • Use Nmap to verify the expected service exposure within the laboratory network.
  • Record the discovered service and port.
  • Confirm that the service is accessible from the intended testing environment.
  • Compare the observed exposure with the intended laboratory configuration.
  • Do not scan external systems or networks.
Tools: Nmap + Kali Linux
STEP 05

Prepare the Public Source-Code Vulnerability Dataset

  • Obtain an existing public source-code vulnerability dataset with documented labels.
  • Inspect the dataset's licence, source-code language, vulnerability categories, and sample structure.
  • Determine whether Java source-code samples associated with OS Command Injection are available.
  • Review whether the source code can be converted into graph representations.
  • Select a suitable public source-code dataset for the intended classification task.
  • Do not assume that a generic vulnerable-code dataset contains command-injection examples without checking its labels.
Tools: Python + Pandas
STEP 06

Inspect and Validate Dataset Labels

  • Load the dataset metadata into Python.
  • Review the vulnerability labels and source-code references.
  • Determine which labels represent vulnerable and non-vulnerable samples.
  • Identify samples associated with command injection, including CWE-78 where the dataset provides verified mapping.
  • Check for duplicate or related samples that could cause data leakage between training and evaluation.
  • Record the selected categories and any limitations.
Tools: Python + Pandas + Scikit-learn
STEP 07

Preprocess the Source Code

  • Load the selected source-code samples.
  • Inspect invalid records, missing source files, and inconsistent metadata.
  • Clean unsuitable samples without changing the meaning of the original source code.
  • Preserve the verified vulnerability labels.
  • Organise the source files for graph generation.
  • Record the preprocessing procedure and the number of usable samples.
Tools: Python + Pandas
STEP 08

Generate Source-Code Graphs

  • Use Joern to analyse source-code samples supported by the selected parser.
  • Generate program graph representations for the training and evaluation samples.
  • Extract supported nodes, edges, and relevant program relationships.
  • Inspect graph-generation errors and incomplete graphs.
  • Verify that graph representations preserve useful program structure.
  • Apply the same graph-generation configuration to compatible WebGoat source code.
Tools: Joern + Python
STEP 09

Prepare Graph Features

  • Convert the generated graphs into the representation required by PyTorch Geometric.
  • Prepare node features using supported program attributes, token information, or other documented representations.
  • Prepare edge indices and graph labels.
  • Ensure that graph labels correspond to the original verified dataset labels.
  • Check graph dimensions, missing features, and invalid node or edge references.
  • Verify that the prepared graphs can be loaded by the GNN implementation.
Tools: Python + PyTorch Geometric + NumPy + Pandas
STEP 10

Prepare Training and Evaluation Data

  • Split the prepared graph samples into training, validation, and test partitions.
  • Preserve the verified labels.
  • Avoid allowing duplicate functions or closely related source-code samples to appear across multiple partitions where this could cause leakage.
  • Check the distribution of vulnerable and non-vulnerable samples.
  • Confirm that the test partition is not used during model training.
  • Record the selected evaluation methodology.
Tools: Python + Scikit-learn + PyTorch Geometric
STEP 11

Build the Graph Neural Network

  • Implement the GNN architecture using PyTorch Geometric.
  • Configure the input features to match the generated graph representation.
  • Define graph-processing layers and a graph-level classification component.
  • Configure the output classes according to the verified training labels.
  • Select an appropriate loss function and optimizer.
  • Run a small batch of graphs to verify the model's input and output dimensions.
Tools: Python + PyTorch + PyTorch Geometric
STEP 12

Train the GNN Model

  • Provide the prepared training graphs and their verified labels to the GNN.
  • Train the model using the selected configuration.
  • Monitor training and validation loss.
  • Observe classification performance across the available classes.
  • Save the trained model and graph-feature configuration.
  • Record the model parameters and training procedure.
  • Do not assume that successful training guarantees accurate command-injection detection on WebGoat.
Tools: Python + PyTorch + PyTorch Geometric
STEP 13

Evaluate the Trained GNN

  • Provide the held-out test graphs to the trained model.
  • Generate predictions for the test samples.
  • Compare the predictions with their verified labels.
  • Calculate precision, recall, and F1-score where appropriate.
  • Generate a confusion matrix to examine classification errors.
  • Review false positives and false negatives.
  • Record the actual evaluation results and determine whether the model is suitable for the controlled experiment.
Tools: Python + PyTorch Geometric + Scikit-learn + Pandas
STEP 14

Analyse the WebGoat Command-Injection Source Code

  • Locate the source-code components associated with the selected WebGoat command-injection lesson.
  • Review the input source, transformations, validation routines, and command-execution path.
  • Use Joern to generate supported graph representations of the relevant source code.
  • Inspect the graph for relationships between user-controlled input and potentially dangerous execution points.
  • Use Semgrep as supplementary evidence where applicable.
  • Record the source-code findings separately from the GNN prediction.
Tools: OWASP WebGoat + Joern + Semgrep + Python
STEP 15

Perform the Controlled Command-Injection Attack

  • Access the local WebGoat command-injection lesson from the authorised laboratory environment.
  • Record the application's baseline behaviour.
  • Follow the lesson's controlled testing scenario using non-destructive test input.
  • Submit the test only to the local WebGoat instance.
  • Observe the application's response and any expected lesson behaviour.
  • Do not execute destructive operating-system commands or test external targets.
  • Record the test conditions and known outcome.
Tools: OWASP WebGoat + Kali Linux + Browser Developer Tools + OWASP ZAP
STEP 16

Capture and Analyse Attack Evidence

  • Capture the HTTP requests and responses associated with the controlled test.
  • Use OWASP ZAP or browser developer tools to inspect application-layer request information.
  • Use Wireshark to capture supporting network traffic where useful.
  • Associate the captured evidence with the known test time and application operation.
  • Verify whether the intended command-injection behaviour occurred.
  • Preserve the original evidence for comparison with the source-code findings.
Tools: OWASP ZAP + Wireshark + Python
STEP 17

Correlate GNN Findings with the Controlled Attack

  • Provide compatible graph representations of the relevant WebGoat source-code samples to the trained GNN.
  • Record the model predictions and available confidence information.
  • Compare the predictions with the source-code analysis and controlled attack evidence.
  • Determine whether the model identifies the relevant source-code sample as belonging to a class it was trained to recognise.
  • Record the outcome of the controlled attack separately from the GNN prediction.
  • Document whether the source-code language and graph representation are compatible with the training pipeline.
  • Do not claim successful command-injection detection if the dataset labels or model inputs do not support that conclusion.
Tools: Python + PyTorch Geometric + Joern + SQLite
STEP 18

Perform Final Detection Validation and Security Review

  • Repeat the evaluation using suitable vulnerable and non-vulnerable source-code samples.
  • Review the model's classification results and evaluation metrics.
  • Inspect the source-code findings associated with the WebGoat command-injection lesson.
  • Compare the controlled attack result with the corresponding source-code evidence.
  • Review false positives, false negatives, and possible data leakage.
  • Document limitations caused by programming-language differences, dataset coverage, or graph-generation compatibility.
  • Record the final experimental findings and potential improvements.
Tools: Python + PyTorch Geometric + Scikit-learn + Joern + Semgrep + OWASP WebGoat + Nmap + Wireshark + OWASP ZAP + SQLite

Outcome

OWASP WebGoat is deployed within an isolated Ubuntu and Kali Linux laboratory, providing a controlled environment for command-injection security testing.

Nmap is used to identify and verify the expected WebGoat service exposure within the authorised laboratory network.

A publicly available source-code vulnerability dataset is inspected to determine whether it provides verified labels and suitable Java source-code samples for the intended GNN classification task.

The selected source-code samples are preprocessed and converted into graph representations using Joern and the associated graph-processing workflow.

A Graph Neural Network is implemented using PyTorch Geometric and trained using the verified labels available in the selected dataset

The trained GNN is evaluated using held-out graph samples, and actual classification metrics are recorded to assess its performance.

The source code associated with the WebGoat command-injection lesson is analysed to identify relevant input-processing and command-execution relationships.

A controlled OS Command Injection attack is performed against the local WebGoat application, and its HTTP and application evidence is captured using the selected security-testing tools.

The GNN prediction, source-code analysis findings, and controlled attack result are compared to determine whether the identified code sample corresponds to the intended vulnerability scenario.

The complete workflow demonstrates a practical investigation of GNN-based source-code vulnerability classification for OS Command Injection, combining public-dataset preparation, graph generation, model training, controlled attack simulation, cybersecurity tool usage, and evidence-based validation.