OWSAP ASVS / WSTG / Code review project

[rainit2006]

OWASP ASVS document

https://owasp.org/www-project-application-security-verification-standard/

OWASP ASVS checklist for audits

https://github.com/shenril/owasp-asvs-checklist

OWASP-ASVS-4.0-testing-guide

https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide/tree/main The OWASP ASVS 4.0 testing guide is an unofficial supporting document to the OWASP Application Security Verification Standard which attempts to describe each level 1 control, what are the consequences of not being compliant with it, how to test it - with known open source tools or manually - and the criteria for the control to be valid. Additionally, to several controls there have been developed scripts using bash or OWASP ZAP scripting engine to automate the check of said controls. The "ZAP-scripts" folder includes a guide on how to get started with ZAP scripts.

OWASP-ASVS-testing-guide.pdf https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide/raw/main/OWASP-ASVS-testing-guide.pdf

ZAP script for ASVS checks

Automate checking ASVS controls using ZAP scripts： https://www.zaproxy.org/blog/2021-02-10-automate-checking-asvs-controls-using-zap-scripts/

github repo for ZAP-scripts： https://github.com/YaleUniversity/ZAP_ASVS_Checks

Getting Started Guide.pdf for ZAP-scripts: https://github.com/YaleUniversity/ZAP_ASVS_Checks/blob/main/Getting%20Started%20Guide.pdf

Video for ZAP ASVS Checks Demo

https://vimeo.com/702190939?&signup=true#_=_

• 00:29 - Download ZAP and Repository
• 02:22 - Open Zap and Session Settings
• 05:50 - Setup Proxy and Certificate with Firefox
• 09:45 - Set Context and Enable Scripts
• 11:21 - Traditional Spider
• 13:45 - Ajax Spider
• 17:29 - Active Scan, Standalone and Report Generation
• 21:57 - Fuzzer Scripts: Default Account
• 24:20 - Fuzzer Scripts: Password Security
• 27:51 - Fuzzer Scripts: New Session Token

OWASP Code Review Project

https://wiki.owasp.org/index.php/Category:OWASP_Code_Review_Project

[rainit2006]

WSTG

The ASVS is better suited for developers. The Web Security Testing Guide (WSTG) from OWASP is the document that shows you how to test those things in the ASVS. The WSTG is better suited for those doing the testing.

WSTG https://owasp.org/www-project-web-security-testing-guide/

WSTG-checklist (xls) https://github.com/OWASP/wstg/blob/master/checklists/WSTG-Checklist_v4.2.xlsx

Web Application Security Testing

4.0 Introduction and Objectives

4.1 Information Gathering

4.2 Configuration and Deployment Management Testing

4.3 Identity Management Testing

4.4 Authentication Testing

4.5 Authorization Testing

4.6 Session Management Testing

4.7 Input Validation Testing

4.8 Testing for Error Handling

4.9 Testing for Weak Cryptography

4.10 Business Logic Testing

4.11 Client-side Testing

[rainit2006]

OWSAP Cheat Sheet

OWASP Cheat Sheet The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics. These cheat sheets were created by various application security professionals who have expertise in specific topics.

[rainit2006]

Free for Open Source Application Security Tools

https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools

We would encourage open source projects to use the following types of tools to improve the security and quality of their code:

• Static Application Security Testing (SAST) Tools
• Dynamic Application Security Testing (DAST) Tools
• (Primarily for web apps)
• Interactive Application Security Testing (IAST) Tools - (Primarily for web apps and web APIs)
• Keeping Open Source libraries up-to-date (to avoid Using Components with Known Vulnerabilities (OWASP Top 10-2017 A9))
• Static Code Quality Tools
• Defense Tools
• Security Tools Built into DevOps/CI Environments
• Secrets Detection Tools
• Privacy Engineering Tools

[rainit2006]

-

[rainit2006]

https://www.youtube.com/watch?v=EZs5W8-mt_I

reddit：How to learn OWASP ASVS?

https://www.reddit.com/r/netsecstudents/comments/167f7ih/how_to_learn_owasp_asvs/

How to Use OWASP ASVS -- by Ralph Andalis

