Skip to content
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

Add text pastebin #19

Open
berthubert opened this issue Dec 21, 2023 · 3 comments
Open

Add text pastebin #19

berthubert opened this issue Dec 21, 2023 · 3 comments

Comments

@berthubert
Copy link
Owner

This is actually nearly there, just a caption without an image.
Might ponder some javascript powered pretty printing later. Or not.

@wandernauta
Copy link

As a workaround until this feature is officially added, Trifecta can also be used as a plain-text pastebin by including a carriage return in the claimed MIME type, like so:

curl -H "Cookie: session=..." -F $'[email protected];type=image/\r' http://localhost:3456/upload 

This submits paste.txt as the "image", without a caption (so the inverse of the above). To paste stdin, replace @paste.txt with @-.

Trifecta will respond with the image ID; the link to share would be http://localhost:3456/i/$id which serves the pasted snippet with the text/plain MIME type.

@berthubert
Copy link
Owner Author

joking aside, do you think this is a bug here or over at cpp-httplib? that it doesn't escape mime-type?

@wandernauta
Copy link

I had expected Trifecta to refuse this on upload.

From the blog posts, I understand that the app does not want to use an image library to validate that the images it receives are indeed valid images in the claimed format, as users might (accidentally?) upload files that exploit vulnerabilities in such a library.

However, the app could still have a hard-coded allowlist of the claimed content types that it is willing to accept and serve (so exactly image/jpeg or exactly image/png or exactly image/webp or...). With such an allowlist in place, the Content-Type header is still controlled by the user, but at least it is one of the expected values; adding a X-Content-Type-Options: nosniff header as suggested in the README would then prevent browsers from second-guessing that header.

One could argue that cpp-httplib should signal error if this happens, but one could also argue that it's the caller's responsibility to not attempt calling this with strings containing carriage return characters. I do not know HTTP well enough to say whether there would be a way for httplib to escape a carriage return here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants