While testing, I found a slight "gotcha" on one of my forms, and I'm not sure what is a reasonable solution?! (It deals with the "stickiness" of the Form.)
I have a simple "Send Private Message" form which has the following fields:
- To
- Subject
- Message
If a User is logged in, completes the Form, but there are errors, I echo back the values entered with an error message (e.g. "Subject must be less than 40 characters.")
This part works fine, however, here is the problem I just discovered...
Let's say JaneDoe has my website loaded in two browser windows. And in one window, she opens up the "Send PM" form, types a long PM to her girlfriend, and then gets distracted by her kids.
Later, she comes back to her PC, and goes to the second window, does whatever, and clicks "Log Out".
Before shutting off her computer, she realizes the first window, and clicks on "Send PM".
The problem is that to my server she is logged out...
Since you have to be logged in to send a PM, at the top of my "send-pm.php" script, I have this code...
PHP Code:
// Set Redirect Path.
$_SESSION['returnToPage'] = "/account/send-pm/" . $_GET['user'];
This code was intended to mark the User you want to PM, take you to my "log-in.php" script, log you in, and then bring you back to a BLANK "Send PM" form which is pre-populated with the Username captured above.
And so JaneDoe just lost her 10 page PM to her girlfriend in this scenario...
I assume this is unacceptable??
Should I be saving the whole "Send PM" form in case this scenario happens?
Or is it okay to just have a "sticky" form when POST is involved?
No...IMO, that's acceptable. Look at many major websites e.g Facebook, they do not have such conveniences for users. Sometimes conveniences only serve to distract you - they may even be unwanted. For example, most users expect that on logging out, all their unsaved user data is lost. Coming back to find data yet they had not been informed whether it was saved kinda becomes an inconvenience by itself. Although, it would be a disaster if email services did not have n auto-saving feature.
A simple way to solve this would be to have Ajax powered draft saving. Like Gmail, StackExchange network sites etc. But you have to give them a little notification that a draft is saved of course. Having a feature that enabled users to save messages when not logged in would be a major security that even script kiddies could exploit by themselves.
But its not very essential. Codingforums doesn't have this feature...yet its okay to me. But if your site is message based, it would not be overkill to have a draft feature.
__________________
For professional Hosting and Web design.....
But its not very essential. Codingforums doesn't have this feature...yet its okay to me. But if your site is message based, it would not be overkill to have a draft feature.
This actually isn't true, we actually do have this feature at least at the posting level (and presumably at the PM level as well since its logic flow if very similar). It just makes no indication of such.
If you let your session time out while authoring a post, it will send you to the login page (with no notification that it will forward the post :/). After logging in again, it will submit the post. I remember testing this a few months ago and I was surprised to find that it would submit the post after.
This actually isn't true, we actually do have this feature at least at the posting level (and presumably at the PM level as well since its logic flow if very similar). It just makes no indication of such.
If you let your session time out while authoring a post, it will send you to the login page (with no notification that it will forward the post :/). After logging in again, it will submit the post. I remember testing this a few months ago and I was surprised to find that it would submit the post after.
I would be interested in finding out how they validate that the data was from that user...maybe the user left(CyberCafe Scenario) and another(malicious) used the computer next - how exactly do they catch that? Random SES IDs in the browser cookies would only work if they are not in the same computer. Looks to me like a loophole that somebody with enough determination - and makes multiple accounts for testing - could exploit.
What do ya think?
__________________
For professional Hosting and Web design.....
If I guessed it, it would either stuff it into the session or forward the post data. Both options would be theoretically open for abuse; if you post and leave the browser open and login as a different user, than it automatically posts as that user instead. That said, no matter whether its through post or through session it should be invalidated once the browser is closed.
Edit:
Quick test shows that the post is forwarded through the form.
If I guessed it, it would either stuff it into the session or forward the post data. Both options would be theoretically open for abuse; if you post and leave the browser open and login as a different user, than it automatically posts as that user instead. That said, no matter whether its through post or through session it should be invalidated once the browser is closed.
Edit:
Quick test shows that the post is forwarded through the form.
Okay, but back on track...
The scenario I was describing is one where there are 2 windows open.
One window has the "Send PM" form in it with an unsent message.
In another window, for whatever reason, the User was logged out.
So in Window #1, when they hit "Submit", I re-route them to a log in screen, thus losing the data I had saved in my original "sticky form".
It would seem that in that scenario, I should save the Form Data in a Session, so after they go from "send-pm.php" to "log-in.php" back to "send-pm.php" that their data is retained in the "Send PM" form?!
(I'm trying to figure out how to do this, and it is a real PITA figuring out the sequence of setting and unsetting variables?!)
If you're not using Ajax, that's a real bummer. Ajax gotten pretty simple with JQuery. If you have followed the conversation, you could pipe the data into session then send it after login, but that would be open to abuse - in the case that a malicious or even unknowing user uses the same computer as the last user who had unsaved PMs - this is because you'd have to use client-side cookies which are open to abuse, editing and such. If you have random Session IDs stored in them for validation, that will at least protect the app from Remote Users( Who don't do cookie stealing). In short, that's a feature - if you don't use Ajax draft Saving - that will introduce an unnecessary security hole that may come to bite you up ahead.
__________________
For professional Hosting and Web design.....
I would be interested in finding out how they validate that the data was from that user...maybe the user left(CyberCafe Scenario) and another(malicious) used the computer next - how exactly do they catch that? Random SES IDs in the browser cookies would only work if they are not in the same computer. Looks to me like a loophole that somebody with enough determination - and makes multiple accounts for testing - could exploit.
What do ya think?
Well considering the next user would need to know the previous users password, I think its a no-go to be honest. You could also put the users ID number in the form (or a hashed version of it at least / random value) so that you can compare the session data to make sure it belongs to the right user should another login with the same session id.
As per Debbies request, you can save the entire $_GET and $_POST arrays in the session (along with the $_SERVER so you know the original url), do your login and then check / use them as you originally would have done. This is a method I've used for a few years with minimal hassle as I also had the same problem with my site (i have a session time out / password confirmation thing which needed to remember input and act on it after the login page).
//Please don't use this for your form processing:
if (isset($_POST['submit']))
//Internet explorer has a bug and does not always send the submit value.
Well considering the next user would need to know the previous users password, I think its a no-go to be honest. You could also put the users ID number in the form (or a hashed version of it at least / random value) so that you can compare the session data to make sure it belongs to the right user should another login with the same session id.
As per Debbies request, you can save the entire $_GET and $_POST arrays in the session (along with the $_SERVER so you know the original url), do your login and then check / use them as you originally would have done. This is a method I've used for a few years with minimal hassle as I also had the same problem with my site (i have a session time out / password confirmation thing which needed to remember input and act on it after the login page).
The problem is....a good secure login regenerates session IDs/keys at the end of the session/session timeout/logout. So having to compare with session values...that is only possible in where the session IDs are not regenrated and therefore a secure-ish system which is prone to attacks, which I don't think any programmer aims for. See? Ajax based draft saving is the most secure.
__________________
For professional Hosting and Web design.....
The problem is....a good secure login regenerates session IDs/keys at the end of the session/session timeout/logout. So having to compare with session values...that is only possible in where the session IDs are not regenrated and therefore a secure-ish system which is prone to attacks, which I don't think any programmer aims for. See? Ajax based draft saving is the most secure.
No I disagree. The session can't be attacked if its had all of its variables unset / deleted and can be recycled for another user on the same computer in a similar way to thread pooling in windows socket apps. Besides, the ID wasn't that of the session i meant.
What I meant, was put the USERS ID in the form so that it can be checked against the current user who logs in. If the two match, it's the correct user so process the stored http data. If its a different user id that has logged on then the data can be dumped or stored in the previous users account somewhere.
Ajax is also fine to use BUT it can be a pita on the browser and CPU resources.
//Please don't use this for your form processing:
if (isset($_POST['submit']))
//Internet explorer has a bug and does not always send the submit value.
No I disagree. The session can't be attacked if its had all of its variables unset / deleted and can be recycled for another user on the same computer in a similar way to thread pooling in windows socket apps. Besides, the ID wasn't that of the session i meant.
What I meant, was put the USERS ID in the form so that it can be checked against the current user who logs in. If the two match, it's the correct user so process the stored http data. If its a different user id that has logged on then the data can be dumped or stored in the previous users account somewhere.
Ajax is also fine to use BUT it can be a pita on the browser and CPU resources.
Well, that's a spam hole in itself. I can do simple HTML injection and input an ID - probably starting sequentially - unless you use random IDs which I'm pretty sure not many do due to collision chances. Posting messages when logged out and they will be posted 'somewhere' in that users space...then post the messages with lets say my ruthless bots mate. What would your application be able to do about that? You might have a captcha or something...but that introduces an inconvenience by itself for logged in users. How about that?
Ajax is not so expensive now on resources...unless you're moving media files or you are on a free host(most have a limit to system pings). Messages will be served well by Ajax.
__________________
For professional Hosting and Web design.....
Well, that's a spam hole in itself. I can do simple HTML injection and input an ID - probably starting sequentially - unless you use random IDs
If you re-read my original reply about this, you'll see I was way ahead of you when I mentioned:
Quote:
Originally Posted by tangoforce
You could also put the users ID number in the form (or a hashed version of it at least / random value) so that you can compare the session data to make sure it belongs to the right user should another login with the same session id.
Quote:
Originally Posted by Redcoder
Posting messages when logged out and they will be posted 'somewhere' in that users space...then post the messages with lets say my ruthless bots mate. What would your application be able to do about that?
I dunno what to say.. I'm stumped Oh hang on..
I guess the password confirmation page that is between the http submission and the processing would luckily stop those nasty bots getting any further Any submission that isn't verified within say 5 minutes doesn't need to be kept and can be blackholed.
To be honest though Red, you're assuming that the attacker will know how the code on the back end operates. What happens when the form field names are all random values? The bot master can send all the forms they want but if the field names haven't been generated or don't match..
//Please don't use this for your form processing:
if (isset($_POST['submit']))
//Internet explorer has a bug and does not always send the submit value.
Okay. If you have random values for form names, don't you think that thats overkill? How will you figure them out during data retrieval? Storing them in session cookies? The attacker can see those too. Remember, anything in session cookies is viewable to the user mate.
The thing is...you have to agree, Ajax is the way to go.
__________________
For professional Hosting and Web design.....
Okay. If you have random values for form names, don't you think that thats overkill?
You're the one who is adamant about defending the site.. coming from you I'm rather shocked that you're now saying another layer of defence is overkill
Quote:
Originally Posted by Redcoder
How will you figure them out during data retrieval?
Store the names and actual name-values in the session or database. It doesn't matter as long as they're on the server.
Quote:
Originally Posted by Redcoder
Storing them in session cookies? The attacker can see those too. Remember, anything in session cookies is viewable to the user mate.
Erm.. No!
I get the impression that in your eagerness to be a coder, you've scrimped on certain bits along the way. Sessions are kept on the server side. Cookies are kept on the clients PC. Session data is written to a session file on the servers hard disk (unless of course you change the default sessionhandler to use a database instead which actually avoids a lot of session timeouts and garbage clearance issues). The only session information that is sent to the client, is the session identifier - also known as the PHPSESSID. PHP does not set any other cookies with session information. Yes, some sites set other things in a cookie but those are minor things that shouldn't affect security.
Even with the PHPSESSID (a name that can be changed) value, you still can't gain access to the session data thats been stored / change it etc. It's only available to the scripts themselves.
Before you even think about quoting me on cookie theft, it would make no difference here as the bot master you're speaking of still wouldn't know the random form names that were output in order to submit any spam data. *HOWEVER* if they've stolen a cookie, it's highly probably that your attacker has been sniffing your TCP traffic and stolen that form anyway which then could in theory be used to submit a form. Checking against IP addresses would be pointless as they can be spoofed. In reality while it is possible, not many people are going to be monitoring visitors to your site for TCP traffic and given that you described a scenario in an internet cafe where someone is on the computer AFTER the last user, it wouldn't be a threat.
The bottom line here is that there are advanced ways to attack a site that advanced attackers can use. People like us don't stand a chance against the real pro's from the old-skool and if they do attack your site, you've pi**ed off someone somewhere. People like us will never defend against the real pro hackers but we can defend against the script kiddy wannabies.
Quote:
Originally Posted by Redcoder
The thing is...you have to agree, Ajax is the way to go.
I don't have to agree to anything. Sure, an ajax call every 10 - 30 seconds may be a good idea but if you were to do it every 1 - 5 seconds it drives up the CPU usage to stupid levels (just check out any page with comments on the suns website - open up 3-4 stories in different tabs and you'll soon see the effects). While it can contribute towards solving the problem, it isn't a solid cure for it.
//Please don't use this for your form processing:
if (isset($_POST['submit']))
//Internet explorer has a bug and does not always send the submit value.
I get the impression that in your eagerness to be a coder, you've scrimped on certain bits along the way.
Why does that feel like its below the belt? Probably is...but I'll let it slide.
Quote:
Originally Posted by tangoforce
Sessions are kept on the server side. Cookies are kept on the clients PC. Session data is written to a session file on the servers hard disk (unless of course you change the default sessionhandler to use a database instead which actually avoids a lot of session timeouts and garbage clearance issues). The only session information that is sent to the client, is the session identifier - also known as the PHPSESSID. PHP does not set any other cookies with session information. Yes, some sites set other things in a cookie but those are minor things that shouldn't affect security.
Even with the PHPSESSID (a name that can be changed) value, you still can't gain access to the session data thats been stored / change it etc. It's only available to the scripts themselves.
Pause right there....Remember I said session cookie, not sessions mate. Not sessions.
And you can be darn sure that I'm the best at what I do.
__________________
For professional Hosting and Web design.....
Before you post, read our: 
Any submission that isn't verified within say 5 minutes doesn't need to be kept and can be blackholed.
