<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title><![CDATA[[SecurityRatty] tag: foolproof]]></title>
    <link>http://securityratty.com/tag/foolproof</link>
    <description></description>
    <pubDate>Tue, 04 Dec 2007 05:56:00 +0000</pubDate>
    <generator>iRatty Engine</generator>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <item>
      <title><![CDATA[Proxy Caches are a Challenging Threat to Internet Security]]></title>
      <link>http://securityratty.com/article/39c5fc50305be98bca63ce241a75ebbd</link>
      <guid>http://securityratty.com/article/39c5fc50305be98bca63ce241a75ebbd</guid>
      <description><![CDATA[Proxy caches, combined with poorly written session management code, can easily leads to serious security flaws similar to what we highlighted in A New Security Breach in Google Docs Revealed
Web...]]></description>
      <content:encoded><![CDATA[<div class="entry-body">
<p>Proxy caches, combined with poorly written session management code, can easily leads to serious security flaws similar to what we highlighted in <a href="http://blog.isc2.org/isc2_blog/2008/09/serious-securit.html">A New Security Breach in Google Docs Revealed</a>.</p>
<p>Web developers have no control over proxy caches in the Internet. However, developers do have control of the code they write and their admin teams have configuration control of their web servers. Developers must assume the worst case Internet scenario with aggressive Internet cache management policies that serve cached data for economic and performance reasons.</p>
<p>As a consequence, this fact-of-life on the Internet sometimes results in multiple web clients being sent the same Set-Cookie HTTP headers, for example.  Caching proxy servers should obtain a fresh cookie for the each new client request. Ideally, proxy caches should not cache session management cookies and distribute cached cookies to multiple clients. However, application developers cannot assume that proxy caches are well behaved, especially for applications where security and privacy are required.</p>
<p>Web developers cannot know whether their content is consumed directly or via a proxy cache. Developers also cannot assume that the HTTP responses will be delivered to the intended browser. Moreover, developers cannot be sure that the intended browser even receives the intended content.  For example, a session ID issued to a client gets used while it is valid or until abandoned and expired. If it is served and delivered in response to an unencrypted HTTP GET request, there’s no guarantee it will be consumed by the intended web browser.</p>
<p>Ideally, SSL should be used on all web transactions that require confidentiality and privacy, including our recent <a href="http://blog.isc2.org/isc2_blog/2008/09/serious-securit.html">Google Docs breach</a>.  On the other hand, even SSL is not foolproof. For example, many web developers do not correctly set the &#8220;Encrypted Sessions Only&#8221; cookie property. These incorrectly configured “secure” servers will send HTTPS cookies in the open, unencrypted.</p>
<p>There be dragons &#8230;</p>
</div>
<hr />Note: Reposted from the <a href="http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html" target="_blank">(ISC)2 blog</a>.</p>
]]></content:encoded>
      <pubDate>Sun, 05 Oct 2008 06:41:52 +0000</pubDate>
      <category domain="http://securityratty.com/tag/proxy caches">proxy caches</category>
      <category domain="http://securityratty.com/tag/security">security</category>
      <category domain="http://securityratty.com/tag/web developers">web developers</category>
      <category domain="http://securityratty.com/tag/developers">developers</category>
      <category domain="http://securityratty.com/tag/internet">internet</category>
      <category domain="http://securityratty.com/tag/application developers">application developers</category>
      <category domain="http://securityratty.com/tag/security flaws similar">security flaws similar</category>
      <category domain="http://securityratty.com/tag/session management code">session management code</category>
      <category domain="http://securityratty.com/tag/code">code</category>
      <source url="http://www.thecepblog.com/2008/10/05/proxy-caches-are-a-challenging-threat-to-internet-security/">Proxy Caches are a Challenging Threat to Internet Security</source>
    </item>
    <item>
      <title><![CDATA[Mashup of the Titans]]></title>
      <link>http://securityratty.com/article/6289294023616c0d4219941919c976a5</link>
      <guid>http://securityratty.com/article/6289294023616c0d4219941919c976a5</guid>
      <description><![CDATA[Information Security - an Oxymoron for the information age

Always the beautiful answer who asks a more beautiful question. e. e. cummings
or why i am with Gelernter

This is a mashup of Saltzer &amp;...]]></description>
      <content:encoded><![CDATA[<div>Information Security - an Oxymoron for the information age</div><br /><div>“Always the beautiful answer who asks a more beautiful question.” e. e. cummings</div><div>...or why i am with Gelernter</div><br /><div>This is a mashup of Saltzer &amp; Schroeder&#39;s famous <a href="http://www.cs.virginia.edu/~evans/cs551/saltzer/">information security principles</a> with David Gelernter&#39;s <a href="http://www.edge.org/documents/archive/edge70.html">Manifesto</a>.</div><br /><div>The premise of this mashup is to examine the paper by Saltzer and Schroeder which was written in 1975 and serves as the basis for most information security programs against the Gelernter&#39;s manifesto as to where computing is actually going. Each of the eight principles in Saltzer and Schroeder&#39;s paper is listed in order, and followed by select excerpts of Gelernter&#39;s manifesto. This comparison is to examine theoretical information security principles vis a vis the actual utility of modern information systems. I will not make an attempt to reconcile theory and practice, but will point out where the two schools of thought agree. In fairness, Saltzer and Schroeder&#39;s paper was written 25 years before Gelernter&#39;s, however Saltzer and Schroeder&#39;s principles dominate the thinking about information security to this day and so its important to view them side by side with Gelernter&#39;s thinking on the direction of computing.</div><br /><div style="color: #bf5f00; ">Saltzer and Schroeder:</div><div>&quot;a) Economy of mechanism: Keep the design as simple and small as possible. This well-known principle applies to any aspect of a system, but it deserves emphasis for protection mechanisms for this reason: design and implementation errors that result in unwanted access paths will not be noticed during normal use (since normal use usually does not include attempts to exercise improper access paths). As a result, techniques such as line-by-line inspection of software and physical examination of hardware that implements protection mechanisms are necessary. For such techniques to be successful, a small and simple design is essential.&quot;</div><br /><div style="color: #0060bf; ">Gelernter:</div><div>&quot;9. The computing future is based on &quot;cyberbodies&quot; — self-contained, neatly-ordered, beautifully-laid-out collections of information, like immaculate giant gardens.&quot;</div><br /><div><span style="color: #00bf00; ">Conclusion(gp):</span>&#0160;So far, so good</div><br /><div>**</div><br /><div><span style="color: #bf5f00; ">Saltzer and Schroeder:</span><br /></div><div>&quot;b) Fail-safe defaults: Base access decisions on permission rather than exclusion. This principle, suggested by E. Glaser in 1965,8 means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation.&quot;</div><br /><div><span style="color: #00bf00; ">Conclusion(gp):</span>&#0160;A conservative design principle that puts the object&#39;s owner in control of permissions. This makes a lot of sense from the object point of view, but does little to address the use case in which it executes.</div><br /><div>**</div><br /><div><span style="color: #bf5f00; ">Saltzer and Schroeder:</span><br /></div><div>&quot;c) Complete mediation: Every access to every object must be checked for authority. This principle, when systematically applied, is the primary underpinning of the protection system. It forces a system-wide view of access control, which in addition to normal operation includes initialization, recovery, shutdown, and maintenance. It implies that a foolproof method of identifying the source of every request must be devised. It also requires that proposals to gain performance by remembering the result of an authority check be examined skeptically. If a change in authority occurs, such remembered results must be systematically updated.&quot;</div><br /><div><span style="color: #0060bf; ">Gelernter:</span><br /></div><div>&quot;8. The software systems we depend on most today are operating systems (Unix, the Macintosh OS, Windows et. al.) and browsers (Internet Explorer, Netscape Communicator...). Operating systems are connectors that fasten users to computers; they attach to the computer at one end, the user at the other. Browsers fasten users to remote computers, to &quot;servers&quot; on the internet.</div><br /><div>Today&#39;s operating systems and browsers are obsolete because people no longer want to be connected to computers — near ones OR remote ones. (They probably never did). They want to be connected to information. In the future, people are connected to cyberbodies; cyberbodies drift in the computational cosmos — also known as the Swarm, the Cybersphere.</div><br /><div>13. Any well-designed next-generation electronic gadget will come with a ``Disable Omniscience&#39;&#39; button.</div><br /><div>17. A cyberbody can be replicated or distributed over many computers; can inhabit many computers at the same time. If the Cybersphere&#39;s computers are tiles in a paved courtyard, a cyberbody is a cloud&#39;s drifting shadow covering many tiles simultaneously.</div><br /><div>20. If a million people use a Web site simultaneously, doesn&#39;t that mean that we must have a heavy-duty remote server to keep them all happy? No; we could move the site onto a million desktops and use the internet for coordination. The &quot;site&quot; is like a military unit in the field, the general moving with his troops (or like a hockey team in constant swarming motion). (We used essentially this technique to build the first tuple space implementations. They seemed to depend on a shared server, but the server was an illusion; there was no server, just a swarm of clients.) Could Amazon.com be an itinerant horde instead of a fixed Central Command Post? Yes.&quot;</div><br /><div><span style="color: #00bf00; ">Conclusion(gp):</span>&#0160;Complete mediation provides the underpinning for Saltzer and Schroeder&#39;s system, but does not appear to scale to the desired itinerant horde at least in common interpretation.</div><br /><div>**</div><br /><div><span style="color: #bf5f00; ">Saltzer and Schroeder:</span><br /></div><div>&quot;d) Open design: The design should not be secret. The mechanisms should not depend on the ignorance of potential attackers, but rather on the possession of specific, more easily protected, keys or passwords. This decoupling of protection mechanisms from protection keys permits the mechanisms to be examined by many reviewers without concern that the review may itself compromise the safeguards. In addition, any skeptical user may be allowed to convince himself that the system he is about to use is adequate for his purpose. Finally, it is simply not realistic to attempt to maintain secrecy for any system which receives wide distribution.&quot;</div><br /><div><span style="color: #00bf00; ">Conclusion(gp):</span>&#0160;both seem to agree, hard to get the itinerant horde moving in a swarm without open standards.</div><br /><div>**</div><br /><div><span style="color: #bf5f00; ">Saltzer and Schroeder:</span><br /></div><div>&quot;e) Separation of privilege: Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key. The relevance of this observation to computer systems was pointed out by R. Needham in 1973. The reason is that, once the mechanism is locked, the two keys can be physically separated and distinct programs, organizations, or individuals made responsible for them. From then on, no single accident, deception, or breach of trust is sufficient to compromise the protected information. This principle is often used in bank safe-deposit boxes. It is also at work in the defense system that fires a nuclear weapon only if two different people both give the correct command. In a computer system, separated keys apply to any situation in which two or more conditions must be met before access should be permitted. For example, systems providing user-extendible protected data types usually depend on separation of privilege for their implementation.&quot;</div><br /><div><span style="color: #0060bf; ">Gelernter:</span><br /></div><div>&quot;37. Elements stored in a mind do not have names and are not organized into folders; are retrieved not by name or folder but by contents. (Hear a voice, think of a face: you&#39;ve retrieved a memory that contains the voice as one component.) You can see everything in your memory from the standpoint of past, present and future. Using a file cabinet, you classify information when you put it in; minds classify information when it is taken out. (Yesterday afternoon at four you stood with Natasha on Fifth Avenue in the rain — as you might recall when you are thinking about &quot;Fifth Avenue,&quot; &quot;rain,&quot; &quot;Natasha&quot; or many other things. But you attached no such labels to the memory when you acquired it. The classification happened retrospectively.)&quot;</div><br /><div><span style="color: #00bf00; ">Conclusion(gp):</span>&#0160;Information Security models tend to look at things statically through information classification lenses, but its how information is used that makes it valuable. In practice this is how information security theory breaks down in the face of reality - what does an access control matrix look like for a mashup? What does it look like for a data mining app?</div><br /><div>**</div><br /><div><span style="color: #bf5f00; ">Saltzer and Schroeder:</span><br /></div><div>&quot;f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide &quot;firewalls,&quot; the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of &quot;need-to-know&quot; is an example of this principle.&quot;</div><br /><div><span style="color: #0060bf; ">Gelernter:</span><br /></div><div>&quot;28. Metaphors have a profound effect on computing: the file-cabinet metaphor traps us in a &quot;passive&quot; instead of &quot;active&quot; view of information management that is fundamentally wrong for computers.</div><br /><div>29. The rigid file and directory system you are stuck with on your Mac or PC was designed by programmers for programmers — and is still a good system for programmers. It is no good for non-programmers. It never was, and was never intended to be.</div><br /><div>30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don&#39;t bother. Nowadays the idea of giving a name to every file on your computer is ridiculous.&quot;</div><br /><div><span style="color: #00bf00; ">Conclusion(gp):</span>&#0160;Least Privilege is the point where the practical matter of applying Saltzer and Schroeder&#39;s principles breaks down in modern systems. Its a deployment issue, and a matter of insufficient models and modes.</div><br /><div>**</div><br /><div><span style="color: #bf5f00; ">Saltzer and Schroeder:</span><br /></div><div>&quot;g) Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users [28]. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security. Further, any mechanism serving all users must be certified to the satisfaction of every user, a job presumably harder than satisfying only one or a few users. For example, given the choice of implementing a new function as a supervisor procedure shared by all users or as a library procedure that can be handled as though it were the user&#39;s own, choose the latter course. Then, if one or a few users are not satisfied with the level of certification of the function, they can provide a substitute or not use it at all. Either way, they can avoid being harmed by a mistake in it.&quot;</div><br /><div><span style="color: #0060bf; ">Gelernter:</span><br /></div><div>&quot;6. Miniaturization was the big theme in the first age of computers: rising power, falling prices, computers for everybody. Theme of the Second Age now approaching: computing transcends computers. Information travels through a sea of anonymous, interchangeable computers like a breeze through tall grass. A dekstop computer is a scooped-out hole in the beach where information from the Cybersphere wells up like seawater.</div><br /><div>16. The future is dense with computers. They will hang around everywhere in lush growths like Spanish moss. They will swarm like locusts. But a swarm is not merely a big crowd. The individuals in the swarm lose their identities. The computers that make up this global swarm will blend together into the seamless substance of the Cybersphere. Within the swarm, individual computers will be as anonymous as molecules of air.</div><br /><div>55. Software can solve hard problems in two ways: by algorithm or by making connections — by delivering the problem to exactly the right human problem-solver. The second technique is just as powerful as the first, but so far we have ignored it.</div><br /><div>56. Lifestreams and microcosms are the two most important cyberbody types; they relate to each other as a single musical line relates to a single chord. The stream is a &quot;moment in space,&quot; the microcosm a moment in time.&quot;</div><br /><div>**</div><br /><div><span style="color: #bf5f00; ">Saltzer and Schroeder:</span><br /></div><div>&quot;h) Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user&#39;s mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If he must translate his image of his protection needs into a radically different specification language, he will make errors.&quot;</div><br /><div><span style="color: #0060bf; ">Gelernter:</span><br /></div><div>&quot;7. &quot;The network is the computer&quot; — yes; but we&#39;re less interested in computers all the time. The real topic in astronomy is the cosmos, not telescopes. The real topic in computing is the Cybersphere and the cyberstructures in it, not the computers we use as telescopes and tuners.</div><br /><div>27. Modern computing is based on an analogy between computers and file cabinets that is fundamentally wrong and affects nearly every move we make. (We store &quot;files&quot; on disks, write &quot;records,&quot; organize files into &quot;folders&quot; — file-cabinet language.) Computers are fundamentally unlike file cabinets because they can take action.</div><br /><div>31. Our standard policy on file names has far-reaching consequences: doesn&#39;t merely force us to make up names where no name is called for; also imposes strong limits on our handling of an important class of documents — ones that arrive from the outside world. A newly-arrived email message (for example) can&#39;t stand on its own as a separate document — can&#39;t show up alongside other files in searches, sit by itself on the desktop, be opened or printed independently; it has no name, so it must be buried on arrival inside some existing file (the mail file) that does have a name. The same holds for incoming photos and faxes, Web bookmarks, scanned images...</div><br /><div>32. You shouldn&#39;t have to put files in directories. The directories should reach out and take them. If a file belongs in six directories, all six should reach out and grab it automatically, simultaneously.</div><br /><div>33. A file should be allowed to have no name, one name or many names. Many files should be allowed to share one name. A file should be allowed to be in no directory, one directory, or many directories. Many files should be allowed to share one directory. Of these eight possibilities, only three are legal and the other five are banned — for no good reason.</div><br /><div>53. Your car, your school, your company and yourself are all one-track vehicles moving forward through time, and they will each leave a stream-shaped cyberbody (like an aircraft&#39;s contrail) behind them as they go. These vapor-trails of crystallized experience will represent our first concrete answer to a hard question: what is a company, a university, any sort of ongoing organization or institution, if its staff and customers and owners can all change, its buildings be bulldozed, its site relocated — what&#39;s left? What is it? The answer: a lifestream in cyberspace.&quot;</div><br /><br /><div>**</div><div style="color: #00bf00; ">Conclusion(gp):</div><br /><div>The Saltzer and Schroeder principles of Open Design and Economy of Mechanism hold up well in the face of modern computing realities, and to a certain extent Fail Safe Defaults does as well; however if we information security people are to be effective we need to re-think the other principles.</div><br /><div>**</div><br /><div>Last word:&#0160;<span style="color: #0060bf; ">Gelernter:</span></div><div>We&#39;ll know the system is working when a butterfly wanders into the in-box and (a few wingbeats later) flutters out — and in that brief interval the system has transcribed the creature&#39;s appearance and analyzed its way of moving, and the real butterfly leaves a shadow-butterfly behind. Some time soon afterward you&#39;ll be examining some tedious electronic document and a cyber-butterfly will appear at the bottom left corner of your screen (maybe a Hamearis lucina) and pause there, briefly hiding the text (and showing its neatly-folded rusty-chocolate wings like Victorian paisley, with orange eyespots) — and moments later will have crossed the screen and be gone.</div>]]></content:encoded>
      <pubDate>Wed, 25 Jun 2008 13:29:25 +0000</pubDate>
      <category domain="http://securityratty.com/tag/protection mechanisms">protection mechanisms</category>
      <category domain="http://securityratty.com/tag/protection mechanisms correctly">protection mechanisms correctly</category>
      <category domain="http://securityratty.com/tag/information security">information security</category>
      <category domain="http://securityratty.com/tag/information">information</category>
      <category domain="http://securityratty.com/tag/implements protection mechanisms">implements protection mechanisms</category>
      <category domain="http://securityratty.com/tag/information travels">information travels</category>
      <category domain="http://securityratty.com/tag/information security people">information security people</category>
      <category domain="http://securityratty.com/tag/protection">protection</category>
      <category domain="http://securityratty.com/tag/potential information path">potential information path</category>
      <source url="http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html">Mashup of the Titans</source>
    </item>
    <item>
      <title><![CDATA[Errors in Quantum Cryptography?]]></title>
      <link>http://securityratty.com/article/bfcdb4c88925dad98f5203934b920e91</link>
      <guid>http://securityratty.com/article/bfcdb4c88925dad98f5203934b920e91</guid>
      <description><![CDATA[Interesting research from Sweden - apparently researchers were able to unexpectedly find a flaw in quantum cryptography, the holy grail of 100%, bullet-proof encryption

The researcher quotes - &quot;We...]]></description>
      <content:encoded><![CDATA[Interesting <a href="http://afp.google.com/article/ALeqM5gmBpOJKKPRHgAy6P5cRzIN62Zk5A">research from Sweden </a>- apparently researchers were able to unexpectedly find a flaw in quantum cryptography, the holy grail of 100%, bullet-proof encryption!<br /><br />The researcher quotes - "We didn't expect to find a flaw". Makes one wonder if there is any technology that can claim it.<br /><br />I think there are no foolproof solutions, only fools (maybe too strong a word, but the rhyming was too good to pass up!) who believe so...<div class="feedflare">
<a href="http://feeds.feedburner.com/~f/BitArmor1?a=8uEQyOG"><img src="http://feeds.feedburner.com/~f/BitArmor1?i=8uEQyOG" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/BitArmor1?a=TqhFzbg"><img src="http://feeds.feedburner.com/~f/BitArmor1?i=TqhFzbg" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/BitArmor1?a=9jNSbiG"><img src="http://feeds.feedburner.com/~f/BitArmor1?i=9jNSbiG" border="0"></img></a>
</div><img src="http://feeds.feedburner.com/~r/BitArmor1/~4/274693000" height="1" width="1"/>]]></content:encoded>
      <pubDate>Mon, 21 Apr 2008 09:02:00 +0000</pubDate>
      <category domain="http://securityratty.com/tag/quantum cryptography">quantum cryptography</category>
      <category domain="http://securityratty.com/tag/foolproof solutions">foolproof solutions</category>
      <category domain="http://securityratty.com/tag/flaw">flaw</category>
      <category domain="http://securityratty.com/tag/apparently researchers">apparently researchers</category>
      <category domain="http://securityratty.com/tag/researcher quotes">researcher quotes</category>
      <category domain="http://securityratty.com/tag/bullet-proof encryption">bullet-proof encryption</category>
      <category domain="http://securityratty.com/tag/holy grail">holy grail</category>
      <category domain="http://securityratty.com/tag/unexpectedly">unexpectedly</category>
      <category domain="http://securityratty.com/tag/research">research</category>
      <source url="http://feeds.feedburner.com/~r/BitArmor1/~3/274693000/errors-in-quantum-cryptography.html">Errors in Quantum Cryptography?</source>
    </item>
    <item>
      <title><![CDATA[When typos attack]]></title>
      <link>http://securityratty.com/article/f4d9ebc893c69858789c3a0688d8f946</link>
      <guid>http://securityratty.com/article/f4d9ebc893c69858789c3a0688d8f946</guid>
      <description><![CDATA[We all make mistakes. In my case, it's pretty much all through the day. I tend to type pretty fast and let spell checker figure it out. But in the case of browsing the web, these innocent typos may...]]></description>
      <content:encoded><![CDATA[<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.typolover.com/images/TYPO.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://www.typolover.com/images/TYPO.jpg" alt="" border="0" /></a><br />We all make mistakes. In my case, it's pretty much all through the day. I tend to type pretty fast and let spell checker figure it out. But in the case of browsing the web, these innocent typos may not be so innocent.<br /><br />According to a recent McAfee study, <a href="http://biz.yahoo.com/prnews/071119/aqm043.html?.v=24">a new attack vector is called "typo-squatting,"</a> which preys upon the folks that make simple typos when browsing. The bad guys register domains that seem like the one you are looking for. Then the fun begins. "<span style="font-style: italic;">These squatter-run sites generate click-through advertising revenues, lure unsuspecting consumers into scams and harvest email addresses to flood users with unwanted email.</span>"<br /><br />Since drive-by Trojans and other nasty web attacks don't need user interaction anymore, it's all the more important to make sure your devices are configured securely. Right, that's Step 2 in <a href="http://www.securitymike.com/">Security Mike's Guide</a>. Step 3 focuses on securely configuring your browser.<br /><br />Over the next week or so, when Step 4 goes live, you'll also learn about a utility that plugs into your browser to show whether a web site is good. None of these methods are totally foolproof, but the more layers of security you have, the more likely you won't get nailed.<div class="feedflare">
<a href="http://feeds.feedburner.com/~f/SecurityMike?a=faGpciC"><img src="http://feeds.feedburner.com/~f/SecurityMike?i=faGpciC" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/SecurityMike?a=4iMkoWc"><img src="http://feeds.feedburner.com/~f/SecurityMike?i=4iMkoWc" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/SecurityMike?a=I9pvLuc"><img src="http://feeds.feedburner.com/~f/SecurityMike?i=I9pvLuc" border="0"></img></a>
</div><img src="http://feeds.feedburner.com/~r/SecurityMike/~4/194959561" height="1" width="1"/>]]></content:encoded>
      <pubDate>Tue, 04 Dec 2007 05:56:00 +0000</pubDate>
      <category domain="http://securityratty.com/tag/nasty web attacks">nasty web attacks</category>
      <category domain="http://securityratty.com/tag/web">web</category>
      <category domain="http://securityratty.com/tag/type pretty fast">type pretty fast</category>
      <category domain="http://securityratty.com/tag/pretty">pretty</category>
      <category domain="http://securityratty.com/tag/web site">web site</category>
      <category domain="http://securityratty.com/tag/email">email</category>
      <category domain="http://securityratty.com/tag/step">step</category>
      <category domain="http://securityratty.com/tag/innocent typos">innocent typos</category>
      <category domain="http://securityratty.com/tag/security">security</category>
      <source url="http://feeds.feedburner.com/~r/SecurityMike/~3/194959561/when-typos-attack.html">When typos attack</source>
    </item>
  </channel>
</rss>
