<?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: Simple Lesson on Secure Cookies</title>
	<atom:link href="http://xs-sniper.com/blog/2008/09/09/secure-cookies/feed/" rel="self" type="application/rss+xml" />
	<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/</link>
	<description>Thoughts on Security in an Uncivilized World…</description>
	<lastBuildDate>Wed, 08 Sep 2010 02:39:08 -0700</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Mike</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-833</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Tue, 29 Sep 2009 20:53:47 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-833</guid>
		<description>I completely agree with this article.  However, I would like to point out that the fact that browsers have to provide a bypass for certs is in part due to the fact that some websites don&#039;t do their certs right or let them expire - and yes, without the bypass, it would break the web.  I just wanted to make sure that we acknowledge that the cert issue is due mostly to laziness on the part of the website admin.</description>
		<content:encoded><![CDATA[<p>I completely agree with this article.  However, I would like to point out that the fact that browsers have to provide a bypass for certs is in part due to the fact that some websites don&#8217;t do their certs right or let them expire &#8211; and yes, without the bypass, it would break the web.  I just wanted to make sure that we acknowledge that the cert issue is due mostly to laziness on the part of the website admin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-672</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sat, 27 Sep 2008 12:23:39 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-672</guid>
		<description>Sorry, example HTML got stripped out of my comment. The image tag would look like this:

{img src=&quot;http://www.facebook.com/favicon.ico&quot;}

where { and } are replaced by less-than and greater-than symbols</description>
		<content:encoded><![CDATA[<p>Sorry, example HTML got stripped out of my comment. The image tag would look like this:</p>
<p>{img src=&#8221;http://www.facebook.com/favicon.ico&#8221;}</p>
<p>where { and } are replaced by less-than and greater-than symbols</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-671</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sat, 27 Sep 2008 12:20:59 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-671</guid>
		<description>@Andre Gironda: I don&#039;t think you understand the vulnerability caused by insecure session cookies. Even though you are restricting your own navigating to HTTPS-only, it is amazingly for an attacker to force your browser to send your cookies over an insecure connection (non-HTTPS). That&#039;s why it&#039;s so big a problem.

For example, to force a browser to leak all of its Facebook cookies, insert an image tag like this into ANY web page your browser loads ANYWHERE:


Now that the attacker has read the session cookies that you&#039;ve leaked, he can simply copy them to his own browser and browse away as if he were you.

(Facebook was used as a simple and well-known example target. Obviously this has security implications far beyond Facebook, most worryingly for banking and other financial websites.)</description>
		<content:encoded><![CDATA[<p>@Andre Gironda: I don&#8217;t think you understand the vulnerability caused by insecure session cookies. Even though you are restricting your own navigating to HTTPS-only, it is amazingly for an attacker to force your browser to send your cookies over an insecure connection (non-HTTPS). That&#8217;s why it&#8217;s so big a problem.</p>
<p>For example, to force a browser to leak all of its Facebook cookies, insert an image tag like this into ANY web page your browser loads ANYWHERE:</p>
<p>Now that the attacker has read the session cookies that you&#8217;ve leaked, he can simply copy them to his own browser and browse away as if he were you.</p>
<p>(Facebook was used as a simple and well-known example target. Obviously this has security implications far beyond Facebook, most worryingly for banking and other financial websites.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andre Gironda</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-632</link>
		<dc:creator>Andre Gironda</dc:creator>
		<pubDate>Fri, 12 Sep 2008 21:55:50 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-632</guid>
		<description>After playing around with .google.com, www.google.com, and mail.google.com cookies - it appears that one or all of the apps will still set an unencrypted SID cookie for .google.com.  Sigh.

I am going to stick with my old methods of doing things, which basically is &quot;never go to a Google domain of any kind unless it&#039;s SSL - when I&#039;m authenticated to any Google application, especially GMail&quot;.

As an example, GMail is marking this cookie without the secure flagh
gmailchat=username@gmail.com/111111</description>
		<content:encoded><![CDATA[<p>After playing around with .google.com, <a href="http://www.google.com" rel="nofollow">http://www.google.com</a>, and mail.google.com cookies &#8211; it appears that one or all of the apps will still set an unencrypted SID cookie for .google.com.  Sigh.</p>
<p>I am going to stick with my old methods of doing things, which basically is &#8220;never go to a Google domain of any kind unless it&#8217;s SSL &#8211; when I&#8217;m authenticated to any Google application, especially GMail&#8221;.</p>
<p>As an example, GMail is marking this cookie without the secure flagh<br />
gmailchat=username@gmail.com/111111</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dylan Kelcher</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-631</link>
		<dc:creator>Dylan Kelcher</dc:creator>
		<pubDate>Fri, 12 Sep 2008 20:46:30 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-631</guid>
		<description>Yes, yes and yes.  Great stuff, thank you.

I&#039;m working on a few Greasemonkey scripts (to be ported to an extension later on) for just this very thing.

My first visit to your site, but based on this, you&#039;re a bookmarked regular now.  Many thanks brother.</description>
		<content:encoded><![CDATA[<p>Yes, yes and yes.  Great stuff, thank you.</p>
<p>I&#8217;m working on a few Greasemonkey scripts (to be ported to an extension later on) for just this very thing.</p>
<p>My first visit to your site, but based on this, you&#8217;re a bookmarked regular now.  Many thanks brother.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lesson on Secure Cookies &#171; 100% free</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-630</link>
		<dc:creator>Lesson on Secure Cookies &#171; 100% free</dc:creator>
		<pubDate>Thu, 11 Sep 2008 07:12:45 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-630</guid>
		<description>[...] Article Source (Continued) [...]</description>
		<content:encoded><![CDATA[<p>[...] Article Source (Continued) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andre Gironda</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-623</link>
		<dc:creator>Andre Gironda</dc:creator>
		<pubDate>Wed, 10 Sep 2008 00:18:12 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-623</guid>
		<description>MikeA: I use Firecookie, too.

I used to use Add N Edit Cookies.  I still use CookieCuller to mark cookies as protected (for ones that I want to keep around a long time).  Although setting cookies as secure doesn&#039;t have the same feeling if I have to do it manually.

Billy&#039;s method is neat (especially if automated with Technika) and gave me some new ideas.  Rock on!</description>
		<content:encoded><![CDATA[<p>MikeA: I use Firecookie, too.</p>
<p>I used to use Add N Edit Cookies.  I still use CookieCuller to mark cookies as protected (for ones that I want to keep around a long time).  Although setting cookies as secure doesn&#8217;t have the same feeling if I have to do it manually.</p>
<p>Billy&#8217;s method is neat (especially if automated with Technika) and gave me some new ideas.  Rock on!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike A.</title>
		<link>http://xs-sniper.com/blog/2008/09/09/secure-cookies/comment-page-1/#comment-622</link>
		<dc:creator>Mike A.</dc:creator>
		<pubDate>Tue, 09 Sep 2008 12:28:40 +0000</pubDate>
		<guid isPermaLink="false">http://xs-sniper.com/blog/?p=144#comment-622</guid>
		<description>&quot;we could also use a browser plugin with a nice UI and fine grained control over each cookie attribute…&quot;

The Firecookie add-on can be used to edit cookies and set them to secure.</description>
		<content:encoded><![CDATA[<p>&#8220;we could also use a browser plugin with a nice UI and fine grained control over each cookie attribute…&#8221;</p>
<p>The Firecookie add-on can be used to edit cookies and set them to secure.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.513 seconds -->
