241–249 of 249 posts
Earlier quoted context omitted.
My apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.
Stored procedures offer no inherent protection.
This list could just as well be called "List of security stuff I learned about when making my product". Some of the stuff is just Draconian, certainly not applicable for any arbitrary web developer.
There are rarely any checklists applicable everywhere in the same way. Why not treat it as: list of ideas to evaluate and prioritise/ignore into your own checklist for future/current project? It's not like it's all invalid because it's not fully applicable.
Earlier quoted context omitted.
It's not a problem with the garbage collector, just how the objects are referenced. Basically you need to ensure the request reaches a terminal state where you either close the connection (ServerResponse.end) or send a response (ServerResponse.send and similar). All the cleanup happens after you do that.
Is there not an OnDispose or some kind of hook to detect when requests can end? To end a request in every framework I've used you just return from your code back to the framework. You shouldn't have to worry about a framework object like request state.
OWASP has published a release candidate of the OWASP "top-ten" available as a PDF at https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2... . They also support the creation and maintenance of quite a few OSS tools to help secure systems. To those who are claiming some of these steps are too onerous or would cause performance issues: Are you sure? For an individual system, maybe some of these checkboxes are i…
I assume you're talking about something like a public facing load balancer that connects into a private network where the web servers and database server live, and you'd need a bastion host (or just the load balancer) to connect into the private network and access any of the machines.
Earlier quoted context omitted.
Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physicall…
We use disk encryption to protect against a specific attack that had occurred in the past: the attacker hacks the hosting provider's admin panel and uses it to reboot our server into a rescue system, in which he has access the raw disk.
It seems to me having admin panel access is an even higher level privilege than having root on the box itself, for any VPS host environment I've personally used before. Linode for instance lets you open up a root shell to your running box, which doesn't even use SSH. I'm surprised it isn't total game-over if your admin panel access is compromised.
Earlier quoted context omitted.
That sounds like BAD validation that needs fixing, not an excuse not to do any. Some US sites still won't let me in because (a) they insist that I must have a middle name or (b) screw up the hyphen in my surname. Many sites and payroll systems assume that everyone has a surname. Never mind its character set and ordering. Even if you don't make these assumptions you don't need to accept a binary gzipped GB of zeros or…
Designing a _good_ validation system (to reliably discriminate between "good" strings and "bad" strings, including all corner cases) is really hard, error-prone, not future-proof (standards change) and might be even theoretically impossible in some cases. Some basic sanity checks are useful, of course. But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks preventio…
Can you define what you mean by "input sanitization"? Because in my mind, a prepared statement is doing just that. You say what part is your SQL, what part is your user input, and you let the DB adapter sanitize the input to build the final statement. You aren't writing sanitization code yourself, you're leaving it up to a library, but that's still what's happening. Or do you have a different term for what's going when a prepared statement routine converts user input into SQL-safe strings?
Earlier quoted context omitted.
We use disk encryption to protect against a specific attack that had occurred in the past: the attacker hacks the hosting provider's admin panel and uses it to reboot our server into a rescue system, in which he has access the raw disk.
Interesting, what hosting provider/system are you talking about here? It seems to me having admin panel access is an even higher level privilege than having root on the box itself, for any VPS host environment I've personally used before. Linode for instance lets you open up a root shell to your running box, which doesn't even use SSH. I'm surprised it isn't total game-over if your admin panel access is compromised.
But there are many providers out there where through the admin panel you can gain access to a system. Many providers provide access to the server's terminal. Even if you can't login, you can reboot the server, and at the boot loader stage you can boot the OS in rescue mode, during which you can mount the hard disk.
OWASP has published a release candidate of the OWASP "top-ten" available as a PDF at https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2... . They also support the creation and maintenance of quite a few OSS tools to help secure systems. To those who are claiming some of these steps are too onerous or would cause performance issues: Are you sure? For an individual system, maybe some of these checkboxes are i…
Can you elaborate a bit more detail around a MVP-style architecture where the database isn't on the public internet? I assume you're talking about something like a public facing load balancer that connects into a private network where the web servers and database server live, and you'd need a bastion host (or just the load balancer) to connect into the private network and access any of the machines.
Earlier quoted context omitted.
At rest basically means on disk. People might not think about this but AWS actually has a physical disk somewhere which someone could yank from the data center and read from. Not that likely but also not hard to protect yourself from.
If someone is yanking and reading disks at AWS then the game was over a long time ago. Physical access always wins. IMO, if you're on AWS (or similar) then at rest encryption is a wholly unnecessary expense, unless you need to tick some kind of regulatory checkbox. I can see it for smaller on premise racks to prevent a "smash and grab" problem, but in a secure datacenter? Nah...
Of course this is very hypothetical and it requires the attacker to know what disk in what rack to target, I'm not saying it's the most likely scenario, I'm saying it can be avoided by flipping a switch and paying a few extra dollars so I'll keep it enabled.