<?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/"
		>
<channel>
	<title>Comments on: Visual Studio as a powerful search and replace tool</title>
	<atom:link href="http://jw0rd.net/2009/02/14/visual-studio-as-a-powerful-search-and-replace-tool/feed/" rel="self" type="application/rss+xml" />
	<link>http://jw0rd.net/2009/02/14/visual-studio-as-a-powerful-search-and-replace-tool/</link>
	<description>Archived Tech Knowledge</description>
	<lastBuildDate>Mon, 19 Apr 2010 21:01:18 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: admin</title>
		<link>http://jw0rd.net/2009/02/14/visual-studio-as-a-powerful-search-and-replace-tool/comment-page-1/#comment-15</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Fri, 06 Mar 2009 03:00:52 +0000</pubDate>
		<guid isPermaLink="false">http://jw0rd.net/?p=138#comment-15</guid>
		<description>Hello Jim,

The root issue was web server file permissions. A certain Windows users group had full permissions recursively to all web files. One site was compromised and was used to inject files on the entire server.

First you need to make sure your site&#039;s file permissions are secure, depending on your host you may not be able to see the entire ACL (access control list) for your files. If that&#039;s the case just ask them to double check to make sure no random Windows users groups have write permissions to your files.

Second also verify the original compromise was not an FTP compromise. Have your host check the FTP logs from the day your files were injected. If it was an FTP compromise, update your passwords and scan all workstations used to connect via FTP for viruses, loggers, sniffers, etc..

If it wasn&#039;t an FTP compromise have your host double check the sandbox securities in ColdFusion admin and verify that no other sites have something stupid like recursive write access to the directory where all the websites are stored.

Assuming your site is on a Windows server have your host setup Windows file auditing/logging for the EVERYONE group on a few of the files that got injected previously. That way if it does happen again you (well, your host) will have evidence of what Windows user wrote to the file.

Hope that helps.</description>
		<content:encoded><![CDATA[<p>Hello Jim,</p>
<p>The root issue was web server file permissions. A certain Windows users group had full permissions recursively to all web files. One site was compromised and was used to inject files on the entire server.</p>
<p>First you need to make sure your site&#8217;s file permissions are secure, depending on your host you may not be able to see the entire ACL (access control list) for your files. If that&#8217;s the case just ask them to double check to make sure no random Windows users groups have write permissions to your files.</p>
<p>Second also verify the original compromise was not an FTP compromise. Have your host check the FTP logs from the day your files were injected. If it was an FTP compromise, update your passwords and scan all workstations used to connect via FTP for viruses, loggers, sniffers, etc..</p>
<p>If it wasn&#8217;t an FTP compromise have your host double check the sandbox securities in ColdFusion admin and verify that no other sites have something stupid like recursive write access to the directory where all the websites are stored.</p>
<p>Assuming your site is on a Windows server have your host setup Windows file auditing/logging for the EVERYONE group on a few of the files that got injected previously. That way if it does happen again you (well, your host) will have evidence of what Windows user wrote to the file.</p>
<p>Hope that helps.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim</title>
		<link>http://jw0rd.net/2009/02/14/visual-studio-as-a-powerful-search-and-replace-tool/comment-page-1/#comment-14</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Thu, 05 Mar 2009 15:38:31 +0000</pubDate>
		<guid isPermaLink="false">http://jw0rd.net/?p=138#comment-14</guid>
		<description>May I ask for more details about the injection itself, specifically how it happened and how you resolved it?  You mentioned &quot;getting permissions in order&quot;.  Could you elaborate?  I&#039;m asking because I have a Coldfusion site that has fallen victim to the same compromise.  I can repair the damage just fine, but I&#039;m not sure how to prevent it from happening again.  

Thanks!</description>
		<content:encoded><![CDATA[<p>May I ask for more details about the injection itself, specifically how it happened and how you resolved it?  You mentioned &#8220;getting permissions in order&#8221;.  Could you elaborate?  I&#8217;m asking because I have a Coldfusion site that has fallen victim to the same compromise.  I can repair the damage just fine, but I&#8217;m not sure how to prevent it from happening again.  </p>
<p>Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://jw0rd.net/2009/02/14/visual-studio-as-a-powerful-search-and-replace-tool/comment-page-1/#comment-13</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Mon, 02 Mar 2009 19:55:51 +0000</pubDate>
		<guid isPermaLink="false">http://jw0rd.net/?p=138#comment-13</guid>
		<description>SQL injection is a completely different subject. The injections I spoke of above were directly in files, not in database records. It was also file permissions related.

Preventing SQL injection is a matter of sanitizing all GET and POST variables.

http://en.wikipedia.org/wiki/SQL_injection#Preventing_SQL_Injection</description>
		<content:encoded><![CDATA[<p>SQL injection is a completely different subject. The injections I spoke of above were directly in files, not in database records. It was also file permissions related.</p>
<p>Preventing SQL injection is a matter of sanitizing all GET and POST variables.</p>
<p><a href="http://en.wikipedia.org/wiki/SQL_injection#Preventing_SQL_Injection" rel="nofollow">http://en.wikipedia.org/wiki/SQL_injection#Preventing_SQL_Injection</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Koyst</title>
		<link>http://jw0rd.net/2009/02/14/visual-studio-as-a-powerful-search-and-replace-tool/comment-page-1/#comment-12</link>
		<dc:creator>Koyst</dc:creator>
		<pubDate>Mon, 02 Mar 2009 17:18:10 +0000</pubDate>
		<guid isPermaLink="false">http://jw0rd.net/?p=138#comment-12</guid>
		<description>How did you stop theSQL injection?</description>
		<content:encoded><![CDATA[<p>How did you stop theSQL injection?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
