Pith. sign in

REVIEW 4 major objections 4 minor 36 references

Detecting and Mitigating SQL Injection Vulnerabilities in Web Applications

T0 review · 4 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Prepared statements close a detected SQL injection hole in a PHP-MySQL test site.

desk verdict Routine SQLi testbed write-up with honest limitations but no new research content; the clean-rescan 'absence' claim is overstated. read the letter →

arxiv 2506.17245 v1 pith:W35KXZNY submitted 2025-06-07 cs.CR

Sagar Neupane This is my paper
classification cs.CR
keywords SQLinjectionpenetrationtestingOWASPZAPsqlmappreparedstatementsPDOPHP-Myvulnerabilityremediation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper builds a deliberately vulnerable PHP-MySQL e-commerce site, scans it with OWASP ZAP, confirms the flagged SQL injection with sqlmap, and then patches the vulnerable page with PHP PDO prepared statements. The central claim is that input sanitization and prepared statements are effective, evidenced by a before-and-after test: the product-detail page allowed database enumeration and credential extraction, and the identical scans after patching reported no exploitable SQL injection. The study matters because it demonstrates a concrete, repeatable workflow for small teams—automated detection, confirmed exploitation, targeted remediation, and re-scan—against a vulnerability class that is still listed among the most dangerous web flaws. It also shows the practical consequences of unsanitized query concatenation in realistic terms: admin credentials, customer records, and billing details were all retrievable before the patch.

What carries the argument

The central mechanism is the PDO prepared statement: SQL text is parsed once with placeholders, and each user input is bound as data, so a payload like ' OR 1=1-- cannot become part of the query structure. On the detection side, OWASP ZAP is used as an automated vulnerability scanner to flag CWE-89, sqlmap is used to confirm exploitability and measure impact, and Nmap supports initial reconnaissance of the localhost test environment. The testbed, a deliberately vulnerable PHP-MySQL shopping site on XAMPP, provides the controlled target where the before-and-after comparison is performed.

What would settle it

Run a set of SQL injection probes that the scanners do not include by default—time-based blind payloads such as SLEEP(5) with URL or hex encoding, second-order injection via stored user data, and malformed multipart parameters—against the patched detail.php. Any response delay, database error, or unexpected row in output would contradict the paper's 'absence of exploitable flaws' conclusion.

Watch

Extended reading notes

Core claim

The paper's discovery is a controlled demonstration that a real PHP-MySQL application's SQL injection weakness—a GET parameter on detail.php concatenated directly into a database query—was found by OWASP ZAP as CWE-89, exploited by sqlmap to enumerate the ecom database and dump admin, customer, and billing data, and then eliminated by switching the query to a PDO prepared statement with parameter binding and custom error handling. On the paper's own terms, the clean OWASP ZAP and sqlmap re-scans after deployment of the patch confirm the absence of exploitable flaws, and the author presents this as evidence for the effectiveness of parameterized queries and input sanitization against SQL injection. The author's broader claim is that this pattern generalizes: regular penetration testing plus secure coding practice keeps PHP-MySQL web applications safe from this class of attack.

Load-bearing premise

The evidence that the vulnerability is gone rests on the completeness of OWASP ZAP and sqlmap scans; if those tools miss a variant, the patched site could still be exploitable.

Editorial extensions

If this is right

  • Parameterized queries with PDO become the demonstrated baseline fix for PHP-MySQL SQL injection, not just theoretical guidance.
  • A clean automated re-scan after patching is treated by the paper as the evidence that the vulnerability is closed.
  • Regular penetration testing with free tools can surface SQL injection flaws before they reach production.
  • Input sanitization alone is presented as insufficient; binding inputs as data is the decisive remediating step.
  • Small organizations with limited budgets can run this same scan-exploit-patch-rescan cycle using open-source tools.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: a clean result from ZAP and sqlmap is corroborating evidence, not proof of absence; payloads beyond the built-in rule sets, manual code review, or a second scanner would be needed to claim the patch is bypass-proof.
  • Editorial inference: because the test ran on localhost with no production-like traffic, the same patch might behave differently behind a load balancer, caching layer, or older PHP runtime, though nothing in the paper suggests PDO itself fails there.
  • Editorial inference: the same unsanitized-input root cause also feeds cross-site scripting and request forgery, so the workflow and patch pattern plausibly extend to those classes, but the paper did not test them.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper reports a penetration-testing case study on a locally built PHP-MySQL e-commerce application. The author describes using OWASP ZAP and sqlmap to detect a SQL injection vulnerability on the product detail page (detail.php), exploiting it to extract database contents, then patching the application with PDO prepared statements and parameter binding. A rescan with the same tools is reported as clean, and the paper concludes that input sanitization and prepared statements are effective mitigations. The manuscript also provides literature review, recommendations, limitations, and future work.

