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

Graph Neural Network (GNN)-Based Server-Side Request Forgery (SSRF) Detection in NodeGoat Through Source-to-Sink Data-Flow Analysis

Description

Web applications may process user-controlled URLs and other input to retrieve resources or communicate with external services. Because server-side request functionality can provide access to network resources, input validation and destination restrictions must be carefully implemented. If an application allows untrusted input to control server-side requests without adequate validation, an attacker may manipulate the destination and cause the server to access unintended resources.

In this use case, NodeGoat is selected as the target Node.js web application for source-code security analysis. Ubuntu and Kali Linux virtual machines are used within an isolated VirtualBox laboratory. A controlled SSRF assessment is performed against an authorized test endpoint after confirming that the selected application version provides a suitable request-handling path.

A Graph Neural Network (GNN) is used to analyze source-to-sink data-flow relationships in the application code. The source-code analysis identifies user-input sources, intermediate functions, validation operations, and potentially sensitive server-side request sinks. These relationships are represented as graphs that can be processed by the GNN to identify patterns associated with potentially vulnerable data flows.

A suitable public vulnerability dataset is used to prepare training, validation, and testing samples. Python and PyTorch Geometric support graph construction, model training, and performance evaluation. Semgrep Community Edition is used for static source-code analysis, while OWASP ZAP and controlled test requests support the investigation of relevant application behavior.

The GNN predictions are correlated with static-analysis results and source-code evidence before security findings are classified. The assessment also reviews input validation, destination allowlisting, and restrictions on outbound requests. If the selected NodeGoat version does not provide a suitable SSRF test path, a separately documented, controlled test endpoint must be used rather than claiming that the default application contains an unverified vulnerability.

The complete security-validation workflow is:
NodeGoat Application
→
Source-Code Inspection
→
Public Vulnerability Dataset Preparation
→
Source-to-Sink Graph Construction
→
GNN Model Training
→
AI-Based SSRF Detection
→
Static Analysis
→
Controlled SSRF Assessment
→
Finding Validation
→
Risk Prioritization
→
Security Remediation
→
Post-Remediation Testing
→
Final Security Validation

Existing Security Problem

Application/Service: NodeGoat Node.js Web Application

NodeGoat is the target web application selected for source-code analysis and security testing. Its relevant request-processing functionality must be inspected to establish whether a suitable SSRF assessment can be performed.

Existing Problem :

Web applications may pass user-controlled input through several functions before using it in server-side request operations. If destination validation is missing or insufficient, an attacker may attempt to manipulate the input and cause the server to access unintended resources.

Identifying these vulnerabilities can be difficult when the input passes through multiple variables, functions, and transformations. Traditional pattern-based security scanning may identify suspicious functions but may not fully capture complex relationships between input sources and request-handling sinks.

A GNN-based approach can represent these relationships as a graph and identify structural patterns associated with potentially vulnerable data flows. However, the model's predictions must be verified through source-code inspection and controlled security testing.

The security problem is:
NodeGoat Web Application
→
User-Controlled Input
→
Input Processing Across Application Functions
→
Potentially Sensitive Server-Side Request Operation
→
Insufficient Input or Destination Validation
→
Potential SSRF Vulnerability
→
Possible Unauthorized Server-Side Resource Access
→
Security Risk

The proposed solution introduces source-to-sink data-flow analysis, public vulnerability dataset preparation, GNN-based vulnerability detection, static security analysis, controlled SSRF testing, finding validation, risk prioritization, defensive configuration, and post-remediation security testing.

Attack

Specific Attack: Server-Side Request Forgery (SSRF)

The controlled attack scenario evaluates whether user-controlled input can influence a server-side request and cause the application to contact an unintended destination.

The objective is to identify potentially unsafe source-to-sink paths, determine whether appropriate destination restrictions are implemented, and validate any suspected SSRF behavior using an authorized test endpoint within the isolated laboratory.

