[Owasp-leaders] [Owasp-community] Research: Static Detection of Second-Order Vulnerabilities in Web Applications

Jim Manico jim.manico at owasp.org
Fri Aug 29 01:38:15 UTC 2014


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 $%^&. :)

*ducks*

Aloha,
Jim



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 
> <mailto: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.
>
>     FWIW,
>     Jim
>
>
>
>
>
>
>     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 & distribute.
>>
>>     https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-dahse.pdf
>>
>>     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!
>>
>>     Regards,
>>
>>     Fabio
>>
>>
>>
>>     _______________________________________________
>>     Owasp-community mailing list
>>     Owasp-community at lists.owasp.org  <mailto:Owasp-community at lists.owasp.org>
>>     https://lists.owasp.org/mailman/listinfo/owasp-community
>
>
>     _______________________________________________
>     OWASP-Leaders mailing list
>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140828/707f18e9/attachment.html>


More information about the OWASP-Leaders mailing list