| Re: Validate Radio Buttons? [message #182376 is a reply to message #182370] |
Thu, 01 August 2013 21:11   |
bill
Messages: 310
Registered: October 2010
Karma:
|
Senior Member |
|
|
On 2013-07-31 3:00 PM, The Natural Philosopher wrote:
> On 31/07/13 19:20, Twayne wrote:
>> Hi all,
>>
>> I was wondering what the general consensus might be on this:
>>
>> Should one Validate Radio Buttons for an online website contact form?
>>
....
>>
>> So, what do YOU think?
>>
> I think really only you can answer this one.
> Think what would happen in a user somehow faked everything and sent out
> of bounds data. Or sql injection type code instead of what was supposed
> to be in the post variable.
I'm trying! :)
One thing I have learned is that I'm woefully ignorant of those
processes and thus am fighting something I have little knowledge of. I'm
working on solutions to that issue too.
>
> One simple way to get rid of most malware is to cast explictily or
> implicitly, all variables to integers,
THAT sounds like a good idea! Why didn't I think of that? But it does
bring a possibly stupid question: If I've been hit with XSS or some kind
of injection, might it already have done its damage by the time I get to
be able to process the cast to numeric?
And more specifically, how could a single-digit result from a Radio
Button contain anything harmful as long as I check that it's in bounds?
I realize that's possibly outside the scope of this group, but
thought I'd ask anyway. No problem if you ignore it.
>
> So for example if you were setting an SQL field to a numeric value based
> on user response, I normally would use sprintf to prepare the query with
> %d representing an integer value, into an ID or an enumerated field. Out
> of bounds data is simply then an error and no further validation is
> rquired, unless you want to send the error back to the user, which n te
> case of a radio button is pointlss because you woat GET error data
> unless they have actively faked the entry.
Makes sense.
>
> Any data that falls into a few well defined entries only, is easy to
> validate. The problem comes when you allow arbitrary string entry.
> Then SQL injection can happen if a really nasty string is concocted, but
> even then php supplies tools to sanitise just about anything you throw
> at it, up to and including (as I discovered) turning strings into
> hecadecimal numbers and inserting THOSE into the database. Assuming you
> are working with a database.
No DB yet, but I do plan to add it after learning it well enough. I'm
primarily interested in radio button validation at the moment.
>
> One of the best ways to approach design to put on a black hat and try
> and crack it yourself. Think when you code 'what would happen if..there
> was no data at all, the data contained special characters you really
> wouldn't expect?
I've tried that, and so have a couple of buddy coders, and to date no
one has managed to get thru. But that's not a very large segment of
people and they're admittedly not the best code breakers around.
>
> Another thought is 'don't bother putting bars on the windows if you
> leave the front door open' the easiest way to hack a website is to find
> the administrative portal and hack past the password. Too many people
> leave the default settings in place when they install code written by
> others. Don't.
Nope, I don't, or I do my best not to, at least. <g> One of the pieces
of code I'm most proud of so far is the generation of the temporary
access code every visitor is given when he starts to fill out the form.
It's been judged better than "average" at PHPBuilder, NAS, Tizag and
here too if I'm not mistaken. It's a good ego boost and probably the
best first line of defense, but nothing can ever be 100% safe as we all
know.
>
>
Regards,
Twayne`
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]