Wednesday , June 20 2018
Home / IT Security / SQL Injection / The SQL Interpreter
The SQL Interpreter
The SQL Interpreter

The SQL Interpreter

SQL Interpreter: One of the main aspects of this vulnerability that you must understand is that it leverages an SQL interpreter. An interpreter takes input and acts on it immediately without having to go through traditional programming processes such as linking, compiling, debugging, and running.

For example, an SQL interpreter plays a key part when you search a new pair of shoes at an online store. This is the code waiting as part of the web application for your search term that you type into a search box:

String query = “SELECT * FROM shoes WHERE shoeName=’” + request.getParam (“term”) + “’”;

 

The SQL Interpreter

 
When you search for a new pair Zoomers shoes, the following steps are completed.

  1. User enters Zoomers into the search box of the online store and clicks the Search
  2. The application stores the user’s input onto a variable named term (as in “search term” on the web application).
  3. The application builds an SQL statement that is made up of some prewritten code and the term variable that is used in the HTTP request.
  4. The application sends this well-formated SQL query to the database where it is executed by the SQL interpreter.
  5. The results are sent back to the application to display to the user’s browser.

ID Numbers   

   shoeName  

  shoePrice

1001       Grands 89.99
1002      Squatchs 74.99
1003      Possums 69.99
1004     Zoomers 133.37

 

The SQL’s query simplified syntax that is executed when searching for Zoomers shoes.

String query = “SELECT * FROM shoe WHERE shoeName=’Zoomers’”;

Pretty basic SQL here. We are simply selecting all (*) the columns (ID Number, shoeName, shoePrice) from the shoe table for any record that has Zoomers in the shoeName column. The results would return a dataset similar to what is introduced in above.

  • The entire query is treated as one string variable (name query) that is passed to the interpreter; this is why a double quote is present before the SELECT and at the very end of the query before the terminating semicolon.
  • The user-supplied search term is gathered by the getParam function and stored inside the single quotes as a string variable. This makes sense, as shoeName is surely a text-based value. The first single quote is right after shoeName= and the second single quote is right before the last double quote.

This is the actual SQL query that is executed by the interpreter.

SELECT * FROM shoes WHERE shoeName=’Zoomers’

 

If you have any question regarding The SQL interpreter ask your question here.

 

Josh Pauli | The SQL Interpreter | SQL for Hackers

About Jahanzaib Khan

Jahanzaib Khan is Web Designer & Ethical Hacker. He Who has been working since 2014, and is managing several successful websites on the internet for about 3 years. Jahanzaib-khan.com

Check Also

SQL: Bypassing Authentication

SQL: Bypassing Authentication

We can now construct a valid SQL statement that will execute gracefully and retrieve information …

Leave a Reply

Your email address will not be published. Required fields are marked *