StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
19036166
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-09-26T18:42:48.817
FavoriteCount
0
LastActivityDate
2013-09-26T19:54:16.740
LastEditDate
2013-09-26T19:54:16.740
LastEditorUserId
1242470
OwnerUserId
1242470
ParentId
19036081
PostTypeId
2
Score
33
ViewCount
0
LastEditorDisplayName
text
Body
To understand the difference, let's go through in detail how each of the solutions would work and their security risks. In this example we are going to store the count of page views of the user. <h2>$_SESSION</h2> We start the session, increment the counter and store it in the <code>$_SESSION</code> array: <pre><code><?php session_start(); if(!isset($_SESSION["pageviews"])) { $_SESSION["pageviews"] = 0; } $_SESSION["pageviews"]++; ?> </code></pre> When a user visits this page for the first time, PHP will generate a random session identifier that looks like the following, and ask the browser to store this ID in a cookie: <pre><code>fh4giqncq25ntgs7gjunvj6i33 </code></pre> On the server, it will store and remember that there is a <code>pageviews</code> variable with the value <code>1</code> that belongs to the session ID <code>fh4giqncq25ntgs7gjunvj6i33</code>. The next time the user visits the page, his or her browser will send the previous session ID along with the request (given that the cookie hasn't expired or got deleted). PHP then recognizes this ID, and populates the <code>$_SESSION</code> array with <code>pageviews = 1</code>, then increments it: <code>pageviews = 2</code> In terms of security, consider the following questions: Is the user able to read the stored data? No – The only thing the client sees is the random session ID in the cookie; the data itself is stored on the server. Is the user able to alter or manipulate the stored data? Again, no – If the session ID is altered in the browser, PHP will not be able to tie the browser to the stored data any more. In this worst case scenario the user will get a new session, starting with <code>pageviews = 1</code>. The main security risk of sessions is session hijacking, when an attacker somehow manages to get the session ID from someone else's browser and then presents it to the server, thereby impersonating the other user. In our example this would not make much sense since we're only storing a page view count; however, most sites use sessions to keep track of which user is logged on from which browser. In that scenario, stealing someone else's session would mean getting access to their account. <h2>Hidden field</h2> In this case we have a form with a hidden field: <pre><code><form action="..." method="post"> <input type="hidden" name="pageviews" value="<?php print($pageviews); ?>" /> ... </form> </code></pre> On the server, we retrieve the <code>pageviews</code> variable from <code>$_POST</code> and increment it: <pre><code><?php $pageviews = @$_POST["pageviews"]; $pageviews++; ?> </code></pre> So, instead of storing it on the server, we essentially send the data down to the client and expect it back in the subsequent request. Apart from the fact that it only works with POST requests, let's look at the security-related downsides of this solution: Is the user able to read the stored data? Yes – it goes straight to the browser in the HTML code. Is the user able to alter or manipulate the stored data? Yes – there is nothing to prevent the user from opening up the developer tools in his or her browser and changing the hidden value to whatever he or she likes. Upon submitting the form, the server gets the altered data. The problem with <code><input type="hidden"></code> is that you just can't trust the client, so you have to verify the data you get in every request. It might be reasonable to do this in some cases, such as filling out multi-page forms, but even that can often be better solved with sessions. <h2>Summary</h2> Persisting data via <code>$_SESSION</code> is generally safer than using <code><input type="hidden"></code> because the session data is stored on the server, and thus cannot be tampered with by the client. Only a random session identifier is sent to the browser in a cookie which ties the data on the server to that particular browser.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIs it more secure to use a session variable instead of a hidden input field?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USMáté Solymosi
UserOwnerUserId
1. USMáté Solymosi
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
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
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

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.