Re: FN-FORUM: PHP PostData security

date posted 29th May 2007 11:43

Thank you Dai - nail on the head!

The original post was...

"I was informed recently of a security risk with post data submitted from
forms in PHP. I was told that if a message is displayed asking the user to
resend data when the page is refreshed then the website is potentially
insecure.

First of all does anyone know if this is really a risk and if so would the
above solution have eliminated that risk?"

Given the feedback, Dai is right in what I was attempting (rather poorly it
seems) to convey - the route from general to specific answer was rather
circuitous. The subject is both multi-faceted and complex.

In summary, what was ultimately referred to as the MVC pattern to approach
(separation of logic) was to enable most developers to kill web page
security issues, whether by URL or form field injection. At the same time it
removed the Postdata message and dealt with the page refresh and submit
problem. Yes, same page form processing can be done by programmers who are
both knowledgeable and accurate in covering all angles but that approach can
still leave the Postdata message and page refresh and submit problem.

I particularly agree with Ben's last post on the subject. All I would add is
that my processing pages always clear $_GET, $_POST, $_REQUEST variables
once parsed, if necessary instantiating an object to retain values.

It has been an interesting thread and one enabling me to take account of
some issues in a tutorial I am writing on the subject. I have learned to
emphasise and clarify definitions and differences as regards subjects like
MVC, RPC and the use of $_SESSION only for passing of return values.

I remain confident of the n-tier approach I use. Not only does it resolve
niggling issues like Postdata messages and security issues but opens doors
to use threading, efficient use of factory classes, "parallel tiers" (Web
services for example), and the building of consistently reusable libraries.
Most of all it enables me to have short, clear, object pages for specific
parts of the development thus making it easier for code maintainance and
upgrade. More of that another time!

Thanks for the thread James!

Mike A.


----- Original Message -----
From: "Dai Williams" [EMAIL REMOVED]
To: [EMAIL REMOVED]
Sent: Monday, May 28, 2007 8:51 PM
Subject: RE: FN-FORUM: PHP PostData security


>
> Mike A wrote:
> > Given this obnoxious and unnecessary statement my part on this thread
> > ends here. My undergraduate and MSc students have a 100% pass rate in
> > both graduation and fast entry into good employment, my client
> > project portfolio is full for several months, and there are two major
> > projects on the go. The preparation, detail and delivery for students
> > far exceeds what I can provide for this forum - even on a good day!
>
> Mike,
>
> I have the greatest respect for your contributions to this forum and
offline
> to a number of members, myself included. In light of their erudition I
have
> no doubt you are extremely successful and helpful offline.
>
> However on this specific issue I do think you have confused a number of
> people by describing handling data within the same script that displays a
> form (model A) as fundamentally insecure as opposed to separating scripts
> for form presentation, processing and subsequent result display (model B).
>
> While model A may well be bad practice according to various programming
> methodologies, your own included, that is not what I and apparently
several
> other people understood by your original statement.
>
> My current understanding and correct me if I am wrong is:
>
> - It is possible to write insecure code with model A
> - It is possible to write secure code with model A
> - It is possible to write insecure code with model B
> - It is possible to write secure code with model B
> - It is more likely that a neophyte programmer would write insecure code
> with model A than model B
>
> If that is a summary of what is being proposed I would agree with it, if
not
> then I would like to understand further, as I too believe it is quite
> possible to write secure code with model A, provided you are knowledgeable
> and careful (ofc).
>
> Regards,
>
> Dai Williams
>
>
> --
> Freelancers, contractors earn more with Prosperity4
> Call 0870 870 4414 or visit www.prosperity4.com
> and benefit from Inland Revenue approved expenses today.
>
> To advertise here: http://www.freelancers.net/advertising.html
>
>