{"id":"078402af-a9db-4242-99f3-7244316c6172","arxiv_id":"2506.17245","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":1.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"A single-case penetration test shows that prepared statements remove SQL injection vulnerabilities in a deliberately vulnerable PHP-MySQL test application.","lead":"This paper reports a hands-on test of a small, deliberately vulnerable online shop built with PHP and MySQL, scanning it with standard hacking tools, patching the SQL injection flaw with prepared statements, and rescanning to confirm the fix. It is a routine case study that confirms well-known security advice rather than introducing a new method or result.","discovery_kind":"incremental","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Section 9's 'confirmed absence of exploitable flaws' overstates what a clean rescan with two tools can prove; the paper's own Section 10 admits limited toolset and constrained manual testing, so the central demonstration is weaker than claimed.","rationale":"The paper's central claim in the abstract and Section 12 is that input sanitization and prepared statements effectively mitigate SQLi, demonstrated by a penetration test where a clean post-patch scan 'confirmed the absence of exploitable flaws' (Section 9). The reader rejected on novelty; my stress-test focuses on the evidentiary support for that demonstration. The clean scan is the only evidence for mitigation. A negative result from OWASP ZAP and sqlmap using identical parameters is not a proof of absence; both tools are known to have false negatives, and identical parameters only re-test the originally successful payloads. The manuscript's Section 10 concedes that the limited toolset introduced potential biases and that manual testing was curtailed, directly contradicting the absolute phrasing in Section 9. Additionally, Section 7.1 lists login and checkout pages as in scope, but the patch in Section 7.3 only mentions detail.php; if those endpoints were not patched or rescanned, the conclusion is incomplete. These are correctness risks, not mere novelty issues. However, because the general efficacy of prepared statements is consensus and the paper presents no new method, the verdict remains REJECT; my concern reinforces the rejection rather than changing it. The reader's weakest assumption (tool and rescan reliability) matches this concern, so agreement is 'agree.' Therefore verdict_should_be is UNCHANGED.","tokens_in":11275,"tokens_out":4238,"duration_ms":41832,"concrete_test":"Obtain the published GitHub repository and run sqlmap with a tamper suite (e.g., --tamper=space2comment,between,randomcase) against all in-scope endpoints (detail.php, login.php, checkout.php) on the patched codebase; if any endpoint remains injectable, Section 9's claim of absent exploitable flaws is falsified. If the repository cannot be retrieved, the mitigation claim is not independently verifiable.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim, as demonstrated, is that the patched application is free of exploitable SQL injection flaws (Sections 7.3 and 9). This conclusion rests entirely on a negative rescan by OWASP ZAP and sqlmap using 'identical attack parameters' (Section 7.3). A clean result from two automated scanners, re-running the same payloads that previously succeeded, is not evidence of absence: scanners have known false-negative rates, and identical parameters only re-test the originally successful attack vectors. The manuscript itself acknowledges in Section 10 that 'reliance on a limited toolset ... introduced potential biases' and that 'time and resource constraints curtailed the depth of manual testing, resulting in a heavy dependence on automated scans.' Thus the unconditional phrasing 'confirmed the absence of exploitable flaws' is not supported by the reported evidence and is in tension with the manuscript's own limitations. Furthermore, Section 7.1 lists login and checkout pages as in scope, but the patch described in Section 7.3 only mentions detail.php; if those endpoints were not remediated or rescanned, the conclusion is incomplete. The general claim that prepared statements mitigate SQLi is consensus and not the issue here; the load-bearing problem is that the paper's specific demonstration does not justify the strong claim of absence.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":11497,"tokens_out":3136,"duration_ms":35483,"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":[{"comment":"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.","section":"§7.3 and §9"},{"comment":"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.","section":"§7.1 vs §7.3"},{"comment":"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.","section":"§9 and References"},{"comment":"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.","section":"§1 and Abstract"}],"minor_comments":[{"comment":"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.","section":"§4, Objective 2"},{"comment":"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.","section":"§6"},{"comment":"The text alternates between 'OW ASP ZAP' and 'OWASP ZAP'; the spacing typo should be fixed throughout.","section":"§7.2"},{"comment":"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.","section":"§7.2.1"}],"recommendation":"major_revision","confidential_remarks":"The paper is not yet publishable: the central demonstration is plausible but the evidence as presented overstates what a clean rescan can prove, the repository link is missing, and the text has a broken sentence and citation errors. These are fixable within the manuscript's scope, so I recommend major revision rather than rejection. I would also ask the editor to check whether the journal's novelty bar is met, since the technical content is a standard application of existing tools and well-known mitigation techniques."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Honestly, this paper is a write-up of a standard penetration-testing exercise. The author built a deliberately vulnerable PHP-MySQL e-commerce site, scanned it with OWASP ZAP and sqlmap, found a SQLi flaw in detail.php, patched it with PDO prepared statements, and rescanned clean. The central takeaway, that parameterized queries stop SQL injection, is textbook knowledge, and the paper cites multiple sources that already say this. There is no new method, no new data, no comparison, and no test on any system beyond the author's own testbed.\n\nWhat the paper does well is modest but real. The methodology is clearly organized into preparation, execution, and patching phases. The limitations section is honest: it acknowledges the single testbed, the limited toolset, the lack of real network conditions, and the heavy reliance on automated scans. The recommendations at the end are sensible standard practice. If the GitHub repository actually exists and contains the testbed and scan logs, that would make this a usable teaching artifact.\n\nThe soft spots are significant. First, Section 9's claim that the post-patch scan 'confirmed the absence of exploitable flaws' overstates what a clean rescan with identical parameters can prove. It only shows those exact payloads no longer work. Two tools with known false-negative rates, re-running the same attack set, do not establish absence, and Section 10's own admissions undercut that phrasing. Second, scope mismatch: Section 7.1 says login and checkout pages are in scope, but the patching section mentions only detail.php. Either those pages were also remediated or the conclusion is incomplete. Third, the text has citation errors: Downey and Fellows is about parameterized complexity theory, not SQL prepared statements, and Neumann and Kemper 2015 is about query unnesting. There is also an incomplete sentence at the end of Section 9. Minor, but sloppy.\n\nThis paper does not deserve a serious research referee. It is not a scientific contribution; it is a well-documented lab report. I would not cite it, and I would not bring it to reading group. If the author wants to share it, a technical report or blog post with the code repository would be the right venue. Desk reject.","headline":"Routine SQLi testbed write-up with honest limitations but no new research content; the clean-rescan 'absence' claim is overstated.","tokens_in":12024,"tokens_out":2399,"would_cite":false,"duration_ms":24126,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Prepared statements close a detected SQL injection hole in a PHP-MySQL test site.","keywords":["SQL injection","penetration testing","OWASP ZAP","sqlmap","prepared statements","PDO","PHP-MySQL","vulnerability remediation"],"falsifier":"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.","tokens_in":11053,"feed_emoji":"🛡️","tokens_out":6296,"duration_ms":57607,"temperature":0.7,"pith_summary":"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.","feed_headline":"Prepared statements close a detected SQL injection hole","feed_subtitle":"A PHP-MySQL test site found vulnerable by ZAP and sqlmap came back clean after a PDO patch.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Provides the OWASP ZAP scanning method used to flag the CWE-89 flaw on detail.php.","marker":"Nájera-Gutiérrez, 2016"},{"why":"Documents sqlmap-based penetration testing used to confirm and exploit the SQL injection and dump tables.","marker":"Gunawan et al., 2018"},{"why":"Supplies the CWE-89 definition that classifies the discovered SQL injection weakness.","marker":"MITRE Corporation, 2021"},{"why":"Describes PHP's PDO library, the mechanism used to replace concatenated queries with prepared statements.","marker":"Kromann, 2018"},{"why":"Cited as the basis for parameterized queries separating SQL code from user data.","marker":"Downey and Fellows, 2012"},{"why":"Prior work on PHP web application security that the paper draws on for input sanitization and secure coding practices.","marker":"Rahman et al., 2015"}],"fun_headline_variants":["ZAP and sqlmap catch SQLi; PDO prepared statements eliminate it","SQL injection found via ZAP and sqlmap, then fixed with PDO","Prepared statements kill SQL injection that ZAP and sqlmap exposed","Detection to mitigation: PDO prepared statements end SQLi in case study"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["ZAP and sqlmap catch SQLi; PDO prepared statements eliminate it","SQL injection found via ZAP and sqlmap, then fixed with PDO","Prepared statements kill SQL injection that ZAP and sqlmap exposed","Detection to mitigation: PDO prepared statements end SQLi in case study"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000217,"raw_usage":{"total_tokens":1386,"prompt_tokens":845,"completion_tokens":541,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":461,"completion_tokens_details":{"reasoning_tokens":461}},"tokens_in":461,"tokens_out":541,"duration_ms":5469,"temperature":1.0,"reasoning_tokens":461,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T05:52:10.876977+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the CWE-89 definition that classifies the discovered SQL injection weakness."}],"review_version":1}