Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day. I’ve
been E-mailing back and forth with their support discussing how to best
identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page (they’re
not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee that
be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
I’m sure that is one reason why those technologies show up more often as
being used but I can imagine the answer my sys admin will give me now about
this and it starts with “hell” and ends with “no”, but to be honest he will
probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day. I’ve
been E-mailing back and forth with their support discussing how to best
identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page (they’re
not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
my servers disclose nginx as the web server. does that make them less
secure? I don’t think so.
Of course it does, as soon as an attacker knows which server it is running
then they know possible attack vectors by which to attempt to exploit it
without having to try ever attack vector under the sun. Removing the
version information goes some way to alleviating this a bit, but still if
you know it is nginx then there is no point in trying the IIS, Apache,
etc… attacks. Any information disclosure, no matter how small will assist
attackers.
how does identifying Lucee without version information making it less
secure? a hacker can easily find out that the engine is Lucee. just by
the presence of cfid cookie you know that this is one of a few possible
options.
my servers disclose nginx as the web server. does that make them less
secure? I don’t think so.
On 3/26/2015 2:58 PM, Alex Skinner wrote:
Hi
I think these are two separate things. I think we have responsibility to
promote secure by default.
Many people do not spend the time to review admin settings and we all know
best practice is security by obscurity. I’m working this week and next to
launch a feature of the Lucee site to make it easier for people to submit
their success stories to LAS.
I think we should encourage through documentation that our community is
aware of ways to get the Lucee message out there and also more importantly
let LAS know of their success too which is part of the problem.
But a credible platform is an opinionated one I think we need less config
options and more baked in best practice.
Cheers
Alex
Sent from my phone
On 26 Mar 2015 21:04, “Malcolm O’Keeffe” <@Malcolm_O_Keeffe> wrote:
While a digital “fingerprint” has its downsides, there are real business
advantages to LAS and the Lucee community if BuiltWith and other services
like it are able to easily identify Lucee web servers.
Lucee is a new technology, and will face lots of “credibility”
challenges. The more that adoption can be demonstrated, both in terms of
raw numbers as well as high-visibility sites, the more easily Lucee can be
justified for new projects.
I think having the HTTP header identify Lucee by default (but easily
turned off) as Brad Wood suggested is the best option.
On Mar 26, 2015, at 1:55 PM, Gert Franz <@Gert_Franz> wrote:
Well was a setting in the Railo admin in the years back for exactly
this. Under output as far as I remember. We changed the default to be off
instead of on. Just check the admin, if its still there.
Gert
Sent from somewhere on the road
Am 26.03.2015 um 21:46 schrieb Tom King <@Tom_King>:
Yeah, I’d definitely not want this. It’s like painting an extra
bullseye on your webserver. Whoever came up with meta-tag of ‘generated-by’
for wordpress was also an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
I’m sure that is one reason why those technologies show up more often
as being used but I can imagine the answer my sys admin will give me now
about this and it starts with “hell” and ends with “no”, but to be honest
he will probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be
hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
Yeah, I’d definitely not want this. It’s like painting an extra bullseye on
your webserver. Whoever came up with meta-tag of ‘generated-by’ for
wordpress was also an idiot.On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
On Thu, Mar 26, 2015 at 2:41 PM, Andrew Dixon <andrew...@gmail.com <javascript:>> wrote:
I’m sure that is one reason why those technologies show up more often as
being used but I can imagine the answer my sys admin will give me now about
this and it starts with “hell” and ends with “no”, but to be honest he will
probably be way more explicit than that!!!
On 26 March 2015 at 17:59, Brad Wood <bdw...@gmail.com <javascript:>> wrote:
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
While a digital “fingerprint” has its downsides, there are real business
advantages to LAS and the Lucee community if BuiltWith and other services
like it are able to easily identify Lucee web servers.
Lucee is a new technology, and will face lots of “credibility” challenges.
The more that adoption can be demonstrated, both in terms of raw numbers as
well as high-visibility sites, the more easily Lucee can be justified for
new projects.
I think having the HTTP header identify Lucee by default (but easily
turned off) as Brad Wood suggested is the best option.
On Mar 26, 2015, at 1:55 PM, Gert Franz <@Gert_Franz> wrote:
Well was a setting in the Railo admin in the years back for exactly this.
Under output as far as I remember. We changed the default to be off instead
of on. Just check the admin, if its still there.
Gert
Sent from somewhere on the road
Am 26.03.2015 um 21:46 schrieb Tom King <@Tom_King>:
Yeah, I’d definitely not want this. It’s like painting an extra bullseye
on your webserver. Whoever came up with meta-tag of ‘generated-by’ for
wordpress was also an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
I’m sure that is one reason why those technologies show up more often as
being used but I can imagine the answer my sys admin will give me now about
this and it starts with “hell” and ends with “no”, but to be honest he will
probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
Yeah, I’d definitely not want this. It’s like painting an extra bullseye
on your webserver. Whoever came up with meta-tag of ‘generated-by’ for
wordpress was also an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
I’m sure that is one reason why those technologies show up more often as
being used but I can imagine the answer my sys admin will give me now about
this and it starts with “hell” and ends with “no”, but to be honest he will
probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
Any information disclosure, no matter how small will assist attackers.
I’m not sure how best to phrase this properly, but the gist of it is that a
determined, very skilled hacker will likely manage to penetrate any server.
The attacks I see against my sites are not of this caliber, because, well,
such hackers are not interested in my sites.
So while this statement seems factually true, in practice, I don’t think a
disclosure identifying Lucee would matter in nearly all cases … as a
common sense perspective on the issue. A very skilled hacker will figure
that out on his way in. The rest will get a bit of head start trying known
vulnerabilities a developer should have locked down. I see a lot of
automated scripts at work, and these typically hit the server hundreds of
times in a few minutes, so that head start won’t make a big difference if
your server isn’t secured.
Again, I’m likely not phrasing this well, but it’s an effort to say
something like " … um yeah, but common sense would indicate that … "
I’m sure that is one reason why those technologies show up more often as
being used but I can imagine the answer my sys admin will give me now about
this and it starts with “hell” and ends with “no”, but to be honest he will
probably be way more explicit than that!!!
On 26 March 2015 at 17:59, Brad Wood <@Brad_Wood> wrote:
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page (they’re
not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
I think these are two separate things. I think we have responsibility to
promote secure by default.
Many people do not spend the time to review admin settings and we all know
best practice is security by obscurity. I’m working this week and next to
launch a feature of the Lucee site to make it easier for people to submit
their success stories to LAS.
I think we should encourage through documentation that our community is
aware of ways to get the Lucee message out there and also more importantly
let LAS know of their success too which is part of the problem.
But a credible platform is an opinionated one I think we need less config
options and more baked in best practice.
Cheers
AlexSent from my phone
On 26 Mar 2015 21:04, “Malcolm O’Keeffe” <@Malcolm_O_Keeffe> wrote:
While a digital “fingerprint” has its downsides, there are real business
advantages to LAS and the Lucee community if BuiltWith and other services
like it are able to easily identify Lucee web servers.
Lucee is a new technology, and will face lots of “credibility” challenges.
The more that adoption can be demonstrated, both in terms of raw numbers as
well as high-visibility sites, the more easily Lucee can be justified for
new projects.
I think having the HTTP header identify Lucee by default (but easily
turned off) as Brad Wood suggested is the best option.
On Mar 26, 2015, at 1:55 PM, Gert Franz <@Gert_Franz> wrote:
Well was a setting in the Railo admin in the years back for exactly this.
Under output as far as I remember. We changed the default to be off instead
of on. Just check the admin, if its still there.
Gert
Sent from somewhere on the road
Am 26.03.2015 um 21:46 schrieb Tom King <@Tom_King>:
Yeah, I’d definitely not want this. It’s like painting an extra bullseye
on your webserver. Whoever came up with meta-tag of ‘generated-by’ for
wordpress was also an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
I’m sure that is one reason why those technologies show up more often as
being used but I can imagine the answer my sys admin will give me now about
this and it starts with “hell” and ends with “no”, but to be honest he will
probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
I’m not sure how best to phrase this properly, but the gist of it is that
a determined, very skilled hacker will likely manage to penetrate any
server.
One of our clients, an ISO 27001 certified company, put in their security
policy that “attacks by nation states and terrorists, possibly assisted by
legal or physical coercion, is out of scope”. I like that phrasing.
So while this statement seems factually true, in practice, I don’t think a
disclosure identifying Lucee would matter in nearly all cases … as a
common sense perspective on the issue.
Except that after this very public discussion putting this header in would
signal to the whole world that Lucee values marketing over best practices.
I think that would more than negate any hypothetical marketing benefits.
JochemOn Fri, Mar 27, 2015 at 12:53 AM, Nando Breiter wrote:
As a developer looking at a new language for the first time, I’d find the
promotion of “secure by default” far more enticing than a list or tally of
sites sites built with it… unless you’re listing some blue-chippers.
Furthermore, you can debate whether it’s only security by obscurity, etc.
but I think the perception that
“these Lucee guys understand the importance of security out of the gate” is
more powerful than knowing x number of sites were built with it.On Thursday, March 26, 2015 at 2:58:39 PM UTC-7, Alex Skinner wrote:
Hi
I think these are two separate things. I think we have responsibility to
promote secure by default.
Many people do not spend the time to review admin settings and we all know
best practice is security by obscurity. I’m working this week and next to
launch a feature of the Lucee site to make it easier for people to submit
their success stories to LAS.
I think we should encourage through documentation that our community is
aware of ways to get the Lucee message out there and also more importantly
let LAS know of their success too which is part of the problem.
But a credible platform is an opinionated one I think we need less config
options and more baked in best practice.
Cheers
Alex
Sent from my phone
On 26 Mar 2015 21:04, “Malcolm O’Keeffe” <malcolm...@blueriver.com <javascript:>> wrote:
While a digital “fingerprint” has its downsides, there are real business
advantages to LAS and the Lucee community if BuiltWith and other services
like it are able to easily identify Lucee web servers.
Lucee is a new technology, and will face lots of “credibility”
challenges. The more that adoption can be demonstrated, both in terms of
raw numbers as well as high-visibility sites, the more easily Lucee can be
justified for new projects.
I think having the HTTP header identify Lucee by default (but easily
turned off) as Brad Wood suggested is the best option.
On Mar 26, 2015, at 1:55 PM, Gert Franz <ge…@rasia.ch <javascript:>> wrote:
Well was a setting in the Railo admin in the years back for exactly this.
Under output as far as I remember. We changed the default to be off instead
of on. Just check the admin, if its still there.
Gert
Sent from somewhere on the road
Am 26.03.2015 um 21:46 schrieb Tom King <t...@oxalto.co.uk <javascript:>
:
Yeah, I’d definitely not want this. It’s like painting an extra bullseye
on your webserver. Whoever came up with meta-tag of ‘generated-by’ for
wordpress was also an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
I’m sure that is one reason why those technologies show up more often
as being used but I can imagine the answer my sys admin will give me now
about this and it starts with “hell” and ends with “no”, but to be honest
he will probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be
hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
On Friday, 27 March 2015 00:06:37 UTC, Alex Skinner wrote:
My argument is that if best practice is to hide identifying platform
information and it is considered a normal part of server hardening then for
me that should be the default as it far outweighs any anecdotal benefit of
some website being able to list which website is built with what.
[…]
Disclosure in itself makes you no less secure but there is some benefit
of security by obscurity.
This is one of the baseline tenets of system security, and it shows no
small amount of hubris for ppl to be thinking their opinions or anecdotal
evidence somehow contradicts the broader industry’s position on this.
Secondly, whether or not the risk is real (but it is), it’s the perception
of the risk that also needs to be mitigated here.
In the real world, we have had two separate security audits that
yellow-flagged predictable cookie names. We don’t expose anything else that
might suggest our site runs on CF, except for CFID/CFTOKEN cookies which -
despite we don’t use them - we can’t switch off. However these cookies
still caused us problems. We had to make a point of explaining and
demonstrating to the auditors there was no risk. It’d simply be better to
not have to do that.
I’d possibly go further with this and consider these:
in a instance-settable “production mode” error situations return nothing at
all except the correct HTTP status code.
as mentioned, configurable cookie names, which are only set if they’re
needed
possibly consider handling directory requests within Lucee, where either
index.cfm (if present; or any of the configured welcome files) is served,
or if no welcome files exist or the directory itself doesn’t
exist treat the last subdir in the path as an obscured filename, eg:
/this/is/some/path/ would serve /this/is/some/path.cfm. This way Lucee
sites do not leak information about the fact they sue CFML files (by the
.cfm extension)
make it easy to get rid of the web-based admins. Or not have them
enabled in the first place at all.
and obscure (or don’t have by default) any predictable asset paths (like
Lucee’s equivalent of /CFIDE/scripts/, if there is one)
Indeed instead of having a setting to switch prod stuff on, perhaps have
this lot on by default and require it to be configured to behave any other
way.
Security is a very marketable feature, because it’s something everyone is
concerned about these days, with its abuse increasing prevalent in the
media.
I’m a 100% with Alex on this, this would be a step in the wrong direction,
make cfid/cftoken customazible is on our agenda and will come.
There is simply no need to be compatible with acf there. We also work to
make it possible to define extensions simply in the in the servlet
specification, so we could not only do guides hoe to hide the identity, we
could also do guides how to look like a php engine. So for me the journey
goes in the different direction.
MichaAm Freitag, 27. März 2015 schrieb ADK :
I completely agree with Alex here.
As a developer looking at a new language for the first time, I’d find the
promotion of “secure by default” far more enticing than a list or tally of
sites sites built with it… unless you’re listing some blue-chippers.
Furthermore, you can debate whether it’s only security by obscurity, etc.
but I think the perception that
“these Lucee guys understand the importance of security out of the gate”
is more powerful than knowing x number of sites were built with it.
On Thursday, March 26, 2015 at 2:58:39 PM UTC-7, Alex Skinner wrote:
Hi
I think these are two separate things. I think we have responsibility to
promote secure by default.
Many people do not spend the time to review admin settings and we all
know best practice is security by obscurity. I’m working this week and
next to launch a feature of the Lucee site to make it easier for people to
submit their success stories to LAS.
I think we should encourage through documentation that our community is
aware of ways to get the Lucee message out there and also more importantly
let LAS know of their success too which is part of the problem.
But a credible platform is an opinionated one I think we need less config
options and more baked in best practice.
While a digital “fingerprint” has its downsides, there are real business
advantages to LAS and the Lucee community if BuiltWith and other services
like it are able to easily identify Lucee web servers.
Lucee is a new technology, and will face lots of “credibility”
challenges. The more that adoption can be demonstrated, both in terms of
raw numbers as well as high-visibility sites, the more easily Lucee can be
justified for new projects.
I think having the HTTP header identify Lucee by default (but easily
turned off) as Brad Wood suggested is the best option.
On Mar 26, 2015, at 1:55 PM, Gert Franz ge...@rasia.ch wrote:
Well was a setting in the Railo admin in the years back for exactly
this. Under output as far as I remember. We changed the default to be off
instead of on. Just check the admin, if its still there.
Yeah, I’d definitely not want this. It’s like painting an extra bullseye
on your webserver. Whoever came up with meta-tag of ‘generated-by’ for
wordpress was also an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
I’m sure that is one reason why those technologies show up more often
as being used but I can imagine the answer my sys admin will give me now
about this and it starts with “hell” and ends with “no”, but to be honest
he will probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be
hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to
Lucee that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
My argument is that if best practice is to hide identifying platform
information and it is considered a normal part of server hardening then for
me that should be the default as it far outweighs any anecdotal benefit of
some website being able to list which website is built with what.
[…]
Disclosure in itself makes you no less secure but there is some benefit of
security by obscurity.
This is one of the baseline tenets of system security, and it shows no
small amount of hubris for ppl to be thinking their opinions or anecdotal
evidence somehow contradicts the broader industry’s position on this.
Secondly, whether or not the risk is real (but it is), it’s the perception
of the risk that also needs to be mitigated here.
In the real world, we have had two separate security audits that
yellow-flagged predictable cookie names. We don’t expose anything else that
might suggest our site runs on CF, except for CFID/CFTOKEN cookies which -
despite we don’t use them - we can’t switch off. However these cookies
still caused us problems. We had to make a point of explaining and
demonstrating to the auditors there was no risk. It’d simply be better to
not have to do that.
I’d possibly go further with this and consider these:
in a instance-settable “production mode” error situations return nothing at
all except the correct HTTP status code.
as mentioned, configurable cookie names, which are only set if they’re
needed
possibly consider handling directory requests within Lucee, where either
index.cfm (if present; or any of the configured welcome files) is served,
or if no welcome files exist or the directory itself doesn’t exist treat
the last subdir in the path as an obscured filename, eg:
/this/is/some/path/ would serve /this/is/some/path.cfm. This way Lucee
sites do not leak information about the fact they sue CFML files (by the
.cfm extension)
make it easy to get rid of the web-based admins. Or not have them enabled
in the first place at all.
and obscure (or don’t have by default) any predictable asset paths (like
Lucee’s equivalent of /CFIDE/scripts/, if there is one)
Indeed instead of having a setting to switch prod stuff on, perhaps have
this lot on by default and require it to be configured to behave any other
way.
Security is a very marketable feature, because it’s something everyone is
concerned about these days, with its abuse increasing prevalent in the
media.On Friday, 27 March 2015 00:06:37 UTC, Alex Skinner wrote:
My argument is that if best practice is to hide identifying platform
information and it is considered a normal part of server hardening then for
me that should be the default as it far outweighs any anecdotal benefit of
some website being able to list which website is built with what.
Plus automated scripts which search for known vulnerable systems tend to
rely on headers and known responses to work out platforms they then proceed
using metasploit or other platforms to run known vulnerabilities.
Disclosure in itself makes you no less secure but there is some benefit of
security by obscurity.
I have raised a feature request a few times about not setting cfid and CF
token unless a session is actually created this would also help in not
leaving an obvious fingerprint.
If as we do in some cases u strip cookies, offending headers, use rewrite
rules and generally catch errors u make it quite difficult for someone to
identify the tech which is helpful.
ASent from my phone
On 26 Mar 2015 23:35, “Igal @ Lucee.org” <@Igal> wrote:
it’s very simple to identify the engine. if the attacker can’t do that
then he wouldn’t be able to do much damage anyway.
most servers (and I’m not only talking about web servers) identify the
product name. if this was an issue then this practice would have changed
long ago.
my servers disclose nginx as the web server. does that make them less
secure? I don’t think so.
Of course it does, as soon as an attacker knows which server it is
running then they know possible attack vectors by which to attempt to
exploit it without having to try ever attack vector under the sun. Removing
the version information goes some way to alleviating this a bit, but still
if you know it is nginx then there is no point in trying the IIS, Apache,
etc… attacks. Any information disclosure, no matter how small will assist
attackers.
On 26 March 2015 at 22:02, Igal @ Lucee.org <@Igal> wrote:
how does identifying Lucee without version information making it less
secure? a hacker can easily find out that the engine is Lucee. just by
the presence of cfid cookie you know that this is one of a few possible
options.
my servers disclose nginx as the web server. does that make them less
secure? I don’t think so.
On 3/26/2015 2:58 PM, Alex Skinner wrote:
Hi
I think these are two separate things. I think we have responsibility to
promote secure by default.
Many people do not spend the time to review admin settings and we all
know best practice is security by obscurity. I’m working this week and
next to launch a feature of the Lucee site to make it easier for people to
submit their success stories to LAS.
I think we should encourage through documentation that our community is
aware of ways to get the Lucee message out there and also more importantly
let LAS know of their success too which is part of the problem.
But a credible platform is an opinionated one I think we need less config
options and more baked in best practice.
Cheers
Alex
Sent from my phone
On 26 Mar 2015 21:04, “Malcolm O’Keeffe” <@Malcolm_O_Keeffe> wrote:
While a digital “fingerprint” has its downsides, there are real business
advantages to LAS and the Lucee community if BuiltWith and other services
like it are able to easily identify Lucee web servers.
Lucee is a new technology, and will face lots of “credibility”
challenges. The more that adoption can be demonstrated, both in terms of
raw numbers as well as high-visibility sites, the more easily Lucee can be
justified for new projects.
I think having the HTTP header identify Lucee by default (but easily
turned off) as Brad Wood suggested is the best option.
On Mar 26, 2015, at 1:55 PM, Gert Franz <@Gert_Franz> wrote:
Well was a setting in the Railo admin in the years back for exactly
this. Under output as far as I remember. We changed the default to be off
instead of on. Just check the admin, if its still there.
Gert
Sent from somewhere on the road
Am 26.03.2015 um 21:46 schrieb Tom King <@Tom_King>:
Yeah, I’d definitely not want this. It’s like painting an extra
bullseye on your webserver. Whoever came up with meta-tag of ‘generated-by’
for wordpress was also an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that’s why it would be able to be turned off
I’m sure that is one reason why those technologies show up more often
as being used but I can imagine the answer my sys admin will give me now
about this and it starts with “hell” and ends with “no”, but to be honest
he will probably be way more explicit than that!!!
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day.
I’ve been E-mailing back and forth with their support discussing how to
best identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be
hidden)
Cause an error like a 404 and hope for standard error page
(they’re not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to
Lucee that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
I think it’s important to point out that probably most of these sites are
for our customers. We might think of them as ours, but at the end of the
day, this is a question of risk - and that is something the site owners
need to chime in on.
Personally, I’d prefer not disclosing the engine just by default. I’m
actually a little bit wary that there might be a setting that could enable
the engine to provide that data. That said, I’d like to be able to promote
my main project as a Lucee powered site (customer and higher ups
permitting). So it’s a bit of a Catch-22. Part of the resistance to this
idea, I feel, is that it’s like saying ‘This is my house - I am out of it
between the hours of 9-5. Please swing by and take a look around the
property.’ Some people will check if you’ve locked the door or left it
open. Of course, if someone wants in, they’ll just break a window, but
advertising it makes it more of an appealing target than every other house
in your neighborhood.
I’m not a decision maker on my project, but I believe there would be less
resistance to submitting stats about things like:
Number of sites we support running Lucee
General Business Sectors
Our company details
But even there, I think there would be a greater comfort level knowing that
data was just going into a aggregated roll up from a ‘trusted’ entity -
such as LAS. But I’d be very concerned about that data being a publicly
available ‘menu’ for anyone that’s just heard of a 0-day and wants to test
out.
Chip.On Thursday, March 26, 2015 at 1:59:43 PM UTC-4, Brad Wood wrote:
Like, I mentioned in this thread https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion, I
submitted Lucee as a new technology to builtwith.com the other day. I’ve
been E-mailing back and forth with their support discussing how to best
identify a Lucee (or any CFML) server. Common approaches are:
File extensions (not specific to Lucee, can be hidden with URL
rewrites)
Common session cookies (not specific to Lucee)
Admin URL (they’re reticent to scan for these, can also be hidden)
Cause an error like a 404 and hope for standard error page (they’re
not doing this yet, only works if no global error handler in place)
What’s the general consensus for adding a default HTTP header to Lucee
that be disabled by an admin that has something like:
X-Powered-By: Lucee
I’m well aware this sort of thing flies in the face standard server
hardening, but it’s been a very common occurrence in technologies such as
.NET or PHP and I can’t help but wonder if it’s made those technologies
look “more used” just because they’re easy to identify.
My argument is that if best practice is to hide identifying platform
information and it is considered a normal part of server hardening
then for me that should be the default as it far outweighs any
anecdotal benefit of some website being able to list which website is
built with what.
Plus automated scripts which search for known vulnerable systems tend
to rely on headers and known responses to work out platforms they then
proceed using metasploit or other platforms to run known vulnerabilities.
Disclosure in itself makes you no less secure but there is some
benefit of security by obscurity.
I have raised a feature request a few times about not setting cfid and
CF token unless a session is actually created this would also help in
not leaving an obvious fingerprint.
If as we do in some cases u strip cookies, offending headers, use
rewrite rules and generally catch errors u make it quite difficult for
someone to identify the tech which is helpful.
it's very simple to identify the engine. if the attacker can't do
that then he wouldn't be able to do much damage anyway.
most servers (and I'm not only talking about web servers) identify
the product name. if this was an issue then this practice would
have changed long ago.
Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>
On 3/26/2015 4:20 PM, Andrew Dixon wrote:
my servers disclose nginx as the web server. does that make
them less secure? I don't think so.
Of course it does, as soon as an attacker knows which server it
is running then they know possible attack vectors by which to
attempt to exploit it without having to try ever attack vector
under the sun. Removing the version information goes some way to
alleviating this a bit, but still if you know it is nginx then
there is no point in trying the IIS, Apache, etc... attacks. Any
information disclosure, no matter how small will assist attackers.
Kind regards,
Andrew
about.me <http://about.me/andrew_dixon>
mso <http://www.mso.net> - Lucee <http://lucee.org> - Member
On 26 March 2015 at 22:02, Igal @ Lucee.org <@Igal <mailto:@Igal>> wrote:
how does identifying Lucee without version information making
it less secure? a hacker can easily find out that the engine
is Lucee. just by the presence of cfid cookie you know that
this is one of a few possible options.
my servers disclose nginx as the web server. does that make
them less secure? I don't think so.
On 3/26/2015 2:58 PM, Alex Skinner wrote:
Hi
I think these are two separate things. I think we have
responsibility to promote secure by default.
Many people do not spend the time to review admin settings
and we all know best practice is security by obscurity. I'm
working this week and next to launch a feature of the Lucee
site to make it easier for people to submit their success
stories to LAS.
I think we should encourage through documentation that our
community is aware of ways to get the Lucee message out
there and also more importantly let LAS know of their
success too which is part of the problem.
But a credible platform is an opinionated one I think we
need less config options and more baked in best practice.
Cheers
Alex
Sent from my phone
On 26 Mar 2015 21:04, "Malcolm O'Keeffe" <@Malcolm_O_Keeffe <mailto:@Malcolm_O_Keeffe>> wrote:
While a digital “fingerprint” has its downsides, there
are real business advantages to LAS and the Lucee
community if BuiltWith and other services like it are
able to easily identify Lucee web servers.
Lucee is a new technology, and will face lots of
“credibility” challenges. The more that adoption can be
demonstrated, both in terms of raw numbers as well as
high-visibility sites, the more easily Lucee can be
justified for new projects.
I think having the HTTP header identify Lucee by default
(but easily turned off) as Brad Wood suggested is the
best option.
Malcolm O'Keeffe
Blue River Interactive Group
(916) 608-8608 <tel:%28916%29%20608-8608> - office
(916) 834-3370 <tel:%28916%29%20834-3370> - cell
www.blueriver.com <http://www.blueriver.com> - Website
Design and Development
www.getmura.com <http://www.getmura.com> - Open Source CMS
On Mar 26, 2015, at 1:55 PM, Gert Franz <@Gert_Franz <mailto:@Gert_Franz>> wrote:
Well was a setting in the Railo admin in the years back
for exactly this. Under output as far as I remember. We
changed the default to be off instead of on. Just check
the admin, if its still there.
Gert
Sent from somewhere on the road
Am 26.03.2015 um 21:46 schrieb Tom King
<@Tom_King <mailto:@Tom_King>>:
Yeah, I'd definitely not want this. It's like painting
an extra bullseye on your webserver. Whoever came up
with meta-tag of 'generated-by' for wordpress was also
an idiot.
On Thursday, 26 March 2015 19:48:07 UTC, Brad Wood wrote:
Lol! well, that's why it would be able to be
turned off :)
Thanks!
~Brad
*ColdBox Platform Evangelist*
/Ortus Solutions, Corp /
*
*
E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
<http://www.coldbox.org/>
Blog: http://www.codersrevolution.com
<http://www.codersrevolution.com/>
On Thu, Mar 26, 2015 at 2:41 PM, Andrew Dixon <andrew...@gmail.com> wrote:
I'm sure that is one reason why those
technologies show up more often as being used
but I can imagine the answer my sys admin will
give me now about this and it starts with
"hell" and ends with "no", but to be honest he
will probably be way more explicit than that!!!
Kind regards,
Andrew
about.me <http://about.me/andrew_dixon>
mso <http://www.mso.net/> - Lucee
<http://lucee.org/> - Member
On 26 March 2015 at 17:59, Brad Wood <bdw...@gmail.com> wrote:
Like, I mentioned in this thread
<https://groups.google.com/d/topic/lucee/0Al-xZy8WeA/discussion>,
I submitted Lucee as a new technology to
builtwith.com <http://builtwith.com/> the
other day. I've been E-mailing back and
forth with their support discussing how to
best identify a Lucee (or any CFML)
server. Common approaches are:
* File extensions (not specific to
Lucee, can be hidden with URL rewrites)
* Common session cookies (not specific
to Lucee)
* Admin URL (they're reticent to scan
for these, can also be hidden)
* Cause an error like a 404 and hope for
standard error page (they're not doing
this yet, only works if no global
error handler in place)
What's the general consensus for adding a
default HTTP header to Lucee that be
disabled by an admin that has something like:
*X-Powered-By: Lucee*
I'm well aware this sort of thing flies in
the face standard server hardening, but
it's been a very common occurrence in
technologies such as .NET or PHP and I
can't help but wonder if it's made those
technologies look "more used" just because
they're easy to identify.
Thoughts?
Thanks!
~Brad
--
You received this message because you are
subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
lucee+un...@googlegroups.com.
To post to this group, send email to
lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/4bf5ec9c-ba28-4931-a327-e6ca395c2efb%40googlegroups.com
<https://groups.google.com/d/msgid/lucee/4bf5ec9c-ba28-4931-a327-e6ca395c2efb%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are
subscribed to a topic in the Google Groups
"Lucee" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/lucee/ps2ST5N4jFU/unsubscribe.
To unsubscribe from this group and all its
topics, send an email to
lucee+un...@googlegroups.com.
To post to this group, send email to
lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG1WijWt%2B6h-%2BpHPq%2BWr%3D5%3DBW5HGb12JG34GAakOyF3MCXOb4Q%40mail.gmail.com
<https://groups.google.com/d/msgid/lucee/CAG1WijWt%2B6h-%2BpHPq%2BWr%3D5%3DBW5HGb12JG34GAakOyF3MCXOb4Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are subscribed
to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to
lucee@googlegroups.com <mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/99af2ba2-ef92-43e1-a9f5-6448b536af39%40googlegroups.com
<https://groups.google.com/d/msgid/lucee/99af2ba2-ef92-43e1-a9f5-6448b536af39%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are subscribed to
the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to
lucee@googlegroups.com <mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CC5AEA52-D13A-4011-B92E-79A4B290B120%40rasia.ch
<https://groups.google.com/d/msgid/lucee/CC5AEA52-D13A-4011-B92E-79A4B290B120%40rasia.ch?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to
the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to
lucee@googlegroups.com <mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/B6768B3C-858C-469E-9872-74FEA3FDFD2D%40blueriver.com
<https://groups.google.com/d/msgid/lucee/B6768B3C-858C-469E-9872-74FEA3FDFD2D%40blueriver.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the
Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to lucee@googlegroups.com
<mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAFrbJ5X0H3WhwetyQLe-P7O9XEGq%2BfTJT58HUAkQeC3YEOnh9g%40mail.gmail.com
<https://groups.google.com/d/msgid/lucee/CAFrbJ5X0H3WhwetyQLe-P7O9XEGq%2BfTJT58HUAkQeC3YEOnh9g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the
Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to lucee@googlegroups.com
<mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/551481ED.90503%40lucee.org
<https://groups.google.com/d/msgid/lucee/551481ED.90503%40lucee.org?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the
Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to lucee@googlegroups.com
<mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG1WijVDsxfQNjHJ6CHid_gywYcUmWQSjhC-QQPLbsy-R%2BNO_g%40mail.gmail.com
<https://groups.google.com/d/msgid/lucee/CAG1WijVDsxfQNjHJ6CHid_gywYcUmWQSjhC-QQPLbsy-R%2BNO_g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+unsubscribe@googlegroups.com
<mailto:lucee+unsubscribe@googlegroups.com>.
To post to this group, send email to lucee@googlegroups.com
<mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/551497C4.4080406%40lucee.org
<https://groups.google.com/d/msgid/lucee/551497C4.4080406%40lucee.org?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
On Fri, Mar 27, 2015 at 1:10 PM, Jochem van Dieten <@Jochem_van_Dieten> wrote:
On Fri, Mar 27, 2015 at 12:53 AM, Nando Breiter wrote:
I’m not sure how best to phrase this properly, but the gist of it is
that a determined, very skilled hacker will likely manage to penetrate any
server.
One of our clients, an ISO 27001 certified company, put in their security
policy that “attacks by nation states and terrorists, possibly assisted by
legal or physical coercion, is out of scope”. I like that phrasing.
So while this statement seems factually true, in practice, I don’t think
a disclosure identifying Lucee would matter in nearly all cases … as a
common sense perspective on the issue.
Except that after this very public discussion putting this header in
would signal to the whole world that Lucee values marketing over best
practices. I think that would more than negate any hypothetical marketing
benefits.
On Fri, Mar 27, 2015 at 1:10 PM, Jochem van Dieten joc...@gmail.com wrote:
On Fri, Mar 27, 2015 at 12:53 AM, Nando Breiter wrote:
I’m not sure how best to phrase this properly, but the gist of it is
that a determined, very skilled hacker will likely manage to penetrate any
server.
One of our clients, an ISO 27001 certified company, put in their
security policy that “attacks by nation states and terrorists, possibly
assisted by legal or physical coercion, is out of scope”. I like that
phrasing.
So while this statement seems factually true, in practice, I don’t
think a disclosure identifying Lucee would matter in nearly all cases …
as a common sense perspective on the issue.
Except that after this very public discussion putting this header in
would signal to the whole world that Lucee values marketing over best
practices. I think that would more than negate any hypothetical marketing
benefits.
