[Owasp-bayarea] REMINDER: OWASP Meetup: Thursday, May 6, 5:30pm @ Google

Brian Bertacini brian at appsecconsulting.com
Tue May 4 01:50:16 EDT 2010

The next OWASP meet up is scheduled for Thursday, May 6, 2010, 5:30pm to
9:00pm at Google in Mt. View.  This event is a great opportunity to keep up
with the happenings in the Web Application Security industry and network
with industry professionals.  As always, this event is open to the public
and free to attend.   Food and beverages will be provided complements of



Thursday, May 6, 2010

5:30 - 9:00pm   




Maxwell Tech Talk

Building 1300 Crittenden (CL3), 1st Fl

1300 Crittenden Lane

Mountain View, CA 94043

tm_campaign=invite> http://may2010owaspmeetup.eventbrite.com  (space is
filling up, please register ASAP)


Updated Schedule of Events:
5:30 - 6:30pm   Check-In
6:00 - 6:45pm   Building Secure Facebook Applications, Justine Osborne, iSEC

6:45 - 7:30pm   Website Security Statistics, Jeremiah Grossman, CTO,
WhiteHat Security
7:30 - 8:15pm   How Mashups Impact Traditional Web Application Trust Models 

                                Jasvir Narga, Software Engineer at Google

                                Mike Samuel, Software Engineer at Google

8:15 - 9:00pm    Networking session


 Securing Facebook Applications


Presentation Abstract: The amount of Facebook applications are growing
rapidly on the web, as well as mobile and desktop platforms.  In order to
ensure security is not an afterthought, Facebook application developers and
security auditors need to understand the particular security implications of
a Facebook application vs. a traditional application. These applications
make use of the Facebook API to integrate tightly with the social network
experience. When a user authorizes a Facebook application, they are
providing the application access to their Facebook account. Therefore, these
applications must be as resilient as possible against attacks which abuse
this trust agreement. Attacks such as FBML injection and Facebook parameter
tampering can be used to compromise the Facebook user data and account
access that the user has granted an application. Traditional attacks are
also possible, and exploits can be tailored to take advantage of integration
with the Facebook platform. This talk accompanies the first whitepaper on
this subject, and will inform the audience about the security
vulnerabilities, exploitation techniques, and protection mechanisms specific
to Facebook applications. 


Speaker Bio: Justine Osborne is a Security Consultant for iSEC Partners, an
information security organization. At iSEC, Justine specializes in
application security, focusing on web application penetration testing, code
review, and secure coding guidelines. She also performs independent security
research, and has presented at security conferences such as Blackhat, Defcon
and DeepSec. Her research interests include emerging web application
technologies, dynamic vulnerability assessment tools, Rich Internet
Applications (RIA), and mobile device security.


Website Security Statistics - "Which Web programming languages are most
Jeremiah Grossman, CTO, WhiteHat Security

Presentation Abstract: The question frequently asked by security
professionals and website developers alike: "What is the most secure
programming language or development framework available?"

Conventional wisdom suggests that most popular modern languages / frameworks
(commercial & open source) perform relatively similarly when it comes to an
overall website security posture. Suggesting PHP, Java, C# and others are
any more secure than other frameworks is sure to spark heated debate.

Until now, no website security report has provided empirical research
measuring how various Web programming languages / frameworks actively
perform in the field. Register to attend our next complimentary webinar, in
which Jeremiah Grossman, WhiteHat Security founder and CTO explores our
latest website security statistics report to answer:

. Which classes of attack are most prone to exploit which programming
languages? How often and for how long?
. How do they fare against popular alternatives?
. Is it really true that popular modern languages / frameworks yield similar
results in production security?

How Mashups Impact Traditional Web Application Trust Models 
Jasvir Narga, Software Engineer at Google Inc. 
Mike Samuel, Software Engineer at Google Inc.

