<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">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">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">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">Owasp-community@lists.owasp.org</a><br>
>>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-community">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">OWASP-Leaders@lists.owasp.org</a><br>
>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">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">OWASP-Leaders@lists.owasp.org</a><br>
> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
><br>
</p>