Re: PS Re: GUI designer in html [message #182448 is a reply to message #182439] |
Sun, 04 August 2013 21:01 |
bill
Messages: 310 Registered: October 2010
Karma:
|
Senior Member |
|
|
On 2013-08-04 1:09 PM, J.O. Aho wrote:
> On 04/08/13 18:47, Twayne wrote:
>> On 2013-08-04 2:32 AM, Lightee wrote:
>>
>> I feel it's necessary to let you know that HTML forms are notoriously
>> famous for being hacked, cracked and used by miscreants for spamming
>> using your forms.
>
> It's not the HTML forms, but the scripts which are to handle the input
> which do not validate the content properly, no HTML WYSIWYG will make
> the script to validate better, no matter how pretty the form looks like.
>
>
>> The best way to alleviate those exposures is to learn PHP coding, IMO.
>> You may write your first page in HTML, and then use a second PHP page to
>> do all the testing of input data on the server-side where no one can see
>> it working nor can they easily get past a rotund random code and
>> sanitization and validation codes.
>
> Rule one, always validate user input, no matter if it's always your
> mother who does the input, one day she may just try to see what happens
> if she enters "'; drop database youdatabase; #" as input and as you
> never have a backup of the database, you lost everything.
Right on! ALL user input, even including things like Radio Buttons and
drop-down Lists should be sanitized and closely scrutinized for any type
of code injection, injected scriptings, all sorts of things.
Also keep in mind that there IS NO such thing as a perfectly 100%
secure website and/or webform in particular.
If one is determined enough and has the proper tools, they WILL
hack the site and its forms! All one can hope to accomplish is to make
it too slow, or too much trouble, to use any methods at all. And another
reason to not copy a captcha script is that tools to crack them are easy
for the bass turds of the world to find and use. All one can do is to
make it hopefully out of reach of their tools and methods to bother with
any particular site. It's a trade-off on how locked you want things to
be and how much interference your visitors are ready to put up with
because sometimes the users rebel at too many hoops. It's best of course
if they never see or suspect why things are, but will still not object
to what strategies that are not going to seriously make them feel like
idiots or bots themselves.
Another strategy is to allow only so many mistakes in submitting or
filling out a form and, depending on what you're monitoring, ban further
input from their IP or Proxy for an hour, 24 hours, whatever you wish.
Personally my forms will allow two error-prone attempts and on the 3rd,
remove their access permanently. .htaccess is one ticket to doing that.
>
>> Also IMO, avoid Captcha code at all costs! Duplicate it yourself, or
>> parts of it, like the protection, but don't use their idiotic, hard to
>> read code images; they keep out as many people as they do robots.
>> Captcha code however is a pretty decent learning code; just don't use
>> it<GRIN>.
>
> I would advice to never write your own captcha or copy those average
> Aarav (kind of Indian Joe), as they usually do include a lot of issues
> with security and validation, if using captcha use something like
> reCaptcha from Google.
Personally I'd avoid using Captcha of any sort although you're right,
reCaptcha is a gentler, kinder captcha for most users. But to get one
introduced to a lot of the possibilities of site security, it's a free,
common thing to study, including some articles about the scripts
available to hack Captcha et al. But that's another book. Better to try
and learn from those who have been there before you, and help you to
understand more and more about Security all the time.
I was in error by using the word "copy" there. I didn't mean to copy
pieces of the captcha code, but to copy and hopefully improve on the
methods used in the scripts. It makes for a good starting point, is
free, and introduces one to the myriad possibilities of PHP.
I do of course agree that HTML simply cannot be made XSS or
injection protected. PHP on the other hand offers many great ways to
achieve those goals.
>
>
Decent post, J; I'd have liked to include a LOT more about sanitizing,
validation techniques et al, but that would be like writing a book
which, strangely enough, has already been covered off on some reputable
websites for PHP and even some pretty decent tuts.
Valid, reliable links are always a good way to avoid re-writing
books or parts of them and there are a few great sites out there for
that purpose. I usually recommend php.net, w3schools, Tizag and NAS as
great starting points but there are others. Just be sure to research any
site you choose before going there: Some of them are pretty ignorant or
even malware-passing pieces of junk! Always check a site's reputation
before using them or even accessing them, if possible.
IMO W3schools is easier to understand, wastes less screen
real-estate, and in general is as knowledgeable as any about PHP and its
features and functions.
Regards,
Twayne`
|
|
|