Attack Behavior :
Unauthorized Input Source
→
User-Controlled URL or Request Parameter
→
Application Processes the Input
→
Input Reaches a Server-Side Request Function
→
Destination Validation Is Missing or Insufficient
→
Server Attempts to Contact an Unintended Destination
→
Controlled SSRF Behavior Assessment
→
Security Finding
→
Input Validation and Destination Restriction
→
Post-Remediation Validation

Security Concept

Graph Neural Network-Based Source-to-Sink Data-Flow Analysis

The primary security concept is GNN-Based Source-to-Sink Data-Flow Analysis for identifying potentially vulnerable server-side request operations.

The objective is not simply to identify a request-handling function. The assessment examines how user-controlled input travels through application code, whether it reaches a sensitive request sink, and whether validation or destination restrictions protect that operation.

The source code is represented as a graph containing nodes for relevant code elements and edges representing data dependencies or other relationships between those elements. A public vulnerability dataset provides suitable labeled examples for training and evaluating the GNN. The trained model is then applied to compatible source-code graphs to identify potentially unsafe data-flow patterns.

The assessment follows:
Application Source-Code Review
→
User-Input Source Identification
→
Server-Side Request Sink Identification
→
Source-to-Sink Data-Flow Extraction
→
Graph Construction
→
Public Dataset Preparation
→
GNN Training and Evaluation
→
AI-Based SSRF Risk Prediction
→
Static Security Analysis
→
Controlled SSRF Testing
→
Finding Validation
→
Risk Assessment
→
Security Remediation
→
Post-Remediation Testing

Defensive Mechanism

The security concept defines the overall security strategy.

The following are the specific defensive mechanisms implemented.

Source-to-Sink Data-Flow Analysis :

Relevant application code is examined to trace user-controlled input through intermediate functions to potentially sensitive server-side request operations.

Purpose: Identify potentially unsafe data flows that require further security validation.

Graph-Based Source-Code Representation

Application code relationships are represented as graph nodes and edges for analysis by the GNN.

Purpose
  • Preserve source-to-sink relationships for graph-based vulnerability detection.

Public Vulnerability Dataset Validation

A suitable public vulnerability dataset is reviewed for relevant source-code examples, labels, and information required for graph construction.

Purpose
  • Provide appropriate examples for GNN training and performance evaluation.

GNN-Based Vulnerability Detection

The GNN is trained using prepared graph representations to identify patterns associated with potentially vulnerable data flows.

Purpose
  • Prioritize suspicious source-code paths for further security investigation.

Input Validation

User-controlled values are validated before they are used in server-side request operations.

Purpose
  • Prevent malformed or unauthorized input from controlling sensitive request behavior.

Destination Allowlisting

Server-side requests are restricted to explicitly approved destinations and permitted protocols according to the application's requirements.

Purpose
  • Prevent requests to unauthorized destinations and reduce SSRF exposure.

Static Security Analysis

Semgrep Community Edition is used to identify suspicious request-handling patterns and potential validation weaknesses in the source code.

Purpose
  • Provide independent code-level evidence to support GNN findings.

Controlled SSRF Testing

An authorized test endpoint is used to assess whether manipulated input can influence server-side request behavior.

Purpose
  • Validate suspected SSRF weaknesses without accessing unauthorized resources.

Risk-Based Prioritization

Findings are evaluated using source-code evidence, GNN predictions, static-analysis results, and controlled-test observations.

Purpose
  • Establish remediation priorities based on verified evidence and potential security impact.

Post-Remediation Validation

The relevant source-code paths and controlled requests are reassessed after implementing defensive changes.

Purpose
  • Confirm that identified weaknesses have been addressed and legitimate application behavior remains functional.

Security Tools

Primary AI-Based Vulnerability Detection Tool: PyTorch Geometric

PyTorch Geometric is used to implement the Graph Neural Network that analyzes graph-structured source-code data.

Purpose
  • Train the selected GNN architecture
  • Process source-code graph representations.
  • Predict potentially vulnerable data-flow patterns.
  • Evaluate model performance using held-out samples.
  • Generate prediction results for security review.

Source-Code Analysis Tool: Python

