A Comparison of TF-IDF-Based SQL Injection Detection Systems Using Logistic Regression and Random…

Introduction

Web applications are constantly exposed to cyber threats, and one of the attacks that continues to be relevant is SQL Injection (SQLi).

Traditional Web Application Firewall (WAF) mechanisms commonly rely on predefined rules and signatures. While this approach can be effective against known attack patterns, it can become challenging when attackers modify payloads through obfuscation, syntax variations, or previously unseen patterns.

This led me to explore a simple question:

Can Machine Learning be placed in a reverse proxy to detect and block SQL Injection attacks in real time?

For my final project at Politeknik Negeri Bandung, I developed a prototype that combines TF-IDF, Logistic Regression, Random Forest, and a reverse proxy to detect SQL Injection before malicious HTTP requests reach the target web application.

The project also compares the performance of Logistic Regression and Random Forest to determine which model performs better for this scenario.

1. The Problem

SQL Injection occurs when an application fails to properly validate user input, allowing an attacker to manipulate SQL statements executed by the backend database.

For example, a vulnerable login mechanism may construct a query directly from user input:

WHERE username='{input}' AND password='{input}'

WHERE username='{input}' AND password='{input}'

Without proper validation or parameterization, malicious input can alter the intended SQL logic.

Traditional security mechanisms can detect many known SQL Injection patterns, but attackers can modify their payloads to bypass static signatures.

Therefore, the idea behind this project was to build an additional detection layer that could learn patterns from existing SQL Injection data.

Instead of modifying the source code of the protected application, the detection mechanism was positioned in a reverse proxy.

2. Why Machine Learning?

The main idea is relatively straightforward.

A SQL query is essentially text.

If we can transform that text into numerical features, a classification algorithm can learn the difference between:

Benign request
Malicious SQL Injection request

The research therefore uses a supervised learning approach.

The target labels are:

0 → Benign
1 → SQL Injection

0 → Benign
1 → SQL Injection

Two algorithms were selected:

Logistic Regression

Logistic Regression was selected because it is relatively lightweight and suitable for binary classification.

The model calculates the probability that an input belongs to the malicious class using a sigmoid function.

Random Forest

Random Forest works differently.

Instead of relying on a single decision tree, it combines multiple decision trees and determines the final prediction through majority voting.

This makes it interesting to compare against Logistic Regression, particularly when dealing with complex and non-linear patterns.

3. Dataset

The experiment uses the SQL Injection Dataset published by Sajid Ali on Kaggle in 2021.

The dataset contains:

The dominant attack category in the dataset is In-Band SQL Injection, particularly Tautology-Based and Union-Based SQL Injection.

The dataset was divided using an 80:20 train-test split.

4. Turning SQL Queries into Features with TF-IDF

Machine Learning models cannot directly process raw strings in the same way humans do.

Therefore, the SQL payload needs to be transformed into numerical features.

The preprocessing pipeline used in this project consists of:

TF-IDF assigns weights to terms according to how important they are within the dataset.

In this project, TF-IDF is combined with word n-grams and character n-grams.

The combination is useful because SQL Injection payloads are not always composed of conventional words.

Characters and short sequences can also contain important attack patterns.

5. The System Architecture

The implementation uses two virtual machines.

VM Client

The client is responsible for sending HTTP requests and SQL Injection payloads.

Browser and Burp Suite are used during testing.

VM Proxy

The proxy runs Ubuntu Server and acts as the main security component.

The reverse proxy listens on:

Port: 8080

Port: 8080

The Web Dummy application runs separately and is only accessible through the proxy.

The system was tested inside an isolated virtual network using a host-only environment.

The main software components were:

Python 3.14
Scikit-learn
Flask
SQLite
Telegram Bot API
Burp Suite
VirtualBox/VMware

6. What Happens When a Request Arrives?

The detection process works like this:

If the request is classified as normal, it is forwarded to the Web Dummy application.

If it is classified as SQL Injection, the proxy returns:

HTTP 403 Forbidden

HTTP 403 Forbidden

The attack is also logged and a Telegram notification is generated.

This means the application itself does not need to be modified to introduce the detection layer.

7. Real-Time Monitoring with Telegram

One of the more practical parts of the implementation is the Telegram notification system.

Whenever an attack is detected, the system automatically sends information to the administrator.

The notification contains information such as:

Attack timestamp
Source IP
Requested endpoint
Parameter containing the payload
Machine Learning algorithm used
Confidence score
Payload
Blocking status

This allows an administrator to monitor attacks without continuously watching the reverse proxy terminal.

