php perl dumb question

[squash@peoriadesignweb.com]

a dumb question i had on my mind:

Say you have a dynamically created web page . Isn't it more secure to
write it in php since a visitor will not be able to tell it is
dynamically created? But if you write it in perl, you have to put it in
your cgi-bin which automatically means it's a dynamically generated
page? security by obscurity . Is this true or hardly means anything?
thx!

[Philip Ronan]

Re: php perl dumb question

squash@peoriade signweb.com wrote:
[color=blue]
> a dumb question i had on my mind:
>
> Say you have a dynamically created web page . Isn't it more secure to
> write it in php since a visitor will not be able to tell it is
> dynamically created? But if you write it in perl, you have to put it in
> your cgi-bin which automatically means it's a dynamically generated
> page? security by obscurity . Is this true or hardly means anything?
> thx!
>[/color]

So what?

Who cares if your pages are created dynamically?

What does that have to do with security?

--
phil [dot] ronan @ virgin [dot] net

http://vzone.virgin.net/phil.ronan/

[squash@peoriadesignweb.com]

Re: php perl dumb question


Philip Ronan wrote:[color=blue]
> Who cares if your pages are created dynamically?
>
> What does that have to do with security?
>
> --
> phil [dot] ronan @ virgin [dot] net
> http://vzone.virgin.net/phil.ronan/[/color]

If the script is in the cgi-bin then the visitor knows there must be
some master script program that is able to update that page. If it's
just in the home directory then the user can't tell if its dynamicall
created or not.

My point is someone who wants to do something malicious with your site
will typically look for the easiest way in, i.e a dynamically created
page.

Thx!

[squash@peoriadesignweb.com]

Re: php perl dumb question


Philip Ronan wrote:[color=blue]
> Who cares if your pages are created dynamically?
>
> What does that have to do with security?
>
> --
> phil [dot] ronan @ virgin [dot] net
> http://vzone.virgin.net/phil.ronan/[/color]

If the script is in the cgi-bin then the visitor knows there must be
some master script program that is able to update that page. If it's
just in the home directory then the user can't tell if its dynamicall
created or not.

My point is someone who wants to do something malicious with your site
will typically look for the easiest way in, i.e a dynamically created
page.

Thx!

[Jacob Atzen]

Re: php perl dumb question

On 2005-01-21, squash@peoriade signweb.com <squash@peoriad esignweb.com> wrote:[color=blue]
> If the script is in the cgi-bin then the visitor knows there must be
> some master script program that is able to update that page. If it's
> just in the home directory then the user can't tell if its dynamicall
> created or not.[/color]

Normally it's pretty obvious if a page is dynamically generated. Almost
all websites today with more than a few pages are dynamically generated.
Often the URL and forms will also reveal the fact. Finally most
webservers tell if they are running some sort of script interpreter.

The point being that this probably shouldn't be your primary concern
regarding security (or your secondary or your...). If your scripts are
secure it doesn't really matter if your pages are dynamically generated
or not.
[color=blue]
> My point is someone who wants to do something malicious with your site
> will typically look for the easiest way in, i.e a dynamically created
> page.[/color]

Why would the easiest way in be a dynamically created webpage?

--
Cheers,
- Jacob Atzen

[Martin Kissner]

Re: php perl dumb question

squash@peoriade signweb.com wrote :[color=blue]
> a dumb question i had on my mind:
>
> Say you have a dynamically created web page . Isn't it more secure to
> write it in php since a visitor will not be able to tell it is
> dynamically created? But if you write it in perl, you have to put it in
> your cgi-bin which automatically means it's a dynamically generated
> page? security by obscurity . Is this true or hardly means anything?
> thx![/color]

You can easily use perl for dynamicly creating webpages which submit
html-code just like static pages.
So the question is pointless.

On the other hand the attentive visitor can tell if a page is dynamycly
created by the content no matter if its prodused by php, perl or any
other language.
Last but not least many providers dont parse php-code in pages with the
html-extension so again the visitor will see that the page was dynamicly
created.

Who cares?

friendly greetings
Martin

--
Epur Si Muove (Gallileo Gallilei)

[Philip Ronan]

Re: php perl dumb question

squash@peoriade signweb.com wrote:
[color=blue]
> My point is someone who wants to do something malicious with your site
> will typically look for the easiest way in, i.e a dynamically created
> page.[/color]

Oh, I see what you mean. Basically you shouldn't be posting insecure scripts
to your server in the first place, regardless of whether they're written in
PHP, Perl or anything else.

A few weeks ago there was a worm that hit thousands of websites running
phpBB (a free PHP-based web forum). The worm itself was written in Perl.
This could just as easily have happened the other way round.

You've just got to be careful, that's all!

--
phil [dot] ronan @ virgin [dot] net

http://vzone.virgin.net/phil.ronan/