Python is used to process source-code information, construct graphs, prepare dataset samples, and coordinate the GNN analysis workflow.

Purpose
  • Extract relevant source-code information.
  • Prepare graph features and dataset labels.
  • Process data-flow relationships.
  • Evaluate model predictions.
  • Generate structured analysis results.

Static Security Analysis Tool: Semgrep Community Edition

Semgrep Community Edition is used to scan application source code for suspicious request-handling operations and potential security weaknesses.

Purpose
  • Identify relevant source-code patterns.
  • Review potentially unsafe input handling.
  • Compare static-analysis findings with GNN predictions.
  • Support source-code investigation.
  • Provide evidence for security findings.

Web Application Security Testing Tool: OWASP ZAP

OWASP ZAP is used to inspect HTTP requests and responses and support controlled testing of the authorized application.

Purpose
  • Inspect application requests and responses.
  • Identify relevant request parameters.
  • Support testing of a suitable SSRF endpoint.
  • Record HTTP evidence.
  • Validate application behavior after remediation.

Target Application: NodeGoat

NodeGoat is the selected Node.js application for source-code inspection and security assessment.

Purpose
  • Provide the application source code for analysis.
  • Identify relevant input-processing functions.
  • Inspect potential server-side request operations.
  • Establish the application testing scope.
  • Support source-to-sink analysis.

GNN Training Dataset: Public Vulnerability Dataset

A suitable public vulnerability dataset provides code examples and labels for training and evaluating the GNN. Its relevance to SSRF and its suitability for graph construction must be verified before use.

Purpose
  • Provide public source-code examples.
  • Support vulnerable and non-vulnerable sample preparation.
  • Enable model training and evaluation.
  • Support performance measurement.
  • Improve reproducibility of the analysis.

Target Platform: Ubuntu Linux

Ubuntu provides the working environment for application analysis, dataset preparation, and model development, subject to available system permissions and resources.

Purpose
  • Maintain the source-code workspace.
  • Run Python-based analysis scripts.
  • Store datasets and assessment evidence.
  • Support application configuration.
  • Maintain the controlled testing environment.

Security Testing Platform: Kali Linux

Kali Linux provides the controlled penetration-testing environment for authorized web application security testing.

Purpose
  • Perform authorized application assessments.
  • Run Nmap when network-service discovery is required.
  • Use OWASP ZAP for web request inspection.
  • Validate controlled SSRF test behavior.
  • Perform post-remediation security testing.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated laboratory containing the application and security-testing virtual machines.

Purpose
  • Host Ubuntu and Kali Linux virtual machines.
  • Configure isolated virtual networking.
  • Separate the application from the testing environment.
  • Support repeatable assessments.
  • Reduce unintended interaction with external systems.

Data Processing Libraries: Pandas and NumPy

Pandas and NumPy support dataset inspection, preprocessing, and analysis of numerical evaluation results.

Purpose
  • Inspect dataset structure and labels.
  • Prepare and validate dataset samples.
  • Analyze model evaluation results.
  • Calculate or organize classification metrics.
  • Produce structured result summaries.

Security Findings and Reporting Tool: Python-Based Assessment Report

A structured assessment report is used to organize GNN predictions, source-code evidence, static-analysis findings, controlled-test observations, and remediation results.

Purpose
  • Record potential and verified findings.
  • Document supporting source-code evidence.
  • Distinguish model predictions from confirmed vulnerabilities.
  • Track remediation requirements.
  • Compare pre-remediation and post-remediation results.
  • Produce structured security-validation documentation.

Process

STEP 01

