StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
8265319
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
7
CommunityOwnedDate
CreationDate
2011-11-25T06:04:42.063
FavoriteCount
0
LastActivityDate
2018-01-05T07:14:43.207
LastEditDate
2018-01-05T07:14:43.207
LastEditorUserId
285587
OwnerUserId
285587
ParentId
8263371
PostTypeId
2
Score
226
ViewCount
0
LastEditorDisplayName
text
Body
The idea is very simple - the query and the data are sent to the database server separately. That's all. The root of the SQL injection problem is mixing of the code and the data. In fact, our SQL query is a legitimate program. And we are creating such a program dynamically, by adding some data on the fly. Thus, this data may interfere with the program code and even alter it, as every SQL injection example shows it (all examples in PHP/Mysql): <pre><code>$expected_data = 1; $query = "SELECT * FROM users where id=$expected_data"; </code></pre> will produce a regular query <pre><code>SELECT * FROM users where id=1 </code></pre> while this code <pre><code>$spoiled_data = "1; DROP TABLE users;" $query = "SELECT * FROM users where id=$spoiled_data"; </code></pre> will produce a malicious sequence <pre><code>SELECT * FROM users where id=1; DROP TABLE users; </code></pre> It works because we are adding the data directly to the program body and it become a part of the program, so the data may alter the program and depending on the data passed, we will have either a regular output or a table <code>users</code> deleted. While in case of prepared statements we don't alter our program, it remains intact That's the point. We are sending a program to the server first <pre><code>$db->prepare("SELECT * FROM users where id=?"); </code></pre> where the data is substituted by some variable called a parameter or a placeholder. Note that the very same query being sent to the server, without any data in it! And then we're sending the data with the second request, essentially separated from the query itself: <pre><code>$db->execute($data); </code></pre> so, it can't alter our program and do any harm. Quite simple - isn't it? However, it worth to be noted that not every time you're using a placeholder, it is processed as a prepared statement. A placeholder is a general idea for substituting the actual data with a variable for the future processing (see <code>printf()</code> for example), while a prepared statement is the only a subset of it. There are cases (notably PDO in PHP can do it) when a prepared statement can be emulated, and a query is actually composed along with data and sent to the server in one request. But it is important to understand that this approach is equally safe, because every bit of data is properly formatted according to it's type and therefore nothing wrong could be happen. The only thing I have to add that always omitted in the every manual: Prepared statements can protect only data, but can't defend the program itself. So, once we have to add, say, a dynamical identifier - a field name, for example, prepared statements can't help us. I've <a href="https://stackoverflow.com/q/8255054/285587">explained the matter recently</a>, so I won't repeat myself. 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow can prepared statements protect from SQL injection attacks?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USYour Common Sense
UserOwnerUserId
1. USYour Common Sense
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POHow can prepared statements protect from SQL injection attacks?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId
1. CO"for example, by default PDO do not use prepared statements" - it is not exactly true, because PDO emulate prepared statements only for drivers that doesn't support such feature.
 singulars
 PostPostId
 PO
 UserUserId
 USpinepain
2. CO@zaq178miami: "PDO emulates prepared statements only for drivers that don't support the feature" - is not exactly true. MySQL has supported prepared statements for quite a while now. The PDO driver has as well. But yet, MySQL queries were still prepared by PDO by default, last time i checked.
 singulars
 PostPostId
 PO
 UserUserId
 UScHao

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.