NYCPHP Meetup

[Anirudh Zala]

On Fri, 15 Sep 2006 20:07:37 +0530, csnyder <chsnyder at gmail.com> wrote:

> On 9/15/06, Anirudh Zala <arzala at gmail.com> wrote:
>> 1) The biggest area of this problem is browser. Not because that it is
>> being exploited in many ways but why can't browser itself provide basic
>> level of validation and input filtering like validations of name, email
>> address, phone, fax, mobile etc. according to country or region. This is
>> not big task or too much difficult for browser's and it's extension's
>> developers. If we have characters set encoding, to display text in  
>> various
>> languages, available in browser then why can't we have support of
>> validation of above items. Now it is not that big that which validation
>> format is to be used for each country or region. We can tell browser  
>> from
>> our HTML in similar way about which character set encoding to be used.
>
> I see where this appears to make a developer's job easier, but it
> doesn't do _anything_ to make web applications more secure, and could
> have a negative impact on security as beginning devs will assume that
> "the browser is checking all that, so I don't have to".
>

Your point is valid. But if you fully read my first reply to this thread,  
You could figure out that my suggestions about minimizing security threats  
are to take precautions from all possible areas. Taking necessary steps at  
one area doesn't mean that you are safe from there. No. instead that step  
might be helpful to other steps so at next step you will have less  
overhead. In that context, taking browser related validation and filter  
can be an add-on advantage to developers as well as clients itself. This  
layer is just a part of many more layers of security practice. Browser is  
to be 1st layer where you can check at least format of input, doesn't  
matter you will do it again at your application layer. Point is that, it  
is helpful to clients as well that they get instant notification about all  
possible incorrectness while filling in data.

At first glance it may seem that it will have negative effect on security  
for beginners, but it might not be true because we already have JS level  
checks and still we do it at application level. So it is similar like  
that. Do double check.

> The problem isn't average humans using browsers. The problem is
> crackers using their own tools and scripts, especially automated
> scripts, to attack your sites directly. Forget about the client and
> focus your efforts on protecting the server from _anything_ that could
> concievably be thrown at it.

>
>> For example while mentioning email address at public
>> place, user can write it in such a way that it can not be figured out  
>> from
>> sources of data. By this way 70% of spamming can be stopped because
>> spammer programs can not figure that out.
>
> Wanna bet? The spammers are just as smart as you are, and probably
> have more time to think about the problem than you do. As long as
> you're the only person doing this, it will work, but as soon as
> obfuscation reaches a critical mass, the screen-scrapers will get a
> lot smarter overnight.

We all are smarter. This is like a battle that will not end ever. However  
probability of winning and loosing that  battle will get changed  
constantly. So if spammers finds new ways to send more and more spams, we  
can find new ways to protect ourselves from them to minimize probability  
of their win. Struggle is everywhere. But probability of survival is  
important.

>
> ----
> Chris Snyder
> http://chxo.com/
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php

-----------------------------------------------
Anirudh Zala (Project Manager)
ASPL, http://www.aspl.in
arzala@@gmail.com
-----------------------------------------------