arborint wrote:the output should be escaped and special chars encoded.
What kind of situation are you talking about here? In general, encoding/escaping is accepted to be the "same" term. Usually encoding is used when the output goes to a user, and escaping is used for outputting data into somewhere else (LDAP, FTP, Shell, databases, ...), but they both have the very same goal: to make sure that the meaning of the data is understood correctly in the certain context - "text" in HTML, "data" in a database and so forth. Encoding is more of a modifying the actual data while Escaping is just making sure it is understood correctly on the context, but these two words are often used together and often referred to the same situations like if you read OWASP, they sometimes refer to encoding or escaping of HTML meta characters.
arborint wrote:Actually neither is more or less secure and both should be used.
Really depends on the situation. Consider:
Code: Select all
$encodedHTML = fetchDataFromSQL();
echo $encodedHTML;
is this as secure as:
Code: Select all
$encodedHTML = encodeForOutput(fetchDataFromSQL());
echo $encodedHTML;
?
Nope, even if the data is handled by a trusted source, the code leads to a security mistake from the coder's part when someone has cracked into your database.
Consider this:
Code: Select all
$newEmployees = fetchFromExternalServer();
echo "New employee list: $newEmployees.";
The above code might rely on Input Encoding (which is done on the remote server). The data is encoded on the remote server, but if the server fails (or anything in between) - so does this code.
Code: Select all
$newEmployees = encodeForOutput(fetchFromExternalServer());
echo "New employee list: $newEmployees.";
This, on the other hand, would corrupt the data, because there are now two levels of encoding: Input and Output applied at the same time. Probably the easiest way to code this securely would be to only use Output Encoding (and revert the Input Encoding applied by the remote server if it is needed). Depends really on the overall implementation of the application and the relationship between the servers.
Sometimes if you keep a database separate from the server and you forget to use SSL - a MITM attack could at least in theory completely bypass Input Encoding attempts. I tried this on my EEE and primary PC, setuped a separate DB server and modified the data on fly, but is nearly impractical to do in real life situations, though. To sum up, in certain situations, Output Encoding is more secure than Input Encoding, because you can't always ensure the data integrity - unless, of course, you use some sort of fingerprints as I noted. So, it's if, if and if. Depending on the situation, Output Encoding can certainly be more secure than Input Encoding when comparing the two
alone. The same thing does not really apply to Escaping as you can't distinct between Output and Input Escaping... that's one thing that separates the two words and as you said Escaping should be applied. Actually, Escaping must be applied imo even if you are doing something like passing a casted integer to an integer column.