[Owasp-testing] review comments
marco.cova at gmail.com
Tue Aug 26 17:02:03 EDT 2008
I've completed a read-through of the guide (except a few sections toward
the end), changing some things along the way (mostly to fix typos or
clarify paragraphs: yes, sorry for all those minor edits :-)).
Here are some more notes/comments, which hopefully should be
addressable in a short
time (the number refers to the chapter/section, "all" means it is
applicable to the whole content):
all: There should be a standard format for references: different sections
use different styles (e.g., inline, footnote).
all: Remove all references to part 1/part 2 of the guide and use
appropriate chapter numbers instead.
2: It refers to a detailed threat modeling methodology ("Part 2 of the
OWASP Testing Guide (the detailed 'How To' text) will outline a specific
Threat Modeling methodology"), which doesn't seem to exist
The paragraph "A Note about Static Source Code Review Tools" is very
confusing (what is the code, what is the undefined variable temp?): it
should either be improved substantially or be removed.
Before the section on Security requirements, there is a link to the TOC:
is that supposed to be there?
What is meant by "application security frame categorization"?
"From the defect management and reporting perspective, software quality
and security testing can leverage similar issue categorizations and
metrics": not clear
Section 3 and Section 4 are a bit disconnected. It probably
would be good to have a paragraph to introduce Section 4, so that it is
clear why it's there. For example, something along the lines of "if you
want to have a successful testing program, you need to know what are the
objectives of the testing. These objectives are specified by security
requirements. This section discusses..."
Some parts of the last section overlap with the content of
the next chapter.
3: The figure could be improved: the text in the boxes is not always
aligned consistently (sometimes it's left-aligned, sometimes it's
centered); fonts in the figure should be used consistently; some of the
boxes in the figure do not correspond to any part of the text
4: The list of contents at the beginning of section 4 should be kept
synchronized with the general table of content. For example, the section
"AJAX Testing" in the ToC is missing in the list of the section.
4.1: The introduction should probably be modified to reflect the fact
that this is a chapter in the testing guide, rather than a guide on its
Capitalization is not used consistently in the table.
The term "gates" seems non standard and later sections use "entry points".
4.2.4: The section is titled "web application fingerprint", but its
content focuses only of fingerprinting "web servers": I think either
the title should be changed, or the content should be updated with
similar techniques for fingerprinting web applications.
4.8: "break the pattern": unclear
"OS commanding" is non standard, better "OS command injection"
In most of the sections, testing follows a 3-step process: identify
attack vectors; determine if sanitization can be bypassed; perform the
actual injection: should the sections have a more standardized structure
to reflect this?
4.8.1: Would it be good to have at least one example of attack that shows
something else than creating a popup?
4.8.3: To be finished
4.8.4: To be done
18.104.22.168: "The single Quotes Problem" paragraph is not very clear
"direct SQL injection could be easily accomplished at a level
depth depending primarily on mysql version": unclear
"Note: there is no way to bypass single quotes outstanding filename":
22.214.171.124: "Blind sql injection vulnerabilities are by no mean the most
frequent type of vulnerability": not clear if they are frequent or not
4.8.12: should be expanded to talk about file injection (e.g.,
include/require in PHP) and dynamic evaluation of code (e.g., eval)?
4.8.13: should the example be clarified, e.g., to specify that the
application passes the user input to a function like system() or open()?
4.8.14: format string is not a buffer overflow. Also, what about
integer overflow vulnerabilities?
Should this section mention more sophisticated defense mechanisms?
126.96.36.199: The last reference seems wrong.
There are non-printable characters in the last <pre> section
188.8.131.52: The description of stack overflow seems quite basic. Should we
add more sophisticated attack techniques?
4.8.15: "incubated" seems a non standard term: should it be
"persistent" or similar instead?
4.9.1: This seems to mix two different problems: one is insufficient
validation allows a user to force the DB to scan the entire table; the
second are algorithmic complexity attacks. See more detailed comment at
More information about the Owasp-testing