<p>At least he didn't try the "Little Bobby Tables" approach (<a href="http://xkcd.com/327">http://xkcd.com/327</a> :-)</p>
<p>-kevin<br>
Sent from my Droid; please excuse typos.</p>
<div class="gmail_quote">On Aug 29, 2014 2:33 AM, "Jim Manico" <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    Aloha,<br>
    Jim<br>
    <br>
    <br>
    <div>On 8/28/14, 8:12 PM, Rogan Dawes wrote:<br>
    </div>
    <blockquote type="cite">
      <p dir="ltr">One of my favourite illustrations of this is a true
        story from a banking client:</p>
      <p dir="ltr">A customer went into a branch and made a deposit into
        his account. As the transaction reference he used:</p>
      <p dir="ltr"><b>test</b></p>
      <p dir="ltr">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.</p>
      <p dir="ltr">Who is at fault here? The banking app merely trusted
        the mainframe <- the point of the story.</p>
      <p dir="ltr">Rogan<br>
      </p>
      <p dir="ltr">On 29 Aug 2014 03:38, "Jim Manico" <<a href="mailto:jim.manico@owasp.org" target="_blank">jim.manico@owasp.org</a>>
        wrote:<br>
        ><br>
        > Thanks kindly, Tom.<br>
        ><br>
        ><br>
        > > What about legacy code where the cost & risk to
        fix & test is high?<br>
        ><br>
        > 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.<br>
        ><br>
        > 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.<br>
        ><br>
        > 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 $%^&. :)<br>
        ><br>
        > *ducks*<br>
        ><br>
        > Aloha,<br>
        > Jim<br>
        ><br>
        ><br>
        ><br>
        ><br>
        > On 8/28/14, 6:31 PM, Tom Conner wrote:<br>
        >><br>
        >> Jim, wow, I love that idea, at least for a greenfield
        application... much less time wasted on proving or disproving
        "taint"<br>
        >> 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?<br>
        >><br>
        >> Tom Conner<br>
        >><br>
        >><br>
        >> On Thu, Aug 28, 2014 at 8:58 PM, Jim Manico <<a href="mailto:jim.manico@owasp.org" target="_blank">jim.manico@owasp.org</a>>
        wrote:<br>
        >>><br>
        >>> 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.<br>
        >>><br>
        >>> 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. <br>
        >>><br>
        >>> 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.<br>
        >>><br>
        >>> FWIW,<br>
        >>> Jim<br>
        >>><br>
        >>><br>
        >>><br>
        >>><br>
        >>><br>
        >>><br>
        >>> On 8/26/14, 6:39 AM, Fabio Cerullo wrote:<br>
        >>>><br>
        >>>> 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.<br>
        >>>><br>
        >>>> <a href="https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-dahse.pdf" target="_blank">https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-dahse.pdf</a><br>
        >>>><br>
        >>>> 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!<br>
        >>>><br>
        >>>> Regards,<br>
        >>>><br>
        >>>> Fabio<br>
        >>>><br>
        >>>><br>
        >>>><br>
        >>>> _______________________________________________<br>
        >>>> Owasp-community mailing list<br>
        >>>> <a href="mailto:Owasp-community@lists.owasp.org" target="_blank">Owasp-community@lists.owasp.org</a><br>
        >>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-community" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-community</a><br>
        >>><br>
        >>><br>
        >>><br>
        >>> _______________________________________________<br>
        >>> OWASP-Leaders mailing list<br>
        >>> <a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>
        >>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
        >>><br>
        >><br>
        ><br>
        ><br>
        > _______________________________________________<br>
        > OWASP-Leaders mailing list<br>
        > <a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>
        > <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
        ><br>
      </p>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div>