Please create new content in the old chapter.

Currently 17.2 says:
"Verify that unique device ID (UDID) values are not used as security controls."

Prefer:
"Verify that ID values stored on the device and retrievable by other applications, such as the UDID or IMEI number are not used as authentication tokens."

Appendix B - Page 46 - OWASP Top 10 Guide Link Should be Consistent

OWASP Top Ten Project - http://www.owasp.org/index.php/Top_10 this is different from the same on page 44

http://www.owasp.org/index.php/Top10

But it looks like the same page

Additionally should the Mobile top 10 be included since there is a big mobile section, V17?
https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks

I think this issue applies to both Android and iOS - they both take screenshots and save the state of the application as they are backgrounded to make it appear like they are being re-hydrated faster than they actually are. I've put in a temporary fix, but I think we can make this much better.

My apologies if this has already been brought up previously. The requirements V11.8 and V11.10 appear to be very similar in intent. Can anyone help me understand what the primary difference between them is?

V11.8: Verify that HTTP headers and / or other mechanisms for older browsers have been included to protect against clickjacking attacks.

V11.10: Verify that the HTTP header, X-Frame-Options is in use for sites where content should not be viewed in a 3rd-party X-Frame. A common middle ground is to send SAMEORIGIN, meaning only websites of the same origin may frame it.

Hey folks,
Maybe I’ve missed this, but I’ve combed the list looking for an answer and haven’t come up with much. I’ve been trying to update a bunch of my stuff to align with the the new 2.0 document and I’m noticing that the numbering system is off. For example, There is no requirement V1, V6, V12, V14. And within most of the other ones, there are individual requirements missing, V2.3, V2.10, V2.11, and so forth in the other sections too.

I could understand if this was done to keep the requirements in the same slots, as the previous published versions, but even then, from version to version, the same requirements have moved, old V1.5 is now V2.17…

Was there a reason for all of this? On a side note, I’m also happy to help contribute to this project, as I’ve been using this standard for a while, and think it’s important, just let me know how I can help out.

Best Regards,
Gerrit Padgham

Would it be possible to rename files by including a leading 0 (zero)
e.g.:
V2 - Authentication.xlsx
would be
V02 - Authentication.xlsx

this making it more logical ordering

Hi,

What is the difference between:

V4.9. Verify that the same access control rules implied by the presentation layer are enforced on the server side for that user role, such that controls and parameters cannot be re-enabled or re-added from higher privilege users.

And:

V4.11. Verify that all access controls are enforced on the server side.

In fact I'm having a hard time seeing a scenario where I would fail V4.9.

Cheers,
Boy

Appendix B page 44 – May want to write out Abbreviations for HTML and LDAP

HTML – The main markup language for the creation of web pages and other information displayed in a web browser.

Write out HTML as HyperText Markup Language (HTML)

LDAP – An application protocol for accessing and maintaining distributed directory information services over a network.

Write out LDAP as Lightweight Directory Access Protocol (LDAP)

Does PII refers to "personally identifiable information"?

Going to remove.

I've found an app that doesn't have an old password when changing password.

I was surprised when I looked through ASVS that we don't explicitly say what makes a good passphrase change dialog:

Old passphrase
New passphrase
Confirm passphrase

2.9 seems the best place to put this in without creating a new finding, as I feel 2.9 is a bit wooly and non-specific / testable.

Thoughts?

Page 14 – I am not sure I agree with having a 3.1 and 3.2 when this is the only Level that even mentions this.

While each level has a variety of sub levels we need to group organizations in “bands” that best fit their maturity.

Could these 4 things be out into a level 3 item or do they really represent a level 4?

I'd love to see "role" taken out of ASVS 2.0 v4.9

Consider changing:

V4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side for that user role, such that controls and parameters cannot be re-enabled or re-added from higher privilege users.

To....

V4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side.

Simple and clear wins the day.

Aloha,
Jim

There are no treatment plans within the ASVS. We can't be specific but we also don't currently give any guidance.

Page 16 – List of Requirement Areas Should Match the Section Header Wording

Should “V11. HTTP“ be “V11. HTTP Security“ to match the category like the others?

Should “V16. File and Resource“ be “V16. Files and Resources“ to match the category like the others?

XSS is not even mentioned, so where relevant, include without duplicating issues.

Both V3.15 and V10.11 Talk about HSTS headers. I think V3.15 should be reduced to just the Secure Flag being set on the session tokens, using cookies, and then leave V10.11 as it is with the HSTS header.

It's too iOS -6.x specific.

i.e. this file OWASP_ASVS_Version_2.docx

Hi all,

What skills, level or type of knowledge areas should have a team development to understand the requirements of ASVS?

Thanks in advance for your answers or ideas you can give me.

Best regards

Beto.

Ari said:

I think that is a very good question that we actually should focus more on later editions of the ASVS.