So the system does not simply classify a request.

It also performs:

Detect → Block → Log → Notify

8. Model Configuration

The two models were configured as follows.

Logistic Regression

solver     = lbfgs
max_iter   = 1000
penalty    = l2
C          = 1.0

solver     = lbfgs
max_iter   = 1000
penalty    = l2
C          = 1.0

Random Forest

n_estimators      = 100
random_state      = 42
criterion         = gini
max_depth         = None
min_samples_split = 2
min_samples_leaf  = 1
bootstrap         = True

n_estimators      = 100
random_state      = 42
criterion         = gini
max_depth         = None
min_samples_split = 2
min_samples_leaf  = 1
bootstrap         = True

The Logistic Regression iteration limit was increased to 1000 to support convergence, while Random Forest used 100 decision trees.

9. Evaluation Method

The models were evaluated using five metrics:

Accuracy
Precision
Recall
Specificity
F1-Score

These metrics are important because accuracy alone does not tell the complete story in cybersecurity.

For example, a security model can have high accuracy but still miss a significant number of attacks.

Therefore, Recall is particularly important because it tells us how many actual SQL Injection attacks were successfully detected.

10. Dataset Testing Results

For the main experiment, 2,107 queries were tested:

1,129 SQL Injection queries
978   Normal queries

1,129 SQL Injection queries
978   Normal queries

The results were interesting.

Logistic Regression

TP = 960
TN = 966
FP = 12
FN = 169

TP = 960
TN = 966
FP = 12
FN = 169

Performance:

The biggest weakness was Recall.

The model missed 169 SQL Injection payloads, resulting in False Negatives.

11. Random Forest Results

Random Forest produced:

TP = 1071
TN = 968
FP = 10
FN = 58

TP = 1071
TN = 968
FP = 10
FN = 58

Performance:

Compared with Logistic Regression, Random Forest significantly reduced False Negatives:

Logistic Regression → 169 FN
Random Forest       → 58 FN

Logistic Regression → 169 FN
Random Forest       → 58 FN

This is particularly important from a cybersecurity perspective.

Missing an attack can be more dangerous than incorrectly flagging a benign request.

12. Logistic Regression vs Random Forest

Here is the overall comparison:

Random Forest wins across all five evaluation metrics.

The most significant difference can be seen in Recall:

Random Forest       94.86%
Logistic Regression 85.03%

Random Forest       94.86%
Logistic Regression 85.03%

That is an improvement of approximately 9.83 percentage points.

The number of missed attacks also decreased from 169 to 58.

Based on the dataset evaluation, Random Forest was therefore selected as the stronger model for the reverse proxy implementation.

13. But There Was an Interesting Twist…

The dataset results were not the end of the experiment.

I also tested the models using real SQL Injection payloads against the Web Dummy application.

The test contained five SQL Injection payloads and five normal payloads.

For example, the SQL Injection test included payloads such as:

' OR '1'='1
' OR 1=1--
' UNION SELECT NULL,NULL--
admin'--

' OR '1'='1
' OR 1=1--
' UNION SELECT NULL,NULL--
admin'--

The purpose was not simply to test the classifier.

The objective was to test the complete detection pipeline:

14. Real Query Test — Logistic Regression

Logistic Regression successfully detected all five SQL Injection payloads.

All malicious requests received:

HTTP 403 Forbidden

HTTP 403 Forbidden

All five normal requests were correctly forwarded and received:

HTTP 200 OK

HTTP 200 OK

The resulting confusion matrix was:

That means:

TP = 5
TN = 5
FP = 0
FN = 0

TP = 5
TN = 5
FP = 0
FN = 0

All five evaluation metrics reached:

100%

15. Real Query Test — Random Forest

Random Forest also detected all five SQL Injection payloads.

However, there was one unexpected result.

The normal payload:

administrator

administrator

was classified as SQL Injection.

Therefore:

TP = 5
TN = 4
FP = 1
FN = 0

TP = 5
TN = 4
FP = 1
FN = 0

The resulting performance was:

This is an interesting result because it shows that the model that performs better on a large dataset does not necessarily perform better on every small real-world test scenario.

16. The Final Comparison

The real-query experiment produced a different winner.

So there are actually two important conclusions:

Dataset evaluation → Random Forest wins

Real-query evaluation → Logistic Regression wins

And this is one of the most valuable lessons from the project.

17. Why Does This Matter?

If we only looked at the dataset results, the answer would be simple:

"Use Random Forest."

But real-world testing tells a more nuanced story.

Machine Learning performance depends heavily on:

