Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
sbiewald4143187dIs the configuration file on the client or your server? Or did I miss it?
In the first case, if an attacker can write the config file, what else can he do? Read the database credentials? Replace the software as a whole? If so, it is only bad design, but not a critical issue (it should get fixed nonetheless).
In the latter case it is still bad design, but the attacker could likely already write to the database.
The client files should be on a network drive where ideally, normal users are only allowed to read. However some of our customers might not have the smartest admins, so it's difficult to be certain about that.
To be fair, if one has write access to the whole project folder there are definitely more attack surfaces. The issue I see here that you only need write access to a config file (and I wasn't sure about how file access is / should be handled before discussing this with my manager).
I actually spotted this while dealing the issue of another layer of security that could possibly be evaded (through extending said file in a non-malicious way). That one would be a comparatively small issue however (in terms of damage potential) and then this came up which is a thousand times worse, but yeah, I guess I was a bit overreacting earlier.
I suppose going from "someone might be able to guess some protected data with a lot of trial & error" to "put this string here and fuck the whole db up" was a bit too much for me today.
alturnativ32187d!dev but similar boat... Discovered that pretty much any end user can inject SQL in a text field in my company's product that doesn't account for single quotes in any way...