2c4dd2594c
Fixes #1712 Disclosure: Coded with help of Copiot. (description wrtten by me) So this does indeed loosen the encoding a bit. However, IMHO, it was neither better before though. You could always bypass the encoding for `args{0]` when you just include `<a` (or the other tag) somewhere or so. **One important notice:** This was (due to the exceptions before and afterwards) valid before and also now: Translators **could** (and can) if they have malicious intent, inject/do "XSS attacks". Thus, translations PRs (also from Crowdin) should be reviewed for wild HTML code inside translations. I suppose this is easy to fix, but anyway a valid risk. But IMHO, we should teat the JSON files being part of our source code as a "trusted source". In the end, such an attak is basicaly just ends up being injecting malicious code. I hope such contributors would be detected. References I explicitly checked again to not introduce an XSS here: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html and the PHP doc for he HTML encoding. I feel the safter way obviously would be encoding the _whole_ string _after_ translation (just like you should apply DOMPurify after everything), but as explained it was not done before and would break compatibility. Also, I looked through the sources and I see no risk described by doing it only for the "dangerous" "untrusted" inputs. Only here is a notice that `%s` shall not be used in some contexts, for example to define a tag: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#dangerous-contexts (obviously in such a case, attacks may be possible even with encoding; but again; this is nothing new) The basic "problem" of it all is: We want HTML to be translated/be usable in our translation. If we'd get rid of that, we would get for sure rid of all such XSS attack possibilities. But that woud be a bigger refactoring, so IMHO, this here is fine for a fix for the issue at hand. Ah another point: I think the `is_int` check is harmless, but it's also kinda useless. Maybe it is some kind of obscure performance optimisation. (Yeah ints have nothing to encode as they have nothing that could be used for XSS, but they could also just be passed through that function.) |
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| .vscode | ||
| bin | ||
| cfg | ||
| css | ||
| doc | ||
| i18n | ||
| img | ||
| js | ||
| lib | ||
| tpl | ||
| tst | ||
| vendor | ||
| .codeclimate.yml | ||
| .csslintrc | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .htaccess.disabled | ||
| .jshintrc | ||
| .nsprc | ||
| .php_cs | ||
| .scrutinizer.yml | ||
| .styleci.yml | ||
| BADGES.md | ||
| browserconfig.xml | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| composer.json | ||
| composer.lock | ||
| CREDITS.md | ||
| crowdin.yml | ||
| index.php | ||
| LICENSE.md | ||
| Makefile | ||
| manifest.json | ||
| Procfile | ||
| README.md | ||
| robots.txt | ||
| SECURITY.md | ||
Current version: 2.0.3
PrivateBin is a minimalist, open source online pastebin where the server has zero knowledge of stored data.
Data is encrypted and decrypted in the browser using 256bit AES in Galois Counter mode.
This is a fork of ZeroBin, originally developed by Sébastien Sauvage. PrivateBin was refactored to allow easier and cleaner extensions and has many additional features.
What PrivateBin provides
-
As a server administrator you don't have to worry if your users post content that is considered illegal in your country. You have plausible deniability of any of the pastes content. If requested or enforced, you can delete any paste from your system.
-
Pastebin-like system to store text documents, code samples, etc.
-
Encryption of data sent to server.
-
Possibility to set a password which is required to read the paste. It further protects a paste and prevents people stumbling upon your paste's link from being able to read it without the password.
What it doesn't provide
-
As a user you have to trust the server administrator not to inject any malicious code. For security, a PrivateBin installation has to be used over HTTPS! Otherwise you would also have to trust your internet provider, and any jurisdiction the traffic passes through. Additionally the instance should be secured by HSTS. It can use traditional certificate authorities and/or use a DNSSEC protected DANE record.
-
The "key" used to encrypt the paste is part of the URL. If you publicly post the URL of a paste that is not password-protected, anyone can read it. Use a password if you want your paste to remain private. In that case, make sure to use a strong password and share it privately and end-to-end-encrypted.
-
A server admin can be forced to hand over access logs to the authorities. PrivateBin encrypts your text and the discussion contents, but who accessed a paste (first) might still be disclosed via access logs.
-
In case of a server breach your data is secure as it is only stored encrypted on the server. However, the server could be abused or the server admin could be legally forced into sending malicious code to their users, which logs the decryption key and sends it to a server when a user accesses a paste. Therefore, do not access any PrivateBin instance if you think it has been compromised. As long as no user accesses this instance with a previously generated URL, the content can't be decrypted.
Options
Some features are optional and can be enabled or disabled in the configuration file:
-
Password protection
-
Discussions, anonymous or with nicknames and IP based identicons or vizhashes
-
Expiration times, including a "forever" and "burn after reading" option
-
Markdown format support for HTML formatted pastes, including preview function
-
Syntax highlighting for source code using prettify.js, including 4 prettify themes
-
File upload support, image, media and PDF preview (disabled by default, size limit adjustable)
-
Templates: By default there are bootstrap5, bootstrap CSS and darkstrap to choose from and it is easy to adapt these to your own websites layout or create your own.
-
Translation system and automatic browser language detection (if enabled in browser)
-
Language selection (disabled by default, as it uses a session cookie)
-
QR code for paste URLs, to easily transfer them over to mobile devices
Further resources
Run into any issues? Have ideas for further developments? Please report them!