How I Went From a Call for Papers to Publishing My First Research Paper

It started in early February. My college’s Director posted something about a call for papers, and honestly, I had no clue what that even meant. I’m a Computer Science student in my third semester, and research papers felt like something PhD people do in labs. But I was curious, so I went and asked her what it was all about. She explained everything: how research works, what a call for papers means, and how submissions get reviewed. Somewhere in that conversation, a thought clicked in my head: why not me?

I went to my HOD next and told her I wanted to try this. She said sure, she’d help me with it. Just like that, I had support from two people, and now I needed an actual topic. I’m a cyber guy, so the choice was kind of obvious. The OWASP Top 10 is something I keep going back to, so the question I settled on was simple: can machine learning detect the attacks that OWASP talks about, especially the injection ones?

Here’s why that question matters. Most web apps are protected by Web Application Firewalls and signature-based detection. They work by matching requests against known attack patterns, which is fine for attacks they’ve already seen. The problem is that attackers don’t send the same payload every time. They encode it, obfuscate it, split it up, and suddenly the signature doesn’t match. The idea behind my paper was to use machine learning as a complementary layer that learns what malicious requests look like statistically, instead of depending on exact patterns.

Now let me break down exactly what I did, because I think the technical part is the real story.

The attacks I targeted

I focused on SQL injection, Cross-Site Scripting (XSS), and command injection, all of which fall under A03: Injection in the OWASP Top 10 (2021). The classic SQLi example is a login query like SELECT * FROM users WHERE username='admin' AND password='1234'. If an attacker sends ' OR '1'='1 as the input, the query becomes SELECT * FROM users WHERE username='' OR '1'='1'. Since '1'='1' is always true, authentication gets bypassed. And that’s the basic version. The same flaw also enables UNION-based data exfiltration, blind inference with boolean or time-based techniques, and in some setups even remote code execution. Detection is hard because payloads can be URL-encoded or obfuscated, and legitimate queries can contain SQL-like syntax too.

The dataset

I used the CSIC 2010 HTTP dataset, a well-known benchmark of requests aimed at an e-commerce application. It has 36,000 normal requests and 25,065 anomalous ones, covering SQLi, XSS, buffer overflow, and other attack categories. I used a 70/30 stratified train-test split, so both sets kept the same ratio of normal and malicious traffic. That gave a hold-out test set of 18,320 samples: 10,800 normal and 7,520 attacks.

Feature engineering

A model can’t read raw HTTP requests, so every request had to be converted into numbers. I extracted eight features per request, and all of them were min-max normalized before training.

Feature	What it captures
Input Length	Character count of the request body; injection payloads tend to be longer
Special Char Frequency	Count of ', ", ;, (, ), =, -- as SQL/XSS indicators
SQL Keyword Count	Keywords such as SELECT, UNION, OR, and DROP
Script Tag Presence	Presence of <script> or javascript:
Parameter Count	Number of GET/POST parameters, potentially indicating abnormal probing
Request Entropy	Shannon entropy of the request, useful for identifying encoded payloads
Path Depth	Directory levels in the URL, potentially indicating path traversal
Content Mismatch	Difference between declared and actual content types

I defined the features formally so the work is reproducible. Input length is L = |c|, where c is all the GET/POST parameter values concatenated. Special character frequency is f_sc = |{c_i ∈ c : c_i ∈ S}| / L, and SQL keyword count is the sum of keyword occurrences in the lowercased input. Together, these three capture the lexical signature of injection payloads.

The entropy feature

This is the one I’m proudest of. Shannon entropy, H(c) = −Σ p_i log₂(p_i), measures how random the bytes in a request are. Normal natural-language input sits around 3.5 to 4.2 bits per byte, while Base64 or URL-encoded payloads land around 4.5 to 5.5. So even if an attacker hides a keyword by encoding it, the request still has a different statistical fingerprint. It gives a first line of defense against encoding-based evasion without decoding the payload at inference time, which matters if you want it fast enough to sit in front of a real firewall. Most of the HTTP-level classifiers I reviewed in related work rely only on keyword presence, so this was my attempt at doing something a bit different.

The models

I trained and compared four classifiers: Random Forest, Decision Tree, SVM (RBF kernel), and Logistic Regression. Everything ran on Python 3.10 with scikit-learn 1.3. For Random Forest, I used n_estimators=100, max_features='sqrt', and min_samples_leaf=1, following Breiman’s original recommendations. For the SVM, I tuned C and gamma with a 5-fold cross-validation grid search over C ∈ {0.1, 1, 10} and γ ∈ {0.001, 0.01, 0.1}. I also applied stratified 5-fold cross-validation to all models because I didn’t want a result that only looked good on one lucky split.