[Erwin Moller]

Re: php perl dumb question

Jacob Atzen wrote:
[color=blue]
> On 2005-01-21, squash@peoriade signweb.com <squash@peoriad esignweb.com>
> wrote:[color=green]
>> If the script is in the cgi-bin then the visitor knows there must be
>> some master script program that is able to update that page. If it's
>> just in the home directory then the user can't tell if its dynamicall
>> created or not.[/color]
>
> Normally it's pretty obvious if a page is dynamically generated. Almost
> all websites today with more than a few pages are dynamically generated.
> Often the URL and forms will also reveal the fact. Finally most
> webservers tell if they are running some sort of script interpreter.
>
> The point being that this probably shouldn't be your primary concern
> regarding security (or your secondary or your...). If your scripts are
> secure it doesn't really matter if your pages are dynamically generated
> or not.
>[color=green]
>> My point is someone who wants to do something malicious with your site
>> will typically look for the easiest way in, i.e a dynamically created
>> page.[/color]
>
> Why would the easiest way in be a dynamically created webpage?
>[/color]

Indeed: I agree completely.

An easy way is:
- find some username. (eg via telltale www.xxx.com/~username)
- Try password: 'secret' or 'password' or something other dumb.
;-)

Seriously: You should try to make your script more robust against funny
things.
Most important: Whenever you receive data from a form, don't trust it.
Just make sure you are protected against naughty stuff like SQL-injection.

Always think DURING CODING if you (the creator of the scripts) can find a
way to screw things up.
Using PHP instead of Perl for that reason is no reason to use PHP.
Of course there ARE good reasons to use PHP instead of Perl, but that is a
whole other discussion.

By the way: You can easily hide the path if you want with apache using
mapping-technics.
eg: instead of posting to www.xxx.com/cgi-bin/mySecurityhole.pl
you can post to www.xxx.com/somescript
and let apache take care of the translation of somescript to
cgi-bin/mySecurityhole. pl

Regards,
Erwin Moller

[John Dunlop]

Re: php perl dumb question

An anonymous being wrote:
[color=blue]
> a dumb question i had on my mind:[/color]

No such thing.
[color=blue]
> Say you have a dynamically created web page . Isn't it more secure to
> write it in php since a visitor will not be able to tell it is
> dynamically created?[/color]

URIs shouldn't contain information about how the resource
was put together. That includes 'cgi-bin', and '.php'.

HAGW!

--
Jock

[Kevin]

Re: php perl dumb question

I sincerely doubt this would add much security, but if you want to hide the
fact that you're page is using PHP, remember to set expose_php to "off" in
php.ini. Otherwise a visitor can tell you're running PHP by adding any of
the credits/easter-egg strings to a URI. For example, add
?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 to any PHP server page.

- Kevin

<squash@peoriad esignweb.com> wrote in message
news:1106316971 .818507.245500@ z14g2000cwz.goo glegroups.com.. .[color=blue]
>a dumb question i had on my mind:
>
> Say you have a dynamically created web page . Isn't it more secure to
> write it in php since a visitor will not be able to tell it is
> dynamically created? But if you write it in perl, you have to put it in
> your cgi-bin which automatically means it's a dynamically generated
> page? security by obscurity . Is this true or hardly means anything?
> thx!
>[/color]

[Philip Ronan]

Re: php perl dumb question

Kevin wrote:
[color=blue]
> I sincerely doubt this would add much security, but if you want to hide the
> fact that you're page is using PHP, remember to set expose_php to "off" in
> php.ini. Otherwise a visitor can tell you're running PHP by adding any of
> the credits/easter-egg strings to a URI. For example, add
> ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 to any PHP server page.[/color]

Awww, it's a cute little doggy!

I never knew you could do that!

--
phil [dot] ronan @ virgin [dot] net

http://vzone.virgin.net/phil.ronan/

[Ginzo]

Re: php perl dumb question

Well I for one see what you're asking and you are not as far off base
as some folks would have you believe.

1) Any web object that accepts input is inherently more vulnerable
than one that doesn't.

2) Any page that openly exposes the fact that it is accepting input is
inherently more likely to have unauthorized/questionable input
directed to it than one that doesn't expose, or exposes in a limited
way, the fact that it is taking input - whether via _POST, _GET,
_COOKIE, _SESSION and so forth.

3) Of course you should write the most secure script you can and I
think the fact that you've thought this through suggests you are on
the right track. But it's absurd to suggest that simply writing a more
secure script is enough in and of itself. The net is littered with the
corpses of the self-satisfied and smug who thought they had written a
secure script. Vulnerabilities are not typically exposed by the
developers, they are exposed by the clever, the persistent, the
motivated - and these are not always desirable characters.

