Abstract

This article presents an approach for retrofitting existing Web applications with run-time protection against known, as well as unseen, SQL injection attacks (SQLIAs) without the involvement of application developers. The precision of the approach is also enhanced with a method for reducing the rate of false positives in the SQLIA detection logic, via runtime discovery of the developers’ intention for individual SQL statements made by Web applications. The proposed approach is implemented in the form of protection mechanisms for J2EE, ASP.NET, and ASP applications. Named SQLPrevent, these mechanisms intercept HTTP requests and SQL statements, mark and track parameter values originating from HTTP requests, and perform SQLIA detection and prevention on the intercepted SQL statements. The AMNESIA testbed is extended to contain false-positive testing traces, and is used to evaluate SQLPrevent. In our experiments, SQLPrevent produced no false positives or false negatives, and imposed a maximum 3.6% performance overhead with 30 milliseconds response time for the tested applications.

Highlights

  • SQL injection attacks (SQLIAs) are one of the foremost threats to web applications

  • We propose an approach for retrofitting existing web applications with runtime protection against known as well as unseen SQL injection attacks (SQLIAs) without the involvement of application developers

  • Applying our heuristic that parameter values should only be used as string or numeric literals in the dynamic SQL statements, the mechanisms of taint tracking, and SQL lexical analysis, we developed an algorithm for SQLIA detection using token type conformity

Read more

Summary

Introduction

SQL injection attacks (SQLIAs) are one of the foremost threats to web applications Web applications commonly use parameter values from HTTP requests to form SQL statements. SQLIAs may occur when data in an HTTP request is directly used to construct SQL statements without sufficient validation or sanitization. When S="SELECT * FROM product WHERE id=" + request.getParameter("product id") is executed in the web application, the value of the HTTP request parameter product id is used in the SQL statement without any validation. By taking advantage of this vulnerability, an attacker can launch various types of attacks by posting HTTP requests that contain arbitrary SQL statements. Is an example of a malicious HTTP request: POST /prodcut.jsp HTTP/1.1 product_id=2; exec master..xp_cmdshell ’net user hacker 1234 /add’

Methods
Results
Discussion
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call