https://medium.com/@ralph.andalis92/how-to-use-owasp-asvs-16da9719c6cb Many developers use ASVS blindly and I heard them say that it is so broad and overwhelming for their teams to deal with it. One of my colleagues said that some software shops he worked with do not have this problem as they take ASVS and fork it for their usage, which is exactly what ASVS is supposed to be! If you will read the “Using ASVS” section and particularly in the “Forking the ASVS” subsection, this is what we have explicitly mentioned in the document for its usage. I’ll repeat it here what I wrote there so that it is fair since this part of the document is not officially released yet, but you may find it on the v 5.0 Github repo. As a clear example, if an organization is not using GraphQL, Websockets, or SOAP web service on their applications, they should drop those sections from their forked ASVS. The forking process must start with looking at ASVS level 1 requirements as a baseline for the organization and then gradually move into ASVS level 2 or 3 based on their application’s risk level. It is as simple as that! Of course, if you will blindly fork it and then look at the 300+ security controls in ASVS where maybe even more than half of it does not apply to your application, then it would definitely be overwhelming. We even joked about it that our colleague is working with the good software development shops if that’s the case that they are following the proper forking of ASVS; ideally, that is how software engineering companies should be using ASVS. Most companies do not do this (fork ASVS to their own usage to tailor-fit their needs) and it is my post’s goal to help reinforce that this is one of ASVS main usage instead of just taking it all and trying to deal with all of its recommendations and verification requirements which may not even apply to them. I hope this clarifies it to most readers of this post so that software dev teams would take it in a more structured approach and help drive security, because if they get overwhelmed what happens next and I guarantee this happens more often than not, is that they would be shelfing the security requirements in favor of functionality requirements just because it was so overwhelming and complicated to use.

For developers, OWASP ASVS + OWASP Cheat Sheet for a particular topic of technology they will implement (i.e. protections against XSS, Content Security Policies, File protections, etc) is a good methodology. Firstly, looking at OWASP ASVS for a checklist of things to implement. It will have some overall principles and guidelines, but the know how and more complete recommendations would be in the OWASP cheatsheets. A good example is about defense against SQL Injection where you have to sanitize user input, use parameterized queries, use Object-relational mapping (ORM), output encoding, etc as some that come to mind. Those are mentioned in ASVS, but how to do that would never be there. It requires some research, a bunch of reading and looking at least at OWASP cheatsheet where there is a specific SQL Injection Prevention Cheatsheet written for it.

For pentesters, it would be OWASP Top 10 as a start, then look at OWASP ASVS as a main overview checklist of where to poke at, then finally follow the OWASP WSTG for web security testing.

[rainit2006]

https://github.com/andifalk/ASVS-Testing

[rainit2006]

AVSV 2.1 password security

--》看看这里的cheat sheet 有助于理解ASVS 2.1的各个项目的要求 https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

• Password Length -- Minimum length of the passwords should be enforced by the application. Passwords shorter than 8 characters are considered to be weak (NIST SP800-63B). -- Maximum password length should be at least 64 characters to allow passphrases (NIST SP800-63B). Note that certain implementations of hashing algorithms may cause long password denial of service. NISTのガイドラインでは、パスワードの長さが強度に大きな影響を与えると指摘した。 最低でも12桁、複数のスペースを含めて最大で64桁の長さが推奨されている。 同じ条件であれば、長いほど良いだろう。

• Do not silently truncate passwords. The Password Storage Cheat Sheet provides further guidance on how to handle passwords that are longer than the maximum length.

• Allow usage of all characters including unicode and whitespace. There should be no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.

• Ensure credential rotation when a password leak occurs, or at the time of compromise identification.

• Include a password strength meter to help users create a more complex password and block common and previously breached passwords zxcvbn-ts library can be used for this purpose. Pwned Passwords is a service where passwords can be checked against previously breached passwords. You can host it yourself or use the API.

ASVS 2.1.11 Verify that "paste" functionality, browser password helpers, and

external password managers are permitted. --> Contrary to popular belief and prior standards, NIST does not suggest frequent password changes (example: every 60 or 90 days); individuals who are asked to change passwords frequently are much more likely to reuse an old password and merely append a number, letter, or special character to the end of it. Professional hackers know this trick and are savvy enough to predict minor changes. Plus, if a previous password has already been compromised, any derivations of that password, even if additional characters are added or modified, are more easily breached in the future.

