I'll give an example. At my previous company there was a program where you basically select a start date, select an end date, select the system and press a button and it reaches out to a database and pulls all the data following that matches those parameters. The horrors of this were 1. The queries were hard coded.

They were stored in a configuration file, in xml format.
The queries were not 1 entry. It was 4, a start, the part between start date and end date, the part between end date and system and then the end part. All of these were then concatenated in the program intermixed with variables.
This was then sent to the server as pure sql, no orm.
Here's my favorite part. You obviously don't want anyone modifying the configuration file so they encrypted it. Now I know what you're thinking at some point you probably will need to modify or add to the configuration so you store an unencrypted version in a secure location. Nope! The program had the ability to encrypt and decrypt but there were no visible buttons to access those functions. The program was written in winforms. You had to open the program in visual studio, manually expand the size of the window(locked size in regular use) and that shows the buttons. Now run the program in debug. Press the decrypt button. DO NOT EXIT THE PROGRAM! Edit the file in a text editor. Save file. Press the encrypt button. Copy the encrypted file to any other location on your computer. Close the program. Manually email the encrypted file to anybody using the file.

you are viewing a single comment's thread
view the rest of the comments

[–] CaptDust@sh.itjust.works 65 points 2 weeks ago* (last edited 2 weeks ago) (12 children)

I've had legacy systems that would encrypt user passwords, but also save the password confirmation field in plain text. There was a multitenent application that would allow front end clients to query across any table for any tenant, if you knew how to change a header. Oh and an API I discovered that would validate using "contains" for a pre-shared secret key. Basically if the secret key was "azh+37ukg", you could send any single individual character like "z" and it would accept the request.

Shits focked out here, mate.

[–] vrek@programming.dev 6 points 2 weeks ago (1 children)

I have to ask, if it's only contains wouldn't you get a ton of collisions?

Expecting an apartment manager to know what a api header was nevermind how to change it is probably not likely. Security hole to be sure though.

[–] CaptDust@sh.itjust.works 11 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

The secrets themselves were basically guids, they had quite a lot of characters. If sent MORE than 1 character, pretty low chance they would clash. But those long guids also covered a lot of letters and number - it wasn't terribly difficult to find one single character that cleared authorization reliably.

And maybe you're joking lol, but multitenant meaning multiple businesses/customers using the same application stored in the same database. If Bob's construction wanted to spy on Jim's contracting, they'd just need to know the right header to send and could get whatever they wanted from the other customer partitions. User access should of course be limited to their own assigned partitions.

[–] vrek@programming.dev 4 points 2 weeks ago

Oh, ok I interpreted multitenant wrong. I was thinking it was like a apartment complex so you have like a manager and a sales person with access and that's it. Still a valid security risk but not as severe as what you are saying now.

Sorry for confusion

load more comments (10 replies)