Multilingual findings

[noraj]

Ref. Ghostwriter #130

Another critical feature is having a Multilingual vulnerability database (findings library).

Pentesters from english-speaking countries are maybe the only ones that doesn't need this feature. But in countries you will need to have a findings library in both English and your native language and some countries also have 2, 3 or more official languages.

PwnDoc is a similar project with Multilingual findings enabled if you need an idea of architecture.

[TheTechromancer]

Pull requests are always welcome. If you're having difficulty saving text in a specific language, please include details of the issue.

[noraj]

It's more like having the same vulnerability in several version each linked together (eg. French + English) so when you update in one language you can directly modify on the other language too rather than having to create separate vulnerabilities and prefix them with FR- or EN- and enter two times the same resources or CVSS scores.

[noraj]

Description and why

Pentesters from english-speaking countries are maybe the only ones that doesn't need this feature.

But in other countries you will need to have a findings library in both English and your native language and some countries also have 2, 3 or more official languages.

Very often, in non-english speaking countries, you need to write pentest report in several languages so having a Multilingual vulnerability database is critical for them.

Implementation

It needs a change of the SQL tables.

Instead of having something like

vulns:
  - vuln1:
    title: xxx
    description: xxx
    cvss: xxx
  - vulns2
    title: xxx
    description: xxx
    cvss: xxx

You would have

vulns:
  - vuln1:
    cvss: xxx
    lang:
      - en:
        title: xxx
        description: xxx
      - fr
        title: xxx
        description: xxx
  - vulns2
    cvss: xxx
    lang:
      - en:
        title: xxx
        description: xxx
      - fr
        title: xxx
        description: xxx

Workaround

A common workaround and why it is bad.

A common bad workaround is to add a lang prefix in the title of the vulnerability.

Like [EN] SQL injection and [FR] Injection SQL.

This is terrible for multiple reasons.

When having multiple languages, only field containing text or sentences need to be translated, all other fields like the CVSS vector, CVE, vulnerability ID, etc. don't need to be translated and can be stored only once in the database.

Also when you edit the vuln in one language if they are not linked you often forgot to update the vuln in other other languages too.

It also possible to filter by language.

And for report you can't ask for vuln.fr.description or vuln.en.description depending on your french or english template.

Demo

It's a big long and hard to explain in details. I invite your to deploy and test PwnDoc (https://github.com/pwndoc/pwndoc) which is the only pentest report platform I know to have a mutli-lang vuln DB. It's easy to deploy with docker-compose so it won't take long to try it.

[chegeanthony]

Awesome