Report a vulnerability
If you find a security problem in Lasbolt, tell the maintainers so that they can fix it. Please do not make it public first.
How to report
Open a confidential issue in the project on GitLab:
https://gitlab.com/lasbolt/lasbolt
Sign in to GitLab
You need a GitLab account to open an issue.
Make a new issue
Go to Issues and click New issue.
Mark it confidential
Tick the box that makes the issue confidential. The wording of the box can change. Check that the issue shows the confidential mark before you submit it.
Describe the problem
Write a short title that does not give away the details. Put the details in the description. See the list below.
What to include
- The part that has the problem: the server, the web app, the CLI, an app or an extension. Give the version or the commit. There is no release yet, so the commit is the version.
- What you did, step by step, so that someone else can repeat it.
- What you expected, and what happened.
- What an attacker can do with it, and what the attacker needs (network access, an account, a stolen device, a hacked server).
- A proof of concept, if you have one. Keep it small.
- Your setup: operating system, browser, and the server flags that matter.
- Whether you want credit when the problem is fixed, and the name to use.
Do not include real secrets, real user data or the data of other people. Use a test server and test accounts.
What is in scope
The threat model says what Lasbolt defends against and what it does not. These are in scope:
- A way to read E2E data, a master password or an encryption key without the right keys.
- A way for the server, or a person on the network, to make a client accept forged E2E data.
- A way past the checks of roles, scopes, approvals or the membership logs.
- A flaw in the cryptography, or in how the code uses it.
- A way to run code in the web app of another user (for example XSS).
- A flaw that gives a person access to the account of another person.
These are known limits, and a report about them alone is not a new finding: the web app has no E2E promise against an active attacker on the server, server-readable data is readable by the operator, and a device that already read a secret keeps a copy.
What to expect
- The maintainers read each confidential issue.
- They tell you if they can repeat the problem, and they work on a fix.
- They ask you to keep the details private until a fix is out.
- Lasbolt is a small project in development. There is no fixed response time and no bug bounty.
Test only what you own
Test against your own server and your own accounts. Do not test the server or the data of another person without written permission. Do not use a method that can destroy data or stop a service.