warning!
From the tests i have done, there are many vulnerabilities on this website, there are also a lot of bugs. Example: when posting something, if you spam click `post` it will create a post for every time you click the button, there should be an implementation to limit the time between posts and to make the button a one time click. (THIS BUG MAKES THE SITE LAG!). its also a pain to delete all of the posts if you accidentally do so as the site refreshes but will still lag and there is a small chance that the post will not be deleted. There is also a password vulnerability… maybe don’t have the user’s passwords get stored as a plain document.
THERE ARE VULNERABILITIES IN THE REPO!; Yes, even tho the repo is the legacy site and isn’t used anymore it is still good to state the vulnerabilities on the repo as people might use the template to make their own site like this and wont know of the vulnerabilities in the code:
List of the vulnerabilities on the repo: SQL Injection, Cross-Site Scripting (XSS), Insecure Direct Object Reference (IDOR), Lack of Input Validation, Insecure, Outdated Dependencies, Lack of Error Handling, Insecure Session Managemen, Storage of Sensitive Data(user and password information: Insecure Password Storage, Weak Password Hashing, Lack of Password Salting, Insecure Password Verification, Missing Password Complexity Requirements, insecure Password Reset Token Generation, insecure Password Storage in Sessions), Lack of Secure Communication… sry <3
comments
what kind of bullshit
The
Data(user
looks highly copy pasted.
i genuinely found this funny
This Man Is 100% A Witch
burn him
Twitter Level Misinformation
wasteof community notes when
The legacy repo doesnt even work due to monkjs being deprecated and mongodb changing some stuff
Also wasteof uses mongodb… how is it vulnerable to sql injections???
“yeah I spend my time on the Internet spreading misinformation, what's wrong with that?”
jeffalo is the wrong person you could tell that their site has a security vuln lmaooo maybe one or two mightve been there in the previous versions but beta/alpha and even prod are all maintained with top notch security
I assume what you mean by “maybe don’t have the user’s passwords get stored as a plain document” is the env setup script for database credentials and URL. Assuming that’s what you saw, (and it’s very very clearly not what it is), you might need to take a few programming classes before posting inflammatory content like this.
i do cybersecurity work (in the form of bug bounty) for companies including google, facebook and the scratch foundation, so i think i have an okay idea of what i’m doing. i’m going to respond to each of these supposed issues.
firstly yes, the handling for clicking buttons assumes perfect internet which is not ideal. but this is not a security vulnerability at all. it’s a UX issue.
i’m not sure what you mean by storing passwords in a plain document. wasteof uses bcrypt hashing that’s industry standard.
next, the legacy website hasn’t been touched in over 4 years. the codebase isn’t great but it’s not pretending to be. i don’t think there’s any expectation for it to have eg. up to date dependencies and it’s also not vulnerable to the issues you mention…
SQL Injection
wasteof uses a non relational database, so it’s not vulnerable to SQL injection. yes NoSQL injection also exists, but it’s a different issue which is far less dangerous. i can’t speak to the legacy codebase but the new codebase is careful about the types of data users submit. i don’t think this is an issue.
Cross-Site Scripting (XSS)
wasteof is almost certainly not vulnerable to XSS.
Insecure Direct Object Reference (IDOR)
where? if you’re looking at the old codebase i don’t even think there’s many areas that reference objects directly. again, the old site is unsupported so please let me know if you find any issues in the current version of the site
Lack of Input Validation
this is very unspecific. where?
Insecure, Outdated Dependencies
again, the open source code is from 2020 and has not been updated since. it’s obviously going to have outdated dependencies…
Lack of Error Handling
lack of error handling is rarely a security issue.
Insecure Session Managemen
you’re going to need to be more specific about what this means. yes the tokens generated in the old open source code are not cryptographically secure. that’s not an issue anymore.
Storage of Sensitive Data(user and password information: Insecure Password Storage
wasteof has never stored passwords, and only the minimum amount of user information is ever stored. the most sensitive thing stored is email adderesses and that;’s optional too.
Weak Password Hashing
bcrypt is not weak
Lack of Password Salting
bcrypt is salted by design
Insecure Password Verification
how? timing attacks?
Missing Password Complexity Requirements
we let users decide how they want to secure their accounts. you can even have no password if you wish. this isn’t a vulnerability.
insecure Password Reset Token Generation
in the current codebase they’re cryptographically secure. in the old codebase there aren’t even password reset tokens.
insecure Password Storage in Sessions)
wasteof doesn’t store passwords in sessions
Lack of Secure Communication
?
this kind of post serves no purpose other than to spread misinformation and fear. if you find real security issues, report them using my contact details on the /security.txt page rather than sharing them publicly. this whole post is wrong on so many levels that you’re really just making real security work look bad…
good to know! /gen
There is also a password vulnerability… maybe don’t have the user’s passwords get stored as a plain document.
As someone who has access to the source code, I can confirm this is not true. Account passwords are hashed and salted before being stored in the database using bcrypt (specifically this implementation: https://www.npmjs.com/package/bcrypt).
There is also ratelimits for posting and pretty much every action on the site, maybe have a look at the response headers ;)
I might be stupid but what the frick is “password salting” 
im sorry to tell you but you can’t SQL inject a mongodb database
well, you can do a "NoSQL injection" or a "MongoDB injection." which are practically the same thing as a “SQL injection“… also, that list is for the vulnerabilities in the repo <3
It’s much trickier to pull off, the web application would have to accept a JSON object in a place where other MongoDB operators can be used to find/update other documents you don’t have access to. As a cyber-security expert as you claim to be, maybe you should responsibly disclose vulnerabilities before making them public? Anyway, if you find any, please reach out using one of the methods on https://wasteof.money/security.txt
ALSO! usernames and passwords are easy to bruteforce as there are no/weak authentication methods.