[WEB SECURITY] Secure Web UI Design

White, Dain dainw at uidaho.edu
Tue Feb 5 11:28:08 EST 2013


"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 at lists.webappsec.org] On
Behalf Of Stephen de Vries
Sent: Tuesday, February 05, 2013 3:51 AM
To: websecurity at lists.webappsec.org
Subject: Re: [WEB SECURITY] Secure Web UI Design


Hi Pete,

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

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

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. 

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

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 at lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.
org



More information about the websecurity mailing list