Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Is 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. -
(1/2)
@sbiewald
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 just got a late-evening reply from one of the seniors: Kinda what @sbiewald said. We have other issues and much easier attack vectors. ¯\_ (ツ) _/¯
Related Rants
Did you say security?
10 points for next century option.
I just found a vulnerability in my companies software.
Anyone who can edit a specific config file could implant some SQL there, which would later be executed by another (unknowing) user from within the software.
The software in question is B2B and has a server-client model, but with the client directly connecting to the database for most operations - but what you can do should be regulated by the software. With this cute little exploit I managed to drop a table from my test environment - or worse: I could manipulate data, so when you realize it it's too late to simply restore a DB backup because there might have been small changes for who knows how long. If someone was to use this maliciously the damages could be easily several million Euros for some of our customers (think about a few hundred thousand orders per day being deleted/changed).
It could also potentially be used for data exfiltration by changing protection flags, though if we're talking industry espionage they would probably find other ways and exploit the OS or DB directly, given that this attack requires specific knowledge of the software. Also we don't promise to safely store your crabby patty recipe (or other super secret secrets).
The good thing is that an attack would only possible for someone with both write access to that file and insider knowledge (though that can be gained by user of the software fairly easily with some knowledge of SQL).
Well, so much for logging off early on Friday.
rant
sql injection
security
drop table users
friday afternoon