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
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