<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: 5 PC Gaming Threats and How To Beat Them</title>
	<atom:link href="http://blog.webroot.com/2009/06/03/5-pc-gaming-threats-and-how-to-beat-them/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.webroot.com/2009/06/03/5-pc-gaming-threats-and-how-to-beat-them/</link>
	<description>WEBROOT - INSIGHTS INTO THREATS AND TRENDS FROM OUR INTERNET SECURITY EXPERTS</description>
	<lastBuildDate>Sat, 11 Feb 2012 02:03:19 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: hannah</title>
		<link>http://blog.webroot.com/2009/06/03/5-pc-gaming-threats-and-how-to-beat-them/#comment-972</link>
		<dc:creator><![CDATA[hannah]]></dc:creator>
		<pubDate>Wed, 09 Jun 2010 04:00:52 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=664#comment-972</guid>
		<description><![CDATA[thank you!]]></description>
		<content:encoded><![CDATA[<p>thank you!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mguthrie09</title>
		<link>http://blog.webroot.com/2009/06/03/5-pc-gaming-threats-and-how-to-beat-them/#comment-89</link>
		<dc:creator><![CDATA[mguthrie09]]></dc:creator>
		<pubDate>Thu, 18 Jun 2009 15:31:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=664#comment-89</guid>
		<description><![CDATA[IWearAWhiteHat -- 

You have a point; once a SQL injection attack is successful, the hacker has already gained access to whatever valuable data might be hosted on the server. This could be anything from usernames/passwords, account information, or personal information. It depends what the server was used for. 
 
However, many times the hacker&#039;s goal is to also propagate malware by adding malicious code to the website which is hosted on the server. In these cases, the exploit would most likely be blocked by a utility such as NoScript. 
 
When it comes to hacked servers, it is the server admin who is responsible for fixing the issue. This leaves a legit site in a compromised state until the site admin is notified and is able to remedy the infection. In addition, site admins often do not notify their users that personal information might have been accessed, and therefore people are unable to take the necessary steps to protect themselves. Not a lot can be done to fix this, though users of sites that are attacked should be encouraged to be vocal on the site forum to alert others that their personal data may have been compromised.

MGuthrie
Webroot Threat Blog admin]]></description>
		<content:encoded><![CDATA[<p>IWearAWhiteHat &#8212; </p>
<p>You have a point; once a SQL injection attack is successful, the hacker has already gained access to whatever valuable data might be hosted on the server. This could be anything from usernames/passwords, account information, or personal information. It depends what the server was used for. </p>
<p>However, many times the hacker&#8217;s goal is to also propagate malware by adding malicious code to the website which is hosted on the server. In these cases, the exploit would most likely be blocked by a utility such as NoScript. </p>
<p>When it comes to hacked servers, it is the server admin who is responsible for fixing the issue. This leaves a legit site in a compromised state until the site admin is notified and is able to remedy the infection. In addition, site admins often do not notify their users that personal information might have been accessed, and therefore people are unable to take the necessary steps to protect themselves. Not a lot can be done to fix this, though users of sites that are attacked should be encouraged to be vocal on the site forum to alert others that their personal data may have been compromised.</p>
<p>MGuthrie<br />
Webroot Threat Blog admin</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: IWearAWhiteHat</title>
		<link>http://blog.webroot.com/2009/06/03/5-pc-gaming-threats-and-how-to-beat-them/#comment-85</link>
		<dc:creator><![CDATA[IWearAWhiteHat]]></dc:creator>
		<pubDate>Wed, 17 Jun 2009 21:19:26 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=664#comment-85</guid>
		<description><![CDATA[Mike,

Do you think you can clarify your last point about defending against SQL injection attacks by switching to Firefox and using NoScript? 

As I understand it (and you describe it), SQL injection attacks are run against a database hosted on a server, not a client or end-user. If such an attack is successful, the cracker is able to view or modify the data within that database, ranging from product pricing to username/password combinations and other personal information. 

What I don&#039;t understand is how a client-side change would affect this problem. If the attacker leveraged a SQL injection into forcing a legitimate server to host malicious JavaScript/Flash components, I can see your point. But if the only attack was a SQL injection, then the problem has to be addressed by the site&#039;s administrators, not it&#039;s users.

For the record, I do believe that we should all be using Firefox with NoScript (or something similar), just want to understand your post better.]]></description>
		<content:encoded><![CDATA[<p>Mike,</p>
<p>Do you think you can clarify your last point about defending against SQL injection attacks by switching to Firefox and using NoScript? </p>
<p>As I understand it (and you describe it), SQL injection attacks are run against a database hosted on a server, not a client or end-user. If such an attack is successful, the cracker is able to view or modify the data within that database, ranging from product pricing to username/password combinations and other personal information. </p>
<p>What I don&#8217;t understand is how a client-side change would affect this problem. If the attacker leveraged a SQL injection into forcing a legitimate server to host malicious JavaScript/Flash components, I can see your point. But if the only attack was a SQL injection, then the problem has to be addressed by the site&#8217;s administrators, not it&#8217;s users.</p>
<p>For the record, I do believe that we should all be using Firefox with NoScript (or something similar), just want to understand your post better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gamers: Fight the Phishers &#171; Webroot Threat Blog</title>
		<link>http://blog.webroot.com/2009/06/03/5-pc-gaming-threats-and-how-to-beat-them/#comment-84</link>
		<dc:creator><![CDATA[Gamers: Fight the Phishers &#171; Webroot Threat Blog]]></dc:creator>
		<pubDate>Wed, 17 Jun 2009 20:03:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=664#comment-84</guid>
		<description><![CDATA[[...] addition to the general advice we gave in an earlier post, there are a few things gamers can do [...]]]></description>
		<content:encoded><![CDATA[<p>[...] addition to the general advice we gave in an earlier post, there are a few things gamers can do [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: If You&#8217;ve Got Game, Phishers Want Your Stuff &#171; Webroot Threat Blog</title>
		<link>http://blog.webroot.com/2009/06/03/5-pc-gaming-threats-and-how-to-beat-them/#comment-78</link>
		<dc:creator><![CDATA[If You&#8217;ve Got Game, Phishers Want Your Stuff &#171; Webroot Threat Blog]]></dc:creator>
		<pubDate>Fri, 12 Jun 2009 17:28:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=664#comment-78</guid>
		<description><![CDATA[[...] little effort for the jerks behind this scheme to retrieve thousands of account details. (We began covering this issue briefly last week.) With such an effortless infection method, and the difficulty of prosecution [...]]]></description>
		<content:encoded><![CDATA[<p>[...] little effort for the jerks behind this scheme to retrieve thousands of account details. (We began covering this issue briefly last week.) With such an effortless infection method, and the difficulty of prosecution [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

