|
|
Posted by Jerry Stuckle on 04/04/06 01:56
David Haynes wrote:
> Michael Trausch wrote:
>
>> David Haynes wrote:
>>
>>> Mike:
>>>
>>> I understand all that.
>>>
>>> There is a level of weak security sometimes called 'security through
>>> obscurity' that URL hiding falls into. I agree it's not sufficient but,
>>> then again, nothing is absolute when talking about security.
>>>
>>
>> Yes, however, security through obscurity is *always* a false sense of
>> security -- even when coupled with other mechanisms. There is no real
>> added benefit with URL hiding. More on that in a second.
>>
>>> At best, you build walls within walls to increase the technical
>>> knowledge required to defeat the system. Sometimes you can add to the
>>> fun by adding false information to the mix. For example, if I change my
>>> php mapping to, say, asp, an inexperienced hacker will spend time
>>> chasing a blind alley (i.e. attempting asp exploits against a php
>>> system).
>>>
>>
>> Yes, and no. Do note that most of the vulnerabilities that *do* exist
>> that are not application bugs, tend to be things like the server itself
>> has a buffer overflow. When you're using ASP, you can use it on
>> Microsoft's IIS using VBScript, JScript, or Perl, or, there is also at
>> least one setup that allows you to use ASP on Apache, so long as the
>> language variant used is Perl (http://www.apache-asp.org/install.html).
>> Since there are various versions of both, and yet, compromises still
>> happen, you can conclude that the obscurity of that "security" is not
>> effective.
>>
>>> Smarter hackers will not trust the asp signature and probe for other
>>> corroborating information, but we have reduced the total population of
>>> hackers hitting the site - which is one of the objectives of security.
>>> Yes, it fails if the hacker is persistent, but the profile of the
>>> amateur hacker is one of quick in/quick out. If they don't crack it
>>> immediately, they tend to move on to easier prey unless there is some
>>> compelling reward for continuing their efforts.
>>>
>>
>> Perhaps, but you never really /truly/ know if the server is telling the
>> truth or not. For example, if I really, *really* wanted to, I could
>> configure Apache to treat all *.php files in the web namespace on that
>> particular server to actually be ran as CGI programs, which could be
>> written in bash, C, C++, Ruby, Python, Perl...
>>
>> And that could actually *worsen* security, if I were using arbitrary C
>> programs and trying to hide them as PHP ones. Remote exploits, say,
>> through a buffer overflow, would be easier to find if the program were a
>> C program that was poorly written, as opposed to a PHP script actually
>> running at a given location.
>>
>>> Organizations use security through obscurity all the time. They will
>>> order equipment to be delivered to a sidewalk location with instructions
>>> to 'drop it and leave the area'. The goal here is that the delivery
>>> person has no idea of the final destination of the goods making it much
>>> more difficult for the delivery person to supply location information to
>>> some third party. Often buildings with security requirements are hidden
>>> by mislabeling them or having no identification information on them at
>>> all. URL masking is like dropping the package on the side walk or
>>> mislabeling the building - it hides information from the attacker.
>>>
>>
>> So, just because the majority of newcomers to the Internet like to
>> top-post, does that mean that it's okay? How about the fact that many
>> people like to use that highly annoying thing called HTML mail and news?
>> Does that make it any better? What about if people were jumping off of
>> bridges and out of buildings because of something they'd seen on TV or
>> heard on the radio? Would you follow them there, too? Just because
>> people seem to find a false sense of security or meaning in something,
>> does not make the practice any more correct. What it does do, is clue
>> crackers into the fact that people actually believe that these methods
>> help and work for them. In many cases, they can correctly assume that
>> "real" security concerns have not been looked after, because the people
>> running on web servers will take their false sense of security and run
>> with it.
>>
>> If anything, that means that they will improve their cracking tools, and
>> try harder to get at information. Especially if that information can
>> help them in some way, such as harvesting of e-mail addresses, or other
>> similar data-harvesting scenerios. They can educate their software to
>> just always assume that it is being lied to, and brute-force their way
>> into things. So, the practice, overall, can be argued to actually
>> weaken security.
>>
>>> You and Jerry seem to be implying that I said that URL hiding
>>> represented all the security you needed - which I never said. I was
>>> simply objecting to Jerry's (and now your) assertion that URL hiding was
>>> not a viable element within the security plan for a site.
>>>
>>
>> Now, I never said that, nor did I imply it. What I am saying is that
>> using anything that breeds a false sense of security is a bad thing.
>> While you may immediately know what is going on with it, and you may
>> know what is going on, you're also going to be likely to confuse
>> maintenance programmers with non-standard configurations, and you'll
>> find, too, that middle- and upper-management love to buy into things
>> that portray that false sense of security, because they don't know any
>> better -- and the old expression of a little bit of knowledge can be a
>> dangerous thing, applies here.
>>
>> The ramifications of such a choice are almost always larger then what
>> you would expect, and consequently, the choice tends to not be worth it.
>> Make the application robust and strong as possible, on its own merit.
>> If you really feel that you want something to analyze and try to
>> strengthen it, set up a honeypot so that you can take that data and put
>> it to good use. That can only help the application become stronger as
>> time goes by.
>>
>> Security through obscurity is a horrible thing. Microsoft relies on
>> that for most of their business to work. And as you can see by doing
>> searches on the Internet, it doesn't work out so well
>> (http://en.wikipedia.org/wiki/Windows_Genuine_Advantage is one such
>> recent example of this). Security through obscurity, in many cases, is
>> just an unnecessary complication on the part of the programmer(s), and
>> really nets no accomplishments or savings down the road.
>>
>> - Mike
>
>
> Mike:
>
> The following article discusses what I am trying to say in another way.
>
> http://www.bastille-linux.org/jay/obscurity-revisited.html
>
> In a nutshell:
> Security through obscurity is not necessarily a bad thing and may be
> part of a security plan.
>
> *Relying* on security through obscurity is a bad thing.
>
> -david-
>
David,
I agree with Mike. Security through obscurity is a bad thing.
As for the article you quoted: it's one person's opinion, and six years old.
Here's some other links:
http://slashdot.org/features/980720/0819202.shtml
http://netsecurity.about.com/cs/generalsecurity/a/aa060103.htm
And a whole tutorial at http://www.cgisecurity.com/owasp/html/pt01.html. Pay
particular atten to Chapter 4.
And there are many others.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|