NIST recommends that businesses enforce password expiration and password resets only when a known compromise has occurred, or every 365 days. The shift to longer password life is intended to encourage users to generate longer passwords that are harder to crack.

総務省から「パスワードの定期変更は不要」と発表 https://blog.trustlogin.com/articles/2018/20230518

[rainit2006]

[rainit2006]

-

[rainit2006]

why automated black-box testing may not be effective.

https://owasp.org/www-project-web-security-testing-guide/v42/2-Introduction/README#penetration-testing The following examples show why automated black-box testing may not be effective.

Example 1: Magic Parameters Imagine a simple web application that accepts a name-value pair of “magic” and then the value. For simplicity, the GET request may be: http://www.host/application?magic=value

To further simplify the example, the values in this case can only be ASCII characters a – z (upper or lowercase) and integers 0 – 9.

The designers of this application created an administrative backdoor during testing, but obfuscated it to prevent the casual observer from discovering it. By submitting the value sf8g7sfjdsurtsdieerwqredsgnfg8d (30 characters), the user will then be logged in and presented with an administrative screen with total control of the application. The HTTP request is now: http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d

Given that all of the other parameters were simple two- and three-characters fields, it is not possible to start guessing combinations at approximately 28 characters. A web application scanner will need to brute force (or guess) the entire key space of 30 characters. That is up to 30\^28 permutations, or trillions of HTTP requests. That is an electron in a digital haystack.

The code for this exemplar Magic Parameter check may look like the following:

