Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a smooth way to mark unsafe parts of a string? i.e. for use in SQL.

example in php:
someFunction("safe text" . $unsafeVariable . "safe text" . $anotherUnsafeVariable);

Is there a smooth way to know, in someFunction, what parts of the passed string that is unsafe?

I could send an array of strings where each string is prepended with something telling if it's safe or unsafe, but that isn't really a smooth way to write code.

share|improve this question
It's not clear what you're asking here. Please rephrase your question. – Adi Apr 7 '13 at 12:13
IMO tracking taint is a fundamentally flawed approach to security. In the case of SQL there is a simple solution, namely named parameters used together with a prepared statement. – CodesInChaos Apr 7 '13 at 12:15
@CodesInChaos Could you please explain why it's fundamentally flawed so I don't ever have to try this again? – Filip Haglund Apr 7 '13 at 14:40
There is no good and evil data. There is only data that's properly escaped for a particular use. Against SQL injection you need SQL string escaping (or preferably parameterized queries), against XSS you need html entity encoding, etc. – CodesInChaos Apr 7 '13 at 15:15
You could surely make a class that encapsulated a string with metadata about what pieces had or hadn't been through different processes, but what would be the point? Don't mix sugar and flour, keep your data and control signals separate, validate on the way in and escape on injections as appropriate. – bobince Apr 7 '13 at 21:16
up vote 4 down vote accepted

Actually there is a way to mark a string element as "unsafe" and it is called prepared statements. A prepared statement is a piece of SQL code which is hardcoded in the application source, i.e. a "safe string", but with a few place-holders for parameters: each place-holder really means: "when it comes to executing this SQL statement, use the argument string, but take care that the argument may be 'unsafe', i.e. may contain anything in a potentially hostile way".

That's exactly the mechanism you are looking for: a way to mark parts of a SQL statement as "unsafe" and thus warranting some extra automatic "resafing".

Some people use manual, non-automatic methods to "make strings safe", with functions such as mysql_really_really_espace_string_this_time_I_said_please(). These manual methods are deeply unsatisfying, inefficient, and occasionally fail because they rely on some PHP-provided method to be fully aware of all the details of the syntax of statements accepted by MySQL, a distinct software package, potentially upgraded separately, and written by distinct developers who do not necessarily synchronize with PHP developers. With prepared statements, the "escaping" (or equivalent mechanism) occurs deep within MySQL itself, and we can assume that MySQL, at least, agrees with itself, avoiding these problems.

share|improve this answer
I am using prepared statements, but I want to validate the input in other ways as well. It's also now always easy to know what has been validated and what hasn't. The latter is mostly caused by bad code, but not always. – Filip Haglund Apr 7 '13 at 14:41
@FilipHaglund The whole point of prepared statements is that you do not need to validate your values. This assumes your worry is SQL injection and that you use prepared statement correctly, without concatenating user-controlled data directly into query string. – Vitaly Osipov Apr 8 '13 at 7:03
That's not marking as "unsafe", that's marking as "data". It is not "resafed" in some way (well, in some DB drivers it is, because driver offloads responsibility to DB itself, but that's not the point), it is simply treated completely differently. That's not even comparing apples and oranges - more likely bicycles and tables. – Oleg V. Volkov Apr 8 '13 at 17:13
I'll just mark this as the answer. It isn't really what I was looking for, but it's definitely the best advice to most other people looking at this question. – Filip Haglund Apr 9 '13 at 9:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.