[OWASP-GUIDE] Guide Chapter 10 Thoughts
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
alex at netWindows.org
alex at SecurePipe.com
More information about the Owasp-guide