public void doPost( HttpServletRequest request, HttpServletResponse response) { String magic = "sf8g7sfjdsurtsdieerwqredsgnfg8d"; boolean admin = magic.equals( request.getParameter("magic")); if (admin) doAdmin( request, response); else … // normal processing } By looking in the code, the vulnerability practically leaps off the page as a potential problem.

Example 2: Bad Cryptography Cryptography is widely used in web applications. Imagine that a developer decided to write a simple cryptography algorithm to sign a user in from site A to site B automatically. In their wisdom, the developer decides that if a user is logged into site A, then they will generate a key using an MD5 hash function that comprises: Hash { username : date }

When a user is passed to site B, they will send the key on the query string to site B in an HTTP redirect. Site B independently computes the hash, and compares it to the hash passed on the request. If they match, site B signs the user in as the user they claim to be.

As the scheme is explained the inadequacies can be worked out. Anyone that figures out the scheme (or is told how it works, or downloads the information from Bugtraq) can log in as any user. Manual inspection, such as a review or code inspection, would have uncovered this security issue quickly. A black-box web application scanner would not have uncovered the vulnerability. It would have seen a 128-bit hash that changed with each user, and by the nature of hash functions, did not change in any predictable way.

[rainit2006]

[フロントエンド]新規登録時のパスワードのルールをOWASP/ASVSに準じて実装してみよう

https://zenn.dev/uyas/articles/fefbdf54f24429

OWASPでの推奨されているパスワード強度はかなり強力です。GoogleやAppleなんかよりもかなり強い印象を受けました。 国内サービスならばIPAのガイドラインに準拠されてれば炎上することは多分ないかな？とか個人的に思ったりします。 あとこういったパスワードの要件はステークホルダーとのコミュニケーションをうまくやる必要があります。彼らからすれば、強力すぎるパスワード要件はユーザー離脱につながるのではないか、と危惧してしまうからですね。

[rainit2006]

OWASP ASVS 4.0 V2.4 からパスワードの保存を考える

https://qiita.com/koujimatsuda11/items/1f7909ea8b626554f556 _V2.4.1 パスワードを、オフライン攻撃に強い形式で保管すること。 オフライン攻撃に強い形式とは、承認済みの一方向鍵導出またはパスワードハッシュ関数を使用して、ハッシュ関数した形式です。その際には、パスワード、salt、コスト係数をパラメータとして指定します。

承認済みの一方向鍵導出またはパスワードハッシュ関数ですが、OWASP Cheat Sheet - Password storageを参考にすると、特に指定がない限り、Bcryptを使うように記載されております。NIST SP 800-63bでは、PBKDF2が推奨されてます。他には、Argon2などもありますが、Bcryptが使いやすいと思います。

V2.4.2 saltの長さが少なくとも３２ビットで、パスワードごとに固有のsalt値をもつことを確認します。

もしくは、OWASP Cheat Sheet - Password storageを参考にすると、少なくとも16文字以上で、16進数やBase64などの安全な文字セットにエンコードする。また、saltを生成するときは、CSPRNGを使いましょう。

ただし、モダンなアルゴリズム（BcryptやArgon2など）では、ソルトは自動で生成してくれます。その場合は、この章は意識しなくて良いです。

V2.4.3 PBKDF2を使っている場合、少なくとも１００，０００回以上反復する必要がある。

PBKDF2とは、Password-Based Key Derivation Function 2の略で、ソルトを用いたハッシュ化を指定した反復回数繰り返し行い求めます。

例えば、PHPならhash_pbkdf2という関数を使うことができます。

hash_pbkdf2 ( string $algo , string $password , string $salt , int $iterations [, int $length = 0 [, bool $raw_output = FALSE ]] ) : string $iterationsが反復回数です。

例）

$salt = bin2hex(random_bytes(16)); hash_pbkdf2('sha512', $password, $salt, 1000000); V2.4.4 bcryptを使っている場合、コストは少なくとも13にする必要がある。

例えば、PHPにはpassword_hashという、まさしくな関数があり、デフォルトではbcryptを使います。

password_hash ( string $password , int $algo [, array $options ] ) : string $algoにPASSWORD_BCRYPTを指定すると、bcryptを使います。PASSWORD_DEFAULTを使ってもbcryptを使いますが、PASSWORD_DEFAULTの場合は、フルリリースの際にアルゴリズムが変更されることがあります。アルゴリズムが変更されると当然ハッシュ値が変わります。なので、個人的には、PASSWORD_BCRYPTを指定しておいた方が良いと思ってます。

さらに、$optionsに連想配列の形式で、PASSWORD_BCRYPTの場合はsaltとcostを指定することができます。ちなみに、アルゴリズムが変われば、オプションも変わります。詳しくは、phpのドキュメントを見てください。

例）

$options = [ 'cost' => 13 ]; $hash = password_hash($password, PASSWORD_BCRYPT, $options); PHPのマニュアルによるとsaltを指定することは、推奨されてません。指定しないと自動saltを付与してくれますので、簡単なsaltを付与する心配がありません。 また、パスワードハッシュを作成する関数としては、hash_pbkdf2よりも、password_hashが推奨されています。

検証するときは、下記のようにします。

password_verify($password, $hash); V2.4.5 verifierだけが知っているsercretをsalt値として使って追加で鍵導出関数の反復が実行されることを確認する。（可能ならば）ソルト値は承認済み乱数生成器 [SP 800-90Ar1]を利用して生成されるべきであり，SP 800-131Aの最新版で指定されている最小のセキュリティ強度(NIST SP 800-63b公開時点で112ビット)を少なくとも備えるべきである。このsalt値は、パスワードハッシュとは別に保管する。

本要件は、俗にいうpepperのことではないかと思います。NIST SP 800-63bでは、secret saltと記載されてます。

$pepper = bin2hex(random_bytes(16)); $options = [ 'cost' => 13 ]; $password_hash = password_hash($password . $pepper, PASSWORD_BCRYPT, $options); また、OWASP Cheat Sheet - Password storageによると、パスワードハッシュを共通鍵暗号で暗号化して保管しても良いと記載されてます。上記の方法では、pepperが漏洩してしまった場合、pepperを変更してしまうと既存に保管しているパスワードハッシュが、変わってしまいます。長期間の運用には向いていません。

共通鍵暗号であれば、鍵の変更もしやすいですね。

$options = [ 'cost' => 13 ]; $password_hash = password_hash($password, PASSWORD_BCRYPT, $options);

$cipher = "aes-１２８-cbc"; $iv_len = openssl_cipher_iv_length($cipher); $iv = random_bytes($iv_len); $encrypt = openssl_encrypt($passwordhash, $cipher, $pepper, 0, $iv); pepperを付与してハッシュ化するよりは、共通鍵暗号で暗号化してしまう方が、長期的な保管に向いていると思います。