Tuesday, September 02, 2008
Cross-site hacks and the art of self defence
Source Taken from The Register
Hackers can force your browser to send requests to any site they want. It's not even hard - all they have to do is get you to view an email or a web page.
Unless the site is specifically protected against this - and almost none are - then attackers can make your browser do anything you can do, and they can use your credentials and your access privileges. They can do things like set preferences, create payees and change passwords.
Generally, browsers stop cross-site communication by following the "same-origin policy". This rule is pretty simple: if your site has a different origin - protocol, domain, and port don't all match - you aren't allowed to access information from or send requests to the other site. Without this simple rule, there would be no security on the internet. Every website could access data from every other one - you'd need a separate web browser for every website.
Unfortunately, the same-origin policy is nowhere near airtight. Attackers don't even need an exploit to bypass it. They can simply embed an IMG, SCRIPT, IFRAME, or FORM tag that references the targeted website in an HTML page. When the victim's browser renders this tag, it generates a request and sends it to the targeted website - right around the same-origin policy. This is a feature of all browsers - it's used by many applications to grab images from other sites and to post from data to services.
Attackers can use this loophole to forge requests that appear to be coming from a legitimate user. These are called cross-site request forgeries, or CSRF, for short. Take a look at the old CSRF attack on Netflix, below.
The attacker can post this image tag anywhere - a blog, a wiki, a website, even an email message. Anyone who accidentally browses a page containing the attack while logged into Netflix will have a movie silently added to their queue.
More complex attacks involve a sending series of requests and delays, allowing the attacker to execute a series of actions in a row. In a strange way, a CSRF attack is a sort of program that executes web instructions on behalf of the attacker.
Imagine your browser suddenly turned evil and started trying to mess up your life. What could it do? It might raid the email account you're currently logged into. Maybe it would go after any bank accounts and healthcare sites you're using. Did you click "remember my login" on any websites? Guess what, your renegade browser is logged in and can take over those accounts.
Hackers can force your browser to send requests to any site they want. It's not even hard - all they have to do is get you to view an email or a web page.
Unless the site is specifically protected against this - and almost none are - then attackers can make your browser do anything you can do, and they can use your credentials and your access privileges. They can do things like set preferences, create payees and change passwords.
Generally, browsers stop cross-site communication by following the "same-origin policy". This rule is pretty simple: if your site has a different origin - protocol, domain, and port don't all match - you aren't allowed to access information from or send requests to the other site. Without this simple rule, there would be no security on the internet. Every website could access data from every other one - you'd need a separate web browser for every website.
Unfortunately, the same-origin policy is nowhere near airtight. Attackers don't even need an exploit to bypass it. They can simply embed an IMG, SCRIPT, IFRAME, or FORM tag that references the targeted website in an HTML page. When the victim's browser renders this tag, it generates a request and sends it to the targeted website - right around the same-origin policy. This is a feature of all browsers - it's used by many applications to grab images from other sites and to post from data to services.
Attackers can use this loophole to forge requests that appear to be coming from a legitimate user. These are called cross-site request forgeries, or CSRF, for short. Take a look at the old CSRF attack on Netflix, below.
The attacker can post this image tag anywhere - a blog, a wiki, a website, even an email message. Anyone who accidentally browses a page containing the attack while logged into Netflix will have a movie silently added to their queue.
More complex attacks involve a sending series of requests and delays, allowing the attacker to execute a series of actions in a row. In a strange way, a CSRF attack is a sort of program that executes web instructions on behalf of the attacker.
Imagine your browser suddenly turned evil and started trying to mess up your life. What could it do? It might raid the email account you're currently logged into. Maybe it would go after any bank accounts and healthcare sites you're using. Did you click "remember my login" on any websites? Guess what, your renegade browser is logged in and can take over those accounts.
Labels: Cross-site hacks
Working with Shadow Copy
Source Taken from www.windowsnetworking.com
Working with Shadow Copy
The Volume Shadow Copy Service is more of a convenience feature rather than an alternative to backups. The reason for this is that shadow copy data resides on the same volume as the original data. Therefore, if the volume became corrupt then there would be no way or restoring shadow copy backups. You would have to rely on a traditional tape backup instead.
Another limitation to shadow copy backups is that they only work if Windows is functional. For example, if Windows crashed due to a corrupt registry then Windows would not be functional. You would therefore have to restore Windows from a traditional backup rather than from a shadow copy backup.
Still another limitation is that shadow copy backups are designed to restore one file at a time. Because of this, shadow copy backups are not suitable for restoring large numbers of files.
These limitations do not mean that shadow copy backups are useless though. On the contrary. If a user needs to revert to a previous version of a file then a shadow copy backup will allow them to restore a previous version without involving you. You don’t have to configure a restore operation, you don’t have to mount a tape, you don’t have to do anything at all.
Working with Shadow Copy
The Volume Shadow Copy Service is more of a convenience feature rather than an alternative to backups. The reason for this is that shadow copy data resides on the same volume as the original data. Therefore, if the volume became corrupt then there would be no way or restoring shadow copy backups. You would have to rely on a traditional tape backup instead.
Another limitation to shadow copy backups is that they only work if Windows is functional. For example, if Windows crashed due to a corrupt registry then Windows would not be functional. You would therefore have to restore Windows from a traditional backup rather than from a shadow copy backup.
Still another limitation is that shadow copy backups are designed to restore one file at a time. Because of this, shadow copy backups are not suitable for restoring large numbers of files.
These limitations do not mean that shadow copy backups are useless though. On the contrary. If a user needs to revert to a previous version of a file then a shadow copy backup will allow them to restore a previous version without involving you. You don’t have to configure a restore operation, you don’t have to mount a tape, you don’t have to do anything at all.