Presentation Abstract: The same-origin policy has governed interaction
between client-side code and user data since Netscape 2.0, but new
development techniques are rendering it obsolete.  Traditionally, a website
consisted of server-side code written by trusted, in-house developers ; and
a minimum of client-side code written by the same in-house devs.  The
same-origin policy worked because it didn't matter whether code ran
server-side or client-side ; the user was interacting with code produced by
the same organization.  But today, complex applications are being written
almost entirely in client-side code requiring developers to specialize and
share code across organizational boundaries.  Server-side developers are
discriminating about which code they run, but the third party plug-in model
adopted by social networking sites and interactive advertisements combines
code from unknown sources so the user's decision to trust site X with their
data is no longer an informed choice -- they are actually interacting with
code of unknown and unknowable provenance.  This has led to a variety of
novel attacks, and as this model is applied to data with greater economic
value, attacks will increase.
The underlying reason for the existence of these novel attacks is that when
a website incorporates third party code, whether by loading a library,
framing someone else's content or redisplaying content that it fetched from
elsewhere; the embedded code gains most or all of the authority of the
embedder.  The same-origin policy does not allow a website to limit the
authority it has from being relayed to code it incorporates.  As a result,
the author of the website is reduced to a binary decision - either he trusts
the third party content completely and is willing to be completely
vulnerable to it, or he does not trust it and as a result chooses not to
include their content at all.  In practice, the trust a website author has
in any given third party content falls somewhere between these two extremes.
But under the same-origin model, an app in another domain has a lot of
ambiently available authority. 


Generally available authority

Domain specific authority

Redirect any reachable frame (reachability does not limit authority in

Modify and read cookies

Initiate a file download of executable content

Modify and inspect the entire user-interface

Create a window (modulo user interaction)

GET or POST to the same origin and observe the result

Sniff local network

Intercept key strokes and mouse clicks

Sniff user history

Modify global definitions including language fundamentals

GET or POST to an domain with current cookies (but not observe response

Interact efficiently with public APIs

Load code from any source

Read and modify form data before, after, or during form submission

Impersonate a website

Create inputs that might auto-fill based on previous user interactions with
same origin

Present file upload controls

Impersonate events from the user.

Deny service


Programming-language based security provides one mechanism for the author of
a site to express the limits of his trust in a third party library by
selectively granting to the third party code a subset of the authority it
holds.  Program analysis of a block of code is sufficient to give a
conservative analysis of the extent of the authority the block can wield.
In other words, before loading a third party library, a program can analyze
it to determine the upper bound on the damage it can carry out and based on
this analysis, choose whether to load the library or not.  Using a
combination of dynamic guards and aggressive static analysis, a programming
language based security model can go further and give a container the
ability to attenuate the authority it grants to programs it loads.  The
extent to which rewriting, language sub-setting, and static analysis is used
distinguishes the four most popular alternative security policies for the

ADSafe, FBJS, Caja and WebSandbox are examples of this style of programming
language based attenuation of authority.  ADSafe is a statically verifiable
subset of JavaScript which removes from the language features which allow a
program to reach outside the public APIs exposed by a container.  It lets
developers write applications, and lets a container bound the authority
available to those applications, but it is such a severe subset that
developers will have to throw away most of what they know.  FBJS uses a
variety of namespace separation techniques and virtualizes the DOM so that
the container can interpose a fake DOM and fake network that mimic a small
portion of the real versions ; this lets developers use familiar tools and
APIs while bounding what they can do.  Caja takes this scheme further and
repairs a number of defects in the illusion of the virtual DOM; and extends
it to allow multiple untrusted modules to interact while preserving mutual
suspicion.  WebSandbox uses a different virtualization technique to allow
for a wide range of configurable policies by virtualizing every object with
which embedded code interacts, but does not attempt to address mutual
suspicion.  Authors of each of these schemes have met under the aegis of the
ECMA standards body to develop a proposal for a JavaScript variant that is a
good foundation for secure and robust computation.  The recently
standardized EcmaScript 5 includes some early work such as freezable
objects, better message interception, encapsulated scopes, and the next
version might include robust support for membraning and secure modular
This talk will explain how the same-origin policy is breaking down, give
examples of attacks, discuss the properties that any alternative must have,
introduce a number of alternative models being examined by the Secure
EcmaScript committee and other standards bodies, demonstrate how they do or
don't thwart these attacks, and discuss how secure interactive documents
could open up new markets for web developers.  We assume a basic familiarity
with web application protocols : HTTP, HTML, JavaScript, CSS ; and common
classes of attacks : XSS, XSRF, Phishing.



I look forward to seeing you at the event,



Brian Bertacini

OWASP Bay Area

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-bayarea/attachments/20100503/9513aef4/attachment-0001.html 

More information about the Owasp-bayarea mailing list