[Owasp-leaders] [Owasp-community] Research: Static Detection of Second-Order Vulnerabilities in Web Applications
rogan at dawes.za.net
Fri Aug 29 03:12:25 UTC 2014
One of my favourite illustrations of this is a true story from a banking
A customer went into a branch and made a deposit into his account. As the
transaction reference he used:
The teller dutifully captured this, not knowing any better, and the
mainframe accepted it, because there was nothing wrong with it from its
perspective. However, when the customer logged in to internet banking, the
reference showed up in bold.
Who is at fault here? The banking app merely trusted the mainframe <- the
point of the story.
On 29 Aug 2014 03:38, "Jim Manico" <jim.manico at owasp.org> wrote:
> Thanks kindly, Tom.
> > What about legacy code where the cost & risk to fix & test is high?
> If depends on the "risk profile" of the application and your tolerance to
compromise. If you don't mind those applications getting hacked then deal
with them down the road. But keep in mind that most risk management and
risk analysis math are complete and utter BS in our industry compared to
more formal risk mathematics that we see in finance and other "risky"
industries like oil and gas. Bottom line for me is that fixing insecure
applications is the cost of doing business and if done right will be a one
time cost as security culture changes worldwide. But the bottom line is,
fix your $%^& if you do not want to get compromised, I state with respect.
> Admittedly, this is NOT an simple issue and it's easy for me to take this
position when I do not have 10,000 applications in my inventory like some
of my clients do.
> I tend to stay out of the risk game and focus on the technology of secure
app development. I tend to state, do you want this application hacked? No?
Then fix your $%^&. :)
> On 8/28/14, 6:31 PM, Tom Conner wrote:
>> Jim, wow, I love that idea, at least for a greenfield
application... much less time wasted on proving or disproving "taint"
>> What about legacy code where the cost & risk to fix & test is high? Can
I sell the big project to retrofit and retest old code? Tough sell. I
suppose might be able to sell a policy of adding perfect injection
resistance into whatever modules are modified... Intuitively it feels like
that policy would pay for itself over time. Is there any data to support
such an idea?
>> Tom Conner
>> On Thu, Aug 28, 2014 at 8:58 PM, Jim Manico <jim.manico at owasp.org> wrote:
>>> Interesting paper. This all stems from developers treating some
"internal" or "partner" data as trusted. This has got to stop. The idea of
"untrusted" vs "trusted" data only confuses the developer.
>>> For complete XSS resistance and other forms of injection resistance, I
feel we need to code using a concept I call "perfect injection resistance".
This concept basically states that all variables are to be treated as
untrusted, and protection is required of all variables at the time of
usage. For example a "perfect injection resistance" UI would output
encoding all variables, would only use safe sinks and safe JSON processing,
and would use CSP - regardless of how those variables were populated.
Again, the key is that ALL variables would require encoding, even static
strings. Also, for any variable that contains HTML, HTML sanitization would
need to also be done at the time of UI rendering, not just on input.
>>> The goal is to build UI's that have no knowledge of what is happening
upstream, and protections are successfully in place even if everything
changes in different layers. This same concept can apply to pretty much any
form of injection.
>>> On 8/26/14, 6:39 AM, Fabio Cerullo wrote:
>>>> Interesting research paper on the so called second order
vulnerabilities in Web Applications. This paper is included in the
Proceedings of the 23rd USENIX Security Symposium and is free to download &
>>>> Congrats to Thorsten Holz @thorstenholz and Johannes Dahse
@FluxReiners from Ruhr-University Bochum, authors of this paper, who were
just awarded @facebook’s inaugural Internet Defense Prize at #sec14!
>>>> Owasp-community mailing list
>>>> Owasp-community at lists.owasp.org
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders