[OWASP-TESTING] finally!

Daniel daniel.cuthbert at owasp.org
Mon Apr 18 04:12:44 EDT 2005


Very true and i'd rather the guide be aimed at anyone involved within the
application development process, than the security conslutants and pentest
scene.

Hence why i initially put in the section on basic pentesting techniques


Curphey, Mark said:
> You might want to consider this carefully as this is in contradiction to
> the way the software development community does (and has always seen)
> testing. If you take this approach you may marginalize the product to
> being only useful to security folks (and a subset at that). Just my 2
> cents....
>
> -----Original Message-----
> From: owasp-testing-admin at lists.sourceforge.net
> [mailto:owasp-testing-admin at lists.sourceforge.net] On Behalf Of Keary,
> Eoin
> Sent: Friday, April 15, 2005 6:58 AM
> To: 'Mauro Bregolin'; Daniel Cuthbert;
> owasp-testing at lists.sourceforge.net
> Subject: RE: [OWASP-TESTING] finally!
>
> Personally we view whitebox as audit and blackbox as testing.
> Audit we see, say, the source code and review if it conforms to internal
> policy and best practice.
> Testing is from a user perspective, what the user sees. No code exposed
> just
> inputs and corresponding outputs.
>
> Regarding port scanning and footprinting these are initial phases of a
> pen
> test, the assessment phase. And it seems correct to cover assessment
> tasks
> in their own section.
> Information leakage is also a part of the assessment phase but is
> closely
> related to the attack phase as a slight adjustment to the attack vector
> can
> lead to an exploit.
>
> Regarding patching and versions of appserver this is related to the
> "secure
> code environment": this includes configuration and deployment,
> versioning,
> administration policy and redundancy/failover.
>
> -----Original Message-----
> From: Mauro Bregolin [mailto:mauro.bregolin at gmail.com]
> Sent: Friday, April 15, 2005 1:58 PM
> To: Daniel Cuthbert; owasp-testing at lists.sourceforge.net
> Subject: Re: [OWASP-TESTING] finally!
>
>
> A few comments of mine next - Mauro
>
> First, what is the assumed point of view? Many areas may be performed
> both black-box and white-box. Techniques will vary - just a trivial
> example, black box testing to identify "backup files" left in the web
> filesystem space amounts to do some sort of scanning, while if you go
> white box and have access to the web server box, you can explore the
> filesystem to spot those files. What is going to be the philosophy of
> the guide? For example, if it will cover both scenarios (and in fact
> it should, since we're talking about code review as well), for each
> section it could separately detail black box techniques and white box
> techniques.
>
> - Configuration Management Infrastructure. The first items (Listening
> HTTP ports, HTTP banner etc.) are part of a preliminary discovery
> phase. I think  it would deserve its own section, sub topics are (I
> assume black box in the following):
>   - network services related to the applications (obviously this
> includes HTTP(s) ports but other ports might be present as well in
> some cases). This is akin to do some port scanning
>   - http fingerprinting
>   - other fingerprinting techniques; for example, trying to identify
> web modules, technologies etc. by looking at URL filename extensions
> (such as the obvious: .pl, .php, .exe... - and the less obvious, there
> are dozen of weird extensions nowadays)
>   - information leakage: looking for sensitive information on the
> Internet which appear related to the target (which consists of: IP
> address(es), dns name(s), application and corporate name and
> information, etc.), via search engines (google...), newsgroups, news
> portals, whois-like services, etc.
>   - application architecture: trying to determine how the application
> is structured; identify tiers (for example, balancers, web servers,
> application servers, database etc.) and gather information about them
> (IP, type/version etc.).
>
> - what about google hacking? this is related to both what I called
> "information leakage" above and scanning for known vulnerabilities
> (though it is indirect...). In this area I guess it'd be appropriate
> to look at the work being done by the folks at Sensepost (see wikto in
> http://www.sensepost.com/garage_portal.html).
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
> _______________________________________________
> owasp-testing mailing list
> owasp-testing at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-testing
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> owasp-testing mailing list
> owasp-testing at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-testing
>
>


Daniel




More information about the Owasp-testing mailing list