hidden php file extension

[Badr.ALmuzini]

hi,there

how can i make php file extension hidden in the URL somthing like this
(http://mail.google.com/mail/?view)

Regard....

[Henrik Hansen]

Ba***********@gmail.com writes:

hi,there

how can i make php file extension hidden in the URL somthing like this
(http://mail.google.com/mail/?view)

If you do this the parameter ?view is appended the index.php file in
that dir, so it's quite easy, just make sure your index.php
understands ?view. Another way is to make .html (.htm) files to be
parsed as php, then you have index.html but you can actually use
php in the file.

--
Henrik Hansen

[tihu]

Henrik suggestions are correct. Another way to mask file extensions is
by using mod_rewrite in apache

[youcantoo]

Henrik Hansen wrote:

Ba***********@gmail.com writes:

hi,there

how can i make php file extension hidden in the URL somthing like this
(http://mail.google.com/mail/?view)

If you do this the parameter ?view is appended the index.php file in
that dir, so it's quite easy, just make sure your index.php
understands ?view. Another way is to make .html (.htm) files to be
parsed as php, then you have index.html but you can actually use
php in the file.

That is not really a good idea as it puts a hugh load on the server. Now
for EVERY .html page apache servers it will have to parse each .html
page for php script, even if the page has no php script in it. This
really increases the load on the server. It all translates to SLOWER
pages. Is that what you really want to achieve?

[Henrik Hansen]

youcantoo <dw*@findmoore.net> writes:

Henrik Hansen wrote:

Ba***********@gmail.com writes:

hi,there

how can i make php file extension hidden in the URL somthing like this
(http://mail.google.com/mail/?view)

If you do this the parameter ?view is appended the index.php file in
that dir, so it's quite easy, just make sure your index.php
understands ?view. Another way is to make .html (.htm) files to be
parsed as php, then you have index.html but you can actually use php
in the file.

That is not really a good idea as it puts a hugh load on the
server. Now for EVERY .html page apache servers it will have to parse
each .html page for php script, even if the page has no php script in
it. This really increases the load on the server. It all translates to
SLOWER pages. Is that what you really want to achieve?

Do you have any banchmarks for your claims? I use this way and can't
really see any difference at all to be honest. Parsing pages to see if
there is php in it goes VERY fast. Ofcource everything is relative but
in general I think it's a good way of masking files.

You could also just turn it on on the php folders if you have seperate
static content folders, so they dont get treatet as php.

--
Henrik Hansen

[Jerry Stuckle]

Henrik Hansen wrote:

youcantoo <dw*@findmoore.net> writes:

Henrik Hansen wrote:

Ba***********@gmail.com writes:
hi,there

how can i make php file extension hidden in the URL somthing like this
(http://mail.google.com/mail/?view)

If you do this the parameter ?view is appended the index.php file in
that dir, so it's quite easy, just make sure your index.php
understands ?view. Another way is to make .html (.htm) files to be
parsed as php, then you have index.html but you can actually use php
in the file.

That is not really a good idea as it puts a hugh load on the
server. Now for EVERY .html page apache servers it will have to parse
each .html page for php script, even if the page has no php script in
it. This really increases the load on the server. It all translates to
SLOWER pages. Is that what you really want to achieve?

Do you have any banchmarks for your claims? I use this way and can't
really see any difference at all to be honest. Parsing pages to see if
there is php in it goes VERY fast. Ofcource everything is relative but
in general I think it's a good way of masking files.

You could also just turn it on on the php folders if you have seperate
static content folders, so they dont get treatet as php.

You obviously don't have a very heavily loaded server. You get one with
a few thousand hits/minute and it's a definite hit. How much depends on
the size of the HTML files, the percentage of PHP in the files and a
bunch of other things.

Why do you even care about masking the files, anyway?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Henrik Hansen]

Jerry Stuckle <js*******@attglobal.net> writes:

Henrik Hansen wrote:

youcantoo <dw*@findmoore.net> writes:

Henrik Hansen wrote:

Ba***********@gmail.com writes:
>hi,there
>
>how can i make php file extension hidden in the URL somthing like this
>(http://mail.google.com/mail/?view)

If you do this the parameter ?view is appended the index.php file in
that dir, so it's quite easy, just make sure your index.php
understands ?view. Another way is to make .html (.htm) files to be
parsed as php, then you have index.html but you can actually use php
in the file.
That is not really a good idea as it puts a hugh load on the
server. Now for EVERY .html page apache servers it will have to parse
each .html page for php script, even if the page has no php script in
it. This really increases the load on the server. It all translates to
SLOWER pages. Is that what you really want to achieve?

Do you have any banchmarks for your claims? I use this way and can't
really see any difference at all to be honest. Parsing pages to see if
there is php in it goes VERY fast. Ofcource everything is relative but
in general I think it's a good way of masking files.
You could also just turn it on on the php folders if you have
seperate
static content folders, so they dont get treatet as php.

You obviously don't have a very heavily loaded server. You get one
with a few thousand hits/minute and it's a definite hit. How much
depends on the size of the HTML files, the percentage of PHP in the
files and a bunch of other things.

Why do you even care about masking the files, anyway?

The goal was to make the best looking urls which meant a .php
extension was out of the picture. But as I said everything is
relative.. our .htm files are purely php. If you mix php and html very
much maybe the performance cost is bigger. I have no numbers of how
much traffic it gets per second but I don't think it's a few
thousand.. although we did test with ab.

--
Henrik Hansen

[burke]

Ba***********@gmail.com wrote:

hi,there

how can i make php file extension hidden in the URL somthing like this
(http://mail.google.com/mail/?view)

Regard....

Here's what I've done in the past:

(index.php)
switch($_GET['id'])
{
case 'main':
require 'main.php';
break;
case 'about':
require 'about.php';
break;
default:
require 'main.php';
break;
}

then you could type http://yourdomain?id=main

if you really wanted to drop the ID part, you'd have to use multiple
ifs, not a switch.

Just never, ever use unsanitized input from $_GET/$_POST.

ie. this is *bad*:

require '$_GET['id']'.'.php';

bad, bad, bad. Don't. ;)

As for a performance hit, I've never noticed one, but I don't run
large-scale websites, so take my experience with a grain of salt.

Sorry if my PHP isn't up to par, I'm thinking in Ruby lately.

[John Dunlop]

Jerry Stuckle:

Why do you even care about masking the files, anyway?

Because filename extensions in URLs are generally worse than useless,
and at least in Apache you need to *do* something (i.e., reconfigure
it) before it will accept "extension-less" URLs.

--
Jock

[Badr.ALmuzini]

hi, again

thanks for all u pepole

Henrik Hansen
i think this is good solution (making folders for each system) for
module projects.

tihu
thanks for your suggestion but you have to configure the Apache server
so you have to get permission on your hosting to make changes.

youcantoo
i thught that Henrik Hansen idea is to make folder and index.html file
for each forlder we can make also index.php if we need so i think there
will be no huge load on the server, in the other side if there is load
it will be scaled in micro second.

Jerry Stuckle
i think we need masking for confusing pepole whom wanna to try playing
with some web site URL or find other site resources.

burke
i will try your idea.

[Jerry Stuckle]

Ba***********@gmail.com wrote:

hi, again

thanks for all u pepole
Jerry Stuckle
i think we need masking for confusing pepole whom wanna to try playing
with some web site URL or find other site resources.

Masking is not security. Rather, you should implement basic security on your
system.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[David Haynes]

Jerry Stuckle wrote:

Ba***********@gmail.com wrote:

hi, again

thanks for all u pepole
Jerry Stuckle
i think we need masking for confusing pepole whom wanna to try playing
with some web site URL or find other site resources.

Masking is not security. Rather, you should implement basic security on
your system.

Well, masking is a form of weak security. I understand that it is not
sufficient in most cases but since it removes some information from a
potential attacker, it is a form of security.

-david-

[Jerry Stuckle]

David Haynes wrote:

Jerry Stuckle wrote:

Ba***********@gmail.com wrote:

hi, again

thanks for all u pepole
Jerry Stuckle
i think we need masking for confusing pepole whom wanna to try playing
with some web site URL or find other site resources.

Masking is not security. Rather, you should implement basic security
on your system.

Well, masking is a form of weak security. I understand that it is not
sufficient in most cases but since it removes some information from a
potential attacker, it is a form of security.

-david-

David,

No, masking is false security.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[David Haynes]

Jerry Stuckle wrote:

David Haynes wrote:

Jerry Stuckle wrote:

Ba***********@gmail.com wrote:

hi, again

thanks for all u pepole
Jerry Stuckle
i think we need masking for confusing pepole whom wanna to try playing
with some web site URL or find other site resources.
Masking is not security. Rather, you should implement basic security
on your system.

Well, masking is a form of weak security. I understand that it is not
sufficient in most cases but since it removes some information from a
potential attacker, it is a form of security.

-david-

David,

No, masking is false security.

Guess we'll agree to disagree.

-david-

[Michael Trausch]

Jerry Stuckle wrote:

David,

No, masking is false security.

Security through obscurity does not tend to work for very long periods
of time... Jerry is right. It is effectively giving you a false sense
of security in that you feel that you're eliminating information from an
attacker. There are many ways to find out if PHP is running on the
system or not, outside of your control as the application writer. It's
best to just follow the conventions that are out there for web content.
This will keep your application portable, as well as enable the coders
involved to know at a glance what language your modules are written in
when they look at them. If you use PHP, Perl, and Ruby in your
environment, file extensions are a good thing.

If you truly want security, then test your application against different
types of attacks that it can and likely will be subject to.

Check to ensure that you aren't using register_globals so that your
global namespace isn't tainted. Ensure that your application is not
subject to SQL injection attacks. Verify that you're able to spew lots
of garbage at it and get nothing valid back. Ensure that cookies can't
be crafted (if your application uses cookies) by an attacker. Be sure
that your application isn't vulnerable to replay attacks.

Those are some of the points of security that you need to watch out for,
that will heighten your level of safety in operating the application.
The job of keeping things secure, however, is almost never done;
somebody, somewhere, will find ways to get around things, and then you
have to circumvent them. Hopefully, before any compromise is made.

- Mike

[David Haynes]

Michael Trausch wrote:

Jerry Stuckle wrote:

David,

No, masking is false security.

Security through obscurity does not tend to work for very long periods
of time... Jerry is right. It is effectively giving you a false sense
of security in that you feel that you're eliminating information from an
attacker. There are many ways to find out if PHP is running on the
system or not, outside of your control as the application writer. It's
best to just follow the conventions that are out there for web content.
This will keep your application portable, as well as enable the coders
involved to know at a glance what language your modules are written in
when they look at them. If you use PHP, Perl, and Ruby in your
environment, file extensions are a good thing.

If you truly want security, then test your application against different
types of attacks that it can and likely will be subject to.

Check to ensure that you aren't using register_globals so that your
global namespace isn't tainted. Ensure that your application is not
subject to SQL injection attacks. Verify that you're able to spew lots
of garbage at it and get nothing valid back. Ensure that cookies can't
be crafted (if your application uses cookies) by an attacker. Be sure
that your application isn't vulnerable to replay attacks.

Those are some of the points of security that you need to watch out for,
that will heighten your level of safety in operating the application.
The job of keeping things secure, however, is almost never done;
somebody, somewhere, will find ways to get around things, and then you
have to circumvent them. Hopefully, before any compromise is made.

- Mike

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.

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).

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.

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.

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.

-david-

[Michael Trausch]

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

[David Haynes]

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/ob...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-

[Jerry Stuckle]

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/ob...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/gene...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.
js*******@attglobal.net
==================

[Michael Trausch]

David Haynes wrote:

Mike:

The following article discusses what I am trying to say in another
way.

http://www.bastille-linux.org/jay/ob...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.

Perhaps that's the issue then. When I say "security through obscurity,"
I certainly do not mean "security solely though obscurity." The
practice of implementing it adds further burdens to future
administrators and programmers alike, not only within your organization,
but others.

As I highlighted in my previous post, when people are used to security
being practiced with means of obscurity in their way, they will merely
adapt their cracking programs to handle any potential obscurities that
they will come across. The consequences of that can be increased
cracking attempts, network traffic, and server load.

By minimizing the number of secrets that you retain in your scheme of
security, you are not only helping yourself and your fellow
admins/programmers, but you are helping a bigger picture. In addition,
it keeps the focus where it *should* be: On the strength of the one
item that *should* be kept secret: The key, or in this case, raw access
to data.

When you give attention to obfuscating things, you're taking attention
away from securing things, plain and simple. The human brain does not
work like a dual processor system, processing things in real time all at
once... and you can't work on two problems at once like that, as you (I
am guessing... but, this is just a guess <g>) only have two hands.

Also, keep in mind that we are talking about something that doesn't use
a PKI system. When you're working with PKI systems, the protocols, and
the information on the algorithms, are wide open (just as the
documentation for PHP and Apache are), and you're working with a
controlled access key (which takes a very long time to break), as
opposed to a mechanism running on a web server, which is insanely easy
to detect.

In the case of PHP, I can detect the presence of it by simply going to a
site, and seeing that there is a page there. Then I revisit the site,
adding something to the query string, and see if I get the PHP easter
egg image back:

http://php.net/?=PHPE9568F36-D428-11...9-00AA001ACF42

This works on every server I know of that is currently running PHP.
This will work for every machine I know of that is running PHP, save for
one where PHP was patched to prevent the easter eggs from showing up.
You can try to alleviate the problem by using .htaccess files as well,
to control the "expose_php" flag -- but only if your web application
provider allows you to, and so you can't assume that it is portable.

One thing that I'd like to highlight from the article:
Does it hurt your site security at all? No, it really doesn't. Your
good access control, in the form of strong authentication, is still
present. All we've done is made the server slightly harder to find!
See, so long as you understand that the server location and port
number can't serve as a method of authentication, you haven't harmed
your security in the slightest.

In this case that they're using in the article, they're making an
(accurate) assessment that hiding certain details does not harm your
security. I agree with this wholeheartedly. But given the nature of
the Internet, you've not really added anything beneficial to your
security, either.

In implementing intentional obscurity, you're hoping that it's not going
to be reversed. Unfortunately, with the number of machines that run on
the Internet today, and with many of them under the control of forces
that are out to assuredly do you no good, you've essentially
accomplished nothing. That makes it not only a waste of time, but in
time, every cracker on the planet will know what to look for and then
everyone who's attempting to do this is going to find that they've
wasted manpower to implement obscurity that is trivial.

Now, if your idea of obscurity is to require a plug-in that responds to
a challenge using a strong cryptographic cypher, before the server even
gives the time of day to the person on the other end, you have something
that is going to work, and was worth the time to implement.

In the end, in this situation, all you're doing is adding unnecessary
complexity. Security through obscurity -- especially this type of it --
is trivial, useless, and honestly, not going to help you out at all. I
stress it again: If you want security, you *must* look at all the right
criteria for security. The goal isn't to do something that "doesn't
harm" your security. The goal is to think like the cracker on the other
end, and do things that will _improve_ your security, at least somewhat
substantially. That's why I stress things like SQL injection.

Also, make sure that your algorithms that you use don't generate
unnecessary overhead. This can allow crackers to create substantial DoS
type outages, temporary though they may be.

Make sure you're not using CGI scripts that are vulnerable to buffer
overflows. Make sure that the application server's security and the
database server's security are the way they should be -- that none of
the services involved in that chain are exploitable that anyone is aware
of, and if they become so, that you upgrade them immediately.

Security is about doing things that improve your situation such that it
adds a non-trivial amount of complexity to the equation when trying to
crack a site. That's where the brainpower needs to stay totally focused
on, from initially writing the application, all the way through to
post-release support.

- Mike