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. |

| 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
| Previous by Date: | Re: Securing file access, PD9 Software |
|---|---|
| Next by Date: | RE: XSS, SQL injection etc - permutations of input strings, Michael Silk |
| Previous by Thread: | RE: XSS, SQL injection etc - permutations of input strings, Keith Roberts |
| Next by Thread: | RE: XSS, SQL injection etc - permutations of input strings, Michael Silk |
| Indexes: | [Date] [Thread] [Top] [All Lists] |