10 Ways to make an Insecure Website

Broken lock because your website was just too secure!

Note: The following article is satire. We urge you not to follow its advice.

So, you want to make yourself (or your client) a terribly insecure website? No worries, here is our guide to making your easily hackable dream come true.

1. Passwords – Passwords are a complete waste of time, aren’t they? They inconvenience you when you login to work every morning, so why would you want to place that burden on your client every time they access their administration system? Make sure to not include passwords, or if you absolutely have to, keep the passwords as short as possible – don’t want to waste time typing them just for extra security. Oh, and don’t use special characters… they’re confusing.
2. https:// – Encryption has been over hyped by the media recently. Just because a decent hacker could sniff all your website user’s passwords and data, that doesn’t mean your web server needs to waste precious CPU time encrypting people’s personal data. Your users will be fine entering their credit/debit card details, regardless of whether on not that ridiculous ‘lock’ symbol appears. Plus, the ‘super secure’ green bar just looks ugly alongside most website designs.
3. Storing passwords – Feel free to store all your passwords in plain text in your database. There is no chance anyone will ever be able to access your server’s database, people just don’t do that nowadays. So, there really is no point in dealing with all that complex hashing and what not. If you truly insist on hashing your passwords before storing them, make sure you use a really fast hashing algorithm such as MD5 or SHA1. Don’t under any circumstances make use of silly things such as bcrypt and/or cryptographic salt.
4. File uploads – It’s very important to allow your users to upload all types of files. For example, if you have a form that allows users to upload a photo of themselves, you’ll also want to make sure they can also upload executable code (such as PHP code) and enormous sized files. Remember, users should have free reign of your servers file system! Who are you to deny them?
5. Form inputs – Don’t restrict or sanitize what your users are allowed to put in your system’s database. And its not just databases, any decent web application will allow you to submit JavaScript and full HTML in comments. If the users of your system want to make alert boxes appear on all pages, creatively ‘tweak’ its layout and content, or have other sorts of ‘fun’, that’s definitely something your web application should accommodate for. Imagine marketing your website as having full XSS and CSRF support! Good buzzwords, right?
6. Leave everything public – Crons jobs and internal little tools you’ve made to help with the development/maintenance of your website… they should all be publicly accessible. If your ‘reset_all_prices_for_testing.php’ script isn’t available for any Joe Bloggs to use, it really wasn’t worth the development time. Now, cron jobs are designed to run at a schedule set on the server, but why not make them public too? You can let your users help out by running that ‘intensive_database_cleanup_cron.php’ file whenever they want! If your server cannot deal with that, perhaps you need to download more RAM.
7. Updating software – Don’t waste time. Keeping your software up-to-date is just over hyped, just like the encryption I mentioned earlier. Hackers don’t go through looking for exploits and there are not huge databases of exploits in popular software. That’s just paranoid fantasy. Why waste your time and even money on these silly updates? You always postpone the Windows ones, right?
8. Make use of HTML comments – I always say that commenting your code is a great idea. It is useful for documentation purposes and to help others make sense of your code in the future, after you get hit by a metaphorical bus. So, since commenting is so good, I’d advise you to take it one step further. Store your passwords there, your database details, your schema info, technical details, lists of problems/bugs, developer contact details, personal information and pretty much anything you can think of. It is much more convenient than sticky notes! You can loose those, but if you put your important info directly in the webpage comments, you’ll never be too far away from it. You can push this as ‘improvised remote access documentation’.
9. Rely on the client – Most people code validation twice. Once on the client (in the user’s browser) and once on the server, before the data actually goes into the database or is processed in some other fashion. One rule of programming is not to duplicate code! But so many people code this validation twice. Just code it client-side, in the browser with some nice JavaScript or HTML5. You could bypass this by disabling JavaScript, but it’s not like people ever turn off JavaScript selectively in Firefox, Chrome or other browsers.
10. Share and care – As developers, it is important to access passwords and important details quickly and easily. Regardless of the company size, you should make sure to keep all passwords in one centralised place, giving all users access to them. Do this for FTP and email passwords. Plus, its important to avoid encrypting them, as this can slow down the development studio and reduce productivity. You should use a standard file format, like a plaintext file or an Excel spreadsheet. Don’t make use of these so called ‘password managers’ with their ‘encrypted vaults’ and other such nonsense.