• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Best way to validate a form's input on submit?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
Database abstraction, frameworks, and many other things will attempt to solve this problem, relying on them for all of your security is a poor decision. The best solution is whitelisting input (so that it only hits the SQL statement if it exactly matches what you whitelisted), otherwise, regular expression matching to ensure that what you are getting is what you expect to get. There's a pretty good slide deck here about it:
http://www.slideshare.net/billkarwin/sql-injection-myths-and-fallacies

It's best to assume that, at some point in its life, someone will try to attack any application. Building an accurate risk profile is impossible because I don't have any information to go on.. if it's a company with 10 people making pretzels, it's going to be very different than a Fortune 500 defense contractor. Needless to say, lots of options:

* A security guy, like me, doing a vulnerability assessment, for audit, compliance, or security lifecycle purposes
* Any employee, who decides that "security is so bad" or "they are so skilled" that they can hack anything they choose, and that's the first thing they see. Yes, they'll get repremanded if caught, but that won't stop them.
* A disgruntled employee, for any reason, really
* A contractor who's getting money on the side by selling the company directory to a headhunter
* That guy with the laptop in his car in the parking lot who broke into your wifi, who's looking to social engineer his way into the building, by adding his name to the employee list
* The botnet owner, who managed to infect one of the company laptops, and is connecting through it to post a message on the front page instructing all employees to install the virus.
* An attacker who has managed to get into the network by hacking a DMZ server. This is a juicy target, because it's likely that a lot of people use the same "work" password for their Intranet login and corporate domain login. Getting domain credentials from a custom-built intranet site is typically going to be way easier than getting it from the domain controllers.
* You get the idea...
 
Well, I ran these concerns by the project lead and while he was interested, he wants the functionality first, security later (never, I'm betting). He did indicate he would have his security techs run their vulnerability suite of tests against the web portal. Oh well, I tried.
At this particular company, any employee or contractor caught hacking a company website would be fired or have their contract terminated, full stop.
 
At this particular company, any employee or contractor caught hacking a company website would be fired or have their contract terminated, full stop.
That would(should!) happen at any company...
 
It takes hardly any time to validate input in your server-side script, and that's the only place where it actually makes any difference. Javascript validation is perhaps a time saver, but if the functionality doesn't exist on the server it can't really be said to exist.

Let's say at some point in the future your company asks another dev to automate the posting of information to your app. If she does the simplest thing, which would be to use cURL to POST the data, then your Javascript-based validation is completely bypassed. Even though she wasn't trying to "hack" the app, you still get incorrect / incomplete data being saved to your database. The automated script might even get the same response from your app that it would get if it had submitted correct/complete data, giving the dev no indication that there's a problem that needs to be fixed. It might seem like I'm reaching, but situations like this happen all of the time.

The proper place to make sure your data is clean and correctly formatted is upon submission, right before you save it to your database, and you need to make sure it's correct then no matter what. Cleaning up badly formatted data is a pain, and if there is missing data you may not be able to recreate it. As a developer, the integrity of the data should be your first priority. Bad code will eventually get replaced, but bad data is forever.
 
At this particular company, any employee or contractor caught hacking a company website would be fired or have their contract terminated, full stop.

Way to totally ignore that disgruntled employee or contractor who is not yet fired or laid off, but knows they will be soon, or for the sake of foil hats, the corporate espionage contractor who is there for the sole purpose of breaking things. Bluntly, ignoring security like that is outright stupid (which is why I find myself making rather long lists of things that really ought to be changed in my work :)).
 
Way to totally ignore that disgruntled employee or contractor who is not yet fired or laid off, but knows they will be soon, or for the sake of foil hats, the corporate espionage contractor who is there for the sole purpose of breaking things. Bluntly, ignoring security like that is outright stupid (which is why I find myself making rather long lists of things that really ought to be changed in my work :)).

I believe that now there are also legal repercussions for illegally hacking a company website -- regardless of
whether or not you're an employee or contractor of the company in question.

Oracle 10g does have recommended procedure guidelines to minimize SQL injection attacks (i.e. using
oci_bind_by_name calls to separately bind parameters to SQL statements).

I'm in no position to argue w/my Project Lead or manager about what their priorities are or aren't. I'm a nobody
contractor. I'd still hate to get blamed for any fallout from their decision though.
 
I believe that now there are also legal repercussions for illegally hacking a company website -- regardless of
whether or not you're an employee or contractor of the company in question.
That has, for all intents and purposes, always been illegal... ;)

Its curious as the verbiage in your posts make it sound like this is a surprise to you?
 
Back