To PHP Developers, seeking your experienced opinion on data validation

I'm new to PHP, so I hope you don't find this a stupid question.

When I make a form, I validate it with JavaScript to make sure all field values are in order. My question is, do you guys do another round of validation on the server with your PHP scripts? I ask because the thought occurred to me that the user might make a copy of the web page on his machine, strip out all the JavaScript, then try to submit the form. That could wreak havoc on the server.

So I'm interested in how PHP developers more experienced than I approach this. Thank you in advance.
elepilAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ray PaseurCommented:
Yes, we do another round of validation on the server.  The simple "security mantra" is filter input.  In every case, accept only known good values.  If your script expects an integer, cast the external input to data type integer.  If PHP thinks the value changed, discard the request.  If you're looking for a telephone number or an email address, filter the external input appropriately and if it fails the filter, discard the request.

You can use the client-side filters to make a nice user experience, but if your client input gets past the client-side filters and fails the server-side filters, it is almost certainly an attack (or your filters are faulty) and you should not use the external data.
0
Ray PaseurCommented:
Afterthought... This is not just a PHP issue - any server script that accepts external data from any source (request vars, databases, session data, etc) has the same issue and needs to filter the input.  By definition all external data is tainted and must be filtered before it is used in a server-side script.
0
elepilAuthor Commented:
Ray,

Afterthought... This is not just a PHP issue - any server script that accepts external data from any source (request vars, databases, session data, etc) has the same issue and needs to filter the input.

You are correct, but the platform I came from, i.e., using Adobe Flex as the front end and Java at the back end, had less risks. I of course always uuencode on the front end and uudecode on the server. But in the case of PHP, I also have to check for field lengths, something I never had to worry about in Adobe Flex (because the front end is compiled code, no one can strip the validations).

Thanks for your wise feedback, Ray. I'm going to keep this ticket open to get more comments from others and see how they handle this.
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Terry WoodsIT GuruCommented:
I agree with Ray, though there are definitely cases where the server side validation can be heavily reduced (compared with the amount of validation done at the client side) to just protect the system from dangerous/malicious data. It should always be considered though!

Note also that the form doesn't even need to be copied to strip out the validation; it can be done in a browser using the developer tools.
0
Ray PaseurCommented:
in a browser using the developer tools
Yep!  Or with a simple cURL script.

All your JavaScript is belong to us!  We are all your requests!
0
Dave BaldwinFixer of ProblemsCommented:
My method is to validate in javascript on the client to help get the form filled out correctly and validate on the server to protect the server and the database.  I also check the referrer in PHP and exit if it isn't coming from the right page.  While I'm aware that it can be forged, a lot of spammers don't bother.  And the 'professionals' aren't going to bother you if there isn't a big payoff available.

On one page where I wasn't checking the referrer, I had a spammer post 38,000 entries trying to break in.  They didn't succeed because all the rest was done correctly.  On a 'search' form on a couple of sites, I get people trying to do "SQL Injection" fairly often.  But since the input data is processed before before sent to the database, they never get in there either.

And on all forms I've done recently, the PHP page only accepts a substring that is the size of the data.  I've had people try to POST 10,000 bytes to a textarea intended for 300 characters.  My POST processing looks like this:
if (!isset($_POST["Name"]))  $Name = ''; else $Name = substr($_POST["Name"],0,64);

Open in new window

0
Ray PaseurCommented:
Some references:
http://php.net/manual/en/security.php
https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet
http://www.sitepoint.com/php-security-blunders/
http://phpsecurity.readthedocs.org/en/latest/Introduction.html#basic-security-thinking (TL;DR - use your own judgement)

Some other random thoughts and scenarios...

You have an older version of PHP, or settings that allow older PHP scripts to work without modernization.
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_6630-Magic-Quotes-a-bad-idea-from-day-one.html
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_7317-Register-Globals-a-bad-idea-from-day-one.html

You expect a two-character string to represent the state, but an attacker sends you an array.  Instead of testing for the data type, you use the external data as if it were the string you expected.  PHP variable type coercion converts this value to a string by delivering you the word "Array" so when you use the first two characters, all of your attack data seems to be coming from Arkansas.

You number your data base elements with AUTO_INCREMENT keys, and use these keys to display discreet data about each client (or similar data resource) with a URL that says something like /details/{id}.  Your script responds to a GET request by providing a page of details.  Your attacker simply makes an array of {id} values from 1 to 1,000,000 and calls your script repeatedly with each {id} in the URL.  In a matter of a seconds, the attacker has stolen all of the information of your entire client base.

A disgruntled employee steals your hard drive.

Your hosting company is on a fiber optic cable that is severed by construction equipment (flooded, hit by lightning, etc).

To sum up, Information Technology Security is a full-time four year college major at the University of Maryland.  In other words, it's a lot to keep up with in a constantly mutating field!
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
elepilAuthor Commented:
What scares me the most, and I don't know if hackers can do this, is to modify all the records of a customer database randomly so as to make them useless where only a restoration from backup becomes the only recourse. And the hacker would have most likely used an automated script himself and can repeat the process anytime he wants just as easily as he did the first time.

I imagine a lot of attacks out there are not limited to lucrativeness (hacking for a 'payoff'). I imagine a lot of attacks are due to mischief (hacking just because they can), malevolence (hacking because they want you to fail), or hatred (hacking because they hate you).

Thanks all for responding.
0
Ray PaseurCommented:
For the most part those kinds of things will not happen if you filter the input.  

One additional item probably worth mentioning because it seems to crop up every few months... If you're using a framework (I'm looking at YOU, WordPress) and you install some kind of add-on or plug-in or whatnot from an unreliable source, and you don't understand what the code is doing but you install it anyway... After you restore your files and rebuild your database and give up trying to reconstruct all of the lost data... only then should you go back and read the part about "filter the input."  

Input is not only request data -- it's anything you put into your web site, especially including foreign code you don't understand!
0
elepilAuthor Commented:
Ray, I am not using Wordpress (yet). I have read about it though, so I know a little about it.

My current application is a custom application from the ground up. No frameworks here (yet). I will be looking for a job as a PHP developer soon, and I'm sure they will be using some kind of framework that I will have to learn.

I do use filter_input. If I remember right, you were the one not using it until lately. Apparently you like it now. :)
0
Ray PaseurCommented:
Just a thought... Your job prospects will be aided greatly if you can show a portfolio of demonstration sites using Laravel.  It's the framework that is taking over all the other frameworks.  And it has a relatively sophisticated client profile, so less risk that a novice will install components without understanding them!
0
elepilAuthor Commented:
Ray,

I've heard you talk about Laravel a few times. I looked into it, but I'm not sure how that framework can even do the kind of application I'm working on right now. But I know so little about Laravel, so my assessment is pretty much worthless at this point.

My transition from Java/AdobeFlex to PHP has been a lengthy journey because I pretty much had to learn all related technologies. While Flex used CSS, it does not play as big a role as CSS does with HTML. I was using ActionScript, and the syntax is the only thing similar to JavaScript because the former has its own components and class libraries. jQuery and PHP were totally new to me. MySQL is pretty much the same. When I looked into PHP frameworks, I was astounded how many there were and the steep learning curves associated with them. I figure if I picked one, there is no guarantee my future job will be using that framework. So I set aside frameworks in the meantime, and I'll just have to cross that bridge when I get to it.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
PHP

From novice to tech pro — start learning today.