My local ISP was saving their database backups in an unprotected folder which was literally domain.com/backups

When I downloaded it contained thousands of their clients data.

Reported it to them and got 2 years of internet/tv services for free.

They wanted to hire me but I was still studying in my first year of uni in another city.

There was a time in Windows 95, where during login, you could just press cancel and you were logged in without the need of a password.

Colleagues sharing passwords.That was a big fat NO when I was a sysadmin - and for a good reason. But now, since I'm closer to development, it feels like no one really cares about the passwords. If I tell my colleague I'll take 10 minutes more because I can't log in, he OFFERS me his credentials. And sends them over saying "in case you need it". [the next day the same colleague was complaining his account is locked out. Oh, wonders! How on Earth...!]

But seriously, password sharing is a serious problem. I would fire the person on spot if I caught him sharing his credentials! This is the 8th deadly sin! IDC if they are for non-prod. Most people reuse their passwords in multiple systems, and even non-prod envs can bring the prod down! Or worse - install a trojan.

Oh you'll love this. A master password to access any user.

Something like:
const masterpassword = <dayABCyearXYZ>
if (password == dbpassword || password == masterpassword) { // allow access }

The best part is this code is available to our clients. They can literally see how this "master password" is generated. And they don't want me to remove it because it's being used by testers.

When /admin is protected by nothing more then:

var admin = false;
If(!admin){
setTimeout( function(){
window.location.href = "/home"
}, 1000);
}

My favourite to ever stumble on and dred going through hundreds of files to actually fix😣

password.trim()

Email and password passed as GET parameters, obviously

I've already ranted about this before, so I will summarize, but users passwords would be placed in plain text at the bottom of a webpage if you interacted with the page in a certain way. This page did not require a login, so user passwords were basically public. Gg.

Our entire application is a security bug

Not a software bug but an organisational bug...

Employees holding the door to other people so they can come into a secured building without using their identity badges.

I look like an asshole everytime I refuse to let people I don't know in because most people let them in...

Apple released an update for MacOS that allowed you to type "root" as the username and "" as the password, hit the Authenticate button twice (the first time erroring out) and then have complete root permissions to the system.

They fixed it pretty much immediately, but then a later patch regressed it again.

password: <company name>!

(Notice the exclamation mark. It's got symbols now right?)

If you discount all the usual sql injections the most blatant was not our but a system one customer switched to after complaining over cost.

The new system was a bit more bare bones featurewize but the real gem was the profile page for their customers.

The only security was an id param pointing to the users primary key, which was an auto incrementing integer :)

And not only could you access all customer data but you could change it to.

But since the new system was built by their it chief’s son we realized it was not much we could do.

High school. The teacher in IT made some learning platform for the school in PHP. There was a module where you could upload files.

You could just upload a PHP file, and get it to run by accessing it through a direct link.

Anyone remembers that in windows XP you coud set any exe as screen saver, and it would run on time, even before you log into any user, as a default system user with administrator privileges?

Thank God the week 233 rants are over - was getting sick of elitist internet losers.

The worst security bug I saw was when I first started work as a dev in Angular almost year ago. Despite the code being a couple of years old, the links to the data on firebase had 0 rules concerning user access, all data basically publicly available, the API keys were uploaded on GitHub, and even the auth guard didn't work. A proper mess that still gives me the night spooks to this day.

School's windows installations had the UAC set to lowest.
Anyone could install malware or fiddle with important settings.

Oh by the way, the same school who's gData found it funny to go through my USB drive and delete all executables and all my code because it was "possibly malicious".

Started installing random crap and messing with people in retaliation.
Was fun.
Until I got caught.
Good thing I compiled a list of security flaws earlier on.

From that day on, everytime I messed up, I sold them two security vulnerabilites to let me off the hook.
These included access to all kinds of drives in the windows network, accessing other PCs desktop, literally uninstalling random printers from the network etc..

Fun time.

Just yesterday I found out that a multimillion euro corporation still uses Http (not https) rest end points, with the only basic authentication mechanism...
It only provides data to sales and inventory management, so I'm guessing it's not f*ing critical enough x.x

Give a review other than changing a variable name 😡

I have a few of these so I'll do a series.
(1 of 3) Public privates

We had a content manager that created a content type called "news item" on a Drupal site. There where two file fields on there. One called "attachments" and the other called "private attachments". The "private attachments" are only for members to see and may contain sensitive data. It was set to go trough Drupals security (instead of being directly hosted by the webserver) but because the permissions on the news items type where completely public everybody had access. So basically it was a slow public file field.

This might be attibuted to ow well Drupal is confusing. Howerver weeks earlier that same CM created a "private article". This actually had permissions on the content type correctly but had a file field that was set to public. So when a member posted the URL to a sensitive file trough unsafe means it got indexed by google and for all to read. When that happend I explained in detail how the system worked and documented it. It was even a website checklist item.

We had two very embarrassing data leaks :-(

Not really a bug so much as ridiculously poor practice, about 15 years ago I was working for a car park company on their booking engine. In the sql server dB, there was a table called CreditCard, easy to guess what was in there!

disableSslVerification()
download("https://...", "update.exe")
execute("update.exe")

In a license reporting software, took them 1,5 years to fix!
If we hadn't specifically requested how to run this software with lesser privileged accounts, it would have had access to all our customer's machines.

Another rant about my school: the default password system.
Each student's username is FirstnameLastname, and the same applies to teachers. The passwords assigned are <First initial><Last initial> for students, and the same for teachers with "teacher" appended to the end. As students, we figured out this system pretty quickly, and we were able to log into the computer system as any teacher who we knew had requested an account. (Teacher accounts had unfiltered Internet access, student accounts did not).
I now teach in this school, where they recently got Google Classrooms accounts for each teacher during Covid. The accounts use the same naming/password scheme! I somehow doubt the teachers replace their passwords, so any student clever enough to figure out the system can log into their Google for Education account.

The school I work at was supposed to implement a new attendance-tracking system. It required teachers to log in to the system using the laptop in each classroom, and mark the attendance.
Oh, and by the way, the same system would be used to track grades.
How would they be sure nobody could get into the system? One student from each class would be chosen to be sure the system is logged out when the teacher leaves!
Thank God they haven't started using this system yet.

This is the last part of the series
(3 of 3) Credentials everywhere; like literally.

I worked for a company that made an authentication system. In a way it was ahead of it's time as it was an attempt at single sign on before we had industry standards but it was not something that had not been done before.

This security system targeted 3rd party websites. Here is where it went wrong. There was a "save" implementation where users where redirected to the authentication system and back.

However for fear of being to hard to implement they made a second method that simply required the third party site to put up a login form on their site and push the input on to the endpoint of the authentication system. This method was provided with sample code and the only solution that was ever pushed.

So users where trained to leave their credentials wherever they saw the products logo; awesome candidates for phishing. Most of the sites didn't have TLS/SSL. And the system stored the password as pain text right next to the email and birth date making the incompetence complete.

The reason for plain text password was so people could recover there password. Like just call the company convincingly frustrated and you can get them to send you the password.

About a decade ago there was a torrent site for audiobooks audiobookbay I think?, if you forgot your password to your username they would literally just give you a new password on the next page. Naturally being a 1337H4X0R teenager I found the username of one of the admins and got into their account on the site. I don't know if they ever fixed that but that was a serious wtf moment.

Edit: just checked this flaw has not been patched.

Storing DB credentials in a repo that were encrypted using functions... that are in the same repo (both encrypt and decrypt!)...

if (password.contains(input)) authorize()

I have quite a few of these so I'm doing a series.
(2 of 3) Flexi Lexi

A backend developer was tired of building data for the templates. So he created a macro/filter for our in house template lexer. This filter allowed the web designers (didn't really call them frond end devs yet back then) could just at an SQL statement in the templates.

The macro had no safe argument parsing and the designers knew basic SQL but did not know about SQL Injection and used string concatination to insert all kinds of user and request data in the queries.
Two months after this novel feature was introduced we had SQL injections all over the place when some piece of input was missing but worse the whole product was riddled with SQLi vulnerabilities.

Not a bug, but a government web system to have control over financial expenses from a region in my country has the login access admin:admin.
Somehow they manage to keep it like that for years with no problem.

Novell networking software. Like, all of it. Glad it’s gone.

Oh boy I got a few. I could tell you stories about very stupid xss vectors like tracking IDs that get properly sanitized when they come through the url but as soon as you go to the next page and the backend returns them they are trusted and put into the Dom unsanitized or an error page for a wrong token / transaction id combo that accidentally set the same auth cookie as the valid combination but I guess the title "dumbest" would go to another one, if only for the management response to it.

Without being to precise let's just say our website contained a service to send a formally correct email or fax to your provider to cancel your mobile contract, nice thing really. You put in all your personal information and then you could hit a button to send your cancelation and get redirected to a page that also allows you to download a pdf with the sent cancelation (including all your personal data). That page was secured by a cancelation id and a (totally save) 16 characters long security token.

Now, a few months ago I tested a small change on the cancelation service and noticed a rather interesting detail : The same email always results in the same (totally save) security token...
So I tried again and sure, the token seemed to be generated from the email, well so much about "totally save". Of course this was a minor problem since our cancelation ids were strong uuids that would be incredibly hard to brute force, right? Well of course they weren't, they counted up. So at that point you could take an email, send a cancelation, get the token and just count down from your id until you hit a 200 and download the pdf with all that juicy user data, nice.

Well, of course now I raised a critical ticket and the issue was fixed as soon as possible, right?
Of course not. Well I raised the ticket, I made it critical and personally went to the ceo to make sure its prioritized. The next day I get an email from jira that the issue now was minor because "its in the code since 2017 and wasn't exploited".

Well, long story short, I argued a lot and in the end it came to the point where I, as QA, wrote a fix to create a proper token because management just "didn't see the need" to secure such a "hard to find problem". Well, before that I sent them a zip file containing 84 pdfs I scrapped in a night and the message that they can be happy I signed an NDA.

The whole app was a shitshow...
- Cancel order as a post request (the same post request used to save the order).
I demoed the client how with a couple of lines of code I could change his "Cancel order" button to "Mark my order as payed" button....
- List orders method took an user id as input...
- Update profile did not care about wich properties you should be able to change as a non admin...
And so on...

A checkout application where, in the confirmation screen, everything (amount, references, currency, quantity of items, etc.) was sent to the client as a form, and they submitted this form to confirm.

...but there was no verification on any of the above. So any of the above could be changed and it'd collect whatever funds, and order whatever items, with whatever references you gave it.

This wasn't a major player in the space, but was big enough that most people would likely have heard of at least some companies using it. It's still being actively used today, and I can near guarantee not all the flaws have been fixed.

The whole autistic “no ssl validation” ServerCertificateValidationCallback to true

One of the online education tools my high school used had client-side validation for test answers

As if that wasn't bad enough, the correct answers were literally marked by the CSS class 'correct', meaning that any idiot who could figure out how to open the devtools could see the correct answers

Thankfully, this program was ditched before it was used for anything major

I saw this a few years ago. Really doubt if such a bug still exists.

So I used to visit some educational websites to get answers to school assignments. Very often it used to be under a paywall.Only that it wasn't. I once saw the markup of the website using inspect element and guess what? The whole answer was available in the markup and was hidden using CSS😂.

A friend of mine removed a paywall deleting the DOM element that covered the page and all functionality from the site was intact.

I had joined a new company and got access to their codebase. They were updating password on MD5 hash of user name and their email in get request. No password validation, no token based authentication, nothing.

Eg
...com/change_password/email=(plainemail)&name= MD5(name)

That's it, you get change user password.

PHP code that didn't use sanitize, but manually checked if strings contained ' or ". Not even in a function, but manually implemented whenever the person writing that burning dumpsterfire thought it was a good idea to check for that.

Code also didn't report, it just exited without error code. Users would just get a white screen if that spaghetti code "security" system got tripped.

Most of the time just standard XSS.

"all these high schoolers can't see others' active directories... but they're all RWX on the Students group all students are in. Also the up button shows everyone's ADs from any student's, but no one will ever press that!"

I worked 2012-2016 for a big telco company in my country and there was this HTTPS webpage with an iframe rendering any url you passed over the ?url query param plus a header with the company's logo.

I was on a meeting with some friends in charge of social media and they found it for a user report.

Unbelievable 🤷🏻‍♂️ I remember I tried the page's url itself and it rendered a loop of the header with the company's logo 😂

This tuesday I saw a really badly made PHP web application. Two actually. I was giving a time estimate for how long it would take to transfer these applications to our servers. While I was reading the code it became apparent that they had more security holes than Emmental cheese. Most views had obvious SQL-injection vulnerabilities and most probably XSS too. Although I didn't think too look for XSS in the moment. It just puzzled me that this bad code even exists.

But cherry on top was that the password wasn't checked at all. The login form was on the organization's website and was sent to the selected application. But the password wasn't checked in the application. And this was made by a real Finnish software development firm, like what the fuck.

Time to redo the applications I guess. Not like there's anything wrong in that if they pay for it.

Super old affiliate management tool that wasn't updated since 2010 and stored all password in plaintext, including all coworker's and ceo's. I'm pretty sure it had some vulnerabilities to get those passwords from the outside as it was just a shitty piece of software. After finding that database it had to stay online for about a year against my recommendation until we had the chance to build an alternative.

One user could report that the data they saw didn't make sense. Turns out there was a one-off hardcoded caching detail for one of our services that cached based on a search query (yes, the entire query was the key) and before any auth checks. The system would return the results owned by whoever asked first, no matter who asked after that point.

There's "Oh dear but we all make mistakes" and there's surrender cobra. This is what PRs are for.