I have come to the realisation that I spend an incredible amount of time on the web. My work is all about the web; at home I visit websites for leisure; even when I’m out and about I use my smartphone to check my e-mails and compare high street prices. I’ve often wondered about how safe I am from malicious websites but my recent musings have been about how safe websites are from me (well, us, the end-user).
In recent months I’ve come across more and more sites that have become comprised with malware, phishing scams and other defacements. Most recently I’ve come across a site that has been hacked more than once and each time the defacement was to add a hidden link farm. All of this has prompted me to think about web site security.
If only we had alerts in real life
I come from a security conscious background and, as you can probably tell, I also think a lot. Here are some of my more coherent musings and ideas about website vulnerabilities.
- It is sad but true that the weakest link is often the squishy human link. Social engineering, is a classic example of a vulnerability, this is the manipulation of people to get access to information. The text-book example would be, someone calling you and tells you they’re “Bob from the IT department” and they need your web server password to apply a patch.
- There’s a rule I live by while I’m wearing my developer-hat, any input needs to be validated, verified and sanitized. Not necessarily in that order. Any time a website takes an input; that is a potential point-of-entry (PoE) for a malicious user. Inputs can include form submission, cookies, sessions and URI. The most common hacks using this PoE are SQL Code Injection and privilege elevation.
- Everyone knows that systems have defaults and common user names and passwords are an open secret. There’s a good chance that any hacker will know them too, so please stop using “admin” and “passw0rd1” for your administrator account. This not only applies for user accounts but anything else that uses default or common names.
- The key is to restrict access to only those that need it. If a database only needs to be accessed by the web-server, restrict access to only that server. This can be considered in the design stage of a web sites’ architecture with having a firm distinction between the presentation and data layers.
I hope this post has given you something to think about, I couldn’t cover everything in this blog but I covered the points that were most coherent.
About the author:
Posted by Ray.
Link to us
If you want to link to this blog, copy and paste the following HTML code to your website.
