Forums

FYI, there's a security bug in how parser errors are handled in post.php and edit.php. The content of error messages is not escaped in any way, and some error messages are allowed to hold user input. For instance, pasting the following message will trigger a JavaScript alert:

[url=<script>alert(1)</script>]test[/url]

Sorry: you're right, my previous statement was slightly incorrect. The named parameters used to construct the initial query have to use colons: the colons are optional when passing in values to be used with the query.

The first one uses htmlspecialchars to sanitize input when the output context is a single-quoted JavaScript string (I could have used a single-quoted attribute in an HTML tag just as easily). An attacker can break out of that since single quotes aren't escaped by default in htmlspecialchars.

The second example uses UTF-7 character encoding. That's a little too much to get into here, but check out http://openmya.hacker.jp/hasegawa/security/utf7cs.html

Yes

Really? What about

2011-03-262345314d8e7a9bf191c.dat.php%00"><script>alert(1)</script>

That's symptomatic of a larger problem (you're not running your inputs through a function like basename even when they're treated as filenames) but it should still work (at least if you're not running the latest version of PHP 5.3).

OK, you seem to have missed my point: that htmlspecialchars is not some magic function that makes your input safe. Lets take two theoretical examples:

1.

<script type="text/javascript">
var text = '<?php echo htmlspecialchars($_GET['text']) ?>';
</script>

2.

<?php
header('Content-Type: text/html; charset=utf-7');
echo htmlspecialchars($_GET['text']);

"Escape once, output everywhere" is not a valid solution (and as I've said, it just means you're shifting the need to escape from output to input: you'll cause a lot of subtle bugs because you forgot to use htmlspecialchars before a comparison). If you're really so concerned about the amount of time your system takes to run htmlspecialchars, I'd recommend using Varnish or another caching server.

As with many areas of computer security, it's not quite so easy as it appears.

For typical query workloads (INSERT/SELECT/UPDATE/DELETE) where all you're doing is adding parameters to your WHERE clause, it can be as easy as always using parameterized queries.

Now, think about the IN clause. As you showed earlier today, it's slightly more complicated than a simple parameterized query. You'd be surprised how many sites will handle IN clauses via raw string concatenation simply because the values can't be used directly in parameterized queries.

Now, try playing around with column names or table names (like in ORDER BY, FROM, or other clauses). Life gets a little bit more tedious: you have to using string concatenation, for which you have to design a whitelist of some kind in order to be secure.

Now, try playing around with some more esoteric statements: ALTER TABLE, CREATE TABLE, DROP TABLE, etc. You can't use parameterized queries here at all. If you use string concatenation here, you're very likely to mess things up.

Then of course you have your own customized database layer, which anyone may happen to circumvent because when they call mysql_query, it picks up the database from the environment and lets them bypass your protection entirely.

So yes, for a lot of use cases it's simple to recommend parameterized queries. Unfortunately, those implementations are subject to many of the same kind of vulnerabilities as the rest of the code. SQL injection is not a solved problem.

Edit: And a real world example:

http://groups.google.com/group/rubyonra … 2cf6bf4eed | Potential SQL Injection in Rails 3.0.x (via LIMIT clause)

As an aside, if there were a fool-proof way to solve these "security problems," I would be out of a job

Edit: To be clear, there are ways to systematically reduce the possibility of some of these attacks.

XSS: Always display content using a system that has been designed to provide context-aware escaping. For an example of such a system, see https://github.com/facebook/xhp/.
SQL Injection: Always use parameterized queries: never ever use string concatenation when constructing queries except on a whitelist of values.
Spoofed Form Input: One method: define all of the forms in code, along with validators. When a form is POSTed back, look up the relevant form and parse the input according to the validators. See Zend_Form (which also handles markup).
CSRF: Random per-user (or per-user per-page) nonces, as Reines said
File Uploads: This encompasses a wide range of possible vulnerabilities, so I won't get in to specifics here.

Of course, all of these mechanisms also assume that the relecant security measures are coded without any flaws as well. The odds of that tend to be low

http://bugs.php.net/41655

A bug that has been fixed for several years, which is only applicable when using deprecated PHP options that don't actually enforce security.

MattF: Of course

adaur: Use htmlspecialchars on that on the security gnomes will destroy you

IN (SELECT ...) in MySQL is very poorly optimized, as you've seen. I don't have any citations, but it might even run the inner subquery multiple times rather than caching the result.

Edit: Citation: http://news.ycombinator.com/item?id=2206359

Upload a file named config.php

Why can't you just use

SELECT p.poster_id, p.poster_ip FROM pun_posts AS p GROUP BY p.poster_id ORDER BY p.id DESC

as a derived table? It's not clear what your constraint is.