[OWASP-GUIDE] Guide Chapter 10 Thoughts

Jeremy Poteet jpoteet at tech-partners.com
Tue Jan 28 16:32:29 EST 2003


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Jeremy Poteet.vcf
Type: text/x-vcard
Size: 572 bytes
Desc: not available
Url : http://lists.owasp.org/pipermail/owasp-guide/attachments/20030128/dd305230/attachment.vcf 


More information about the Owasp-guide mailing list