What does it mean to escape a string?

Question 1

I was reading Does $_SESSION['username'] need to be escaped before getting into an SQL query? and it said "You need to escape every string you pass to the sql query, regardless of its origin". Now I know something like this is really basic. A Google search turned up over 20, 000 results. Stackoverflow alone had 20 pages of results but no one actually explains what escaping a string is or how to do it. It is just assumed. Can you help me? I want to learn because as always I am making a web app in PHP.

I have looked at: Inserting Escape Characters, What are all the escape characters in Java?, Cant escape a string with addcslashes(), Escape character, what does mysql_real_escape_string() really do?, How can i escape double quotes from a string in php?, MySQL_real_escape_string not adding slashes?, remove escape sequences from string in php I could go on but I am sure you get the point. This is not laziness.

Question 2

Escaping a string means to reduce ambiguity in quotes (and other characters) used in that string. For instance, when you're defining a string, you typically surround it in either double quotes or single quotes:

"Hello World."

But what if my string had double quotes within it?

"Hello "World.""

Now I have ambiguity - the interpreter doesn't know where my string ends. If I want to keep my double quotes, I have a couple options. I could use single quotes around my string:

'Hello "World."'

Or I can escape my quotes:

"Hello "World.""

Any quote that is preceded by a slash is escaped, and understood to be part of the value of the string.

When it comes to queries, MySQL has certain keywords it watches for that we cannot use in our queries without causing some confusion. Suppose we had a table of values where a column was named "Select", and we wanted to select that:

SELECT select FROM myTable

We've now introduced some ambiguity into our query. Within our query, we can reduce that ambiguity by using back-ticks:

SELECT `select` FROM myTable

This removes the confusion we've introduced by using poor judgment in selecting field names.

A lot of this can be handled for you by simply passing your values through mysql_real_escape_string(). In the example below you can see that we're passing user-submitted data through this function to ensure it won't cause any problems for our query:

// Query
$query = sprintf("SELECT * FROM users WHERE user='%s' AND password='%s'",
            mysql_real_escape_string($user),
            mysql_real_escape_string($password));

Other methods exist for escaping strings, such as add_slashes, addcslashes, quotemeta, and more, though you'll find that when the goal is to run a safe query, by and large developers prefer mysql_real_escape_string or pg_escape_string (in the context of PostgreSQL.

Question 3

A few things here:

You aren't really encrypting it, you're hashing it. Easy thing for newbies to confuse, but just wanted to get that out of the way.
Don't use MD5, it's just not a very secure hash. Use one of the SHA variants instead if possible.
Don't just hash the password, you'll want to "salt" it too. Basicly this involves adding a random string to the password before you hash it, and storing that random string somewhere where you can retrieve it later (so that you can validate the hash when the user enters their password). This helps prevent against pre-computed dictionary attacks.

As for generating the password, I think you are on the right track - I would just generate it when they create their account, email it to them, then hash it and store the hashed (and a random salt) on the user record in the DB.

Question 4

Zend Framework is based on MVC design pattern which stands for Model View Controller. The View is presentation part including html, javascript, css or any other aesthetics.

Rendering a view means showing up a View eg html part to user or browser. Let's say you have a controller for About page of your site, now from your controller you would render the About view which means show the that page in browser for users to see otherwise if you don't users will see just blank page :)

Think of it echoing html/css/js to browser.

Question 5

The discussion thus far has been about protecting from SQL Injection and Persistent cross site scripting. It sounds like you're on the right track.

Your use of prepared statements is a "best practice" to combat SQL injection.
htmlspecialchars() is a good start to prevent XSS, but you have to escape data in the encoding scheme that is appropriate to where you are outputting data. OWASP has a comprehensive page that discusses this: XSS (Cross Site Scripting) Prevention Cheat Sheet. The short answer: Ensure you are using "the escape syntax for the part of the HTML document you're putting untrusted data into."

Question 6

The current CSP spec (version 2) says (emphasis mine):

3.6. Policy applicability

Policies are associated with an protected resource, and enforced or monitored for that resource. If a resource does not create a new execution context (for example, when including a script, image, or stylesheet into a document), then any policies delivered with that resource are discarded without effect. Its execution is subject to the policy or policies of the including context.

CSPs only apply to resources that create a new execution context (i.e., a Web page), which includes only top-level documents, embedded objects like <iframe>s, and scripts loaded as Web Workers. If a resource is served over HTTP and that reource is not used in a way that creates a new execution context, the CSP has no effect.

Therefore, your scripts will behave identically whether or not they are served with a Content-Security-Policy header.

What does it mean to escape a string?

Answers

php,mysql,security,escaping