Archived entries for SQL-Injection
Stefan Esser über WordPress Security
blogsecurity hat mit Stefan Esser über WordPress Sicherheit gesprochen.
I think the WordPress software is the best blogging software around from an end user’s perspective. Its GUI is full of eye-candy and features that are not present in other blog software. But wearing my security hat, I see past this eye-candy onto the code and see several bad design decisions. This starts with how they interface with the database. Additionally, I consider some of their features quite dangerous. I personally dislike it when software encourages its users to have writeable files within the document root. WordPress’s feature to edit files/templates on the server does exactly this. The problem with this is that when I take over the admin account of a WordPress blog, usually nothing stops me from executing any PHP code on the system. And from that it is often only a small step to control the whole server.
Google for SQL Injection Vulnerabilities
Michael Sutton zeigt wie sich Google für die Suche nach SQL Injection Vulnerabilities nutzen läßt.
After some contemplating, I came up with the following theory:
- Identify a population of web sites likely to have databases and determine the request syntax.
- For this requirement, I turned to Google and took a bit of a shortcut. (…) For my purposes, I chose inurl:”id=10”. This query was selected for two reasons. First, using a GET request would allow me to leverage a search engine to identify a population of URLs for testing. Second, a URL containing a query such as “id=10” is likely to be querying a database for something such as a product catalog.(…)
- Submit an altered query in order to elicit a SQL error message.
- Once again, I took a relatively simplistic approach here by altering the query to inject an single quote ahead of the actual query. (…) Injecting an extra quote will create a query with an open quotation mark and this will often cause the application to return an error message. I took this one step further and URL encoded the single quote to bypass sites that may be filtering for unusual characters. Therefore, the injected query was now “id=%2710”.
- Parse all responses to look for signs of verbose SQL error messages.
- After much trial and error, I settled on three simple words that allowed for the identification of most SQL error messages. I would grep responses for “sql”, “query” and “error”.
via Bruce Schneier