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

Jim Manico jim.manico at owasp.org
Fri Aug 29 06:28:37 UTC 2014


Would that be considered to be an illegal action? It's kind of an 
unauthorized security test and I do not think that is legal. You know 
Rogan, it's a pretty bold move to put HTML in a banking transaction form 
description.

Aloha,
Jim


On 8/28/14, 8:12 PM, Rogan Dawes wrote:
>
> One of my favourite illustrations of this is a true story from a 
> banking client:
>
> A customer went into a branch and made a deposit into his account. As 
> the transaction reference he used:
>
> <b>test</b>
>
> 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.
>
> Rogan
>
> On 29 Aug 2014 03:38, "Jim Manico" <jim.manico at owasp.org 
> <mailto: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 $%^&. :)
> >
> > *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
> >>>
> >>
> >
> >
> > _______________________________________________
> > 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/704d7658/attachment.html>


More information about the OWASP-Leaders mailing list