4) So... Anything that enhances the security of s web application is
probably a worthwhile effort. You're idea is valid and yes, you should
pursue that. Simply as a case in point, there's a little article in
the latest 2600 about exposing php include weaknesses with a simple
Google search. When I first read it, I thought, "well that's stupid -
of course you would do x, y and z to protect yourself". Then I did
the search. HOLY SHIT. This is the very premise behind Apache features
like configurable auto-indexing and associating non-standard
extesnions with the interpreter - ie

application/x-php .html

Ginzo

Good luck and keep thinking about things in this way. You'll be a lot
better off in the long run.

On 21 Jan 2005 07:08:42 -0800, squash@peoriade signweb.com wrote:
[color=blue]
>
>Philip Ronan wrote:[color=green]
>> Who cares if your pages are created dynamically?
>>
>> What does that have to do with security?
>>
>> --
>> phil [dot] ronan @ virgin [dot] net
>> http://vzone.virgin.net/phil.ronan/[/color]
>
>If the script is in the cgi-bin then the visitor knows there must be
>some master script program that is able to update that page. If it's
>just in the home directory then the user can't tell if its dynamicall
>created or not.
>
>My point is someone who wants to do something malicious with your site
>will typically look for the easiest way in, i.e a dynamically created
>page.
>
>Thx![/color]

[Jacob Atzen]

Re: php perl dumb question

On 2005-01-22, Ginzo <sumpn@hotmail. com> wrote:[color=blue]
> 1) Any web object that accepts input is inherently more vulnerable
> than one that doesn't.[/color]

Yes.
[color=blue]
> 2) Any page that openly exposes the fact that it is accepting input is
> inherently more likely to have unauthorized/questionable input
> directed to it than one that doesn't expose[/color]

Yes. But it's impossible to hide that you're accepting input.
[color=blue]
> 3) Of course you should write the most secure script you can[/color]
[...][color=blue]
> But it's absurd to suggest that simply writing a more secure script is
> enough in and of itself.[/color]

Why? If your script is secure then it's secure. Of course this does not
mean, that it really is secure just because you think so.
[color=blue]
> The net is littered with the corpses of the self-satisfied and smug
> who thought they had written a secure script. Vulnerabilities are not
> typically exposed by the developers, they are exposed by the clever,
> the persistent, the motivated - and these are not always desirable
> characters.[/color]

Which relates in what way to trying to hide the fact that a webpage is
dynamically created?
[color=blue]
> 4) So... Anything that enhances the security of s web application is
> probably a worthwhile effort.[/color]

You still have not put forward any arguments indicating that obscuring
the fact your webpage is dynamically created, leads to better
security.

--
Regards,
- Jacob Atzen

[Ginzo]

Re: php perl dumb question

Well, you can decline to accept the argument all you want; but I stand
by my position and the facts that support it.
[color=blue]
>Yes. But it's impossible to hide that you're accepting input.[/color]

True, but it's not impossible to be subtle and it's not unreasonable
to limit your exposure. Maybe the tradeoff isn't always worthwhile;
but to say "No, there's no security benefit" is just wrong and to say
"the nominal security benefit isn't worth exploring" is arrogant. This
is the kind of thing that falls into the famous last words category
[color=blue][color=green]
>> 3) Of course you should write the most secure script you can[/color]
>[...][color=green]
>> But it's absurd to suggest that simply writing a more secure script is
>> enough in and of itself.[/color]
>
>Why? If your script is secure then it's secure. Of course this does not
>mean, that it really is secure just because you think so.[/color]

Yeah well, honest developers don't generally knowingly release product
that they believe to be insecure. But a lot of great and highly
respectable products are found, after the fact, to have significant
vulnerabilities all the time. I'm not just talking about MS here,
where you expect this kind of thing. We're talking about Apache, PHP,
Bind, sendmail and off shoot products. CERT had more than 2600
reported vulnerabilities in the first 9 months of 2004 alone. For the
mathematically challenged that's just a little less than 10 per day.
[color=blue][color=green]
>> The net is littered with the corpses of the self-satisfied and smug
>> who thought they had written a secure script. Vulnerabilities are not
>> typically exposed by the developers, they are exposed by the clever,
>> the persistent, the motivated - and these are not always desirable
>> characters.[/color]
>
>Which relates in what way to trying to hide the fact that a webpage is
>dynamically created?[/color]

