Re: [SL] SQL-Ledger vulnerability CVE-2006-4244

[GeorgeOsvald <geo...@ya...>]

On Friday 08 September 2006 09:55, Josh Berkus wrote:
> George,
>
> > I am not saying they are naive if they trusted Dieter. What I say is
> > that there is a lot more to security then just the application itself.
> > Anyone who just slaps anything on a web server without any additional
> > precautions is naive. Dieter does behave strangely sometimes I admit but
> > he can not be held responsible for every one who just blindely installs
> > SL and then hopes for the best. I understand that there is a problem, my
> > point is though that if your server is safe there is no way anyone from
> > outside (not an employee) can do anything if your setup is half sane.
>
> Well, security is something you implement at every level, not just at the
> gateway.  So:  SSL: yes, Domain limits: Yes, server lockdown: yes, strong
> passwords: yes, secure session tracking: yes, database security: yes,
> database auditing: yes.   What you *don't* do is implement security in one
> area (like SSL or VPN) and expect that you don't need to worry about
> security anywhere else.  That's a fast way to get hacked.

You can do bit more than that depending on your level of paranoia. I am 
extremely paranoid. When it comes to security redundancy is a good thing.

> Also, I'll tell you as someone who occasionally used to do database
> forensics professionally, 90% of hacks against a financial application
> happen from *inside* your organization.  The most likely reason for
> someone to hack SL is to commit malfeasance which is almost always going
> to be an employee.  So the fact that SL (or whatever) "isn't on the web"
> isn't a security policy.

When it comes to employee honesty there is nothing you can do. I know people 
who keep there passwords in their wallets just to remember. Dishonest person 
could take that password and access SL normally. 
Frankly If I had an employee who would be able to hack SL he/she would not be 
working as an accountant. You can still search the logs to find out who was 
logged in and did what.