Prepare the Isolated SSRF Security Testing Environment

  • Create an isolated cybersecurity laboratory using VirtualBox.
  • Configure Ubuntu as the application-analysis and development environment.
  • Configure Kali Linux as the controlled penetration-testing system.
  • Establish the required virtual network communication between the systems.
  • Verify that the virtual machines can communicate as required for the assessment.
  • Ensure that the testing environment does not expose vulnerable services to public networks.
  • Create separate working directories for source code, datasets, scripts, evidence, and reports.
  • Record the initial laboratory configuration and authorized testing scope.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Obtain and Inspect the NodeGoat Application

  • Obtain NodeGoat from its official public source repository.
  • Record the repository location and selected application version.
  • Review the application directory structure.
  • Identify relevant routes, controllers, and request-processing functions.
  • Search for operations that make server-side requests or process user-supplied URLs.
  • Trace candidate input values through relevant functions and variables.
  • Determine whether the selected version contains a suitable SSRF-related source-to-sink path.
  • If no suitable path exists, document the limitation and identify a compatible, controlled test endpoint.
Tools: NodeGoat + Git + Python + Ubuntu
STEP 03

Configure the Application Analysis Environment

  • Configure the NodeGoat application according to the setup instructions for the selected version.
  • Install the required application dependencies inside the isolated laboratory.
  • Verify that the application starts successfully.
  • Confirm that its normal functionality is accessible within the laboratory.
  • Review application logs for startup and dependency errors.
  • Identify the source files that contain relevant input-processing logic.
  • Record the application version and configuration.
  • Ensure that any additional SSRF test functionality is explicitly documented and isolated.
Tools: NodeGoat + Node.js + npm + Ubuntu
STEP 04

Prepare the Public Vulnerability Dataset

  • Select a publicly available vulnerability dataset suitable for source-code analysis.
  • Verify the dataset source and permitted usage conditions.
  • Inspect its code samples, vulnerability labels, and metadata.
  • Determine whether relevant SSRF examples are available.
  • Check whether the examples contain sufficient information for source-to-sink graph construction.
  • Identify incomplete, duplicated, or irrelevant records.
  • Record the dataset source and the selection criteria.
  • If suitable SSRF examples are unavailable, document the limitation and identify an appropriate alternative before proceeding with SSRF-specific model training.
Tools: Public Vulnerability Dataset + Python + Pandas + Ubuntu
STEP 05

Process and Prepare the Dataset

  • Load the selected public dataset using Python.
  • Inspect the source-code samples and their associated labels.
  • Remove unusable or duplicated records where appropriate.
  • Normalize supported source-code representations without removing security-relevant information.
  • Separate vulnerable and non-vulnerable examples according to their documented labels.
  • Identify samples that lack sufficient information for reliable graph construction.
  • Split the selected data into training, validation, and testing subsets.
  • Check for duplicate or near-duplicate samples across the subsets to reduce data leakage.
Tools: Python + Pandas + NumPy + Public Vulnerability Dataset
STEP 06

Configure the GNN Development Environment

  • Create a dedicated Python virtual environment for model development.
  • Install compatible versions of PyTorch and PyTorch Geometric.
  • Verify that the required libraries import successfully.
  • Run a basic graph-processing test to validate the environment.
  • Select a GNN architecture appropriate for the graph representation and dataset size.
  • Configure the model to run on the available CPU if GPU acceleration is unavailable.
  • Check memory usage and processing requirements.
  • Record the installed library versions and selected model configuration.
Tools: Python + PyTorch + PyTorch Geometric + Ubuntu
STEP 07

Construct Source-to-Sink Data-Flow Graphs

  • Identify user-input sources in the selected application code.
  • Locate functions or operations that may initiate server-side requests.
  • Trace relevant input values through intermediate variables and functions.
  • Represent relevant code elements as graph nodes.
  • Create edges representing supported data dependencies and function relationships.
  • Prepare graph features for the selected GNN architecture.
  • Associate graph examples with dataset labels where reliable labels are available.
  • Validate sample graphs against the original source code before processing the remaining examples.
Tools: Python + NodeGoat + PyTorch Geometric
STEP 08

Train the Graph Neural Network Model

  • Load the prepared graph representations and corresponding labels.
  • Use the training subset to train the selected GNN architecture.
  • Configure an appropriate loss function and optimization method.
  • Monitor training and validation performance across training epochs.
  • Check for overfitting and other signs of poor model generalization.
  • Adjust model parameters when justified by validation results.
  • Save the trained model and its configuration.
  • Record the training settings and observed performance for reproducibility.
