RE: XSS, SQL injection etc - permutations of input strings

[Keith Roberts <keith () kar eclipse co uk>]

Hi Chris.

Seems like a sensible way to handle to situation, by
educating the bosses, then letting them take the initiative!

Keith


On Tue, 21 Sep 2004, Conacher, Chris wrote:

> To: Mike Andrews <mike () se fit edu>, webappsec () securityfocus com
> From: "Conacher, Chris" <Chris.Conacher () negt com>
> Subject: RE: XSS, SQL injection etc - permutations of input strings
>
> Mike
>
> I worked on a project with a very large software company training their internal (not product) developers and 
> application testers on application security testing and development.
>
> That company overcame the problem of what needed to be demonstrated before it would be fixed by educating senior 
> decision makers as to the potential implications of xss, sql injection, buffer overflows, etc.
>
> These people in turn decided that it was not acceptable for applications to be deployed in the environment that had 
> any potential for certain vulnerabilities. Other vulnerabilities were assessed on the basis of available time, 
> resource implications, etc for fixing and were rated as to priority or the level of exploitation that needed to be 
> demonstrated. Note that buffer overflows did not need to be shown to be exploitable as it was considered that no 
> developer working there should be allowing buffer overflows in any situation.
>
> This was then published as a company policy with great effect.
>
> For example, all a tester had to show was that it was possible to bypass an input validation designed to prevent sql 
> injection by entering a tick a returning an error and the application was kicked back to the developers for them to 
> fix.
>
> This removed any ability of the developers to argue as to the 'real impact' of a particular vulnerability and saved 
> so much time in the to-ing and fro-ing between testers and developers.
>
> The business basically understood that just because a tester is not able to demonstrate serious potential for a 
> vulnerability does not mean that there are not people out there with more ability and time who could and made a 
> decision.
>
> It removed the ability of the developers and testers to affect the decision making process and became a business 
> decision as what was acceptable to that business.
>
> Chris
>
> Chris Conacher
> Security Analyst
>
> Ext:    34508
> Tel:    +1.503.833.4508
> Email:  chris.conacher () negt com