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

Arturo 'Buanzo' Busleiman buanzo at buanzo.com.ar
Fri Oct 3 19:36:59 UTC 2014


The legality is not at question here..The fact that it is attackable is.
 On Aug 29, 2014 2:31 AM, "Jim Manico" <jim.manico at owasp.org> wrote:

>  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> 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>
> 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
> >>>> https://lists.owasp.org/mailman/listinfo/owasp-community
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> OWASP-Leaders mailing list
> >>> OWASP-Leaders at lists.owasp.org
> >>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >>>
> >>
> >
> >
> > _______________________________________________
> > OWASP-Leaders mailing list
> > OWASP-Leaders at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >
>
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> 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/20141003/43253272/attachment-0001.html>


More information about the OWASP-Leaders mailing list