Significance. If the claims were fully supported, the paper would offer a reproducible, hands-on demonstration of a standard SQL injection detection-and-remediation workflow, which could be useful for teaching or practitioner-oriented venues. Strengths include the controlled testbed, the use of established tools (OWASP ZAP, sqlmap), and an explicit limitations section. However, the central contribution is not novel: the effectiveness of prepared statements against SQL injection is well-established consensus, and the paper's own evidence for the headline claim is a clean automated rescan rather than a proof of absence. The manuscript also lacks a verifiable repository link, contains an incomplete sentence in Section 9, and uses at least one irrelevant citation. These issues make the paper unsuitable for acceptance in its current form, but they are localizable and fixable.

major comments (4)
  1. [§7.3 and §9] The claim in Section 9 that rescanning 'confirmed the absence of SQL injection flaws' is not supported by the reported evidence. Section 7.3 states that verification consisted of rescanning with OWASP ZAP and re-running sqlmap with 'identical attack parameters.' A clean result from two automated scanners reusing the previously successful payloads cannot establish the absence of exploitable flaws, because scanners have known false-negative rates and identical parameters retest only the originally successful vectors. Section 10 itself acknowledges that reliance on a limited toolset and constrained manual testing may have overlooked sophisticated attack vectors. The claim should be softened to state that no SQL injection was detected by those tools under the tested scenarios, and the conclusion in Section 12 should be revised accordingly.
  2. [§7.1 vs §7.3] There is a scope mismatch that undermines the comprehensiveness of the assessment. Section 7.1 lists product detail, login, and checkout pages as in scope, but the patching phase in Section 7.3 only describes remediating detail.php. If login and checkout were not vulnerable, the paper should say so explicitly; if they were not tested or not patched, the conclusion that the vulnerability was eliminated across the application is incomplete. This needs to be clarified in the methodology and reflected in the results.
  3. [§9 and References] Section 9 contains an incomplete sentence and a misdirected citation: 'by establishing a (Hahn et al., 2015).' The cited work by Hahn et al. is about a kill-chain security analysis framework for cyber-physical systems and is not relevant to the sentence being completed. The broken sentence must be repaired, and the citation either removed or replaced with an appropriate reference. Similarly, Section 6 cites Downey and Fellows (2012), 'Parameterized Complexity,' as support for parameterized queries in SQL; that reference is a complexity-theory monograph, not a source on SQL prepared statements, and should be corrected.
  4. [§1 and Abstract] The paper claims that 'The complete source code and datasets used in this research, are hosted on GitHub. The repository can be accessed here,' yet no repository URL appears anywhere in the manuscript. Without a verifiable artifact, the reproducibility claim cannot be checked, and the figures referenced in the text (e.g., Figures 1–4) are not present in the provided manuscript. The authors should include the full repository URL, confirm that the code and datasets are actually accessible, and ensure figures are embedded, or remove the unverifiable claims.
minor comments (4)
  1. [§4, Objective 2] Objective 2 lists Burp Suite as a tool to be used, but the methodology in Section 7 does not mention Burp Suite; the tool list should be aligned or the discrepancy explained.
  2. [§6] Several literature-review paragraphs state that gaps 'led this paper to propose' methods that the paper does not actually implement, such as 'a comprehensive detection approach' and 'adaptive, scalable mitigation strategies.' The claims about the paper's contribution should be toned down to match what is actually delivered.
  3. [§7.2] The text alternates between 'OW ASP ZAP' and 'OWASP ZAP'; the spacing typo should be fixed throughout.
  4. [§7.2.1] The manual injection payload is written inconsistently as 'OR 1 = 1' and '' OR 1=1 –'; the payloads should be quoted consistently and explained as illustrative examples.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is an empirical before/after case study with no derivation chain, fitted parameters, or load-bearing self-citation.

full rationale

