When you have a server side script that involves more than one web page you might have one page that you only ever expect to be called from another specific page. The second page expects to receive specific data from the first page. One often overlooked security hole in this particular setup is where someone finds a way to access the second page directly without going through the first page and therefore without the expected data being passed.
There are several possible approaches to implementing security to protect against this situation. The most obvious would be to check the referrer header to ensure that the second page has actually been called from the first page. Unfortunately since that header can easily be tampered with by the person trying to breach your security this by itself is not sufficient. While this will eliminate accidental attempts to access the second page directly without going through the first page first, it will not prevent deliberate attempts to bypass the first page. Implementing a redirect to the first page if the referrer doesn't identify it as the previous page is one layer of security that might be worth implementing but it is not something that can be relied on completely.
What we need to do to ensure that the second page is secure is to consider what information is actually being passed from the first page to the second page and what impact it could have if that data were missing or tampered with.
This is a situation where sanitizing the input data is essential. If control is being passed from somewhere other than the page that is supposed to be passing the data then you cannot rely on any validation that page applies having actually been applied to what is being given to the second page. Just how you sanitize the fields depends on how you validate them on the first page. Anything that actually comes from the first page where it has been validated should be able to pass through the sanitizing without being altered in any way while anything that would have failed validation should have those characters that caused it to fail validation removed. Of course if something gets altered by sanitizing then that is a good indicator that the page has not been called properly from the correct page and you may want to set up to redirect back to the first page whenever any of the sanitized values don't match the originals.
So if we have implemented the above two security measures then the only time we don't hit those redirects where the page has been accessed from the wrong place is where someone has gone to the trouble of both updating the referrer header to make it look like it cane from the right place and has entered data that would have passed validation had it come from the right place. Assuming that you actually did retest all of the fields properly then you don't really have a problem with this situation as the person could have achieved exactly the same result by using the first page. If that isn't the case then your sanitizing does not properly duplicate the validations from the previous page and you need to adjust that.
This article written by Stephen Chapman, Felgall Pty Ltd.