<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="wordpress/2.2.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>

<channel>
	<title>StraightSecTalk</title>
	<link>http://www.straightsectalk.com</link>
	<description>Real security issues. Real answers.</description>
	<pubDate>Mon, 08 Jun 2009 03:28:41 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>
	<language>en</language>
			<item>
		<title>HTTP Request I Saw Today</title>
		<link>http://www.straightsectalk.com/?p=55</link>
		<comments>http://www.straightsectalk.com/?p=55#comments</comments>
		<pubDate>Mon, 08 Jun 2009 03:28:03 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[General]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=55</guid>
		<description><![CDATA[I just thought I would quickly share an HTTP request that I saw today. Here it is, a one-liner:
GET http://www.vmware.com/a/info/?id=290 HTTP/1.0
Calling this an HTTP request is actually pretty generous. It violates the protocol in just about every way imagineable. The fact that real programmers write this stuff illustrates just how hard it is to detect [...]]]></description>
			<content:encoded><![CDATA[<p>I just thought I would quickly share an HTTP request that I saw today. Here it is, a one-liner:</p>
<p>GET http://www.vmware.com/a/info/?id=290 HTTP/1.0</p>
<p>Calling this an HTTP request is actually pretty generous. It violates the protocol in just about every way imagineable. The fact that real programmers write this stuff illustrates just how hard it is to detect malicious web requests without raising any false positives.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=55</wfw:commentRss>
		</item>
		<item>
		<title>Finding the Right Rewards for Security Contests</title>
		<link>http://www.straightsectalk.com/?p=54</link>
		<comments>http://www.straightsectalk.com/?p=54#comments</comments>
		<pubDate>Fri, 17 Apr 2009 18:13:53 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Vulnerabilities]]></category>

		<category><![CDATA[Economics]]></category>

		<category><![CDATA[Articles]]></category>

		<category><![CDATA[Penetration Testing]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=54</guid>
		<description><![CDATA[At a recent Dagstuhl seminar on web application security, I spoke with Jasvir Nagra (one of the people at Google working on Caja) about the best way to run a public security contest. The goal of the contest would be to encourage people to find as many bugs as possible, with additional rewards for more [...]]]></description>
			<content:encoded><![CDATA[<p>At a recent Dagstuhl seminar on web application security, I spoke with Jasvir Nagra (one of the people at Google working on <a target="_blank" href="http://code.google.com/p/google-caja/">Caja</a>) about the best way to run a public security contest. The goal of the contest would be to encourage people to find as many bugs as possible, with additional rewards for more severe security vulnerabilities. As a starting point, we discussed the ongoing <a target="_blank" href="http://code.google.com/contests/nativeclient-security/">Google Native Client (NaCl) security contest</a>. For this contest, the top five bug-finders over a ten-week period receive recognition and cash prizes of $8192, $4096, $2048, $1024, and $1024. While this model has a few strong points, it also is problematic in the way that it incentivizes security research. This article discusses how to more effectively design a security contest.</p>
<p> <a href="http://www.straightsectalk.com/?p=54#more-54" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=54</wfw:commentRss>
		</item>
		<item>
		<title>Improving SSL Indicators</title>
		<link>http://www.straightsectalk.com/?p=51</link>
		<comments>http://www.straightsectalk.com/?p=51#comments</comments>
		<pubDate>Wed, 01 Apr 2009 19:48:54 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Phishing]]></category>

		<category><![CDATA[Usability]]></category>

		<category><![CDATA[Browsers]]></category>

		<category><![CDATA[Articles]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=51</guid>
		<description><![CDATA[Research has shown that most people are unable to tell whether they are at an authentic website that is using SSL encryption (see The Emperor&#8217;s New Security Indicators). This is part of the reason people are so susceptible to phishing. Web browsers provide enough information to tell if SSL is on, but it is presented [...]]]></description>
			<content:encoded><![CDATA[<p>Research has shown that most people are unable to tell whether they are at an authentic website that is using SSL encryption (see <a target="_blank" href="http://www.usablesecurity.org/emperor/emperor.pdf">The Emperor&#8217;s New Security Indicators</a>). This is part of the reason people are so susceptible to phishing. Web browsers provide enough information to tell if SSL is on, but it is presented in a poor manner (as a small lock icon). Other bad security practices, like the website embedding its own lock icon and saying &#8220;secure login&#8221;, make matters even worse.</p>
<p>The problem is that people tend to notice glaring differences, but do not take explicit steps to check for security. They shouldn&#8217;t have to. Firefox 3 tries to improve SSL indicators for &#8220;Extended Verification&#8221; certificates by displaying the company name in green to the left of the URL along with the fav-icon. It looks like this:</p>
<p><img src="http://www.straightsectalk.com/wp-content/uploads/2009/04/paypal.png" alt="PayPal EV Screenshot" /></p>
<p>Unfortunately, this indicator is still just text, plus an insecure/unsigned fav-icon. One must deliberately read it to verify the site&#8217;s identity, so it is likely to go unnoticed if the user is at a different site, just like like previous security indicators. If a hacker can compromise <em>any</em> site that has an EV certificate using cross-site scripting (a common problem on many sites), then he can create a believable phishing page. Sure, the company name will be different, but the fav-icon could presumably be spoofed and the address bar will still have the green indicator.</p>
<p> Firefox 3 SSL indicators for EV certificates are a much better than previous indicators, but there is still room for improvement. The problem is that there isn&#8217;t a striking visual difference between the security indicators for different sites with EV certificates. Confusion is possible, especially if one can spoof the fav-icon. What I propose is that each site with an EV certificate also sign a logo for display <em>in place of the hostname</em>. The logo should also be a registered trademark, which, by law, must be clearly different from other trademarks. In fact, the test for trademark violation is &#8220;confusion,&#8221; so using registered trademarks for EV certificates guarantees (legally) that there will be no visual confusion. Here is an example of what, in my mind, SSL indicators should look like:</p>
<p><img src="http://www.straightsectalk.com/wp-content/uploads/2009/04/paypalnew.png" alt="Proposed EV SSL Indicator" /></p>
<p>This way, any deviation from PayPal.com would immediately stand out to the user and serve as a much better indicator not only of SSL, but also the identity of the current site.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=51</wfw:commentRss>
		</item>
		<item>
		<title>Vigilante Justice for Blog Spammers?</title>
		<link>http://www.straightsectalk.com/?p=50</link>
		<comments>http://www.straightsectalk.com/?p=50#comments</comments>
		<pubDate>Mon, 26 Jan 2009 23:40:49 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Spam]]></category>

		<category><![CDATA[Fraud]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=50</guid>
		<description><![CDATA[ After receiving yet another blog spam post today, I decided to dig a bit deeper. The spammer was trying to get a comment onto this blog presumably to increase the page rank of another site, http://www.kerago.com. This is one of those illegitimate websites that contains a bunch of garbage content packed with keywords, and then [...]]]></description>
			<content:encoded><![CDATA[<p> After receiving yet another blog spam post today, I decided to dig a bit deeper. The spammer was trying to get a comment onto this blog presumably to increase the page rank of another site, <a href="http://www.kerago.com/">http://www.kerago.com</a>. This is one of those illegitimate websites that contains a bunch of garbage content packed with keywords, and then tries to get visitors to click on its sponsored links. Seeing this site got me wondering, if one started hammering the sponsored links in what would look like blatent click fraud, would Google shut down the website&#8217;s AdWords account? If this type of attack were launched a more legitimate site, the owners might be able to convince Google that they were not involved. However, since this website is already using shady tactics like blog spamming, its owners might have a harder time denying click fraud.This fake click fraud attack raises a number of interesting questions. First, is it illegal? The website owner has an agreement with Google to not click on their own links, but you as a visitor to the website do not. Perhaps if you wrote a script to send a very large number of clicks, then you might get hit with trying to disrupt a computer system, similar to what would happen if you ran a denial-of-service attack. If you just click on the links a lot, however, then how could that possibly be illegal? Second, would this be immoral? The issue leads back to the whole idea of vigilante justice. Someone else is harming you and others (spamming), so would retribution in the form of fake click fraud be justified? It is hard to say because you would not just be hurting the website owner, you would also be potentially hurting Google and the advertisers.The final question is: would Google actually shut down the website owner&#8217;s account, or just automatically filter out what appear to be fraudulent clicks and leave the rest of the website&#8217;s legitimate clicks alone? If the website owner claimed that they were not responsible for the fraudelent clicks and Google did not believe them, the owner could potentially take Google to court to get the money it deserved for legitimate clicks. It would be interesting to see who would prevail in this type of lawsuit.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=50</wfw:commentRss>
		</item>
		<item>
		<title>Botnet Back - How Did This Happen?</title>
		<link>http://www.straightsectalk.com/?p=49</link>
		<comments>http://www.straightsectalk.com/?p=49#comments</comments>
		<pubDate>Thu, 27 Nov 2008 17:13:37 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Malware]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=49</guid>
		<description><![CDATA[Computerworld recently reported on the shut down and subsequent resurrection of the Srizbi botnet. When the ISP hosting the Srizbi command and control (C&#38;C) servers was taken offline, spam levels for the entire Internet dropped by 41%. The welcome reduction in junk mail was short-lived, however, when hackers regained control of infected machines yesterday. After such [...]]]></description>
			<content:encoded><![CDATA[<p>Computerworld recently reported on the <a target="_blank" href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9119963">shut down</a> and <a target="_blank" href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9121678&amp;intsrc=hm_list">subsequent resurrection</a> of the Srizbi botnet. When the ISP hosting the Srizbi command and control (C&amp;C) servers was taken offline, spam levels for the <em>entire Internet</em> dropped by 41%. The welcome reduction in junk mail was short-lived, however, when hackers regained control of infected machines yesterday. After such a successful botnet take-down, how did authorities allow this to happen? Also, what did the hackers do wrong that allowed their botnet to be shut down for so long?</p>
<p> <a href="http://www.straightsectalk.com/?p=49#more-49" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=49</wfw:commentRss>
		</item>
		<item>
		<title>Effective Advertising on Facebook</title>
		<link>http://www.straightsectalk.com/?p=48</link>
		<comments>http://www.straightsectalk.com/?p=48#comments</comments>
		<pubDate>Fri, 21 Nov 2008 23:15:57 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Phishing]]></category>

		<category><![CDATA[Articles]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=48</guid>
		<description><![CDATA[This article covers a topic that is somewhat unrelated to computer security. However, Internet advertising does share some similarities with one security issue: phishing. Both cost-per-click (CPC) ads and phishing attacks use social engineering to elicit participation from the user. The main difference between phishing and advertising is that the former aims to deceive and [...]]]></description>
			<content:encoded><![CDATA[<p>This article covers a topic that is somewhat unrelated to computer security. However, Internet advertising does share some similarities with one security issue: phishing. Both cost-per-click (CPC) ads and phishing attacks use social engineering to elicit participation from the user. The main difference between phishing and advertising is that the former aims to deceive and defraud the user, while the latter tries to sell an actual product. This article discusses an approach for effective ad placement on social networks (Facebook, in particular). Some of the same principles could also be applied to deliver better context-aware phishing attacks or spam, which are described in a recent paper from our research group available <a href="http://www.eecs.umich.edu/~aprakash/papers/cscw08_socialnetworkspam.pdf">here</a>.</p>
<p> <a href="http://www.straightsectalk.com/?p=48#more-48" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=48</wfw:commentRss>
		</item>
		<item>
		<title>Google Chrome: The End of Drive-By Downloads</title>
		<link>http://www.straightsectalk.com/?p=47</link>
		<comments>http://www.straightsectalk.com/?p=47#comments</comments>
		<pubDate>Sat, 06 Sep 2008 05:25:56 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Vulnerabilities]]></category>

		<category><![CDATA[Browsers]]></category>

		<category><![CDATA[Articles]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=47</guid>
		<description><![CDATA[At the recent USENIX Security Symposium, Niels Provos, head of the security team at Google, gave a compelling presentation about the state of client-side web security (you can find research project details here). His research project involves idenfitying drive-by downloads and filtering them from Google search results. One conclusion of the analysis was that any [...]]]></description>
			<content:encoded><![CDATA[<p>At the recent USENIX Security Symposium, Niels Provos, head of the security team at Google, gave a compelling presentation about the state of client-side web security (you can find research project details <a href="http://googleonlinesecurity.blogspot.com/2008/02/all-your-iframe-are-point-to-us.html">here</a>). His research project involves idenfitying drive-by downloads and filtering them from Google search results. One conclusion of the analysis was that any type of site can be malicious. It is usually not the owner, but rather a hacker who places exploit code on websites. This seems to suggest that the only way to keep malware off of computers is to either stop browsing the web, or lock down the web browser.</p>
<p>As security experts, we know how to use a browsing sandbox like Sandboxie or a VMWare appliance. Try, however, to explain this to an average user. It is not a straightforward process. Most people do not even understand the necessity for such precautions. People need a secure browser that is easy to install and manage. An example of such a browser was GreenBorder, which Google bought and promptly took out of commission. During the Q&amp;A session following Niels&#8217; talk, I asked him (in more friendly terms) why Google bought the one browser that promised to improve web security and stopped selling it. At the time he was unable to comment on Google&#8217;s strategy, but now the answer is clear: Google Chrome.</p>
<p> <a href="http://www.straightsectalk.com/?p=47#more-47" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=47</wfw:commentRss>
		</item>
		<item>
		<title>Browser Usability Problems Trump Design Flaws</title>
		<link>http://www.straightsectalk.com/?p=46</link>
		<comments>http://www.straightsectalk.com/?p=46#comments</comments>
		<pubDate>Mon, 28 Jul 2008 17:25:41 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Usability]]></category>

		<category><![CDATA[Browsers]]></category>

		<category><![CDATA[Articles]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=46</guid>
		<description><![CDATA[Recent discussions about research on bank website design flaws (see Analyzing Websites for User-Visible Security Design Flaws) have brought up a few important points about web security. The research conducted by Dr. Prakash, Laura Falk, and myself addresses problems that preclude secure usage of bank websites by expert users. It does not consider how to [...]]]></description>
			<content:encoded><![CDATA[<p>Recent discussions about research on bank website design flaws (see <a href="http://cups.cs.cmu.edu/soups/2008/proceedings/p117Falk.pdf">Analyzing Websites for User-Visible Security Design Flaws</a>) have brought up a few important points about web security. The research conducted by Dr. Prakash, Laura Falk, and myself addresses problems that preclude secure usage of bank websites by expert users. It does not consider how to design websites in such a way that they are secure for <em>non-expert</em> users. In the recent study, we looked at bank websites that have login boxes on insecure pages. However, if a hacker has access to the network link, he or she could just direct customers to a page that doesn&#8217;t use SSL at all. How many people will notice the difference? This article looks at the severity of usability problems in secure web transactions, and what could be done in web browsers to fix them.</p>
<p> <a href="http://www.straightsectalk.com/?p=46#more-46" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=46</wfw:commentRss>
		</item>
		<item>
		<title>A Referrer Spam Anecdote</title>
		<link>http://www.straightsectalk.com/?p=45</link>
		<comments>http://www.straightsectalk.com/?p=45#comments</comments>
		<pubDate>Thu, 24 Jul 2008 17:45:17 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Spam]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=45</guid>
		<description><![CDATA[While I was going the logs for this website today, I noticed an interesting anomaly. One of the top ten links from an external page was a particularly shady website, http://www.bloggingtothebank.com/, which obviously did not contain a link to here. Looking into things a little deeper, I learned that so-called referrer spam is quite prevalent. [...]]]></description>
			<content:encoded><![CDATA[<p>While I was going the logs for this website today, I noticed an interesting anomaly. One of the top ten links from an external page was a particularly shady website, <a href="http://www.bloggingtothebank.com/">http://www.bloggingtothebank.com/</a>, which obviously did not contain a link to here. Looking into things a little deeper, I learned that so-called referrer spam is quite prevalent. In most cases, spammers will continuously hit well-known websites that publish their log statistics to inflate their page rank. This makes sense. However, what I noticed today was much more clever and insiduous. The logs from straightsectalk.com aren&#8217;t published anywhere. The spammer was actually targeting me - the owner of a blog website. Very clever. What will spammers do next?</p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=45</wfw:commentRss>
		</item>
		<item>
		<title>Bank Website Design Flaws Pose Serious Security Threat</title>
		<link>http://www.straightsectalk.com/?p=44</link>
		<comments>http://www.straightsectalk.com/?p=44#comments</comments>
		<pubDate>Thu, 24 Jul 2008 16:59:12 +0000</pubDate>
		<dc:creator>Kevin Borders</dc:creator>
		
		<category><![CDATA[Usability]]></category>

		<category><![CDATA[Web Applications]]></category>

		<category><![CDATA[Authentication]]></category>

		<category><![CDATA[Vulnerabilities]]></category>

		<category><![CDATA[Articles]]></category>

		<guid isPermaLink="false">http://www.straightsectalk.com/?p=44</guid>
		<description><![CDATA[The results of a recent study on security design flaws in banking websites will be presented tomorrow at the Symposium on Usability and Privacy. The research was conducted by Dr. Atul Prakash, Laura Falk, and myself (Kevin Borders). It found that flaws, such as presenting login information on an insecure page, were widespread. What does [...]]]></description>
			<content:encoded><![CDATA[<p>The results of a recent study on security design flaws in banking websites will be presented tomorrow at the <a href="http://cups.cs.cmu.edu/soups/2008/">Symposium on Usability and Privacy</a>. The research was conducted by Dr. Atul Prakash, Laura Falk, and myself (Kevin Borders). It found that flaws, such as presenting login information on an insecure page, were widespread. What does this mean for the security of the internet at large? Will hackers routinely exploit these vulnerabilities to conduct widespread fraud in the future? And, the most important question: how do we fix it?</p>
<p> <a href="http://www.straightsectalk.com/?p=44#more-44" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.straightsectalk.com/?feed=rss2&amp;p=44</wfw:commentRss>
		</item>
	</channel>
</rss>