The paper makes no mathematical or definitional derivation: it reports a penetration test on a purpose-built PHP/MySQL application (Section 7), a vulnerability confirmed by OWASP ZAP and sqlmap (Section 7.2), a patch using PDO prepared statements (Section 7.3), and a post-patch rescan. There are no fitted parameters, no closed-form equations, and no result that is defined in terms of the conclusion. The recommendation that prepared statements and input validation mitigate SQLi is established external consensus (e.g., OWASP guidelines; Downey and Fellows, 2012), and the case study is an empirical demonstration rather than a prediction. The strongest overstatement is Section 9's 'confirmed the absence of exploitable flaws' based on a clean rescan with identical attack parameters; this is an inference-strength limitation acknowledged in Section 10 ('reliance on a limited toolset ... introduced potential biases', 'heavy dependence on automated scans'), but it is not circular because the post-patch scan outcome is not built into the patch definition or into the tools' output by construction. The only self-referential feature is that the testbed was authored by the researcher, but a controlled test on one's own application is a valid experimental design, not a circular argument. No load-bearing self-citation, uniqueness theorem, or ansatz-by-citation appears; the reference list is external and none of the cited results is used to define the paper's target claim. Therefore the circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No free parameters are used; the paper is a case study. The axioms are domain assumptions about tool reliability, the completeness of post-patch scans, and the representativeness of the testbed.

assumptions (3)
  • domain assumption OWASP ZAP and sqlmap accurately identify SQL injection vulnerabilities
    The entire detection claim relies on the reliability of these tools, which the paper does not independently validate.
  • domain assumption The absence of detections in the post-patch scan implies the vulnerability is fully mitigated
    The paper assumes that a clean ZAP/sqlmap scan is sufficient to prove the fix, without testing for bypasses or edge cases.
  • domain assumption The self-built testbed is representative of real-world PHP-MySQL applications
    The paper restricts testing to a single locally developed e-commerce app; the abstract and Section 8 generalize the findings to web applications broadly, which requires this assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Detecting and Mitigating SQL Injection Vulnerabilities in Web Applications." pith.science (2026). https://pith.science/paper/W35KXZNY

@misc{pith2026250617245,
  author       = {Pith},
  title        = {Pith review of: Detecting and Mitigating SQL Injection Vulnerabilities in Web Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/W35KXZNY}},
  note         = {Machine review of arXiv:2506.17245}
}
read the original abstract

SQL injection (SQLi) remains a critical vulnerability in web applications, enabling attackers to manipulate databases through malicious inputs. Despite advancements in mitigation techniques, the evolving complexity of web applications and attack strategies continues to pose significant risks. This paper presents a comprehensive penetration testing methodology to identify, exploit, and mitigate SQLi vulnerabilities in a PHP-MySQL-based web application. Utilizing tools such as OWASP ZAP, sqlmap, and Nmap, the study demonstrates a systematic approach to vulnerability assessment and remediation. The findings underscore the efficacy of input sanitization and prepared statements in mitigating SQLi risks, while highlighting the need for ongoing security assessments to address emerging threats. The study contributes to the field by providing practical insights into effective detection and prevention strategies, supported by a real-world case study.

Figures

Figures reproduced from arXiv: 2506.17245 by the authors.

