RE: [WEB SECURITY] Interview With Jeremiah Grossman on ClickJacking attack

[<Glenn.Everhart@xxxxxxxxx>]

This is a bit of blue sky...

In other situations where people have had difficulty ensuring a program
is doing what is intended, one solution has been to put assertions into the
code which express (differently) what was intended.

Perhaps it would be helpful were there to be assertions in some form added to
html which could express intent around environment or function. Such expressions
would need to be useful and clear, and be possible to get machines to follow.

As a very crude example, suppose a page had assertions that said in effect "No links
from this page should go to another machine". A browser that enforced that assertion
might then refuse to follow any such that got injected. (Yes, such things would make tracking
operations fail sometimes; so what?)

This kind of thing would I presume not ever be used everywhere, but might make some
sites safer and make it easier to close holes caused by the excessive cleverness and
inventiveness of attacks.

End blue sky...

Glenn Everhart


-----Original Message-----
From: Matthew Chalmers [mailto:matthew.chalmers@xxxxxxxxx]
Sent: Thursday, October 16, 2008 8:11 PM
To: websecurity@xxxxxxxxxxxxx
Subject: Fwd: [WEB SECURITY] Interview With Jeremiah Grossman on
ClickJacking attack


There is a lot of good discussion on this topic but I want to
interject a small, possibly devil's advocate, point: It's not all the
browsers' fault. The protocols and languages/technologies share some
blame, as well as implementors of these tools on web sites/apps, and
even end users. It's a complicated situation, and neither a quick fix
like turning off Javascript nor a back-to-the-drawingboard stance on
any ONE piece of the puzzle will solve all the problems. In short the
various pieces have been mostly designed to give users what they
(think they) want: features/functionality. HTTP and later protos/techs
are loosey goosey in order to provide a relatively stateless,
resource-friendly client/server model that does what the developer
tells it, and the browser does what the user asks of it: namely to
fetch a foreign resource and display/execute what was requested.
Everyone here knows this. The browser does what the user asks.
Sometimes the user, however, and unfortunately, doesn't realise what
he or she is asking, or plainly asks for trouble (by visiting unknown
or questionable sites/links). Sometimes the "other user" in the
picture, the developer--the user of the technological tools for
building sites/apps--also doesn't realise what he or she is "asking"
in the sense that not every potential threat or vulnerability is
realised in design and build and test. So we have legitimate sites
that have questionable code...when used in the way they were
*intended* by end users, everything is typically fine...when exploited
by the unscrupulous, everything may not be fine. Because the browser,
as the user's agent, does what the user asks, and/or because the web
site/app, as the developer's agent, does what the developer asked it
to do, and because neither of them--nor perhaps the
designers/implementers of the tools in use (browsers, protocols, etc.
all inclusive)--considered all the possible threats and
vulnerabilities, we "in the know" who do consider these things see
risks and/or exploits. It is not up to any one party to fix their
piece and make everything better. Each party must do their best at
threat modelling up front and patching when something comes up they
didn't consider, and each of these things will inevitably take into
account a usability vs. security trade-off, or a risk management
situation. Which is basically what's happening, but, as has been
pointed out, usability and "hoping for the best" does seem to be
winning out.

Matt

On Thu, Oct 16, 2008 at 4:19 PM, Bil Corry <bil@xxxxxxxxx> wrote:
> Arshan Dabirsiaghi wrote on 10/16/2008 3:00 PM:
>> It took 5 years to get HTTPOnly everywhere, true. At that rate, we'll
>>  never get anywhere, but I hope that HTTPOnly is the embarassing
>> example that inspires better behavior.
>
> And even still, HTTPOnly isn't implemented the same across the major browsers (and none prevent reading the cookie via XHR):
>
>        http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly
>
>
>> As per Bil's solution for clickjacking, it would obviously work but
>> it would be a non-starter. What users would tolerate a random UI
>> layout? A 5-second risk analysis says its probably not worth it.
>
> My example site uses the random URL token idea, which is very doable.  I didn't implement the random UI idea for the same reason you're pointing out, users won't go for it.  You might be able to have a confirmation dialog box pop up in a limited random area, but beyond that, it'd be annoying.  Especially for web apps used for repetitive tasks where the user expects the UI to remain constant; a random UI would quickly become a barrier to efficiency for them.
>
>
> - Bil
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

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



-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

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