gpg: Signature made Thu Jan 31 07:24:45 2013 UTC
gpg: using RSA key 8B2EA07A2ED7E3E6
gpg: Can't check signature: No public key
On 2013/01/30 8:15 PM, Jeremy Kitchen wrote:
> 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.
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.
