Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Prepared statements / parameterized queries are generally sufficient to prevent <em>1st order</em> injection on that statement<sup>*</sup>. If you use un-checked dynamic sql anywhere else in your application you are still vulnerable to <em>2nd order</em> injection.</p> <p>2nd order injection means data has been cycled through the database once before being included in a query, and is much harder to pull off. AFAIK, you almost never see real engineered 2nd order attacks, as it is usually easier for attackers to social-engineer their way in, but you sometimes have 2nd order bugs crop up because of extra benign <code>'</code> characters or similar.</p> <p>You can accomplish a 2nd order injection attack when you can cause a value to be stored in a database that is later used as a literal in a query. As an example, let's say you enter the following information as your new username when creating an account on a web site (assuming MySQL DB for this question):</p> <pre><code>' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + ' </code></pre> <p>If there are no other restrictions on the username, a prepared statement would still make sure that the above embedded query doesn't execute at the time of insert, and store the value correctly in the database. However, imagine that later the application retrieves your username from the database, and uses string concatenation to include that value a new query. You might get to see someone else's password. Since the first few names in users table tend to be admins, you may have also just given away the farm. (Also note: this is one more reason not to store passwords in plain text!)</p> <p>We see, then, that prepared statements are enough for a single query, but by themselves they are <strong>not</strong> sufficient to protect against sql injection attacks throughout an entire application, because they lack a mechanism to enforce that all access to a database within the application uses safe code. However, used as part of good application design &mdash; which may include practices such as code review or static analysis, or use of an ORM, data layer, or service layer that limits dynamic sql &mdash; <em><strong>prepared statements</em> are <em>the primary tool for solving the Sql Injection problem.</strong></em> If you follow good application design principles, such that your data access is separated from the rest of your program, it becomes easy to enforce or audit that every query correctly uses parameterization. In this case, sql injection (both first and second order) is completely prevented. </p> <hr> <p><sub><sup>*</sup>It turns out that MySql/PHP are (okay, were) just dumb about handling parameters when wide characters are involved, and there is still a <em>rare</em> case outlined in the <a href="https://stackoverflow.com/a/12202218/3043">other highly-voted answer here</a> that can allow injection to slip through a parameterized query.</sub></p>
    singulars
    1. This table or related slice is empty.
    1. POAre PDO prepared statements sufficient to prevent SQL injection?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJoel Coehoorn
    1. USJoel Coehoorn
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThat's interesting. I wasn't aware of 1st order vs. 2nd order. Can you elaborate a little more on how 2nd order works?
      singulars
      1. PO
      1. USMark Biek
    2. COIf ALL your queries are parametrized, you're also protected against 2nd order injection. 1st order injection is forgetting that user data is untrustworthy. 2nd order injection is forgetting that database data is untrustworthy (because it came from the user originally).
      singulars
      1. PO
      1. UScjm
    3. COThanks cjm. I also found this article helpful in explaining 2nd order injections: http://www.codeproject.com/KB/database/SqlInjectionAttacks.aspx
      singulars
      1. PO
      1. USMark Biek
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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