StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Have you considered <em>not</em> escaping the data until it hits the data access layer? I ask, because their are some gotchas with the approach your team is taking:</p> <ul> <li>If you need to display form data to the user (e.g., to redisplay the form with an error message because some validation failed), you need to de-escape the data (because <code>'</code> is not special to HTML) and then re-escape the data (because <code><</code> is special). If you need to display form data to the user <em>pulled from the database</em>, you mustn't do that de-escape step (because it was done by the database, when the data was saved), but still must do the HTML escape step. If you make a mistake and do the wrong procedure, you corrupt data or worse introduce security problems.</li> <li>You can deal with the different formats from different sources problem by decided all data passed around your app will be escaped. So, your data access layer will re-escape the data upon getting it from the database. But, as different parts of the app need slightly (or completely) different escapes, this quickly leads to a lot of de-escape/re-escape nonsense. Grab the data from the database, escape it, de-escape it, escape it for HTML, output it.</li> <li>Your front-end form handling code has to have intimate knowledge of your database. For example, what does <code>\'</code> mean to your database? How should a <code>'</code> or <code>\</code> be escape — if at all? If you ever change your database engine, or even change its settings, those may change. And then you have a bunch of escaping/de-escaping code to find. Missing a single escape/de-escape may lead to SQL injection.</li> <li>Alternatively, you can take that knowledge of the database out of the front-end code by having the database layer do a de-escape/escape cycle to convert from your app-standard escape sequence to your database's. But this seems rather silly!</li> </ul> <p>There is another way: Let whichever layer needs the data escaped escape it itself. Data is always passed between layers in raw, unescaped form. So your data access layer does all database escaping. Your HTML output code does all HTML escaping. When you decide you want to generate PDFs, your PDF code does all PDF escaping.</p> <ul> <li>Now, when you do form output, its clear what to do: always HTML escape the data. No matter where it came from. Never run a de-escape.</li> <li>There is now no de-escape/escape nonsense, as everything is passed around raw. It is only escaped when necessary.</li> <li>Your front-end code doesn't care about the data access layer's implementation. The data access layer stores and returns any arbitrary string.</li> <li>You have only <em>one</em> place to look in your app to make sure you have no SQL injection problems.</li> <li>You can easily make use of database driver features such as placeholders. Then not even your data access layer needs to be aware of each database's escaping requirements; the database driver handles it.</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload