473,883 Members | 1,741 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

hidden php file extension

hi,there

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

Regard....

Mar 21 '06
19 3847
Ba***********@g mail.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*******@attgl obal.net
=============== ===
Apr 3 '06 #11
Jerry Stuckle wrote:
Ba***********@g mail.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-

Apr 3 '06 #12
David Haynes wrote:
Jerry Stuckle wrote:
Ba***********@g mail.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*******@attgl obal.net
=============== ===
Apr 3 '06 #13
Jerry Stuckle wrote:
David Haynes wrote:
Jerry Stuckle wrote:
Ba***********@g mail.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-

Apr 3 '06 #14
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_global s 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
Apr 3 '06 #15
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_global s 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-

Apr 3 '06 #16
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
Apr 3 '06 #17
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-

Apr 3 '06 #18
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*******@attgl obal.net
=============== ===
Apr 3 '06 #19
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
Apr 3 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
11841
by: Paul | last post by:
I am trying to get a form to dynamicaly add hidden elements. Below is the function I've created, basicaly it loops thru an array and attempts to add those values to a newly created hidden input field which it then appends to the form. I works in IE, but in NN7 nothing is passed. function processAssortment(){ // get the form Element var formElement=document.getElementById("candyBoxForm"); //loop thru the candy box contents, add them to...
3
1605
by: markus | last post by:
I have an application that I think was developed using some form of Borland C with a folder for BIG images with the extension .fre. When I try to view them they cannot be read even by changing the extension to jpg, bmp, zip, etc. I also used some utilities for resource extraction with no success. I know the images are there and there has to be a way to show and convert them to a known format. I have seen libjpeg.dll and zlib.dll in...
3
1939
by: Botan Guner | last post by:
Hi everyone, I'm running php on win2000 server and iis. I have a script that builds the directory sturcture of a directory or a drive. My problem is that i want to find that which directories are hidden. I have looked stat() function but it seems that it does not return a value for being hidden or not. Thanks for any help,
7
1477
by: Shaul Feldman | last post by:
Hello, the question is how can I masquerade ASPX files behind HTML extension? Thank you in advance. -- With the best wishes, Shaul Feldman
2
2020
by: UJ | last post by:
I have an aspx page that does some database look ups on the initial load. I then need to do stuff later after an autopostback based on some of the values. So I put some variables in input variables of type hidden. Problem is on the reload-prerender the variables are not filled in yet. Is the best solution session variables? TIA.
3
3176
by: Shapper | last post by:
Hello, I created a script to upload a file. To determine the file type I am using userPostedFile.ContentType. For example, for a png image I get "image/png". My questions are: 1. Where can I find a list of all the types which can be returned? For example, if it is a Word document will it return "document/doc".
0
2637
by: rautsmita | last post by:
hello friends , i am using to jdk6 and JAXB2.0, i have geomtry.xsd file i am trying to compile this file using jaxb but i got some error i.e.The particle of the type is not a valid restriction of the particle of the base this xsd file is valid as per w3c standard i am also providing error in detail and geometry.xsd file geometry.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/gml"...
11
6050
by: geoffbache | last post by:
Hi, As part of my efforts to write a test tool that copes with GUIs nicely, I'm trying to establish how I can start a GUI process on Windows that will not bring up the window. So I try to hide the window as follows: info = subprocess.STARTUPINFO() info.dwFlags |= subprocess.STARTF_USESHOWWINDOW info.wShowWindow = subprocess.SW_HIDE
3
3565
by: =?Utf-8?B?UGVycmlud29sZg==?= | last post by:
Not sure where to post this... Found some interesting behavior in Windows Search (Start =Search =All files and folders =search for "A word or phrase in the file:"). This applies to XP and maybe other Windows flavors. Procedure: 1. Create a simple text file named test.txt. 2. Open the text file in a text editor and add a simple test word such as "blah" (not quotes).
0
9944
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9796
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10757
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10860
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10420
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9583
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7134
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
4620
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3239
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.