There are at least these things you need to consider:

• what are the most essential pieces of general knowledge the team must have, e.g. understanding the concept of injection or validation
• what coding principles are followed and why (defensive coding, complying with external or internal architecture standards etc — this of course varies but typically a team should have some guiding security and implementation principles, some of which are relatively universal)
• what does the team need to understand about the technology stack they’re using (and I think this is very important thing), that is, how does it work
• what parts of the ASVS are handled already by the technology stack (also an important thing to consider)

In practice, I would think that at the very least, the team needs to understand how HTTP works, how things like HTTP parameters and requests get handled in their application, and what an injection is (as a general concept, not just XSS and SQLi). Also they should have a clear concept how authorisation is supposed to work in the application and be able to validate that with the requirements. I’m less concerned about authentication, as it typically is handled by an external component and just kind of plugged in to the application.

I would put less emphasis on for example session handling (unless you do that in your application, which you shouldn’t) and cryptography (rarely needed). Proper configuration of cookies, secured connections etc. are important, but luckily they can be relatively easily fixed if the team doesn’t get them right already during development.

As for ASVS, would it make sense to somehow categorize verification items based on where they are (or should be) handled, e.g. infrastructure, middleware, program code, centralised libraries etc? Or maybe as part of the ASVS itself, but as a supplemental guide? I can help with this, although it is obvious that there’s no one single categorisation as it depends on what technology is used and how. But I still assert that typically a software development team should only consider a subset of the verification items, while other items are considered by other teams (e.g. infra).

This needs serious cleanup....

v4.17 Aggregate access control protection – verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For example, possibly by the use of a resource governor to limit the number of edits per hour or to prevent the entire database from being scraped by an individual user.

perhaps...

v4.17 Verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For example, consider the use of a resource governor to limit the number of edits per hour or to prevent the entire database from being scraped by an individual user.

Aloha,
Jim

Appendix B - Page 46 – OWASP Testing Guide Link Should be Consistent

May consider changing the URL from http://www.owasp.org/index.php/Testing_Guide to https://www.owasp.org/index.php/OWASP_Testing_Project to be more direct

It would also then match the same link on page 44

Appendix A page 38-41 – Inconsistent Capitalization in the Suggested ASVS Level Description

Wording in the Suggested Level All start with a small character except for the ones in Retail, Food, Hospitality

For Example:
Level 1: all Internet-accessible applications.

Level 2: Suitable for business applications, product catalogue information, internal corporate information, and applications with limited user information (e.g. contact information). Applications with small or moderate amounts of payment data or checkout functionality.

Doesn't say why the control is necessary. I'm going to add "potentially unencrypted" to the control

Duplicate
CSP
Sniffing headers

The following terms are in the Appendix B but I cannot find them in the document
Appendix B - Page 43-45

The following are not found in the document except here (it is unclear why they are here):
Application Component
Back Doors
Blacklist
Common Criteria
Internal Verification
Denial of Service (DOS) Attacks
Easter Eggs
OWASP Risk Rating Methodology
Salami Attack
Time Bomb
UAT
Also for UAT:

UAT – Traditionally a test environment that behaves like the production environment where all software testing is performed before going live.

Should UAT be also written out?

Also, if this is User Acceptance Testing I do not see how this is different from Integration or Validation environments. UAT many times is conducted in a validation environment.

May also want to add to the Appendix:
V17.21 Verify that the application makes use of Address Space Layout Randomization (ASLR).

Address Space Layout Randomization (ASLR) – A technique to help protect against buffer overflow attacks.

Issue: ASVS has always been a "20% of the controls to cover 80% of the issue" standard. Reverse engineering and obfuscation are not controls, but delaying tactics for software that fits into a tiny corner case. Additionally, as an open standard, any control that requires a significant investment in third party tools to be compliant is unacceptable.

Remove all references to reverse engineering and obfuscation.
Align 17.7 with the results of OWASP Top M10 2015
Retire 17.11
Retire 17.25

To allow easy transition to 2.1, 17.11 and 11.25 should simply be blanked out to avoid a renumbering effort on the part of ASVS users and tools.

"v2.27 Verify that the use of commonly chosen passwords and weak passphrases (such as “let me in” or “Password1!”) are in place."

"[] measures against the use [] are in place"
or
"[] use of [] are blocked"

Issue: the crypo in transit chapter is practically impossible to verify. It's very old school J2EE centric, which doesn't help modern applications.

Solution:

Use the SSL/TLS threat model and best practice guides from Mozilla, Microsoft and Qualys to ensure that we have a reasonable set of controls, with adequate guideance to test these empirically from either a configuration or code point of view, as well as a simple set of references for developers to follow that will end up with a reasonable outcome from an ASVS assessment.

Platform issues such as certificate pinning and so on should be considered, but only to note that this should be a platform issue, rather than a developer temporary fix.

