Recently a friend came to me and told me about a scenario which he had used to deploy his web application. He had built his application using PHP on Apache. There was a front-end server directly accessible to the internet and a back-end server only accessible to the front-end server. The PHP application deployed on the front end server included PHP files kept on the back-end server and showed it on the browser. The included PHP files were hard coded in the code of the PHP application running on the front-end server and this front end application took a GET parameter as input. Now, this scenario kind of caught my interest. I recently read about HTTP parameters pollution and I thought this attack might work in this case. So I began digging and experimenting. And I came up with a demonstration which shows how will this attack work when someone is using a setup similar to the setup described above to bypass a hard coded value in the code. I know this is not recon stuff ,but still its interesting.. 😉
We will see 4 PHP codes here :-
1.) hpp.php – The main application deployed on the front-end server, which remotely includes a PHP code (cms.php) kept on the back-end server.
2.) cms.php – A PHP code kept on the back-end server which receives an input from hpp.php in the “function” parameter and includes a PHP code (set to normaluser.php) meant for a normal user locally.
3.) normaluser.php – A PHP code kept on the back-end server meant for a normal user and included by cms.php .The ping command was set in this case to show that the normal user can only use the ping service.
4.) adminuser.php – A PHP code meant for an admin user. This code can run any OS command directly to show that this code really is for the admin 😉 .
Second Order SQL Injection :-
I always thought that escaping single quotes in a string based user input used for database transactions will prevent SQL injections..but this is not always the case when single quotes are escaped inconsistently (as we will see in this blog).
Say hello to SQL injection of the second order !
Basically second order SQL injections take place when one functionality of a web application takes a user input from a user, escapes (not strips) all SQL metacharacters and inserts that data input into a database. Next, some other functionality of the same application uses that data to craft another SQL query to do a database transaction without escaping that data first (bad idea!). The database transaction done by the second functionality introduces a SQL injection bug in the web application known as second order SQL injection.
I have’nt heard of any Second Order SQL Injection Attacks on real world targets, so decided to make up an example attack myself. Following are the two functionalities with their respective codes (select.php and insert2.php).
The first functionality inserts data into the database. The second functionality uses the data inserted into the fname column to craft a SQL query and get data from the database and show it on the frontend. For making it easy to understand, all the SQL queries run by the web applications are also shown on the frontend.