31 Jan
2013
31 Jan
'13
7:24 a.m.
On 2013/01/30 8:15 PM, Jeremy Kitchen wrote:
Yeah. Definately agree here.
I don't run other people's code. I have one developer who works with me,
who uses wordpress - and he's not had any issues yet (touch wood), due
to keeping up-to-date, etc.
I write my own code. I write it securely. And then even if you manage to
get into my system, most of the times you can't even change my data
(user is read-only). You can't traverse the filesystem.
My own code has actually once been targeted by an international hackers
group. On a specific site (out of loads I have done) they managed to get
in via an obscure sql injection, and stole a load of *public*
information, and unfortunately a list of my sha1 passwords for logins to
that site (±100 users).
"$ update users set password='.';" invalidated all those passwords in a
couple of milliseconds. Our support staff had to simply re-generate
those passwords as the clients complained. And some of the clients
accessed that site once a month or less, so no huge strain on them.
Eh. As much as I like to hate on php, any poorly
written web application
is just as vulnerable. mod_php's default model just tends to be
inherently insecure, and silly application devs often solve permissions
issues with 777 "because it's just easier" (or maybe they're just
ignorant of how to *properly* secure a directory which needs to be
writable by the application)
I once had a _senior_ developer ask me how unix permissions works, as he
could not execute any commands. I don't know if his PATH was wrong or
anything as I wasn't allowed to touch the box. He ended up googling and
doing a... wait for it...
chmod -R 777 /
I saw that later on. Luckily I don't work there anymore.
Keep an inventory of your applications, keep them up
to
date. Purge early and purge often.
If any of these applications provides a "updates" or "security" list
join them.
- Expect to be
compromised, so try to secure your PHP execution
environment from the rest of your server.
e.g. do assume that at some point an attacker will get to execute
commands as the user that is running your PHP app so try to reduce
what the app can do.
I can't agree with this statement any harder than I am right now. This
statement is basically web application security from an ops perspective
in a nutshell.