[OWASP-TESTING] Comment on testing guide and contrib for part 2
mauro_bregolin at yahoo.com
Fri Jul 30 11:27:54 EDT 2004
I agree with your remarks on the typical background of
professionals (which is, in my opinion, a limitation).
Yes I come from a sw development background; in the
I worked at a company which acquired SEI CMM level 3
Then it happened that I switched to security; and when
the company I was
working for at the time was taken over by ISS and
became ISS Italy,
I managed ISS security assessment services for the
(that was 2001-2003; it might be that we were actually
for some time, though Italy was somehow at the margins
of the picture
for ISS worldwide...).
Concerning SQL Injection, actually those
found and exploited during pen tests (all of them).
In my experience, clients are not very keen in having
box assessments, not to mention let you snoop through
I'm not saying they don't do this, but usually when we
called in it was for pen test or application
People dealing with security - the guys who called us
- usually managed deployed applications;
intervening in the SDLC is somehow harder for an
partly because one tends to "wash dirty laundry at
home", as an
italian saying puts it.
Maybe others have different experiences...
--- Mark Curphey <mark at curphey.com> wrote:
> 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
> 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
> 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
> 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
> 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
> With this I mean real-life situations worth of being
> Personally I have one related to SQL Injection,
> which is in my opinion good
> to show the dangers lying in seemingly minimal
> 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
> 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
> 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,
> >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
=== message truncated ===
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
More information about the Owasp-testing