Today we’ll show you some examples of how a web application can be exploited so you can learn from them; for this we’ll use Gruyere, an intentionally vulnerable application we use for security training internally, too. Do not probe others’ websites for vulnerabilities without permission as it may be perceived as hacking; but you’re welcome—nay, encouraged—to run tests on Gruyere.

Possibly related posts (automatically generated)

• Website Security Basics
• Web Application Exploits and Defenses
• WebScarab, Paros Tutorial
• XSS
• XSS Rays

Disclaimer: the things we’ll talk about in this article today won’t make you a security expert, just as buying a Swiss Army knife won’t make you a locksmith or buying a whip won’t make you a lion tamer. The purpose here is to raise awareness and perhaps make some of that security mumbo-jumbo a bit more understandable to you.

Possibly related posts (automatically generated)

• Website Security
• Writing secure PHP applications
• Web Application Exploits and Defenses
• WebScarab, Paros Tutorial
• XSS

This article looks at some of the more popular vulnerabilities, such as cross-site scripting and SQL injections, and introduces tools you can use to help safeguard not only your sites, but the data and networks that power them.

Possibly related posts (automatically generated)

• Website Security
• Website Security Basics
• Web Application Exploits and Defenses
• XSS
• sql injection

via fefe

Possibly related posts (automatically generated)

• Ungewöhnliche SQL Injection
• Website Security
• Website Security Basics
• WebScarab, Paros Tutorial
• Parteienmeinungen zum Internet

An SQL injection scanner, using blind SQL injection techniques to extract information from a target database.

Possibly related posts (automatically generated)

• Website Security
• Website Security Basics
• Ungewöhnliche SQL Injection
• AIR Lesestoff
• Stefan Esser über Wordpress Security

Possibly related posts (automatically generated)

• Website Security
• Website Security Basics
• sql injection
• SQL Injection Scanner: sqlfury
• Stefan Esser über Wordpress Security

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.

Possibly related posts (automatically generated)

• WordPress scanner
• WordPress: 10 Tips zum Schutz von wp-admin
• WordPress Exploit Scanner
• WordPress Sicherheit
• Wordpress Noversion plugin

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

Possibly related posts (automatically generated)

• Website Security
• Website Security Basics
• SQL Injection Scanner: sqlfury
• Ungewöhnliche SQL Injection
• Stefan Esser über Wordpress Security