Ask Slashdot: Do-It-Yourself Security Auditing Tools? 116
An anonymous reader writes "I'm a 'prosumer' website builder, have a few sites that are mainly hobbies, but I would like to know that they're at least fairly robust. I'm thinking of the equivalent of a 'dental clinic' — where someone interested in the white hat security field might be willing to take on an audit for the experience and to build a resume. Or, tools such as websites that let you put in a password and see how long it takes to crack it. Or sites where you can put in a URL and it gets poked and prodded by a number of different cracker tools and a 'score' is given. Ideally with suggestions on how to improve. Does anything like that exist? I'm not talking FBI/CIA level security, but just common-sense basics. I've tried to use techniques that improve security, but I don't know how well they work. And I've realized that in the ever growing, fast changing field of computers I'm not going to ever get the knowledge I need to do this myself. I know there are software suites that allow you to sniff and test things on your own, but I'm afraid it's overwhelmingly foreign to me and I just feel like I can't reliably do this myself. Any ideas?"
You could try PWNPI (Score:4, Interesting)
This is a nifty suite of programs made for a lot of what you want that runs on a Raspberry Pi. If you don;t want to get a Pi you can look at the list of software and download then into your favorite Linux distro. Most (if not all) of these are open source.
http://pwnpi.sourceforge.net/ [sourceforge.net]
You probably already took the test (Score:2, Interesting)
Whether you wanted to or not, just by having a site, you've already asked the whole Internet to check it out. One way to find out if you've done things right, is to look for evidence that you've done things wrong. And there's a little tip I learned...
Grep your logs for your table names.
If you have an injection hole, for example, then automated spiders have already found it and exploited it, and (so far) they don't obfuscate or even escape/character-encode their requests, so you'll plainly see their injected queries in your logs.
Preferably, look for site-unique table names, so that you'll know they could have only gotten the name by successfully querying the schema. You're going to see lots of scary-looking things in your logs, but some of those are just unsuccessful attempts. A unique table name (hint: use tables names with the word "user" or "password" in them) will be a dead giveaway they succeeded.
Don't ask me how I know what that looks like. Hey, it wasn't my fault. Mostly. Ok, partly but mostly not. Look, it's complicated, and involves an inherited legacy, OKAY?! Everybody just back off. ;-)
Anyway, when you see that, then it means you screwed up, so you'll learn something and know you need to fix something. If you don't see it .. sadly, you won't really know much more than you did before.