[WEB SECURITY] Announcing the Web Application Security Roadmap v0.9. Modest proposal...

Glenn.Everhart at chase.com Glenn.Everhart at chase.com
Mon Apr 28 13:21:02 EDT 2008

Perhaps when speaking of web app security, an already enormous area, it is
not so useful to enlarge it still more, but "fools rush in..."..

One way to look at web code (and many other kinds) is that we are sending
strings to an interpreter and it does things. What makes security hard is
that the underlying interpreter doesn't give us much (any?) help in figuring 
out what the set of functions/operations done are, so if we get some string
together we are going to pass, which we want to do some set of things, and if
it does some different set because it is an attacker, we don't have any easy way
to find out or do anything.

(This is easier to see with SQL or other languages where the string passing tends
to be easier to identify.)

Suppose the interpreter were made to count how many times major functions ran -
stuff from its parse tree - and make some kind of hash or structure that encapsulated
these counts (or even the functions only, counting just "done" or "not done"), and
returned that the first time it was run, and gave a way to rerun the call a second
time if this count were what was wanted? 

You'd need a way to train your app in what was wanted, or otherwise somehow figure
out these hashes or structures without editing every time, and you'd need a way to
get the underlying interpreter to check what was passed to it, compare the "legality"
functions, and execute finally what was legal. (This can be viewed as an access control
system if you like.) 

But might such a system not give a way to keep web apps (or others) from doing unexpected

The next question might be: could a web page be constructed so that this kind of thing
might be done, altering only logic at the server?

If it can be, then, would it not make sense to think about building a server or servers
with such properties available, so that one could write a web site that would tend only
to behave in predictable ways?

Or would such a thing so constrain what could be done that it is useless?

It seems to me that the numerous attacks are such that removing them one at a time is
a bit like using a hammer to wipe out a roach infestation, and some more generic
approaches should be asked about. But what about it? Does anyone have some suggestions
that might be generic and might be possible to implement a site at a time?

Glenn C. Everhart
302 282 3122

-----Original Message-----
From: feedyourhead at gmail.com [mailto:feedyourhead at gmail.com]On Behalf Of
Joe White
Sent: Sunday, April 27, 2008 9:32 PM
To: WASC Forum
Subject: [WEB SECURITY] Announcing the Web Application Security Roadmap

Announcing the Web Application Security Roadmap v0.9

This presentation is v0.9 because I would like a little extra slack to
incorporate the comments I am likely to receive after posting to this
list.  =)

Seriously, I have actually put quite a bit of work into this
presentation and I am being serious when I say that I welcome and
actively encourage your thoughts, comments and feedback.  Some of you
on this list have already quietly offered your feedback in private
conversation and for this I am very grateful.  You know who you are so
let's just leave it at that.  That said, I think the presentation is
now ready for a larger audience.

As a bit of background, the driver for this presentation was a
realization that the information security landscape is quickly
changing. Traditional operations focused security teams are sometimes
unable to keep up with the faster paced evolution of web application
focused threats.  Often, it seems, traditional network/systems focused
information security professionals are resistant to realize that their
current defenses are inadequate to defend against a world freely
exchanging web application traffic all around them.

I also found that in communicating with my peers, many of them found
themselves accountable for all the web application exposure in their
respective organizations.  Without a publicly available resource or
baseline of a roadmap to assist with this challenge, their effort
offered no assurance of success.

There is a lot of information in this presentation and some have
suggested that it may have been better to break the presentation into
multiple smaller presentations or even limit the information to a
white paper.

For the record, I am working on a complementary whitepaper as well but
my intention all along was to offer a foundation for a presentation
that could be used by other security professionals and shared
internally within other organizations to better communicate the work
required to secure an existing web application infrastructure.
Offering the information in only a white paper would not have best
served the target audience for this presentation, namely security
professionals who are wrestling with the scope and breadth of
accepting ownership of their organizations web application risk

At one level, this presentation aims to offer a current 'state of the
nation' in terms of the current information security threat
environment and on another level, I am hoping to call attention to the
vast divide that is likely to exist between traditional
operations/systems focused information security teams and those more
aware of the web application specific changes in today's overall
threat environment.  I think it is fair to say that in today's
information security threat environment, having some extra letters
after your name or title is not going to offer you any sizable degree
of assurance that you will be better able to successfully adapt to the
current web application security risks.

At the end of the day, the key point I am trying to make in this
presentation is that if you are accountable for the overall web
application security risks in your organization, you need to be
*proactively* managing expectations of the additional work that
will/may be required to secure your web application infrastructure.

Furthermore, you need to be focusing your attention on building a
*foundation* for your success in securing your web applications.
Otherwise, you are likely to find yourself sidetracked on any number
of side projects that will ultimately distract you form your ultimate
goal of addressing the overall web application risk exposure for your

In reality, the security related Capital Expenditures (CapEx) for your
organization to date may ultimately turn out to seem misguided as you
wrestle with securing your web applications.  In the end, you will
need to have a solid understanding of the steps required to secure
your web applications so you can better manage the expectations of
your senior executives in terms of any additional CapEx requirements
you may hrequire to secure your organization's web application

Finally, I am also hoping to call attention to the one area that many
(if not all) of the web application companies are missing, a formal
Web Application Security Incident Response Plan.  It is all but
guaranteed that if you look under the covers at your current Incident
Response Plans, you will find that they served you well in terms of a
'checkbox' solution for compliance and other regulatory concerns but I
would venture to speculate that your existing Incident Response Plans
fall short in the area of Web Application specific events.  My point
in the presentation is that you are best served in getting your arms
around this beast sooner rather than later. You cannot afford to be
blindsided by a Web Application Security event while you are spending
your time managing expectations and building trust among the senior
executives within your organization.

The current Web Application Security Roadmap presentation is available
here in both ppt and pdf formats:


As mentioned earlier, I am actively working on a complementary
whitepaper to this presentation that captures some of the narrative
likely to be included during an actual showing of the presentation and
once this becomes available, you will likely find it posted somewhere
at webappsecroadmap.com.

We may ultimately 'agree to disagree' on some of the points I make in
the presentation, but with any luck it will still offer the intended
foundation so that others can build upon it and adapt/customize it to
fit their needs

Finally, in return for publicly offering this presentation to the
list, I ask that any improvements and/or refinements to the
presentation also be posted to the list so that everyone can benefit
as well.

I hope this helps.



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

Have a question? Search The Web Security Mailing List Archives: 

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

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: 

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

More information about the websecurity mailing list