Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

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

Subject: RE: XSS, SQL injection etc - permutations of input strings
Date: Sat, 25 Sep 2004 07:46:31 +0000 (GMT)

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



<Prev in Thread] Current Thread [Next in Thread>