It is unfortunate but common for PHP applications to be incorrectly configured with world writable access to the interpreted sources (A5 of the OWASP Top 10) or that old known vulnerable versions of libraries or frameworks are used (A9 of the OWASP Top 10).
Neither is a verification requirement for applications, only for mobile.

Page 19 – Should V37 and V38 prevent the same issue?

V37 Verify that the session id is changed on login to prevent session fixation.
V38 Verify that the session id is changed upon re-authentication.

Should we add “to prevent session fixation.” To v38?

Page 31 - The Malicious Code Section wording as a bit difficult to read, wordy

We should try to use positive wording

Examples:

V13.1 Verify that no malicious code is in any code that was either developed or modified in order to create the application.
V13.3 Verify that all code implementing or using authentication controls is not affected by any malicious code.
V13.6 Verify that all input validation controls are not affected by any malicious code.
V13.7 Verify that all code implementing or using output validation controls is not affected by any malicious code.

Possible Solutions:

13.1 Verify that the code used to develop or create the application is free of malicious code.

13.3 Verify that malicious code cannot affect code that implements or uses authentication controls

13.6 Verify that malicious code cannot affect input validation controls.

13.7 Verify that malicious code cannot affect code that implements or uses output validation controls.

“Affect” may be changed to, “interact with” or “impact”

When entered into the dialer, this can lead to grant an access to hidden sensitive information.

Install the App
Go to phone app
Dial ##-------##
See hidden menu

Table of Contents page numbers is off by 1 for everything after Application Security Verification Levels page 9

For example:
Level 0: Cursory show page 11 but in reality is page 10

Issue: The crypto chapters in ASVS have historically been unreviewable by professional code reviewers and unimplementable by professional developers.

Aim: Re-write the crypto at rest chapter to ensure code can be assessed for compliance, and that developers have clear guidance on what to implement correctly.

People using the former version 2.0, want to know what had changed so that they can update their policies.

words. I can't believe we haven't been pinged on this yet.

I'm going to add API tokens to it

Page 22:

V2.27 Verify that the use commonly chosen passwords ... are in place. Should be: are NOT in place?

Page 27:

V5.3 Missing full stop.

Page 28:

V5.21 "Verify that remove the unneeded "

Page 37:

V10.16 current leading practice I think current best practice makes more sense.

Page 39:

V11.13 X-CONTENT-TYPE-OPTIONS should be X-Content-Type-Options

Page 45:

V16.1 Verify that URL redirects and forwards only allow whitelisted destinations. I think it might be worth mentioning that it is also acceptable to redirect to non-whitelisted destinations if the user is warned first. This is what Facebook does. Something like V16.1 Verify that URL redirects and forwards only allow whitelisted destinations or show a user warning when redirecting to an untrusted domain.

Page 46:

Typo: Provide unqiue security requirements unique*

Page 47:

There is a check for ASLR. Would it be worth also adding a check for Position Independent Executable (PIE)?

It is unclear why there are “Skipped/Missing” verification requirements

It is unclear if the missing requirements were forgotten or have been removed.

It may help reader and user of ASVS to have either a generic paragraph stating why there are some missing or include the line and say something like “No longer relevant” or “Deleted from this version of ASVS”

The entire V6 verification is is not included any more.

The following verification requirements are missing or have been removed:
2.3
2.10
2.11
3.9
4.6
4.7
4.8
5.9
7.4
8.12
11.1

Page 46 – Appendix C – May Want to Include the Actual MITRE Page Title

MITRE - Common Weakness Enumeration – Vulnerability Trends, http://cwe.mitre.org/documents/vuln-trends.html

May want to remove the “,” and the actual page Title is “Vulnerability Type Distributions in CVE“

This and PCI Security Standards Council are the only ones that say why the site is useful

Page 15 Scope of verification Misspelling Be should be By

Be default, ASVS assumes that the scope of the verification includes all code that was developed or modified in order to create the application or release.

Should be:

By default, ASVS assumes that the scope of the verification includes all code that was developed or modified in order to create the application or release.

There is an unstated assumption in the Data Protection chapter that data protection is occurring on a trusted device. This is not always true.

I feel that we either need to make it clear that there is an assumption, or make it a requirement for Levels 2 and 3 that Data Protection is enforced on a trusted device, much in the same way as all other chapters.

Hi there!

I checked the ASVS version 2 document , and came across this at page 37 near the bottom:

“Verify that sensitive data is stored in a cryptographically secure manner (even when stored in the iOS keychain).”

If I’m interpreting it right, then ASVS is saying that I have to encrypt my data before storing it in the keychain. I use the iOS keychain, but I’ve never encrypted data before storing it in it. The reason that I always thought this would be particularly useless is that someone can find the encryption key by checking the binary data of my app’s code.

Am I missing something?

Kind regards,

Joris ten Tusscher