We’ve heard news about someone hacking google or facebook. We’ve heard about accounts being stolen or sabotaged. We’ve probably even seen a few movies about it! However, unless you’ve experienced or know a friend who have experienced it, you probably won’t realize how real and how much it could happen to you.
You’re probably aware of scams and phishing issues particularly if you do a lot of online shopping, but there are a lot graver threats out there that could harm both your online and offline life – and they could happen when you feel your most secure.
Recently, i’ve had a chance to learn (and develop) about these security threats, and i have become ‘aware’ of some of them. Triggered by the Halloween spirit, i’ve decided to put up a post regarding the scary things that people should really be aware of when doing things online. This is a sort of a sloppy-joe of info that could be useful for people from the technically-challenged to the technically savvy (if your a geek, then you probably already know this). I’ll also try to simplify the explanations as there are other more detailed resources out there that could present you with more ‘advanced’ info (check out the Resources sections).
I do not mean to scare people from using the internet. Well, i actually do! It’s Halloween!
Besides, we all should be a little more careful, especially these days, when technology can go so out of control.
What should i be afraid of?
First, what are the things that you should be worried about? Here’s some of them:
1. Minor: Someone could pick up your e-mail address and begin spamming it.
2. Major: Someone could steal your identity on facebook, yahoo or google and begin posting things that you’d rather not, or start contacting your friends and family to try to get money from them. Or they could start ruining your personality, if it’s more fun. Once your identity is stolen, the culprit, would probably immediately change your passwords and related info so you’d have a hard time fixing the problem.
3. Major: While checking your bank accounts online, someone could pick up your identity and force a funds transfer, without you knowing about it. You’ll just find out when you check the next time, that your account has zero-balanced.
4. Major: While checking some items on a shopping website, a hacker would trigger purchases for you without you being aware of it.
5. Major: A hacker could acquire sensitive information from your online account. This information could be your full name, where you live, where you work, your phone number, your family members, where they live and work, which restaurants you go to, which banks your using, which route your taking to work. I can only imagine what a ‘baddy’ could do with all this info.
6. Major: If you’re a VIP kind of person, and someone managed to do #5 but they are ‘smart’ to do the actual dirty work on your info – they’d probably just sell them to someone who wants to (say, a competitor or a blackmailer). For the normal (non-VIP) people – that means goodbye privacy!
There’s probably a ton more of this things to be worried about. Really, for the malevolent mind, the possibilities are endless.
How can these happen?
So, what are the things that make the above possible?
They are a combination of website vulnerabilities, carelessness of people (consumer and producer) and malicious intent. Since the last two are infinitely difficult to define and enumerate, let’s focus on the first one: Site Vulnerabilities.
In the following sections, i would be enumerating the vulnerabilities that (i think) are common, as based on what i have learned so far. I’ll also try to put in how ‘secure’ websites deal with each of these vulnerabilities. For developers, these are the things that should be done but sometimes get forgotten (especially when we’re too distressed about our pay and taxes). For normal users, this would at least explain why websites do what they do if it is annoying (i’ll be posting a separate blog regarding this point of view later).
Note: as much as i would want to post concrete examples (i.e. actual sites), i can’t. It would put me in a really terrible position (and probably you, who would intend to try them out). So for now, just settle for being aware of them.
Let me remind you though, that this is just an overview. I certainly can’t (and won’t bother to) give all the info in here.
1. Little or No Password Complexity: Insecure Passwords
Okay, the regular user has a big part on this but website owners/developers should really have a say on what you use as your passwords. There are websites that does not implement a policy regarding their passwords. So, if a user uses his name or birthday as a password, website (system) would accept it. There are so many ways to guess a password (and most of them can be automated). This means a hacker could simply run a program (a script) to try out most of the combinations. If the site does not strictly implement a password complexity scheme or password management rules – someone could easily ‘guess’ that password.
For developers: you need to create and implement a password complexity scheme that isn’t easy to break. This would deter possible hackers.
For users: consider what you use as your passwords and follow the recommendations on forming passwords (no usernames, birthdays; don’t use ‘secret’ or ‘password’ or ‘123456’ etc).
Resources: Password Best Practices (Microsoft), Strong Passwords (Microsoft), Strong passwords
2. Cross-Site Scripting (CSS or XSS) : Controlling a website from another site
A typical webpage would normally contain one or more dynamic elements that issue commands that your browser executes, usually in the form of scripts (but not limited to). That’s normal, and makes the web a lot more feature-rich and useful. However, an ‘attacker’ can actually use this to his advantage by sending a user his scripts and letting that user execute it for him. It’s quite simple really. A hacker would simply post a link or something similar on a forum or a blog that looks all too normal. It could be something like, the best restaurant in town. However, the link actually has some malicious script behind it. Since, a typical user would not check out how the link is formed, he would happily click on it in the hopes that he’d be having a great dinner tonight. The link though, points to some javascript on another site made by the hacker. The script could trigger anything from simply opening pages to stealing cookies or info from the client’s browser. A vulnerable (but trusted) site would now play host to these scripts that can cross it’s control to another site (hence, the name). And, since the link came from a trusted site, the user would have no idea what just happened. It could also happen the other way.
A hacker can even embed malicious scripts on a venerable site (i.e. a business or financial site). The script could be placed as his user name, a welcome greet or a link on a broken image, and saved permanently on the site’s website. This would get executed every time that data is accessed and displayed from the website. This is called injection.
For developers: always consider security when creating your webpages, particularly those that needs input from users. Perform proper sanitization and encoding.
For users: be careful on which websites or forums you visit.
Resources: Wikipedia: Cross-site_scripting, OWASP: XSS
3. Cross-Site Request Forgery (CSRF or XSRF) : Your identity, my commands
This is a form of XSS it also involves another website taking control (or maliciously) using another website, but this time it focuses on your account. When you login into your account from your favorite websites. You normally remain logged in, until you explicitly log out. A hacker takes advantage of that. Let’s say for example, you log into your banking account. You get a little bored, so you open up another browser window (or tab) and visit a blog. Like the case above, a hacker embedded a malicious script on one of the links he posted on one of the comments. This time, the script would take advantage on the fact that you’re already (and still) logged in to the banking site. From that mere link, he could initiate transfers or whatever feature from the website. It’s called ‘request forgery’ since the hacker could use your already existing session to perform requests on your behalf, often without you knowing it.
For developers: implement anti-XSRF (and anti-XSS) solutions to your sites. There are a number of best practices, but consider their limitations as well. There are no bulletproof solutions but you can still make it a little harder for hackers to break your security.
For users: Log-out of sites when you’re not using them and again, be careful on which websites or forums you visit.
Resources: Wikipedia: Cross-site_request_forgery, Bytes.com: What is XSRF, OWASP: Cross-Site_Request_Forgery_(CSRF)
4. Insecure Sessions : Stealing your identity, Too much easily understandable details
If the website developers of your favorite banking site was too underpaid (hehe) or overworked to even bother encrypting and securing the forms and information on their pages, a hacker could easily sniff out these sites when you log in and pull out sensitive information about your account and yourself. There are a lot of tools that a hacker can use to pull out bits of data and pull them together to form detailed information about your account (that they could use later to perform something like request forgery) or information about your daily life (which could be used from spamming to blackmailing).
There are cases when hackers don’t even need to sniff out the data. URL histories, browsing histories make all of the important details readily available. And, if the developers put in too much information, then it would be a lot easier to be hacked.
This threat is now more apparent when people can log in to public areas like an internet cafe, a coffee shop with free wifi or some other public domain connection.
For developers: Implement proper encryption and security on your sites. What is proper? You need to research the best practices out there and tailor and improve it for your own sites. If you’re underpaid or overworked (or both) then it becomes a management concern. lol. In any case, companies’ and solutions providers’ should include security as part of all their projects.
For users: Check the sites your joining. See if they have considered security issues. If your a paying costumer, then you have the right to know. If they don’t bother about these, then better to switch to another site/provider. You should also avoid doing sensitive transactions over public connections. Limit them to your home or office connection. Whenever, you use a public computer, don’t forget to log-out.
5. Exposed Site directory: Exposing the site’s gut
This is a simple vulnerability but one that can aid a hacker to do his intentions especially combined with the other vulnerabilities. Directory browsing, means that any user can navigate through the whole website by simply editing the URL from a host. It is sort of browsing through folders/files in a website. If this feature is not disabled for a server, then a hacker can track and enumerate every page that a site contains – including pages that should not be disclosed to a normal user (i.e. Admin pages). Once the pages are enumerated, it would be a lot easier for someone to just begin forging requests or formulating pieces of information to be sent to a website to perform user account changes and even server settings.
For developers: Turn of directory browsing; use https and remove sensitive files out of your public domain.
For users: Check the sites if you can browse through their site by simply typing a ‘/’ at the end of their hostname. If you’re browser is able to provide you with possible pages, then it’s a good indication that the site is vulnerable. Of course, there are sites that does this intentionally for some of their pages for easy navigation but this should not be the case for banking or financial sites where there are a ton of sensitive information.
Resources: http://technet.microsoft.com/en-us/library/cc731109(WS.10).aspx
6. No time-out: Hackers can have their coffee breaks if they want
This is one of the most annoying things for most banking systems – the constant time out. However, they are there for a very good reason. With all the security checks already in place for a site, there are really ‘evil geniuses’ out there that could still break that system. If the security implementations are strong, then a hacker would have a hard time cracking it, they would need time. Without timeouts, they could spend the whole day just trying to break a websites protection. They would have enough to time to research more or run more scripts and tools to basically brute-force or experiment on your system.
There are also, the common case of users forgetting to log out. If they were on a public computer, then the next user could easily re-use the already existing account.
For developers: Implement timeouts on website log-ins. Combine your other security checks with time out so hackers will have little chance to try out their experiments.
For users: Just be thankful that your site implements it. Decide what your going to do before you log in and make your transactions quick. Also remember, that closing a browser window, doesn’t necessarily mean you’re automatically logged out of the website.
7. Detailed Error Messages: Exposing the site’s gut (yet again)
It’s perfectly normal for a site to display error pages like inaccessibility or processing errors or some other problems that the server has encountered. What’s not normal is for the error page to display detailed information about the server or the type of processing that was just done. If a website does not handle ALL of it’s exceptions or errors and course that through a custom Error page, then there is a chance that a default (usually a very simple text-based page) could be displayed detailing the error encountered. It could display the name of the server, the database, database field entries or the software being used by the server. To some hackers this tiny bit of information could spell the doom of the whole website. For example, if the error displayed the name and version of the server’s OS, a hacker could research the known vulnerabilities of that version of the OS and begin attacking from there.
For developers: Create custom error page that does not present any unnecessary details to the user. Error details are server only information and should not be released.
For users: If you think you’re seeing too much details when you encounter an error, report it immediately to the site developers (preferably avoiding publicly available forums of their site as the error details could be particular about your account).
If you haven’t noticed it yet, a lot of the links in the resources points to OWASP. It is a very good source of information and best practices regarding website security. Here is the full link: www.owasp.org
Obviously, these aren’t the only grave threats out there. And indeed, they keep coming out as fast as technology is growing. There’s no need to be scared, just be vigilant.
0 comments:
Post a Comment