Dataset characteristics
Feature representation
Payload variations
Training distribution
Test distribution
Threshold selection
Number and diversity of real-world samples

A model can achieve excellent benchmark performance while still producing unexpected classifications when exposed to inputs that differ from the training distribution.

This is why cybersecurity ML systems should not be evaluated using a single metric or a single dataset.

18. Learning Curve

The project also evaluated the learning behavior of both models using 5-fold cross-validation.

For Logistic Regression, training accuracy remained very high, around 0.994–0.996, while validation accuracy increased as the training dataset grew and eventually approached approximately 0.994.

This suggests that the model was able to generalize well as more training data became available.

Random Forest showed training accuracy approaching 1.000, while validation accuracy increased toward approximately 0.997 as the amount of training data increased.

These results provide additional evidence that both models can learn the patterns present in the dataset effectively.

19. Functional Testing

Beyond Machine Learning metrics, the entire security pipeline was also tested.

The following functions successfully worked:

Malicious requests were blocked using:

HTTP 403 Forbidden

HTTP 403 Forbidden

while normal requests were forwarded to the Web Dummy application.

20. Final Architecture

The complete system can therefore be summarized as:

The important part is that detection happens before the request reaches the application.

21. What I Learned from This Project

This project gave me several important lessons about implementing Machine Learning for cybersecurity.

1. Accuracy is not enough

A security model needs to minimize missed attacks.

Therefore, Recall and False Negative rates are extremely important.

2. Benchmark performance is not everything

Random Forest performed better on the 2,107-query dataset.

However, Logistic Regression achieved perfect classification in the small real-query experiment.

3. Feature engineering matters

TF-IDF was essential for transforming HTTP query text into numerical representations that could be processed by the models.

4. Deployment changes the problem

A model that works in a notebook is very different from a model operating inside a real request-processing pipeline.

The system must also handle:

Request interception
→ Feature extraction
→ Prediction
→ Blocking
→ Logging
→ Notification

Request interception
→ Feature extraction
→ Prediction
→ Blocking
→ Logging
→ Notification

5. Cybersecurity systems need multiple layers

Machine Learning should not necessarily replace traditional security mechanisms.

Instead, it can become an additional detection layer alongside conventional security controls.

22. Conclusion

This project successfully demonstrated a prototype of a real-time SQL Injection detection system using Machine Learning on a reverse proxy.

The system was able to:

Intercept HTTP requests
Extract request payloads
Transform payloads using TF-IDF
Classify requests using Logistic Regression or Random Forest
Block malicious requests with HTTP 403
Forward legitimate requests
Record attack logs
Send real-time Telegram notifications

Based on the main dataset evaluation, Random Forest provided the strongest overall performance, achieving:

96.77% Accuracy, 99.07% Precision, 94.86% Recall, 98.98% Specificity, and 96.92% F1-Score.

However, the real-query experiment demonstrated that Logistic Regression achieved 100% across all evaluation metrics, while Random Forest achieved 90% accuracy due to one false positive.

Therefore, the most important conclusion is not simply that one algorithm is universally better.

Rather:

Model selection for cybersecurity should consider both benchmark performance and behavior against realistic traffic.

The complete final project concluded that the reverse-proxy-based detection system successfully performed real-time SQL Injection detection and mitigation, while Random Forest was the strongest model according to the larger dataset evaluation.

Final Thoughts

What started as a comparison between two Machine Learning algorithms became a practical experiment in integrating Machine Learning with network security infrastructure.

The interesting part was not only achieving a high accuracy score.

It was making the model actually sit between the attacker and the application:

Receive → Analyze → Detect → Block → Log → Notify.

And that is where Machine Learning becomes more than just a model in a notebook — it becomes part of a cybersecurity system.

Contents

Introduction

1. The Problem

2. Why Machine Learning?

Logistic Regression

Random Forest

3. Dataset

4. Turning SQL Queries into Features with TF-IDF

5. The System Architecture

VM Client

VM Proxy

6. What Happens When a Request Arrives?

7. Real-Time Monitoring with Telegram

8. Model Configuration

Logistic Regression

Random Forest

9. Evaluation Method

10. Dataset Testing Results

Logistic Regression

11. Random Forest Results

12. Logistic Regression vs Random Forest

13. But There Was an Interesting Twist…

14. Real Query Test — Logistic Regression

15. Real Query Test — Random Forest

16. The Final Comparison

17. Why Does This Matter?

18. Learning Curve

19. Functional Testing

20. Final Architecture

21. What I Learned from This Project

22. Conclusion

Final Thoughts