Comments for SpotTheVuln.com » Develop Secure Code and Identify Security Vulnerabilities

Comment on Imagination by Helping Developers Understand Security | National Cyber Security

Helping Developers Understand Security | National Cyber Security — Wed, 17 Aug 2011 15:39:31 +0000

[...] What about including these weekly challenges in your software security program, so that developers, development managers, and QA staff can test their source code analysis skills and enjoy security by solving them? This week challenge is about… Imagination. [...]

Comment on Boundaries – SQL Injection by matt cool

matt cool — Wed, 10 Aug 2011 14:54:18 +0000

Is there also a XSRF here?

else if (isset($_GET['mode']) && isset($_GET['category_id']) && $_GET['mode'] == ‘delete’)

Thanks,
Matt

Comment on Invincible by Validating validation

Validating validation — Wed, 10 Aug 2011 07:08:44 +0000

[...] Success in increasing code quality comes from making it very difficult for a developer to do the wrong thing, making sure that the path of least resistance is also the most correct path. Unfortunately as some programming languages have come to be used as much by designers and artists than the more mathematically included coder of old, a mindset of working around the coder and giving them results that they expect rather than what they’ve asked for has become common. This leads the developers to think they’re doing the right thing, while actually shooting themselves in the foot. A friend of mine (hat tip to @suburbsec) pointed me to a very good example of this the other day on one of spotthevuln.com’s latest entries. [...]

Comment on Boundaries by Christina

Christina — Fri, 05 Aug 2011 20:30:10 +0000

I just realised something about this. If mysql_escape_string doesn’t escape the % character, would that allow us to put in something like, say, %22 for a double-quote character? It would be the same as with some URLs having %20 in place of a space character, wouldn’t it? Or would that work with this? Just a thought.

Comment on Boundaries by Christina

Christina — Fri, 05 Aug 2011 17:36:45 +0000

Wow, this one is tougher. The only thing I can see, aside from not knowing where some of the variables are defined, is that the coder uses mysql_escape_string, which has a great big red danger sign on the documentation page saying that it’s deprecated. It doesn’t escape % or _. Does this open us up to injection? It also says that the new function escapes according to the current character set.

Can WP_CALENDAR_CATEGORIES_TABLE or WP_CALENDAR_TABLE be changed by an attacker? I’m sort of assuming not, but assuming can get one in trouble.

If they can be, though, then it could be an SQL injection.

Related to SQL injection, but not to this particular code: Would it completely eliminate SQL vulnerabilities to use a function that sanitises inclusively instead of exclusively? For example, instead of looking for specific characters to escape, it woulde escape everything not on a “whitelist” of allowable characters – or scold the user if they try to use anything other than what we want them to use, say letters and numbers only. It could limit globalisation, but it would be more secure. Just an idea.

Comment on Boundaries by Jon Zobrist

Jon Zobrist — Tue, 02 Aug 2011 05:51:43 +0000

Rampant use of deprecated function mysql_escape_string() which “does not escape % and _” according to the linked man page. Especially bad is that % which is MySQL wildcard.
Any of the queries passed directly to MySQL with this could result in rampantly bad behavior…
WHERE category_id=”.mysql_escape_string($_POST['category_id']);
If $_POST['category_id'] where say iterated from 0% … 9%

Comment on Floods – SQL Injection by Yuliy

Yuliy — Mon, 01 Aug 2011 07:14:05 +0000

There’s also a vulnerability due to insufficient escaping and validation of data going into the log file. An attacker can easily generate arbitrary entries in the log file by embedding newlines into $_POST['info'] and $_POST['user']

Comment on Floods by PHP, Solution, SQL Injection Vulnerability Code Example « SpotTheVuln.com

PHP, Solution, SQL Injection Vulnerability Code Example « SpotTheVuln.com — Mon, 01 Aug 2011 07:03:44 +0000

[...] [...]

Comment on Floods by Christina

Christina — Fri, 29 Jul 2011 16:56:26 +0000

Ok … first try here. I’m not overly good with PHP, but I think this one is an obvious SQL injection (obvious because even I can see it!). The coder pulls $id, $info, and $user straight from POST and GET (lines 13-20), never sanitizes, escapes, or validates any of it, and puts it straight into the query on lines 31 and 32. At least, I don’t see any validation or anything. And, as I understand it, both POST and GET can be manipulated by the attacker.

If I’m not mistaken, even if you turn off SQL by setting $use_mysql to something else, couldn’t you still screw up the logs a little with some garbage? Line 41 seems to do the same as the injection, only it just puts it straight to the log file.

Did I win?

Comment on Grammys by Cross-Site Scripting (XSS), PHP, Solution Vulnerability Code Example « SpotTheVuln.com

Wed, 27 Jul 2011 06:02:18 +0000

[...] [...]