The results

Classifier	Accuracy	Precision	Recall	F1
Random Forest	98.7%	0.989	0.984	0.986
Decision Tree	96.2%	0.961	0.964	0.962
SVM (RBF)	95.8%	0.957	0.959	0.958
Logistic Regression	91.4%	0.912	0.916	0.914

Random Forest won on every metric. Its cross-validated accuracy was 98.4% (σ = 0.003), so the 98.7% hold-out score isn’t a lucky split. The Decision Tree showed higher variance (σ = 0.011), and the SVM was stable (σ = 0.004) but way more expensive, taking 42.3 seconds to train against 3.1 seconds for Random Forest, around 14 times slower.

Accuracy alone can hide problems, so I went into the confusion matrix. On the 18,320-sample test set, Random Forest produced 130 false positives (a 1.2% false positive rate, roughly one legitimate request in 83 flagged) and 120 false negatives (1.6% FNR). The Matthews Correlation Coefficient came out at 0.973, which tells you the model performs genuinely well on both classes instead of leaning on the majority class. The Decision Tree produced 278 false positives (2.6% FPR), which is why I picked Random Forest as the practical choice. A firewall that blocks real users every few minutes will get switched off by an angry admin pretty quickly.

Which features actually mattered

Using Gini importance from the Random Forest, the ranking was: SQL Keyword Count (31.2%), Special Character Frequency (22.8%), Input Length (13.4%), Request Entropy (11.7%), Script Tag Presence (9.3%), Parameter Count (5.8%), Path Depth (3.6%), and Content-Type Mismatch (2.2%). The top three alone covered 67.4% of the model’s decisions. That told me something interesting: injection attacks are mostly characterized by lexical anomalies in the input, not by structural weirdness in the HTTP request.

Since Gini importance can be biased toward high-cardinality features, I also ran permutation importance as a check. SQL Keyword Count and Special Character Frequency stayed in the top two, losing 4.1% and 3.2% accuracy respectively when shuffled. Request Entropy actually moved up to fourth place (it was sixth under Gini), which supported keeping it as an anti-evasion feature.

Speed

Feature extraction takes about 0.8 ms per request, and Random Forest inference across 100 trees adds roughly 2.3 ms, so the whole pipeline stays under 5 ms on a standard 2.4 GHz CPU core. That’s compatible with synchronous WAF operation. Some CNN-based approaches in the literature reach similar accuracy but need GPU acceleration and offer no interpretability, which makes them harder to deploy in constrained environments. Mine uses eight interpretable features on plain CPU hardware.

The limitations

I put the weaknesses in the paper too, because a paper that pretends it has none isn’t worth much. CSIC 2010 is an old dataset and may not represent modern obfuscation. An attacker who splits keywords across parameters or uses hex encoding could push the SQL keyword count to zero while keeping the attack intact. So the next steps are adversarial testing with tools like SQLMap’s tamper scripts, retraining on mutated payloads, trying newer datasets like CICIDS 2018, and adding SHAP so analysts can see why a request was flagged.

The conference and the publication

Okay, now back to the story. On 29 March, there was a conference at my college, and I presented all of this there. And you know what? I was the youngest person in the room, hahaha. It was nerve-wracking, but also one of the best experiences I’ve had. Standing in front of professors and researchers and explaining something I built myself felt unreal. Then months passed. In August, I asked the Director about the status, and she said the paper was under review. I said alright and just waited. In the first week of October, I got a link saying my paper was published. Man, I was so happy. This was my first time presenting something at that level, and now it was in a journal with my name on it.

You can read the published paper here: Read the published paper

The whole thing was a great experience, and the networking was a big part of it. I met people I would never have met just sitting in my room doing CTFs.

One more thing I want to say. Some people won’t appreciate what you do, no matter how good it is. That’s just how it goes. Don’t waste energy on them. Keep focusing on yourself and keep growing. Your only competition is you. If you’re even 1% better than you were yesterday, congrats, you’re growing.

Also, there’s another conference on 13 November that I’m going to attend. I won’t reveal the topic yet, but I’ve put so many hours into that research, like omg dude, I literally haven’t slept for days. Once I give my presentation, I’ll make it public. I’ll just say it’s healthcare related. 😄

I’ll also be making some changes to this site soon, maybe with animations and all, so keep an eye out. Until next time.