Tools: Python + PyTorch + PyTorch Geometric + Public Vulnerability Dataset
STEP 09

Evaluate GNN Model Performance

  • Load the held-out test graphs that were not used during training.
  • Generate predictions using the trained GNN.
  • Compare model predictions with the available ground-truth labels.
  • Calculate precision, recall, F1-score, and other suitable classification metrics.
  • Review false positives and false negatives.
  • Examine whether class imbalance affects the evaluation results.
  • Check for possible data leakage between training and testing samples.
  • Record the evaluation results and document the model's limitations.
Tools: Python + PyTorch Geometric + Pandas + NumPy
STEP 10

Analyze NodeGoat Source Code Using the GNN

  • Identify the relevant source files and request-processing functions.
  • Locate candidate user-input sources and server-side request sinks.
  • Trace the relationships between input values and request-handling operations.
  • Construct compatible graphs for the relevant source-to-sink paths.
  • Apply the trained GNN to the prepared graphs.
  • Record the model predictions and associated source-code locations.
  • Inspect predicted paths for validation checks and destination restrictions.
  • Classify the results as candidate findings that require further security verification.
Tools: NodeGoat + Python + PyTorch Geometric + Git
STEP 11

Perform Static Security Analysis

  • Scan the relevant application source code using Semgrep Community Edition.
  • Review findings associated with request-handling functions and user-controlled input.
  • Inspect whether input validation and destination restrictions are implemented.
  • Compare static-analysis results with the GNN predictions.
  • Investigate paths detected by one method but not the other.
  • Review the surrounding source code to determine whether the findings are applicable.
  • Record relevant source-code locations and supporting evidence.
  • Prepare a list of candidate issues for controlled validation.
Tools: Semgrep Community Edition + NodeGoat + Python
STEP 12

Prepare the Controlled SSRF Assessment

  • Confirm that the selected application or documented test endpoint provides suitable SSRF-related functionality.
  • Define the authorized testing scope and controlled destination.
  • Configure a safe test destination that can demonstrate server-side request behavior.
  • Establish a baseline using a normal permitted request.
  • Prepare authorized test inputs to evaluate destination restrictions.
  • Ensure that the test does not target unauthorized systems or real internal infrastructure.
  • Record the expected secure behavior and evidence requirements.
  • If NodeGoat does not contain a suitable SSRF path, document the alternative test endpoint and its relationship to the assessment.
Tools: NodeGoat or Documented Controlled Test Endpoint + Ubuntu + Kali Linux + OWASP ZAP
STEP 13

Perform Controlled SSRF Testing

  • Send authorized test requests to the confirmed endpoint.
  • Observe how the application processes the supplied input.
  • Determine whether the application initiates a server-side request to the controlled destination.
  • Check whether malformed or unauthorized destinations are rejected.
  • Record relevant request and response details.
  • Compare the observed behavior with the expected security controls.
  • Stop testing if the application attempts to access a destination outside the authorized scope.
  • Classify the result as confirmed, not reproduced, or inconclusive according to the evidence.
Tools: Kali Linux + OWASP ZAP + Controlled Test Endpoint
STEP 14

Perform Additional Web Application Security Testing

  • Configure OWASP ZAP to inspect the authorized application.
  • Browse the relevant functionality or submit permitted test requests.
  • Identify input parameters associated with the selected request-handling path.
  • Inspect HTTP requests and responses for relevant application behavior.
  • Review any security alerts associated with URL handling or server-side requests.
  • Compare the alerts with the source-code and GNN findings.
  • Record supporting HTTP evidence for further analysis.
  • Document testing limitations and avoid treating an unverified scanner alert as proof of SSRF.
Tools: OWASP ZAP + Kali Linux + NodeGoat or Controlled Test Endpoint
STEP 15

