How are input keys exploitable by malicious users?

You see this junk often in noob code:

$_SESSION = $_POST;

A seldom known secret is that $_SESSION is "special" and can't handle the pipe character, |, as a top level array key. php fails to save the session variables during shutdown/session_write_close, instead wiping the entire array.

session_start();if (!isset($_SESSION['cnt'])) {    $_SESSION['cnt'] = 0;}$_SESSION['cnt']++;/* prior to php 5.4, it will never increment, because it never successfuly savesunless you comment line below*/$_SESSION['a|b'] = 1;print_r($_SESSION);

I'm not saying that's why CodeIgniter scrubs the keys, but it's one of many "ways input keys are exploitable".

Maybe a more likely reason though is because people certainly do stuff like this:

if ($formPostDidntValidate) {    echo "Please fix the form submission errors and try again\n";    foreach ($_POST as $key => $value) {        echo "<p>$key<br>              <input name='$key' value='$value'></p>";    }}

Outputting request variables without doing proper context-specific escaping, such as escaping for html contexts, html attribute contexts, or even sql contexts:

$sql = "select * from myTable where 1=1";foreach ($_POST as $key => $value) {    $sql .= " and $key = '$value'";}

I've seen plenty of people escape the value, but not the key when building sql and/or html.

If you don't escape everything, you are easily hacked. Scrubbing values isn't as good as escaping, but it's much better than nothing, and considering how many developers aren't yet sophisticated enough to understand when and how to escape, I can see the attraction to adding automatic request variable scrubbing.

Your question, in itself, brings up a good point: it's unclear what exactly you're being protected against. But there are some popular items it could be addressing:

• magic quotes
• things that could eventually lead to SQL injection
• strings that could be executed by way of shell commands
• things that could conflict with your URL
• things that could conflict with HTML
• things that resemble a directory traversal attack
• cross site scripting (XSS) attacks

But other than those, I really can't think of why you'd always why you'd want to generally protect via preg_match("/^[a-z0-9:_\/-]+$/i", $str).

I've got the feeling that they're overprotecting simply because CodeIgniter is so widely used that they need to protect against things they themselves haven't thought of yet for the sake of their users who may be even less-aware of such attacks than CodeIgniter's developers.

Say in a console I change your form's field name from name="email" to name="email\"); DROP TABLE users;

It's not likely to be a successful XSS attack but I can see something like that doing damage to poorly coded PHP. CI is probably just trying to cover all their bases so they can have a claim to be as XSS-protected as possible.