In honour of LulzSec: Post IT security problems and fixes

[Patashu]

0) Your password is hopelessly insecure.
Why this is bad: A computer can test every 6 character long password in a matter of minutes. Computers are only getting faster and botnets bigger. Also, you use the same password for every site you go to because your memory is bad, so cracked once = cracked everywhere.
Solution: An IP should be locked out after X number of failed password guessing attempts.
That won't protect you, though, if you (or a company's admin!) uses the same password on a site without such protection. The only solution is to use a different password per page - try having a 'master' password that you modify subtly based on the name (but not the whole name) of the website. This way it's easy for you to remember but a program testing cracked passwords on every site it can won't figure it out.
More secure are 'keychain' programs which produce high complexity passwords for every site you go to, and permit you access to this keychain with the 'master password' that you memorize. This way stealing your password on one site is useless. Try https://lastpass.com/ or http://keepass.info/

0.5) Your password is still insecure, even after that salted MD5 database of passwords is leaked.
Why this is bad: Even if it's salted so you can't use a rainbow table (do people still use those?) a computer can try every possibility until it works, because most passwords are short and come out of the dictionary with minor modifications on the end.
Solution: Use bcrypt. http://codahale.com/how-to-safely-store-a-password/ Why bcrypt and not MD5 or SHA-256? Because bcrypt has a 'work factor' - the higher the work factor, the longer it takes to hash. Meaning that a brute force password guesser will now take years for one password, but a legitimate user won't even notice the difference.

1) SQL injection lets arbitrary SQL get executed on your database.
Why this is bad: The hacker can now retrieve the contents of every table, drop every table, query system parameters to find out more about the software and what it's running on, etc.
Solution: mysql_real_escape_string. http://php.net/manual/en/function.my...ape-string.php
If you're sending a number, however, check that it's composed entirely of 0-9s.
Finally, why not just use stored procedures? They have a pre computed query plan so they'll run faster, they explicitly separate code from data by parametrization.

2) XSS vulnerabilities can let a user upload javascript code and have it be executed as part of the page by the next user to access it.
Why this is bad:If you can get an admin to execute the code you now have admin privileges. Failing that, you can always mass steal session cookies and impersonate users.
Solution: Not easy. Refer to https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet

3) Cookies, passwords and other information you transmit over a wireless connection can be intercepted by other people in the area
Why this is bad: There's a plugin for Firefox called Firesheep that automatically notifies you when it picks up other people's cookies! Stealing people's sessions has never been easier.
Solution: Only use https:// to connect to sites that you care about or just read a book while you're sitting in the airport. For most people this won't matter because it's difficult to mass mine people's passwords

4) Devices on a company network will respond to all pings and TCP connections by default.
Why this is bad: A hacker could do a scan of IP addresses and ports in your network, finding out not just what you have on the network but if they find even one service with a known vulnerability it can be leveraged to do more damage. It's not worth the risk.
Solution: Set up access control lists either on the routers or on the firewall to prevent all IP traffic and ports except the ones that need to be open to the internet. Network address translation can be used to allow devices on the network to only be accessed when they start the session.

5) Users can travel to webpages you didn't expect or send parameters you didn't expect by altering the URL/the source code of a page which sends a form.
Why this is bad: If you forget to sanity check parameters, your users can send bizzare results. For a while on the site www.epicmafia.com you could use Google Chrome to edit a page letting you rate a user up or down - normally by 1 or -1, but if you change it to 100000 or -100000 then it worked!
Webpages can be vulnerable in two ways - they can directly represent actions, which when used will perform the action whether you wanted it to or not (e.g. on www.furaffinity.net you could trick an admin into deleting an image because it was a simple URL) or it can contain content you're not supposed to access as a normal user. ps these sites are coded REALLY badly
Solution: Always, always assume data you receive from the user is untrustworthy and sanity check it.
URLs that modify the state in some way (like deleting an image) should either be impossible to predict by someone who isn't you or rely on hidden parameters so it's not as easily spoofed.
Your web server program, like Apache, can forbid access to web pages that aren't meant to be publicly viewable.
I'm not as certain about this kind of vulnerability, so someone with more experience might be able to correct me here, but I definitely know this is a problem

6) Social engineering: An employee can be conned into giving out a working password to a high privilege account to someone pretending to be a member of the company.
Why this is bad: All the security in the world won't help you if you'll give out admin access to anyone.
Solution: Security policies and vetting I guess, what's the usual tactic?