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

Daniel daniel at deeper.co.za
Thu Jul 29 18:21:07 EDT 2004


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 SQL Server does.
> The only available indication regarding the injection was a binary
> condition, essentially whether the query produced an empty versus a
> non-empty result set.
> Admittedly, not much, but enough to fetch data at will.
> I coded a little java application to automate the process of submitting
> injected requests (may provide the code as well if that's considered
> helpful), with the result of:
> a) automatically determining database schema information (table, 
> columns,
> datatypes etc.),
> b) fetching data at will - compatibly with the DBMS account privileges.
> In two cases determining the schema allowed to spot a table where 
> credential
> where stored - in clear, which allowed to grab them and access the 
> service
> with arbitrary credentials.
> Needles to say, clients were quite impressed when they
>
> saw it...
>
> Let me know what you think...
>
> Mauro Bregolin
>
>> -- Messaggio Originale --
>> Date: Wed, 28 Jul 2004 20:05:32 -0700
>> From: owasp-testing-request at lists.sourceforge.net
>> Subject: owasp-testing digest, Vol 1 #247 - 1 msg
>> Reply-to: owasp-testing at lists.sourceforge.net
>> To: owasp-testing at lists.sourceforge.net
>>
>>
>> Send owasp-testing mailing list submissions to
>>  owasp-testing at lists.sourceforge.net
>>
>> To subscribe or unsubscribe via the World Wide Web,
> visit
>>
> https://lists.sourceforge.net/lists/listinfo/owasp-testing
>> or, via email, send a message with subject or body
> 'help' to
>>  owasp-testing-request at lists.sourceforge.net
>>
>> You can reach the person managing the list at
>>  owasp-testing-admin at lists.sourceforge.net
>>
>> When replying, please edit your Subject line so it is
> more specific
>> than "Re: Contents of owasp-testing digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Part 1 Update and Session Token Testing Request
> (Mark Curphey)
>>
>> --__--__--
>>
>> Message: 1
>> Date: Wed, 28 Jul 2004 21:53:47 -0400
>> From: "Mark Curphey"
>> To:
>> Subject: [OWASP-TESTING] Part 1 Update and Session
> Token Testing Request
>>
>> Can someone please send me the great work (I forget
> who did it)=A0on =
>> black box testing session management / session
> tokens? I would like to
> =
>> add it as an Appendix to Part 1 of an example of what
> will be coming in
> =
>> Part 2.
>>
>> I spent time today reworking the main chapters about
> techniques (manual
> =
>> inspections, code review, threat modeling and pen
> testing). This was =
>> because when we read through it as a whole document
> after the tech =
>> editor had his wicked way, some sections were just
> far to detailed for
> =
>> this document. They will all be able to be
> re-purposed for Part 2 so its
>> =
>> certainly not lost work.
>>
>> Larry and I will be updating Chapter 2 and the final
> Framework Chapter
> =
>> tomorrow and we hope to then have a final draft for
> you all to review by
>> =
>> the end of the week.
>>
>> Finally we maybe able to release this next week!
> Yippee.
>>
>> Cheers,
>>
>>
>> Mark
>>
>> PS What is the status of Part 2? Who is working on
> what? Is there a =
>> "table of contents"?
>>
>>
>>
>> --__--__--
>>
>> _______________________________________________
>> owasp-testing mailing list
>> owasp-testing at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owasp-testing
>>
>>
>> End of owasp-testing Digest
>
>
>
> 	
> 		
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, 
> one
> more big change to announce. We are now OSTG- Open Source Technology 
> Group.
> Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> owasp-testing mailing list
> owasp-testing at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-testing
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source 
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> owasp-testing mailing list
> owasp-testing at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-testing





More information about the Owasp-testing mailing list