yes.. mao na ang common thinking that to be more restrictive is to be
more secure...
but how about for applications(both on the web and standalone) that
offer other services aside from security?
what if it was an OS, basin ma sacrifice pud ang convenience and the
user's capability to customize?
what if our program was a web browser and it would pop out something
everytime it detects something it cannot understand..
imagine the number of registered mime-types in IANA, it would be close
to impossible to develop a browser that can validate,parse
and process all streams using those mime-types... how much for the
"custom" mime-types, katong dili pa standard ug mga modified
mime-types? our web browser program behvaior would be very annoying to
users....
dili man tingali ni murag silver bullet or magical solution na issue...
like what ardie stated, depende gyud ni sa needs..
there are tradeoffs to be made...
true, ur statements are valid when it comes to security and
virus-control.. but not always when it comes to other issues...
we, programmers cannot really rely on absolutes forever.. mao gyud na
ang challenge everytime...
hard wyrd wrote:
On a security standpoint, you really cannot afford to provide a
'window of opportunity' for malicious code to run rampant. What I
found out about blacklisting is that 'if a belongs in z, then a is not
allowed. if b is not in z, then it is allowed. " Anything that is not
in the list is allowed. Picture out a virus definition file when
thinking about blacklists.
Whitelisting on the other hand is explicitly saying that 'if a is in
z, then a is allowed. If b is not in z, then it is not allowed.". All
other else not in the list are not allowed. This will then give a
coder, programmer, administrator to pick/choose which will be allowed
to function (code, application, device, user). I'd rather selectively
allow something, rather than allowing everything else, then when the
problem arise, block the one or ones that created the problem(s)
because it might be too late reverse the damage done.
On 11/6/06, *Raymond Olavides* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Whitelisting will definitely block all those unwanted codes but it
definitely needs more of the coder's/scripter's attention to
ensure valid and good codes will be parsed correctly. Whitelisting
is some sort of "predetermination" It's like saying that only
apples, mango, and grapes are the good fruits and everything else
is bad. In programming applications we deal with limited amounts
of logic thus, this method is generally good cause we know exactly
what is needed.
My fondness for blacklisting is as mentioned - when a blacklist is
created you are filtering bad apples from good ones. To know which
are bad fruits would entail research and/or actual cases where the
fruits not suitable for processing. In programming, this process
forces coders/scripters to be constantly aware of security
pitfalls, it actually ensures that the coder will take it upon
himself to improve his coding styles and logic (if it's his coding
practices is flawed) or block exploitable areas (if the problem
lies with the underlying technology) - it ensures that the
developer will improve. Blacklisting is actually great for
creating dynamic applications where users are given the greater
control over their own data and how they want the system to
function - just like the many webapp that comes around every now
and then.
And lastly, of course consideration whether to use whitelisting or
blacklisting always depends on the type and data access of the
application that you are developing.
On 11/5/06, *hard wyrd* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
The Whitelist method has been the best kept secret when
talking about security in any application.
A lot of apps (anti-vir, etc...) uses blacklisting and this is
somewhat ineffective specially towards problems that you
haven't encountered yet. Explicitly and selectively allowing
methods, functions, applications will prevent exploitation.
--
http://audienceone.blogspot.com <http://audienceone.blogspot.com>
_________________________________________________
Kagay-Anon Linux Users' Group (KLUG) Mailing List
[email protected] <mailto:[email protected]>
(http://cdo.linux.org.ph)
Searchable Archives: http://archives.free.net.ph
--
"A dog that has no bite, barks loudest."
Registered Linux User #400165
Subscribed to:
LARTC, Open-ITLUG, PRUG, KLUG, sybase.public.ase.linux
------------------------------------------------------------------------
_________________________________________________
Kagay-Anon Linux Users' Group (KLUG) Mailing List
[email protected] (http://cdo.linux.org.ph)
Searchable Archives: http://archives.free.net.ph
_________________________________________________
Kagay-Anon Linux Users' Group (KLUG) Mailing List
[email protected] (http://cdo.linux.org.ph)
Searchable Archives: http://archives.free.net.ph
