Hola Brian,
My mates and I released a proxy at BH Amsterdam that did
all this for you automatically. 256 bit AES, stored flags for
various bits in the HTTP resp, removed and stored things like
cookies for you (which is how it worked transparently), and
could be 1) URL param, 2) URI resource, 3) replace URI (most
secure...and fun, 4) legacy URL/param support.
Would you be willing to summarize what kind of attacks your proxy can
prevent, and what kind it cannot? Or perhaps point us to a more
detailed description of what it does?
Please see the trailing paragraph of the original post. We have
kind of gone back to the drawing board after the baffling response
at Black Hat Amsterdam/06 for what we/I was sure would be a big hit.
Obviously I am missing something either technically or simply
communication abilities; either way, until we figure out what
it is that went wrong our project is shelved.
I would promise a paper on this but I am about four papers
behind at the moment, two of which are still papervapour.
I am wondering if some of the "problems" we "solved" are still
problems people don't take seriously, so we may have jumped
the a prior gun. Backing up, we are going to release papers
focused on the attacks and tools to facilitate them, since
many commercial tools still can't detect or block basic script
injection with moderate encoding applied.
-ae
-------------------------------------------------------------------------
Sponsored by: Watchfire
Methodologies & Tools for Web Application Security Assessment
With the rapid rise in the number and types of security threats, web
application security assessments should be considered a crucial phase in
the development of any web application. What methodology should be
followed? What tools can accelerate the assessment process?
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h
--------------------------------------------------------------------------
