Sanitisation of user input is essential for preventing SQL injection, regardless of the format of the supplied data. Today I'm going to look at SQL injection through a more obscure injection point: serialized PHP arrays. Taking inspiration from a finding in a recent test, I've created a small app which allows the user to upload a CSV file. This file is then converted to a PHP array, serialized and returned to the user as a hidden form field. Finally, this is posted back to the application where the supplied data is inserted into the MySQL database.
Cyberis exhibited at the CEE Cyber and Information Security Showcase, Vienna, Austria on 13th February and 14th February 2013.
At the event we featured a 10-minute web application hacking demonstration, illustrating the retrieval of sensitive data from a vulnerable e-commerce application.
Command execution via SQL injection is rarely possible on MySQL 5, as specifying the path to a shared library is not permitted due to security concerns - in other words it is not possible to create a UDF allowing you to run shell commands. Normally, if you can write to the default plugins location (/usr/lib/mysql/plugin), you already have root privileges and it's already game over. With MySQL 4 you could specify the full path to a shared library, so the install of a dangerous function was relatively straightforward.
Had a friend today test a site with multiple SQL injection points across the application. It was blind injection - no errors were being returned to the browser, but on a valid (true) statement you'd get content back, on a false statement and error you'd get nothing. One particular vulnerable page was quite basic (only one parameter, the result of which would display just one small text article), so we had a go at guessing the number of columns and the type of columns for a 'union select' injection.