Brainstorming how to proceed with this repo

[clintgibler]

What would be a good way to go about fleshing out this repo?

A few potential ways come to mind, we could:

1. Choose a given area (e.g. XSS) and try to write rules giving coverage for most popular languages and frameworks.
   • Pro: Regardless of what language/framework you're using, you can start using this repo and get some value.
   • Con: Will be a large amount of upfront effort for each category, and anyone using this repo (at first) only gets a minimal value, as it'll only give one or a small handful of things.
2. Choose one language/framework and try to get at least initial coverage on most categories.
   • Pro: This is a more feasible amount of work to do for each category, will give us some early feedback on if there are certain categories that are easier/harder to support, anyone using the language/framework we're targeting will find it really useful, could provide a blueprint for community contributions for other languages and frameworks.
   • Con: If you/your company don't use the initial language/framework we target, this repo will have little to no immediate value to you as an AppSec engineer.
3. Other options?

[clintgibler]

@hazanasec Any thoughts?

I don't feel super strongly about it to be honest, but I might slightly lead towards the second if I had to pick.

[hazanasec]

Well put together thoughts, and I agree it's a tough sell either way. Honestly my initial thinking when writing this was tackling v5.3 Output encoding and Injection Prevention Requirements first as this covers the most widely seen vulnerabilities and with lots of code snippets/secure libraries in lots of languages and frameworks available. I guess if you do that it would take you down a path of covering off a given requirement (can prioritise by most common?) with the info available in the cheat sheets and known secure defaults. However that would still bring you to the cons you raised in option 1, and I agree it would be nice if an engineer picked this up and instantly have decent coverage and value. In that case I also slightly lean towards option 2 also, as would be really powerful to have that coverage, and accept it will take some time to get together the other languages/frameworks. Do you have any initial preference?

[clintgibler]

Hm that's a good point, focusing on what most people care about / what has the most available code snippets seems like a good place to start 👍

I could imagine, eventually, each section or vulnerability class starting with some header table like the following to give people a quick understanding of the current state of the rule set and where they could help.

Language	Framework	Coverage
Java	Spring	✅
Python	Django	✅
Python	Flask	🚧
Ruby	Rails	❌

Thoughts on focusing on: "you're doing something that's potentially dangerous / opting out of security controls" vs "this is a vulnerability"?

I feel like the spirit of ASVS may be more the former, but I'm not sure. In that case, we could flag things like innerHTML even if we're not necessarily sure that user input flows there.

Maybe start with XSS (then SQLi, shell exec) based on guidance from OWASP Cheat Sheets?

[hazanasec]

Yeah that heading looks really good! I imagined the rules to be something like: Check to see if dangerous code is there and not the secure code. e.g.

rules:
- id: DOMPurify
  patterns:
    - pattern-not-inside: |
        var $CLEAN = DOMPurify.sanitize(...);
        ...
        document.getElementById(...).innerHTML = "..." + $CLEAN;
    - pattern: |
        document.getElementById(...).innerHTML = ...
    
  message: No DOMPurify when using innerHTML

In this example the requirement of Output encoding is met, and the control of using DOMPurify when using innerHTML is evidenced as there's nothing triggered. That would require the known insecure code to begin with though, so there might be some edge cases, but seems like a good start

[hazanasec]

or I guess you could do it the other way around, alert if it's good :)

[clintgibler]

Some notes per a chat with @hazanasec, @danielcuthbert and @clintgibler .

Discussions

There are a few angles this repo could take on rules it includes:

1. Identifying vulnerabilities - this is definitely (or very likely) exploitable
2. This is a vulnerable coding pattern that doesn’t adhere to best practices (e.g. violations of OWASP Cheat Sheets, opting out of security protections like output encoding)
3. Detecting use of security controls (and where they’re applied/not applied)

All of these seem useful, and will likely play a role in this repo.

Helping users meet compliance requirements could also be a valuable outcome of this project.

• Upon realizing that we were discussing compliance in a positive light, we looked back on our choices and tried to pinpoint the time where it all went disastrously wrong.

Current Focus

For now let's focus on 1) of the above options - choose a given area and get initial coverage for major languages/frameworks.

Major languages/frameworks under consideration:

• Java - Spring
• Ruby - Rails
• Python - Flask, Django
• JavaScript - ExpressJS, React/Angular/VueJS
• Golang - Gorilla, built-in HTTP, ...

For now, let's focus on Java (enterprise) Spring, Python (companies in the middle) Flask/Django, and JavaScript for frontend.

To provide value to ASVS users as soon as possible, we'll focus on common community pain points. For example, focus on the top vulnerability classes in the OWASP Top 10.

Initial target vulnerability classes:

• Injection (XSS / output encoding, SQL injection)
• Deserialization
• XXE
• Sensitive data exposure
• Broken auth

Logistics

We'll break out specific vulnerability classes (e.g. XSS, SQLi) into their own GitHub issues to make it clear who's working on what, what's left to do, deduplicate efforts, etc.

[clintgibler]

Other useful resources:

• OWASP Security Knowledge Framework (SKF) and labs

[hazanasec]

Thanks for taking the notes Clint! One thing we also need to agree on is how to structure the repo and the how to layout the message presented from the rule. I just did /v6/java/6.2.5.yaml as worked in that moment but I'm sure it's not the best way, I also laid out the message like:

  message: |
    V6 Stored Cryptography Verification Requirements
    6.2.5 Insecure Algorithm
    https://github.com/OWASP/ASVS/blob/master/4.0/en/0x14-V6-Cryptography.md#v62-algorithms
   ...

So overarching verification and title since its short, then added the specific requirement and summarised it, as it's a bit too long for a message, then the link to ASVS. Again probably not the best way to do it :)

^ I'll create an issue :)

[moneeraden]

i am interesting to use rules-owasp-asvs but is seems still not implemented(no rules), if it is ready please guide me where i can get them(rules) if no please is there any plan when it is going to be ready?

[clintgibler]

Hey @moneeraden! Thanks for being interested in this. We ended up adding ASVS metadata to a number of existing rules in the semgrep-rules repo. Here are some examples.

You can also search the Registry for rules that you might find useful: https://semgrep.dev/r.

[danielcuthbert]

If there is enough public interest, maybe I could make a dedicated ASVS_V1 ruleset that adds as many as @clintgibler mentioned above.

[moneeraden]

thank you guys for your support, we are using Sonarqube with Find-Sec-Bugs and profile, let's try semgrep, thanks a lot

[clintgibler]

Great, hope you like Semgrep! If you have any questions about the rules, feel free to create an issue on semgrep-rules, or on semgrep if it's about Semgrep itself.

Also, we have a community Slack where people are super active asking and answering questions. If you writing a rule and want help, that's a good place to ask 😃

Good luck!