-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multilingual findings #8
Comments
Yeah thank's, we already added more languages in our dev branch: English, German, Spanish, French, Portuguese, Dutch, Italian, Danish, Polish, Ukrainian, Romanian, Slovak, Slovenian, Greek, Swedish If anyone else need additional languages, an issue can be opened. We discussed the feature of multilingual finding templates in the past and for the moment decided to go with having separate finding templates for different languages (as in your screenshot under "Workaround"). However, in our own setup it is currently only:
Because most of the fields have to be maintained separately anyway, we decided keep the templates separately for the moment. |
Maintaining the CVSS, references and tags twice, while annoying, is not the biggest issue. When the different language versions are not linked, some issues will arise over time:
The earlier this feature is implemented, the better and easier. Because it requires a structural change of the code and the database schema, it means breaking changes. So the more features and more complex the platform becomes, the harder it will be to bring this feature and the more breaks it will induce. |
Absolute fair points :)
Every design has a language too. If you create a project, it inherits the language from the design. |
In the template list you can filter for the language code in the search field. Internally we use Postgres full text search for template title, tags and language field. Since the language is stored as language code in the DB, you can only search for the code ("en", "de") and not the display label ("English", "German"). We have not added a language filter to the search UI yet. |
We discussed how this feature could be implemented. Finding templates of different languages would be linked to each other.
There need to be a list of fields that should be synchronized between linked templates. This can be by default:
This list of fields could be modified, either via the Django admin interface (=database) or via environment variables. This means that this is an installation-wide setting and does not allow granular control. If a field that should be synced in an existing template is linked and contains different data (e.g. a different CVSS score), this field will be overwritten by the template that is currently open. If a finding template is opened and a field that should be synced is updated, this update process overwrites values in linked finding templates (last save wins). When findings are created from templates, the user has to choose which language to use. The field contents of the selected language are then copied into the finding. |
I didn't dig too much in how this could be implemented. But I know PwnDoc has managed to get multilingual finding as well as custom fields. But rather than the idea of having two vulnerabilities and linking them up and synching them up, I had more the idea of one vulnerability with an unlimited amount of lang properties and having all variables fields depending on it and the constant fields across langs such as cvss or tags being at the root level and not under the lang scope as shown in the implementation idea of my original message #8 (comment). TL;DR: sounds better that the lang dependant fiels would be properties of a unique vulnerability rather than synching several vulnerabilities. There won't be sync issues if there is no sync :) I don't see the issue for custom fields either in theory (I didn't take a look at the actual db schema), if custom fields formats are defined in a table and have a unique id, the unique id of a custom field can be attached to a finding template, and the value stored in a mapping table, this way custom fields could be attached to a finding template by default on creation by a field could be removed or added on an unitary basis afterward. |
This would also be a solution, but would be more complex in implementation. It might also be more difficult to keep the interface clean for users who don't need that feature. |
We once again discussed internally. I maybe misunderstood your suggestion. GUIA finding template can have multiple tabs. A new tab can created for a new language. If a new language is added to an existing finding template, by default, all field values are synced to the new tab. All fields are then read-only (greyed out) and have button "Translate". If this button is clicked, the field gets enabled and the content can be replaced by the user. Users can dynamically choose which fields to sync, even per language in one template. DatabaseFields of finding templates are internally stored in a JSON structure. Finding templates will have a "parent" template. If a parent template exists, the template is a translation. Translations will have no JSON fields by default. If a field is not present in the JSON structure, this means that its value will be taken from the parent template. As soon as the user clicks "Translate", the field name is added to the JSON, which means that the field's value is controlled by the translated finding template (this way, fields can also be empty). This could also mean that "parent" templates can be of any language. We might want to discuss if this is desirable. |
In implementation and will be released in July. |
This is super good news 🥳 I can't wait to test this and make a video about it. |
Multilingual templates are implemented in https://github.com/Syslifters/sysreptor/releases/tag/0.110 We implemented them similar as described in #8 (comment): Templates have a main language and multiple translations. Every translation inherits its fields from the main template and can override language specific fields. See the template docs for a more detailed description. |
Description and why
Pentesters from english-speaking countries are maybe the only ones that don't need this feature.
But in other countries you will need to have a finding 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
You would have
Workaround
A common bad workaround is to add a lang prefix in the title of the vulnerability.
Like
[EN] SQL injection
and[FR] Injection SQL
.Or here in SysReptor to create the same vulnerability two times with a different value in language field.
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 languages too.
It would also be 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.
Here is what I mean in video, I'm talking about multilingual finding template (the data stored, the db schema, etc.) not the translation of the label on the WebUI (I18N):
pwndoc-2023-01-04_19.47.40.mp4
The text was updated successfully, but these errors were encountered: