[OWASP-TESTING] Notes on Testing
DEndler at iDefense.com
Wed Dec 4 16:43:19 EST 2002
Great feedback, thanks Mark and Nick. No hurt feelings whatsoever. For the
future, what would be most helpful is for the sections that require a
rewrite in your mind, please take a stab at it in the actual document and
send me your edits. Even if you can't produce the entire section, an
attempt at it would really help when piecing together everyone's
> -----Original Message-----
> From: owasp-testing-admin at lists.sourceforge.net
> [mailto:owasp-testing-admin at lists.sourceforge.net]On Behalf Of Mark
> Sent: Wednesday, December 04, 2002 2:22 AM
> To: owasp-testing at lists.sourceforge.net
> Subject: [OWASP-TESTING] Notes on Testing
> Its late I am tired and so I haven't made this polite or politically
> correct. Pls forgive me before reading. Nothing is personal.
> I will re-write into and what are web applications sections. I have to
> do this for the Guide anyways.
> Page 15 - Pretty diagram but not sure what it is trying to show ?
> Page 16 / 66 - I think planning of each phase of a test
> occurs, its not
> a discrete task. You plan the architecture assessment as well as an
> implementation review.
> I strongly (STRONGLY) think that there are discrete Requirements,
> Architecture (design), Implementation and Management Reviews.
> There may
> even be more phases we wish to call out.
> Section 5 should be removed for the same reasons as section 1
> Planning a test - maybe this section should be replaced with
> an overview
> about testing, planning, organizing etc
> white box, black box, static whitebox....urgh i hate those
> terms. If we
> are going to use them then we need to really clearly define them in a
> glossary so we are all on the same page as to exactly what
> they mean. I
> hate them ;-)
> Based on above comments the requirements review and architecture
> analysis doesn't exist
> Page 17 / 66 - agree with Nicks comments earlier. I think this is like
> 25% at most of a good assessment methodology. Its the after the fact
> tactical testing.
> 23 / 66 - obtaining source code - this should be the norm not the ab
> norm. It says in large tests. I don't think thats true. It
> also says in
> addition to pen tests. It should read as part of the testing
> life cycle
> including requirements, management etc
> 24 / 66 - this is a UML sequence diagram and we should use well
> understood language and syntax I think
> 25 / 66 - Infr review - I was thinking this would include more stuff
> like if the app uses getHostByName() and not GetHostbyIP() or doesn't
> synchronize tie clocks making timing attacks possible
> 26 / 66 - everyone should have dev, qa, pre-prod and prod. I would
> strongly argue that most testing is well before prod. Real data should
> never (NEVER) be used in testing. This section IMHO needs a
> big rewrite.
> This is all good and well for momandpops.php but....
> 27 - 66 - decompilers ? This is testing not hacking ;-) I think this
> section should explain how browser proxies work, how
> automated scanners
> are combos of automated http_user agents and fuzzers etc. It needs to
> outline source code analyzers. There are technical tools and checklist
> tools for the management reviews as well.
> DCMA - should be moved into an overview section if not
> removed. DCMA is
> about reverse engineering stuff, not examining stuff with permission
> unless I am missing the point
> 33 / 66 - webdav is an http extension and not an httpd extension.
> Options will return that baby ;-)
> SSL - again this is stuff an arch review and implementation / code
> review combined are best suited for. I am not sure I get the comments
> about making sure an entire page is SSL. You should make sure your
> applications transport matches your requirements but in many
> cases only
> sending data back may require a tunnel. This section should
> explain the
> SSL helo, how the cipher suites are determined and how you find
> algorithms supported and key lengths etc. Saying you should block old
> SSL (which I assume you mean 2) is interesting. Why ? Let the SSL
> negotiate the best it can do and allow your customers to make
> the choice
> with informed info.Summary, this section should show how to determine
> SSL version, cipher specs, and cert validity.And its all in the ssl
> headers and I can knock up a quick Java app if you want as a
> demo. JSSE
> is a king.
> SSL requirements by source code on each page ?
> And on that section its back to the code review / arch review
> / pen test
> thing. Looking at this from the outside is much harder than inspecting
> the code and arch. Have a good MVC model and you know one
> thing. Look at
> JSSE and you know another
> 33 /66 . old backup unreferenced files. This doesn't explain how to
> test. Too much guide type explanation. I think we should
> provide a list
> of extensions mapped to apps asa to asp for instance from FP, and then
> explain how from a crawled site and common file names you
> fuzz requests
> and look for an http 200 to come back.
> Less mature code - bit of a leap of faith isn't it ?
> This is only true if you build on same box as you deploy
> anyway which is
> a big no no IMHO. We cant just say the tools used to spider
> should check
> for this. Its a cop out ;-)
> 38 - logging 0- again as a general comment we should be driving people
> to testing against logging requirements or best practice. The logging
> section is a valid point but what about testing to make sure failed
> logins actual log, about malicious input creates an event etc
> OK only half way thru and probably offended 90% of people by now, but
> candid comments is the only way to go. If anyone finds this helpful I
> will do the rest, if not tell me or ignore.
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> owasp-testing mailing list
> owasp-testing at lists.sourceforge.net
More information about the Owasp-testing