[OWASP-GUIDE] Guide Chapter 10 Thoughts

Alex Russell alex at netWindows.org
Tue Jan 28 15:13:15 EST 2003

Ok, here's what I'd be thinking about for ch's 10 and 11 (given my 

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 

> 	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

More information about the Owasp-guide mailing list