Results 1 to 4 of 4

Thread: Book like "The Database Hacker's Handbook: Defending Database Servers"

Hybrid View

  1. #1
    Just burned his ISO
    Join Date
    Feb 2010
    Posts
    13

    Default Book like "The Database Hacker's Handbook: Defending Database Servers"

    Hey guys!

    Years ago I found that kinda nice book about Database Hacking called The Database Hacker's Handbook: Defending Database Servers

    I have read through it and found some quite interesting stuff, but since the book is released in 2005, the information is kinda odd nowadays. So I am searching for an (e)book just like this one.

    Any ideas about that? Thanks in advance

  2. #2
    Very good friend of the forum Gitsnik's Avatar
    Join Date
    Jan 2010
    Location
    The Crystal Wind
    Posts
    851

    Default

    Rather than just commenting out of the blue, I just picked up my copy and skimmed back through it and I have to say most of the information is still relevant (I can't say all of it as certain architectural changes have been made). I would be surprised if a DBA couldn't put the book to good use as-is, and would question one who couldn't anyway.

    I have to ask what you find odd about the book? Doing so might give a better insight.

    But to stay on topic, the best documents to read are the best practice documents for your respective vendor. Even SQL Sewer can be locked down fairly tightly just by following these practices without (bonus of bonuses) having to change much code on the front end (disable exec..xp_ and so on).

    A theory I'm pretty sure I've broached here before: There is no such thing as bad information - I've pointed kids at Meinel's work before despite her being a complete moron (in my views). There is truth in the data, so you sift it all, even the crap stuff.
    Still not underestimating the power...

    There is no such thing as bad information - There is truth in the data, so you sift it all, even the crap stuff.

  3. #3
    Just burned his ISO
    Join Date
    Feb 2010
    Posts
    13

    Default

    You might be absolute right since basic structures won't change in a few time, but security is a topic that always moves on and on and never stops, and even the database software is evolving.

    Surely, basic structures may remain the same, but I can't imagine that in more than 4 years, no new dangers to databases have arrived, that's why I have asked for an up-to-date book.

    (And I still really like the book, its fairly nice)

  4. #4
    Very good friend of the forum Gitsnik's Avatar
    Join Date
    Jan 2010
    Location
    The Crystal Wind
    Posts
    851

    Default

    Quote Originally Posted by -=Renegade=- View Post
    You might be absolute right since basic structures won't change in a few time, but security is a topic that always moves on and on and never stops, and even the database software is evolving.

    Surely, basic structures may remain the same, but I can't imagine that in more than 4 years, no new dangers to databases have arrived, that's why I have asked for an up-to-date book.

    (And I still really like the book, its fairly nice)
    Not really. There aren't that many changes in any attack methodology - you can read aleph1's buffer overflow guide just fine and exploit things these days quite simply (for example). The same basic principals apply to database security today as it did 5 years ago: Filter your input, don't have commands available that you don't need, run at lowest minimal privileges.

    During my time programming I came across a lot of other peoples code and realised that most people seem to forget these strictures. You rarely see filtering in aspx applications (for example) because the IDE does it all for them so people tend to ignore it. Counter that with a few years ago when you didn't see filtering in applications because the IDE didn't do it for them and people tended to ignore it, and you start seeing the problem

    Protecting your databases now is exactly the same as then: Stored Procedures, Disable Commands, Lowest Priv's necessary.

    As I said though: Keep reading the best practices documents. Commands like DELETE INTO have been invaluable to me in protecting deletion records.
    Still not underestimating the power...

    There is no such thing as bad information - There is truth in the data, so you sift it all, even the crap stuff.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •