[Owasp-testing] review comments

Ariel E. Coronel coronelariel at gmail.com
Mon Sep 1 14:46:42 EDT 2008


Marco,
About section 4.8.1, please note that following the popup example there is
another example where the victim downloads an executable file (.exe) of the
attacker's choice.
aec.


On Tue, Aug 26, 2008 at 6:02 PM, Marco Cova <marco.cova at gmail.com> wrote:

> Hello list!
>
> 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
> own.
> 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
> 4.8.5.2: "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":
> unclear
> 4.8.5.4: "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?
> 4.8.14.1: The last reference seems wrong.
> There are non-printable characters in the last <pre> section
> 4.8.14.2: 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
> https://www.owasp.org/index.php/Talk:Testing_for_SQL_Wildcard_Attacks
>
> Marco
> _______________________________________________
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-testing
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-testing/attachments/20080901/d651a85d/attachment.html 


More information about the Owasp-testing mailing list