Now you're just being ornery. If you can't string it together, that's
not a hole in my argument - that's just your own refusal to see the
other side of the coin. If a web page is dynamically generated, it
immediately suggests a host of possibilities to a would be attacker.
SQL injection, altered globals, forged headers - all become
increasingly attractive in the face of a web application. If you can
help ameliorate a vulnerability that you may not have thought of by
limiting your exposure - that's a good call. Ignore it if you want.
This isn't me out here on some island spouting controversial security
philosophy - this is textbook shit man. There are several pages on the
concept in "Linux Firewalls 2nd Ed." , "Hacking Exposed", "Securing
Red Hat Linux" and Gibson's book (forget the name, it's on Amazon).
You should be reading 2600 and see how black hats find places to use
the vulnerabilities they learn about. If that don't sell you - you
can't be sold and I'll just give up quietly.
[color=blue][color=green]
>> 4) So... Anything that enhances the security of s web application is
>> probably a worthwhile effort.[/color]
>
>You still have not put forward any arguments indicating that obscuring
>the fact your webpage is dynamically created, leads to better
>security.[/color]

I've put forward several, twice now; and then clarified the position.
Do what you want with it.

Ginzo

[Jacob Atzen]

Re: php perl dumb question

On 2005-01-22, Ginzo <sumpn@hotmail. com> wrote:[color=blue]
> Well, you can decline to accept the argument all you want; but I stand
> by my position and the facts that support it.[/color]

I'm terribly sorry but I can't seem to find any facts supporting your
stance. All I see is references to insecure applications, blackhats,
2600 and whatnot. All this tells us is that if you have an insecure
application somebody will probably exploit it sooner or later.
What it does not tell us is whether you increase security by obscuring
the fact that you're using PHP or perl or whatever.

I will agree that the risk of being compromised decreases if you hide
that you're generating your pages dynamically. From the logic that some
attackers will find it easier to move on to pages that are obviously
generated. This however does not equate increased security as I see it,
as your application is just as capable (or not) of being compromised and
therefore not more or less secure. As such I think that we agree
fundamentally.
[color=blue]
> True, but it's not impossible to be subtle and it's not unreasonable
> to limit your exposure.[/color]

That wholly depends on your setup. If you're using $_GET, $_POST,
$_SESSION or $_COOKIE it's a no go. More on this later.
[color=blue]
> Maybe the tradeoff isn't always worthwhile; but to say "No, there's no
> security benefit" is just wrong and to say "the nominal security
> benefit isn't worth exploring" is arrogant. This is the kind of thing
> that falls into the famous last words category[/color]

Agreed.
[color=blue]
> Now you're just being ornery. If you can't string it together, that's
> not a hole in my argument - that's just your own refusal to see the
> other side of the coin. If a web page is dynamically generated, it
> immediately suggests a host of possibilities to a would be attacker.[/color]

Yes, of course. Except it's more the fact that an attacker may influence
the application than the fact it's dynamically generated. A subtle but
important point. Your website can be totally generated from a database
but unless you somehow make it possible for an attacker to influence the
application it leaves him no attack opportunities.
[color=blue]
> SQL injection, altered globals, forged headers - all become
> increasingly attractive in the face of a web application. If you can
> help ameliorate a vulnerability that you may not have thought of by
> limiting your exposure - that's a good call.[/color]

Yes, I just find it very hard to see how you can limit your exposure. If
you're using anything from $_GET, $_POST, $_SESSION og $_COOKIE the
attacker will immediately know that he may influence the application.
And if your application still depends on register_global s being on you
really need to shape up.

The only possible way to hide that you're running an application is to
gather the necessary parameters from the URL (like
www.example.com/articles/2005/10, where articles, 2005 and 10 is
parameters). Now assuming you are only using this kind of parameters to
influence your application you can hide the fact that the it is possible
to influence the application (under the assumption that your application
behaves rationally when given unexpected input). But in this case it is
trivial to make sure you only accept valid URL's and as such your
application is secure, thereby making it irrelevant whether an attacker
knows about the application or not.

It would be quite interesting to see statistics of what kind of attacks
are being pursued in attacks on PHP applications. Does anyone know of
such a statistics? I would assume that the majority of attacks are SQL
injections and forged globals.
[color=blue]
> This isn't me out here on some island spouting controversial security
> philosophy - this is textbook shit man. There are several pages on the
> concept in "Linux Firewalls 2nd Ed." , "Hacking Exposed", "Securing
> Red Hat Linux" and Gibson's book (forget the name, it's on Amazon).
> You should be reading 2600 and see how black hats find places to use
> the vulnerabilities they learn about. If that don't sell you - you
> can't be sold and I'll just give up quietly.[/color]

Please don't. You seem very knowledgeable and I always like to learn. I
just have a habbit of not accepting opinion unless it is backed by
logic.
[color=blue][color=green]
>>You still have not put forward any arguments indicating that obscuring
>>the fact your webpage is dynamically created, leads to better
>>security.[/color]
>
> I've put forward several, twice now; and then clarified the position.
> Do what you want with it.[/color]

Under the assumption that less risk of being exploited is the same as
increased security, yes.

I'm glad that we're having this little debate as I really would like to
learn more about security in regards to PHP web applications. Does
anyone know of a list of known forms of attacks?

--
Regards,
- Jacob Atzen