Hi,

On 5 Feb 2013, at 07:52, Bolger, Ken wrote:

Exactly.  Real security is implemented on the server side and doesn't depend on the options presented in the UI.  If that security control fails then you have a serious security vulnerability, whether or not the options are presented to the user.  Not presenting the options adds a layer of "security through obscurity" which is no security at all, so no real point implementing it.

This depends on how the unauthorised actions are presented in the UI.  They should not be selectable in the UI, e.g. Buttons should be disabled, which would mean that an attacker would have to deliberately modify the HTML or intercept and modify the request in order to provoke the action.
In my opinion, having UI elements that are selectable, but then deny access to the function is just bad UI design.

regards,
Stephen

Hi,

On 2/5/2013 9:02 AM, Stephen de Vries wrote:

It's a great discussion because web apps are complicated beasts to
fence in. So I always like to see how people are dealing with it on a
whole. But I don't think generalized statements like the one about
security through obscurity can help. Research has shown time and again
that obscurity can control certain types of interactions where
operations require them to be there but not be so obvious. This is
true in web apps, services, wifi, street safety, and war. It can't
control all interactions so as to create security, but no single
control can do that. In attack surface measurements, obscurity as a
poor form of authentication is right up there with user-generated
passwords as a poor form of authentication. Neither holds up under a
microscope. So I wonder why obscurity gets such a bad rep when here I
thought most like a good masquerade party. ;)  Either that or the
whole make a login/password ensemble is sleeping with the right folks
to get left alone :)

My informed opinion shows that a little privacy can go a long way and
while server-side security is best, it doesn't hurt for your server to
keep its rejections to itself and bottle it up inside to its own logs
like people aren't supposed to. But we're not really worried about the
servers mental health here... at least not until Skynet goes self
aware. tick tock tick tock

-pete.

--
Pete Herzog - Managing Director - pete@isecom.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org

Hi Pete,

On 5 Feb 2013, at 10:34, Pete Herzog wrote:

Yes the role of obscurity in security is an interesting discussion to have[*], but coming back to Ken's original question as to whether hiding unauthorised actions provides a measurable and worthwhile form of security I stand by my original view that the security benefit is so negligible as to be practically non-existent.

Rather than focus limited security resources on hiding actions, I would focus them on testing and verifying that the server side controls are properly implemented.  In fact, in the right testing environment, by displaying the disabled links/buttons/widgets to the user, access control tests can more easily be performed by QA testers or automated testing scripts.

Mmmm, I'd take the opposite view :)
Having an application announce attempted security violations provides a deterrent to attackers, particularly to legitimate users who attempt to escalate their level of privilege.  Include the source IP address in the violation message and there's a good chance you'll scare the bejesus out of a lot of opportunistic attackers.

[*] You could argue that not only does obscurity aid security, but in fact it forms the basis for confidentiality and crypto.  What is a secret, if not a sufficiently obscure piece of data?  So we end up talking about degrees of obscurity, and in the context of the original question, I don't believe that the degree of obscurity provided by not displaying web actions provides a sufficient amount of security as to be worthwhile.

cheers,
Stephen

"Having an application announce attempted security violations provides a
deterrent to attackers, particularly to legitimate users who attempt to
escalate their level of privilege.  Include the source IP address in the
violation message and there's a good chance you'll scare the bejesus out
of a lot of opportunistic attackers."

I think it's good to do this, however, I think it's better to be as
generic as possible in the announcement - so the announcement itself
doesn't contribute to the attack. In other words, saying 'there has been
a problem with this login' is better than saying 'Hello Admin, your
password is incorrect'. Even better (in my humble opinion) is saying
something like 'A problem has been encountered, and administrators have
been notified.'

I've tried outputting the IP address, and in my experience it doesn't do
much. For the script kiddie who is already surfing through 'seven
proxies', all it does is show them their IP is successfully being
hidden, for the casual user it's just arcane. I will allow that there is
a thin slice of folks it will freak out. It might be better simply to
say 'your IP address has been logged' (again, in my humble opinion).

Dain White

-----Original Message-----
From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On
Behalf Of Stephen de Vries
Sent: Tuesday, February 05, 2013 3:51 AM
To: websecurity@lists.webappsec.org
Subject: Re: [WEB SECURITY] Secure Web UI Design

Hi Pete,

On 5 Feb 2013, at 10:34, Pete Herzog wrote:

through obscurity can help. Research has shown time and again that
obscurity can control certain types of interactions where operations
require them to be there but not be so obvious. This is true in web
apps, services, wifi, street safety, and war.

Yes the role of obscurity in security is an interesting discussion to
have[*], but coming back to Ken's original question as to whether hiding
unauthorised actions provides a measurable and worthwhile form of
security I stand by my original view that the security benefit is so
negligible as to be practically non-existent.

Rather than focus limited security resources on hiding actions, I would
focus them on testing and verifying that the server side controls are
properly implemented.  In fact, in the right testing environment, by
displaying the disabled links/buttons/widgets to the user, access
control tests can more easily be performed by QA testers or automated
testing scripts.

while server-side security is best, it doesn't hurt for your server to
keep its rejections to itself and bottle it up inside to its own logs
like people aren't supposed to.

Mmmm, I'd take the opposite view :)
Having an application announce attempted security violations provides a
deterrent to attackers, particularly to legitimate users who attempt to
escalate their level of privilege.  Include the source IP address in the
violation message and there's a good chance you'll scare the bejesus out
of a lot of opportunistic attackers.

[*] You could argue that not only does obscurity aid security, but in
fact it forms the basis for confidentiality and crypto.  What is a
secret, if not a sufficiently obscure piece of data?  So we end up
talking about degrees of obscurity, and in the context of the original
question, I don't believe that the degree of obscurity provided by not
displaying web actions provides a sufficient amount of security as to be
worthwhile.

cheers,
Stephen

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.
org

Thanks all for the feedback, greatly appreciated.

I guess the bottom line for me is that if the UI presented all the options but
disabled the buttons for which a user wasn't authorised I would be more comfortable
with the UI design. If the server then received a request for an un-authorised
action then we could assume some form of attack was being tried.

This approach separates a user who simply selects the button by mistake or is
a little inquisitive from someone who has obviously bypassed the UI to try
a little forced browsing.

Ken