[OWASP-TESTING] pentest cheat sheet

Lluis Mora llmora at sentryware.com
Tue Jul 13 18:46:06 EDT 2004

Hi all,

I was not particularly thinking on code review (more on the external audit
side of things), but I can see how we can split section 4 (and probably 5)
for both ways of approaching the "testing".

I see section 6 ("Things to test/try") as an "external audit" kind of thing,
although we could add a "Things to look for in the code" when coming to code

A sample of what a section covering "Cross-site scripting" might look like
(Ok, I did chose an easy one, blame me :) this is not meant to be complete
or technically correct, just to see if we agree on what the content of each
subsection (4,5,6 and 7?) could be and whether to split them or not):

4. How to test for it

4a. During code review
Find input data from the client that gets directly output back to the
client, with no previous filtering or encoding.
Find dynamic data output to the client that is based on information provided
by the client itself (take into account that this can be information
provided in the very same request or information retrieved from permanent
storage - e.g. a database). Keep track of input variables, where (and how)
they are stored in every part of the application that deals with them.

4b. During an "external audit"
Look for data provided by the remote client that gets output back by the
application (this could be any part of the request, but particularly look
for input variables -GET,POST- and cookies). A good way to test for them is
to browse the remote website using a "keyword" on all date fed to the
application. After that review find if that "keyword" shows up in any
response from the server, which will lead you to a good starting point to a
possible XSS vulnerability.

5. Drawbacks of the testing
It is easy to spot "direct" XSS vulnerabilities, where the input to an
application gets output by the application on the same transaction where it
is received. Applications that store the provided data into a permanent
storage (e.g. database) and later on use it in output to the client are
harder to test (note: for the time being I will use the "indirect XSS
vulnerability" term to describe them, for lack of a better name).

5a. During code review
One of the ways to test for "indirect XSS" is to follow the application
logic to determine what is actually done with the client input and make sure
that either on the way in it gets filtered or on the way out it gets
encoded. This might involve a large amount of work and there is not probably
an automated way to do it, so it is easy for one of these vulnerabilities to
slip through. A good approach is to make the data provided by the user
"tainted" and make sure it is either properly validated during input or
encoded on output.

5b. During an "external audit"
Finding "indirect XSS" vulnerabilities while performing an external audit is
directly related to the amount of time we spend interacting with the
application and the number of functionalities we access. It is usually
prohibitive/impossible to interact with the application in every single
possible way, which is the only way to spot them all, so code review is a
better option to test for these kind of vulnerabilities (note: I am afraid
this is probably going to show up all over the document :).

6. "Things to test in an external audit"

7. "Things to look for in the code"
  - Output of variables provided by the client (e.g.: print $_GET["data"])

What do you think of the structure and kind of content for each subsection?
I feel as if we were missing something important here, can anybody think of
more subsections?



> -----Original Message-----
> From: owasp-testing-admin at lists.sourceforge.net 
> [mailto:owasp-testing-admin at lists.sourceforge.net] On Behalf 
> Of Jeff Williams
> Sent: martes, 13 de julio de 2004 20:34
> To: Mads Rasmussen; Lluis Mora; Daniel at deeper.co.za; 'owasp '
> Subject: Re: [OWASP-TESTING] pentest cheat sheet
> Are we all using the word 'testing' to include code review?  
> And would section 4 be split somehow to cover both?
> I think references to "how to solve it" -- like pointers to 
> the Guide would be pretty helpful.
> --Jeff

More information about the Owasp-testing mailing list