[OWASP-TESTING] Comment on testing guide and contrib for part 2

Mauro Bregolin mauro_bregolin at yahoo.com
Fri Jul 30 11:34:37 EDT 2004


Daniel,

I'll be glad to help.
Actually I'll be on vacation most of August, hope that
won't be
a problem with the project schedule.

ciao

Mauro

P.S. I remember someone complained in the past about
attachments,
I have the same problem - they appear as raw base64
data and I
have to manually convert them to get the final
document.

--- Daniel <daniel at deeper.co.za> wrote:

> Mauro,
> 
> I'm hoping your able to give your input and
> experience with the 2nd 
> phase of the testing doc
> Your development background would really add a
> valued background
> 
> I'll be updating the outline for the 2nd phase this
> weekend and will 
> include you on the list
> 
> Cheers
> 
> Daniel
> 
> 
> On 29 Jul 2004, at 21:48, Mark Curphey wrote:
> 
> > Mauro,
> >
> > This is great feedback. You are clearly a
> developer who speaks about
> > requirements and architecture and how testing
> (non-security) is or 
> > should be
> > a part of the developers life. This is exactly
> what we IMHO need to get
> > across in this project. A lot of the security
> community (even 
> > application
> > pen testers) are not from development backgrounds
> so are more familiar 
> > with
> > pen testing. If we all agree that testing should
> be part of the 
> > development
> > process then it needs to work with the other
> testing that is done such 
> > as
> > functional testing and regression testing etc .
> >
> > What this project set out to do was to help people
> build their own 
> > testing
> > program as a whole (holistic view) and understand
> what and how to test 
> > for
> > certain issues is a part of that.
> >
> > FYI Part 1 was really meant to instill a simple
> high level management
> > message. To build a testing program there are a
> lot of techniques 
> > including
> > code review, manual inspection etc. Don't just
> think of testing as 
> > testing
> > deployed applications and pen testing. You need to
> test people, policy,
> > process AND technology.
> >
> > Part 2 will flesh that out into hard fast
> suggestions such as how to 
> > test
> > for SQL injection.
> >
> > The point of the above and SQL injection is a good
> one I think. If you 
> > see
> > in the design there were no data validation
> boundaries defined and then
> > parameterized stored procs were not used, you
> pretty much know you 
> > will have
> > a sql injection issue before you touch the code or
> pen test. If you 
> > look in
> > code and see dynamic queries being built of of url
> params again you 
> > know you
> > have an issue. You don't need a pen testers to
> stumble on the table 
> > names
> > ;-) In your example below it sounds like you found
> this issue in code 
> > and
> > then proved it with pen testing. Is that right ?
> >
> >
> >
> > -----Original Message-----
> > From: owasp-testing-admin at lists.sourceforge.net
> > [mailto:owasp-testing-admin at lists.sourceforge.net]
> On Behalf Of Mauro
> > Bregolin
> > Sent: Thursday, July 29, 2004 4:09 PM
> > To: owasp-testing at lists.sourceforge.net
> > Subject: [OWASP-TESTING] Comment on testing guide
> and contrib for part 
> > 2
> >
> > [I'm posting from a different address since my
> address
> > mauro.bregolin at tiscali.it was rejected as its SMTP
> server was in the
> > "Spamcop RBL"...
> > guess I should change provider]
> >
>
------------------------------------------------------
> >
> > Hi to all,
> >
> > I'm one of the relatively recently added folks who
> have yet to 
> > contribute
> > (needless to say, I was hit by Murphy's law and
> swamped by work as 
> > soon as I
> > subscribed to the list...)
> >
> > Now, feeling guilty:
> >
> > 1. Comments on testing guide
> >
> > I found the guide a bit unbalanced.
> > I think there are different assumptions when you
> write something 
> > addressed
> > to both when you have control over the software
> development life cycle 
> > and
> > when you test something already developed by
> others.
> > In the first case, test is a part of the
> development process and is 
> > under
> > control. You should have documentation about
> requirements,
> > architecture/design, code, etc.; your test cases
> should have been 
> > prepared
> > according to established test plans in order to
> verify adherence to
> > requirements (including security).
> > Now, talking about things like "software
> development life cycle", 
> > "threat
> > models", "code reviews", etc. is risky because
> there are tons of books 
> > which
> > do this.
> > I'm not saying it's wrong, but it's difficult to
> do it without being 
> > too
> > naive, or simplistic.
> > For example, UML is one of the prominent (if not
> > "the")
> > modeling methodology in use nowadays, but it's not
> the only one.
> > It's difficult to summarize good testing practices
> in a few pages, when
> > others have wrote piles of books on the subject.
> > Things are perhaps a bit simpler with grey/black
> box testing, where 
> > not much
> > information is available, or even with white box
> testing when performed
> > afterwards by external people (in the sense that
> only available
> > documentation is considered; you are somehow
> >
> > constrained by what others have written/produced).
> > Just my 2c on the topic...
> >
> > 2. Contribution for part 2
> > I was wondering if you deem of interest inserting
> in part two some 
> > "case
> > studies".
> > With this I mean real-life situations worth of
> being thoroughly
> > explained/analyzed.
> > Personally I have one related to SQL Injection,
> which is in my opinion 
> > good
> > to show the dangers lying in seemingly minimal
> exposures.
> > Briefly stated, I found several examples (all at
> prominent 
> > organizations!)
> > of SQL injection vulnerabilities in
> authentication-related forms which
> > unfortunately granted no output to control where
> to "union" data 
> > fetched
> > from the DBMS via the injected query. Moreover,
> the DBMS involved (DB2,
> > Oracle) didn't allow fancy things like statement
> concatenation, nor the
> > invocation of a plethora of stored procedures like
> MS 
=== message truncated ===



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail




More information about the Owasp-testing mailing list