Correlate and Prioritize Security Findings

  • Review the GNN predictions and associated source-code evidence.
  • Review the Semgrep static-analysis findings.
  • Review the controlled SSRF testing results.
  • Match each candidate finding to the relevant source-to-sink path.
  • Identify findings supported by multiple independent analysis methods.
  • Investigate false positives and predictions that could not be reproduced.
  • Prioritize verified issues according to accessibility, potential impact, and available evidence.
  • Prepare a consolidated security assessment record distinguishing predicted risks from confirmed findings.
Tools: Python + PyTorch Geometric + Semgrep Community Edition + OWASP ZAP
STEP 16

Develop and Apply the SSRF Remediation Strategy

  • Review the source-code path associated with each verified weakness
  • Determine how user-controlled input reaches the server-side request operation.
  • Implement strict input validation appropriate to the application's requirements.
  • Restrict outbound requests to explicitly approved destinations.
  • Limit permitted protocols and reject unauthorized destination formats.
  • Review redirect handling where applicable to prevent destination restrictions from being bypassed.
  • Apply suitable network-level controls to restrict unnecessary outbound access.
  • Document the remediation changes and their intended security effects.
Tools: NodeGoat + Node.js + Semgrep Community Edition + Ubuntu
STEP 17

Perform Post-Remediation SSRF Testing

  • Restart or redeploy the application if required by the remediation changes.
  • Repeat source-code inspection of the affected request-handling paths.
  • Run static analysis against the updated source code.
  • Repeat the authorized test requests against the controlled endpoint.
  • Verify that approved requests continue to work as expected.
  • Confirm that unauthorized destinations are rejected according to the implemented policy.
  • Compare the new results with the original findings.
  • Record any remaining weaknesses or limitations that require further investigation.
Tools: NodeGoat + Semgrep Community Edition + OWASP ZAP + Kali Linux
STEP 18

Perform Final Security Validation and Advisory Review

  • Review the original GNN predictions and supporting source-code evidence.
  • Compare the initial and final static-analysis results.
  • Compare the original and final controlled SSRF testing observations.
  • Review the implemented input-validation and destination-restriction controls.
  • Confirm whether each verified finding has been resolved.
  • Document unresolved issues and limitations in the assessment report.
  • Record the GNN evaluation results and relevant performance metrics.
  • Include the pre-remediation and post-remediation evidence.
  • Document the security impact and recommendations for further improvement.
  • Finalize the source-to-sink analysis and SSRF security-validation report.
Tools: PyTorch Geometric + Semgrep Community Edition + OWASP ZAP + Python + NodeGoat

Outcome

A NodeGoat application-analysis environment is established within an isolated VirtualBox laboratory, providing a controlled environment for source-code inspection and authorized SSRF security testing.

The selected public vulnerability dataset is inspected and prepared for model development, providing suitable source-code examples and labels for GNN training and evaluation where SSRF-relevant data is available.

Source-to-sink data-flow graphs are constructed from relevant code elements, representing relationships between user-controlled input, intermediate processing functions, validation operations, and potentially sensitive server-side request sinks.

A Graph Neural Network is trained and evaluated using the prepared graph representations, producing performance metrics that help assess its ability to identify patterns associated with potentially vulnerable data flows.

The NodeGoat source code is analyzed using the trained GNN, identifying suspicious data-flow paths that require further investigation through source-code inspection and independent security-analysis methods.

Static security analysis is performed using Semgrep Community Edition, allowing GNN predictions to be compared with code-level findings and helping identify potentially unsafe request-handling patterns.

Controlled SSRF testing is performed against a confirmed suitable test endpoint, determining whether user-controlled input can influence server-side request behavior and whether destination restrictions operate as intended.

The security findings are correlated and prioritized using model predictions, source-code evidence, static-analysis results, and controlled-test observations, distinguishing potential vulnerabilities from issues supported by validation evidence.

Appropriate defensive controls, including input validation, destination allowlisting, and outbound-request restrictions, are applied to verified weaknesses, reducing the risk of unauthorized server-side requests.

The complete source-to-sink graph construction, public dataset preparation, GNN-based SSRF detection, static security analysis, controlled SSRF testing, finding validation, remediation, and post-remediation security-validation workflow is documented, with the final results reflecting the actual implementation and testing evidence.