Figure 1
Figure 1. SQL injection attack flow (Hasan et al., 2019). [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. CWE-89 (SQL Injection) ( MITRE Corporation, 2021). [PITH_FULL_IMAGE:figures/full_fig_p012_2.png] view at source ↗
Figure 3
Figure 3. SQL Vulnerability Discovered on ’details.php’ page. [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Dumping the ‘billing details‘ table. 7.3 Patching The patching phase focused on remediating identified SQL injection vulner￾abilities through secure code modifications, deployment, and rigorous verifi￾cation to enhance website security. The vulnerability was traced to …

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

36 extracted references · 28 canonical work pages

  1. [1]

    M. S. Aliero, I. Ghani, K. N. Qureshi, and M. F. A. Rohani. 2020. An algorithm for detecting SQL injection vulnerability using black-box testing. Journal of Ambient Intelligence and Humanized Computing 11, 1 (2020), 249--266. doi:10.1007/s12652-019-01234-6

    work page doi:10.1007/s12652-019-01234-6 2020

  2. [2]

    Alomari and R

    R. Alomari and R. Jerisat. 2021. Detecting SQL Injection Attacks Using Machine Learning Algorithms. International Journal of Advanced Computer Science and Applications 12, 4 (2021), 230--234. doi:10.14569/IJACSA.2021.0120429

    work page arXiv 2021

  3. [3]

    Al-Saleh and T

    M. Al-Saleh and T. Saito. 2021. A Framework for Automated SQL Injection Testing of Web Applications Using Machine Learning. IEEE Access 9 (2021), 7370--7383. doi:10.1109/ACCESS.2020.3048745

    arXiv 2021

  4. [4]

    Appelt, C

    D. Appelt, C. D. Nguyen, and L. Briand. 2015. Behind an Application Firewall, Are We Safe from SQL Injection Attacks? In 2015 IEEE 8th International Conference on Software Testing, Verification and Validation (ICST). IEEE, 1--10. doi:10.1109/ICST.2015.7102603

    work page arXiv 2015

  5. [5]

    Charania and V

    S. Charania and V. Vyas. 2016. SQL Injection Attack: Detection and Prevention. International Research Journal of Engineering and Technology (2016), 2395--0056

    work page 2016

  6. [6]

    Y. Chen, C. Liu, X. Wang, and Y. Wu. 2020. SQL Injection Detection Based on Deep Belief Network with Transfer Learning. IEEE Access 8 (2020), 186771--186778. doi:10.1109/ACCESS.2020.3029745

    arXiv 2020

  7. [7]

    R. G. Downey and M. R. Fellows. 2012. Parameterized Complexity. Springer Science & Business Media. 978-1-4612-0798-6

    work page 2012

  8. [8]

    D. D. Dvorski. 2007. Installing, configuring, and developing with Xampp. Skills Canada 492 (2007)

    work page 2007

Show all 36 references
  1. [9]

    Farah, M

    T. Farah, M. Shojol, M. Hassan, and D. Alam. 2016. Assessment of Vulnerabilities of Web Applications of Bangladesh: A Case Study of XSS and CSRF. In 2016 Sixth International Conference on Digital Information and Communication Technology and its Applications (DICTAP). IEEE, 74-...

    2016

  2. [10]

    V. M. Grippa and S. Kuzmichev. 2021. Learning MySQL. O'Reilly Media, Inc. 978-1-4920-8592-8

    2021

  3. [11]

    T. S. Gunawan, M. K. Lim, M. Kartiwi, N. A. Malik, and N. Ismail. 2018. Penetration testing using Kali Linux: SQL injection, XSS, Wordpress, and WPA2 attacks. Indonesian Journal of Electrical Engineering and Computer Science 12, 2 (2018), 729--737. doi:10.11591/ijeecs.v12.i2.pp729-737

    2018 doi

  4. [12]

    A. Hahn, R. K. Thomas, I. Lozano, and A. Cardenas. 2015. A multi-layered and kill-chain based security analysis framework for cyber-physical systems. International Journal of Critical Infrastructure Protection 11 (2015), 39--50. doi:10.1016/j.ijcip.2015.08.001

    2015 doi

  5. [13]

    Hasan, Z

    M. Hasan, Z. Balbahaith, and M. Tarique. 2019. Detection of SQL Injection Attacks: A Machine Learning Approach. In 2019 International Conference on Electrical and Computing Technologies and Applications (ICECTA). IEEE, 1--6. doi:10.1109/ICECTA48151.2019.8959710

    2019

  6. [14]

    Z. C. S. S. Hlaing and M. Khaing. 2020. A Detection and Prevention Technique on SQL Injection Attacks. In 2020 IEEE Conference on Computer Applications (ICCA). IEEE, 1--6. doi:10.1109/ICCA49450.2020.9098401

    2020

  7. [15]

    Hussain and S

    T. Hussain and S. Singh. 2015. A Comparative Study of Software Testing Techniques Viz. White Box Testing Black Box Testing and Grey Box Testing. IJAPRR (2015), 2350--1294

    2015

  8. [16]

    S. Jero, J. Furgala, R. Pan, P. K. Gadepalli, A. Clifford, B. Ye, R. Khazan, B. C. Ward, G. Parmer, and R. Skowyra. 2021. Practical Principle of Least Privilege for Secure Embedded Systems. In 2021 IEEE 27th Real-Time and Embedded Technology and Applications Symposium (RTAS). ...

    2021

  9. [17]

    R. A. Katole, S. S. Sherekar, and V. M. Thakare. 2018. Detection of SQL Injection Attacks by Removing the Parameter Values of SQL Query. In 2018 2nd International Conference on Inventive Systems and Control (ICISC). IEEE, 736--741. doi:10.1109/ICISC.2018.8398892

    2018

  10. [18]

    F. M. Kromann. 2018. Introducing PDO. In Beginning PHP and MySQL: From Novice to Professional. Apress, Berkeley, CA, 663--688. 978-1-4302-6043-1

    2018

  11. [19]

    Kumar, N

    R. Kumar, N. Arora, T. Gera, A. Jain, and D. Thakur. 2022. Empirical Methods, Anomaly Detection and Preventive Measures of Web Attacks. In 2022 10th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO). IEEE, 1-...

    2022

  12. [20]

    R. Kushe. 2017. Comparative Study of Vulnerability Scanning Tools: Nessus vs Retina. Security & Future 1, 2 (2017), 69--71

    2017

  13. [21]

    Labiad, M

    B. Labiad, M. Tanana, A. Laaychi, and A. Lyhyaoui. 2022. A Comparative Study of Vulnerabilities Scanners for Web Applications: Nexpose vs Acunetix. In International Conference on Advanced Intelligent Systems for Sustainable Development. Springer Nature Switzerland, Cham, 107--...

    2022 doi

  14. [22]

    S. Liao, C. Zhou, Y. Zhao, Z. Zhang, C. Zhang, Y. Gao, and G. Zhong. 2020. A Comprehensive Detection Approach of Nmap: Principles, Rules and Experiments. In 2020 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC). IEEE, 64--71. doi...

    2020

  15. [23]

    MITRE Corporation. 2021. CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). https://cwe.mitre.org/data/definitions/89.html

    2021

  16. [24]

    Nasereddin, A

    M. Nasereddin, A. ALKhamaiseh, M. Qasaimeh, and R. Al-Qassas. 2021. A Systematic Review of Detection and Prevention Techniques of SQL Injection Attacks. Information Security Journal: A Global Perspective (2021), 1--14. doi:10.1080/19393555.2021.1904248

    2021

  17. [25]

    Nájera-Gutiérrez

    G. Nájera-Gutiérrez. 2016. Kali Linux Web Penetration Testing Cookbook. Packt Publishing Ltd. 978-1-78539-291-7

    2016

  18. [26]

    Neumann and A

    T. Neumann and A. Kemper. 2015. Unnesting Arbitrary Queries. In Datenbanksysteme für Business, Technologie und Web (BTW 2015). Gesellschaft für Informatik eV, 383--402

    2015

  19. [27]

    Prandl, M

    S. Prandl, M. Lazarescu, and D. S. Pham. 2015. A Study of Web Application Firewall Solutions. In Information Systems Security: 11th International Conference, ICISS 2015, Kolkata, India, December 16-20, 2015. Proceedings 11. Springer International Publishing, 501--510. doi:10.1...

    2015 doi

  20. [28]

    Rahman, M

    A. Rahman, M. M. Islam, and A. Chakraborty. 2015. Security Assessment of PHP Web Applications from SQL Injection Attacks. Journal of Next Generation Information Technology 6, 2 (2015), 56

    2015

  21. [29]

    Sarjitus and M

    O. Sarjitus and M. B. El-Yakub. 2019. Neutralizing SQL Injection Attack on Web Application Using Server Side Code Modification. International Journal of Scientific Research in Computer Science, Engineering and Information Technology 5, 3 (2019)

    2019

  22. [30]

    P. Tang, W. Qiu, Z. Huang, H. Lian, and G. Liu. 2020. Detection of SQL Injection Based on Artificial Neural Network. Knowledge-Based Systems 190 (2020), 105528. doi:10.1016/j.knosys.2020.105528

    2020

  23. [31]

    Tripathy, R

    D. Tripathy, R. Gohil, and T. Halabi. 2020. Detecting SQL Injection Attacks in Cloud SaaS Using Machine Learning. In 2020 IEEE 6th International Conference on Big Data Security on Cloud (BigDataSecurity), IEEE International Conference on High Performance and Smart Computing, (...

    2020

  24. [32]

    V. K. Velu and R. Beggs. 2019. Mastering Kali Linux for Advanced Penetration Testing: Secure Your Network with Kali Linux 2019.1 – The Ultimate White Hat Hackers' Toolkit. Packt Publishing Ltd. 978-1-78934-056-3

    2019

  25. [33]

    S. Wear. 2018. Burp Suite Cookbook: Practical Recipes to Help You Master Web Penetration Testing with Burp Suite. Packt Publishing Ltd. 978-1-78847-623-2

    2018

  26. [34]

    K. Y. Yip, K. H. Looi, and K. L. A. Yau. 2021. An Adaptive Learning-Based SQL Injection Detection System with Ensemble Feature Selection. IEEE Access 9 (2021), 105134--105145. doi:10.1109/ACCESS.2021.3097741

    2021

  27. [35]

    K. Zhang. 2019. A Machine Learning Based Approach to Identify SQL Injection Vulnerabilities. In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1286--1288. doi:10.1109/ASE.2019.00136

    2019

  28. [36]

    Zhang, Y

    Q. Zhang, Y. Huang, J. Li, M. Li, and Q. Jiang. 2021. An Intelligent SQL Injection Detection Method Based on Machine Learning. Mathematical Problems in Engineering 2021 (2021), 1--9. doi:10.1155/2021/6682970

    2021 doi

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.