[OWASP-GUIDE] Guide Chapter 10 Thoughts

Gene McKenna mckenna at bluedot.com
Tue Jan 28 17:10:59 EST 2003


Jeremy,

I have contributed to chapt 10, and have rewritten most
of chapt 11 at this point. I think you have more time
and resources to put into this than I do, and I am in
favor of the approach you outlined below.

I would like to be involved a bit as you redo these.
Also, I contributed source code examples for some of
the mitigation techniques and they are directly related
to ch 11. Other source code samples are planned and
if we have until Feb sometime now, it makes them more
likely. :)

GENE


> -----Original Message-----
> From: owasp-guide-admin at lists.sourceforge.net
> [mailto:owasp-guide-admin at lists.sourceforge.net]On Behalf Of Jeremy
> Poteet
> Sent: Tuesday, January 28, 2003 1:32 PM
> To: owasp-guide at lists.sourceforge.net
> Cc: Greg Nichols; Glenn Niemeyer
> Subject: RE: [OWASP-GUIDE] Guide Chapter 10 Thoughts
>
>
> I left for a long meeting and missed an entire discussion. :-)
>
> I discussed this with our company president Greg Nichols and one of our
> security analysts, Glenn Niemeyer, who have offered to help me in putting
> together chapter 11.  As we looked over chapter 10, it seems to make the
> most sense when joined with the data input issues (XSS, SQL
> Injection, etc.)
> of Chapter 11.  However, there are other items currently in
> Chapter 11 that
> are not data input related but are common problems that need to be dealt
> with.
>
> Our recommendation would be to have two chapters, Chapter 10 that
> deals with
> data input issues and Chapter 11 that deals with other common problems.
> Those topics currently in chapter 11 that are data input related would be
> moved to chapter 10.  We would be willing to write both chapters.
>
> To address some of the other issues that were presented in this thread:
>
> * I like the idea of naming the chapters rather than using
> chapter numbers.
> Glenn and I are currently finishing a book on XP/Ant and I know we have
> moved things around several times.  It would be nice to have that
> flexibility.
>
> * Our approach to the chapters is going to be much more like Alex
> discusses.
> For example, we plan on covering injection as a concept first.
> When people
> are aware of how unchecked input is passed to and used by an application,
> specific types of injection such as SQL Injection, XSS, OS Injection, etc.
> become much easier to understand.  If the case can be made first
> why this is
> such a bad thing, then the specific vulnerabilities usually are much
> clearer.
>
> * As for the timeframe, we have our 100% deadline for our book on
> Monday, so
> we have only done some preliminary work on the OWASP chapters.  We will be
> sending out a detailed outline early next week to get feedback from all of
> you.  As for can we meet the February 15 deadline or if we would need more
> time, I can let you know then.  We have put a lot of thought into how to
> layout the chapters and feel we can get the verbiage ready for review very
> quickly.
>
> Thanks,
>
> Jeremy Poteet
> Chief Technology Officer
> Technology Partners, Inc.
> 1-877-636-1331 x105 (toll free)
> 636-519-1221 x105
> http://www.tech-partners.com
>
>
> -----Original Message-----
> From: owasp-guide-admin at lists.sourceforge.net
> [mailto:owasp-guide-admin at lists.sourceforge.net]On Behalf Of Mark
> Curphey
> Sent: Tuesday, January 28, 2003 1:41 PM
> To: owasp-guide at lists.sourceforge.net; owasp-guide at lists.sourceforge.net
> Subject: Re: [OWASP-GUIDE] Guide Chapter 10 Thoughts
>
>
> Salient points as I am on the move (wonders of wireless)
>
> Descriptive chapter names - brilliant idea
> Threat modeling including attack trees - brilliant idea. Should
> prob be part
> of the risk assessment and threat modeling chapter early on?
>
> Collapsing 10 and 11 would get my vote but I still want to hear
> from Jeremy
> to make sure this and the mitigating specific issues are in sync
>
> ---- Alex Russell <alex at netWindows.org> wrote:
> > Ok, here's what I'd be thinking about for ch's 10 and 11 (given my
> > druthers):
> >
> > first, we need to outline in a more anecdotal way _why_ trusting input
> from
> > _any_ external source is a poor plan. As it currently stands,
> we've got a
> > lot of dull, copied, boilerplate filled in with some
> interesting examples.
> > If we can change both of these chapters to be more engaging of the
> reader's
> > own experiences then I think we're going to wind up with a more
> > approachable set of chapters. So my primary goal for these
> chapters would
> > be to teach developers a healthy distrust for anything system
> they didn't
> > write (and even the ones they did) and for input they didn't generate.
> >
> > I think we need some kind of a primer on "how to be paranoid (in a good
> > way!)". Structurally speaking, I think it should either be the
> first half
> > of ch 10 or a chapter preceeding it (I've got no issues with re-ordering
> > things). I've actually been mulling a proposal to change all
> our filenames
> > to descriptives names outlining the contents of each chapter so we can
> > re-order things without causing lots of confusion about what's
> in Chapter
> X
> > and why it is for some strange reason appearing behind Chapter
> Y when one
> > goes to generate the guide...
> >
> > On Tuesday 28 January 2003 12:25, Gene McKenna wrote:
> > > A few other things to consider.
> > >
> > > Chapter 11 and Chapter 10 both discuss data input validation.
> > > If we are looking at redoing chapt 10, we should also look
> > > at chapt 11.
> > >
> > > I think together these chapters discuss four things.
> > >
> > > 	0) User Input validation and sanitization in
> > > 	   general as a means of preventing a variety of
> > > 	   known problems.
> >
> > well, more strongly, as the _only_ reliable way of preventing those
> > problems.
> >
> > > 	1) Embedded HTML Tag attacks
> > >
> > > 	    The mitigation technique for the above is
> > > 	    user input validation.
> >
> > eh, I think that if we do a section on healthy paranoia of
> external input,
> > that'll be kind of obvious (as most of the "mitigation
> technique" sections
> > in the current ch10 are).
> >
> > Frankly, I think that all of these categories would be better
> served by a
> > chapter on threat modeling and data flow analysis. If we only
> point out to
> > developers that they might wind up with some class of problems, how have
> we
> > helped prevent them in the future?
> >
> > A chapter on threat modeling might include:
> >
> > 	* attack trees
> > 	* data flow diagraming (DFD) and analysis
> > 	* learning from current systems
> >
> > among other things that I can't seem to think of now.
> >
> > > 	2) SQL Injection Attacks
> > >
> > > 	   The mitigation technique for this is not user input
> > > 	   validation, it is use of prepared statements to
> > > 	   execute queries, or failing that, data sanitization.
> > >
> > > 	3) OS attacks
> >
> > I really don't like this term. There are whole stacks of code between a
> web
> > app and an OS. We need to acknowledge that said code (web
> servers, etc...)
> > exits, isn't necessarialy protected by OS-level controls on
> actions (e.g.,
> > if I comprimise a web server, I can do all kinds of malicious things and
> > not have to circumvent file system perms), and need to be locked down in
> > logical ways.
> >
> > --
> > Alex Russell
> > alex at netWindows.org
> > alex at SecurePipe.com
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Owasp-guide mailing list
> > Owasp-guide at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owasp-guide
> >
> >
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Owasp-guide mailing list
> Owasp-guide at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-guide
>





More information about the Owasp-guide mailing list