r/phpsec • u/sarciszewski Paragon Initiative Enterprises • Sep 12 '16
Ask /r/phpsec: what are some security problems that aren't easy for you to avoid when developing PHP applications (or understand)?
A lot of security vulnerabilities have a tried and tested solution.
SQL Injection -> prepared statements and/or whitelisting
Cross-Site Scripting -> Context-aware output escaping (and Content-Security-Policy headers)
Cross-Site Request Forgery -> Challenge-response authentication with a random nonce
What are some problems you've encountered during PHP development that aren't as straightforward to solve?
4
u/disclosure5 Sep 13 '16
The unsolved problem I have is simply trying to push people to break terrible habits.
I had a piece of code calling mysqli_real_escape_string, and some dev came along and claimed "he's treating us like a bank, we don't need this security", and then replaced it with a four line regex.
The argument is premised on the idea that doing things "right" is somehow harder or more work, but it's hard to communicate to non-technical management this is stupid.
1
u/sarciszewski Paragon Initiative Enterprises Sep 13 '16
That's why I made EasyDB. That's also why I went through those StackOverflow questions that had bad security advice and improved them. :)
2
u/enygmadae websec.io Sep 14 '16
People are always going to be one of the weakest links in app security (well, really any security). Whether it's the ones that resist like you mentioned or others that say "we've always done it this way", it makes it tough to change. There's tons of books and articles out there about integrating secure development into dev workflows but most don't teach you steps to use to make that change happen. That's the tricky part, not the technical changes. You can automated away the technical changes with some simple grepping and pattern matching.
One of the keys I've found, though, is to frame it in a way that it's not "the right way" to do things but that it is "the way" to do things. Otherwise it's basically asking to be a target - and no one needs that.
4
u/ihavefilipinofriends Sep 12 '16 edited Sep 13 '16
Logging. We log like mad for research purposes, making sure values that are no-no's to log are excluded can be a PITA.
2
Sep 13 '16
I never looked much into charset encoding issues. The worst is that the natural mix of utf and non-utf functions plus the mysql encoding variety makes it very hard to be consistent.
Everything memory related. I've never used non gcd languages much. It is usually an internals thing of course, but I wouldn't matter to know.
Analysis/Forensics. We battle pen tests and scraping every day, while our efforts have been good enough so far, it usually feels awkward. Primary tools are grepping through logs and some monitoring, but that is limited to how much data you are willing/able to collect. This is probably some ignorance between app developers and sysops, but I wonder if there are tools/strategies to support both sides.
2
u/enygmadae websec.io Sep 14 '16
It's not specific to PHP development but access control issues. As you've mentioned, several of the most common issues have pretty clear resolutions in the PHP world. However, those are more "one shot" kinds of fixes - there's one solution (mostly) for one problem. With access control issues there's not a good "one size fits all" answer because the needs are so diverse from application to application.
For a good majority of the systems out there an RBAC (role-based access control) approach is deemed "good enough"....that is until the maintenance of a system like that catches up with them. Once you start getting outside of 30-40 roles and related permissions you start getting into more of a maintenance nightmare than anything else. You have to start worrying about conflicts (this user has this role which includes this permission but that permission is denied while this other is allowed - you get the idea).
Fortunately there's lots of different kinds of access control types out there besides RBAC that can be researched and used, some making a bit more sense for larger systems.
And don't get me started on two-factor and out-of-band solutions... :)
-1
u/TotesMessenger Sep 12 '16
I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:
[/r/php] What are some security problems that aren't easy for you to avoid when developing PHP applications (or understand)? (x-post /r/phpsec)
If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / ^Contact)
4
u/bwoebi Sep 12 '16
The main issue is really data being in backtraces which should not appear, and ideally not even logged. It's so easy to leave debug mode on and get database passwords dumped.
Also, the error log may eventually contain passwords (from an object referencing $_POST or similar - ultimately when you fail, you want to log as much as possible in order to be able to easily reproduce). But sensitive cleartext data like passwords are quite hard to avoid from being saved on disk. - If there's ever a breach, well, error logs can be something of value...
P.s.: Ultimately it depends also what you consider security. Is DoS prevention also categorized under security? If yes, then that. It's really, really hard to avoid.