On Thu, March 29, 2007 10:06 am, Daniel Brown wrote:
> Just wondering how many of you actually use any type of secure
> coding
> when doing form processing.
Always.
For all new code.
I can't possibly go back and re-write every script everywhere I ever
wrote over the past decade, though...
Which is worrisome, but what can be done?
> I'm guilty of not doing it all the time
> myself,
> but I'm trying to get into the habit of doing so. For example, I
> don't want
> someone else modifying a form to auto-post values to my handler, so I
> would
> use:
>
> <?
> if($_POST && eregi(getenv("SERVER_NAME"),getenv("HTTP_REFERER")))
> {
> // This is a safe POST
> } elseif(!eregi(getenv("SERVER_NAME"),getenv("HTTP_REFERER"))) {
> die("Illegal access. Your IP has been logged.\n");
> }
> ?>
You are locking out users whose browser chooses not to send
HTTP_REFERER, which is not a required header to be sent.
So it's pretty much locking out valid users.
And I don't think it's all that great to force the POST data to have
come from your server anyway...
Maybe I'm just scarred from the bad old days...
There were times in the dawn of www where I'd take FORMs, save them as
HTML on my hard drive, FIX the stupid bugs that wouldn't let me submit
perfectly valid data, and then submit the data. I forget exactly what
was going wrong on a regular basis... It was maybe browser 2.0 days,
mind you... Javascript checks that claimed my email was "invalid"?
Just plain broken FORM and TABLE tags? Ah yes, that's probably it.
Their form only worked in IE, and I used Netscape on Linux.
> That's one method.... any other thoughts on that part?
I think you are better off worrying about the actual POST data coming
in, than trying to "catch" how they sent it.
> Then, once the data is there, I try to remember to use
> addslashes(),
> htmlspecialchars(), and other functions (as well as some I've written
> myself
> over the years) to handle the data properly and securely when
> inserting it
> into a database or processing it on anything more than a bare, basic
> level.
Well, addslashes is pretty much not right anymore.
It won't protect against UTF-8/16 when you upgrade to Unicode PHP/DB
in anticipation of going global.
I think you really ought to be using htmlentities() rather than just
htmlspecialchars() on anything going to the browser -- Unless it's got
very specific HTML you want to allow already added under controlled
conditions... Which is very difficult to achieve.
I think you'd be best served by reading everything on this site:
http://phpsec.org/
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
