SQL injection insecurities: RIAA
As I was reading Digg early this morning, I stumbled upon this story that many SQL injection opportunities were uncovered by people hoping to defame the site. Through a simple query to drop entries or the tables themselves, the database was cleared of all custom data, leaving many of the pages on riaa.com devoid of any content. In addition, some variables in the php pages could be exploited to show custom content on the respective pages.
Given the general online response to the RIAA and its questionable tactics going after illegal file-sharers, many users online have grumbled at the way the RIAA tries to quash file sharing online. Through this disgruntlement, some internet users use their anonymity to take cheap shots back at the RIAA, trying to discredit the organization’s purpose.
The RIAA’s official site had some glaring security errors, the most significant of which were SQL injection exploits. This type of vulnerability stem from giving the user access to directly influence a database query and furthermore not validating the user input for the explicit purpose of the user input. For example, if an example application wanted a client to enter their age, the user input text box should reject all input that do not solely consist of numbers, immediately discarding input that contain invalid characters before it has a chance to make it to the SQL query. By guessing approximately where the inputted string will be inserted into the query, the input can be fabricated to prematurely close the query and start a new query to do whatever the user wants, including modifying, creating, or dropping tables and rows.
To combat this, there are a couple of things that the RIAA neglected to do initially. The first was simple pattern matching (with client-side javascript or server-side php) the user input to make sure that that it was valid and non-destructive. The second was not utilizing a myriad of php database-safe queries and functions that protect against this very vulnerability and, with a single call, completely control this vulnerability. The third missing control was fundamental – the RIAA must have used a database user account for the client that had full database access since the client was able to drop tables in the database. Typically, websites should restrict client database accounts to only selecting rows from a database, and perhaps adding/modifying rows in a forum system. A secondary consequence of the RIAA’s negligence to check user input was that a user could fabricate content by placing the encoded content into a vulnerable page’s URI.
The actions that the anonymous internet user took in dropping the database tables was destructive to the purpose of the site and temporarily interrupted the service of the website to the public. For a short time, many RIAA pages were showing “content is not available” or SQL errors to visiting users. Modifying or removing other people’s data for the sole purpose of interrupting their site and their message is unethical to the purpose of the internet (freedom of information for everyone). In response, the RIAA took down the offending pages briefly to implement one or more of the controls detailed above, and fixed their URI argument vulnerability on news_feed.php by temporarily taking it offline and subsequently ignoring invalid input to that argument.
In any case, it was kind of startling to see the gaping security holes in such a well-traveled site. Hopefully all parties learned their lessons from this fiasco. 🙂