send POSTDATA back and forwar how to prevent ??
Moderator: General Moderators
-
d3ad1ysp0rk
- Forum Donator
- Posts: 1661
- Joined: Mon Oct 20, 2003 8:31 pm
- Location: Maine, USA
but im wrong or if you do a check first, like every form you need a check if a user with that name already exist... right ???
so if you do that... how refreshing will inserting the same DATA to the database... im not getting the point from some ppl here saying that refreshing will duplicate entrys in DB..
this POST was mine, but i was referring other stuff, as when you do back in the browser he ask you to post again data, what i need was, try to clear the buffer becouse all POST data was inserted into SESSIONS vars and i dont need again to post DATA again... but when i go back all forms will have the data that have been sent, becouse every data is now in SESSION vars, its why i dont want to the browser when i do back to send again POSTDATA... but anyway i think i dont need more to clear the POSTDATA...
so if you do that... how refreshing will inserting the same DATA to the database... im not getting the point from some ppl here saying that refreshing will duplicate entrys in DB..
this POST was mine, but i was referring other stuff, as when you do back in the browser he ask you to post again data, what i need was, try to clear the buffer becouse all POST data was inserted into SESSIONS vars and i dont need again to post DATA again... but when i go back all forms will have the data that have been sent, becouse every data is now in SESSION vars, its why i dont want to the browser when i do back to send again POSTDATA... but anyway i think i dont need more to clear the POSTDATA...
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Problem is you can't tell the browser what to do. What if a rogue site was allowed that privelege? Where do you draw the line for what a server can tell a user's browser to do?
The idea of a form token is probably most workable - its unique, can only be used once. Its also a useful practice to use on any form to prevent CSRF (Cross Site Request Forgeries) as described by Chris over on http://shiflett.org/articles/security-corner-dec2004 .
That way you can have some standard method of preventing postdata refreshes which are unintentional (or the result of forgeries). No DB required... Even helps against multiple submissions.
The key to a useable system as above (keeping in mind most invalid tokens are probably unintentional user errors) or the one Roja described elsewhere for this scenario - is to ensure it allows a redirect to a safe page. One which requires no form submission (could even be the same page if form validation is triggered by a specific POST value).
The idea of a form token is probably most workable - its unique, can only be used once. Its also a useful practice to use on any form to prevent CSRF (Cross Site Request Forgeries) as described by Chris over on http://shiflett.org/articles/security-corner-dec2004 .
That way you can have some standard method of preventing postdata refreshes which are unintentional (or the result of forgeries). No DB required... Even helps against multiple submissions.
The key to a useable system as above (keeping in mind most invalid tokens are probably unintentional user errors) or the one Roja described elsewhere for this scenario - is to ensure it allows a redirect to a safe page. One which requires no form submission (could even be the same page if form validation is triggered by a specific POST value).