Preventing XSS Attacks

396 Chapter 9 • Preventing XSS Attacks

Introduction

Cross-site scripting (XSS) is a complex problem that is not going to go away anytime soon. Unlike most security-related issues, there is no quick fix that is acceptable for the majority. The problem is two-fold. First, the browser is not secure by design. It was created to make requests and process the results. This includes the ability to understand JavaScript, which is a standard programming language that Web developers can use to perform all sorts of functions, both good and bad. The browser doesn’t decide if a piece of code is doing something malicious. Cookie data is often called by valid programs. Accessing clipboard data is an approved feature of Internet Explorer (IE) 6.0. It isn’t the browser’s job to determine what code is good and what is bad.

The second problem, which compounds the issue, is that Web developers are not creating secure sites. As a result, attackers are able to exploit their vulnerable scripts and inject code into the user’s browser. So now the user is stuck between two impossible situations. They either have to disable all scripting ability, which will seriously dampen their Web browsing experience, or only visit Web sites they trust and know are secure.

In this section, we look at both sides of the equation. First, we examine the difficulties in setting up a solid foolproof filtering engine. As you will see, filtering is not a simple concept, and if not done exactly right it will fail. In fact, each and every person on this book project has made mistakes in creating their own filtering solutions due to the simple fact that browsers change, insecure code gets reused, and simple human error.

Following this, we will then look at some of the things you can do as a user to prevent yourself from becoming a victim. However, note that nothing will protect you like a bit of paranoia, a tad of common sense, and a solid understand of how the Internet works.

Filtering

There are two basic XSS filtering concepts—input and output filtering. The most commonly used tactic is input filtering, which is often implemented in the form of input blocking and input sanitation. Each of these methods is fraught with risks and should be thoroughly understood before implementation.

Input sanitation can often look exactly the same as output sanitation to an attacker, especially in the case of reflected XSS. However, there are subtle, minor differences in that with input sanitation all the data is parsed, whereas output sanitation only applies to data that is written back to the page. In other words, if data is placed directly into an e-mail script, only input sanitation will catch invalid content. Like we said, it’s a subtle difference but it makes a huge difference when dealing with persistent XSS attacks. In this case, output sanitation is the best option due to the complexity of trying to capture all malicious data.

Input blocking is a simple concept and is similar to input sanitation; however, blocked content is immediately reflected back to the page. The most common place to find this is in

www.syngress.com

Preventing XSS Attacks • Chapter 9 397

error conditions, which are found all over the Internet. Let’s take a very simple example and say there is an input that requests a phone number:

Phone number:

That phone number should take a specific format. There are some rules you would no doubt want to put in place to take into account things like extensions, international numbers, and so on. If the input does not fit the syntax of the expected data, the principle of input blocking would output a message stating you cannot enter the input until the data matches the input type expected by the application. Here’s an example of an error condition:

You entered: blahblahblah.

The result: A phone number must include numbers dashes, spaces and parenthesis. Please re-enter the phone number:

Unfortunately, because the text has been reflected to the page, there is the possibility for XSSing through the reflection of the blocked text in the error condition. Error conditions yield the vast majority of reflected XSS on the Internet. In fact, one of the goals of many XSS attacks is to intentionally cause error conditions so that the injected content is reflected to the page. So it would seem that blocking inputs has issues, what about input sanitation?

Input sanitation is designed to scrub the content that the user inputs. After it has been scrubbed, it will no longer be dangerous and therefore can be passed on to the application. Many Web sites prefer this method because it is the most seamless.

Note

Be wary of using input cleansing for legal reasons. You can end up turning content into completely different text unintentionally, which can cause legal issues depending on what you do with the content. If in doubt, please check with an attorney about the liability issues regarding changing user input arbitrarily.

There are many problems regarding input sanitation. For one, it is far more complicated than it sounds. Let’s take a very simply example where the text of the page is set up to strip out the text <script. Never mind the dozens of ways to circumvent this simple filter. Let’s attempt to attack it directly, as you saw in the filter evasion section:

<scr<scriptipt src=http://ha.ckers.org/xss.js></script>

When scrubbed the text will be changed to:

www.syngress.com

398 Chapter 9 • Preventing XSS Attacks

Let’s take another real-world example of a filter. It attempts to do a number of very smart things to protect it’s users, and even takes into account many of the tactics found on the XSS Cheat Sheet (http://ha.ckers.org/xss.html) as well as a number of other issues. Here’s the code written in PHP. See if you can find the issue:

function RemoveXSS($val) {

$val = preg_replace('/([\x00-\x08][\xOb-\xOc][\x0e-\x20])/', '', $val); $search = 'abcdefghijklmnopqrstuvwxyz'; $search .= 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'; $search .= '1234567890!@#$%*&*()'; $search .= '~~ ";:?+/={}[]-_|\'\\'; for ($i = 0; $i < strlen($search); $i++) { $val = preg_replace('/(&#[x|X]0{0,8}'.dechex(ord($search[$i])).';?)/i', $search[$i], $val);

$val = preg_replace('/(&#0{0,8}'.ord($search[$i]).';?)/', $search[$i], $val); }

$ral = Array('javascript', 'vbscript', 'expression', 'applet', 'meta', 'xml', 'blink', 'link', 'style', 'script', 'embed', 'object', 'iframe', 'frame', 'frameset', 'ilayer', 'layer', 'bgsound', 'title', 'base');

$ra2 = Array('onabort', 'onactivate', 'onafterprint', 'onafterupdate', 'onbeforeactivate', 'onbeforecopy', 'onbeforecut', 'onbeforedeactivate', 'onbeforeeditfocus', 'onbeforepaste', 'onbeforeprint', 'onbeforeunload', 'onbeforeupdate', 'onblur', 'onbounce', 'oncellchange', 'onchange', 'onclick', 'oncontextmenu', 'oncontrolselect', 'oncopy', 'oncut', 'ondataavailable', 'ondatasetchanged', 'ondatasetcomplete', 'ondblclick', 'ondeactivate', 'ondrag', 'ondragend', 'ondragenter', 'ondragleave', 'ondragover', 'ondragstart', 'ondrop', 'onerror', 'onerrorupdate', 'onfilterchange', 'onfinish', 'onfocus', 'onfocusin', 'onfocusout', 'onhelp', 'onkeydown', 'onkeypress', 'onkeyup', 'onlayoutcomplete', 'onload', 'onlosecapture', 'onmousedown', 'onmouseenter', 'onmouseleave', 'onmousemove', 'onmouseout', 'onmouseover', 'onmouseup', 'onmousewheel', 'onmove', 'onmoveend', 'onmovestart', 'onpaste', 'onpropertychange', 'onreadystatechange', 'onreset', 'onresize', 'onresizeend', 'onresizestart', 'onrowenter', 'onrowexit', 'onrowsdelete', 'onrowsinserted', 'onscroll', 'onselect', 'onselectionchange', 'onselectstart', 'onstart', 'onstop', 'onsubmit', 'onunload'); $ra = array_merge($ral, $ra2); $found = true; while ($found == true) {

$val_before = $val;

for ($i =0; $i < sizeof($ra); $i++) { $pattern = '/';

for ($j = 0; $j < strlen($ra[$i]); $j++) { if ($j > 0) {

$pattern .= '(';

$pattern .= '(&#[x|X]0{0,8}([9][a][b]);?)?'; $pattern .= '|(&#0{0,8}([9][10][13]);?)?'; $pattern .= ')?'; } $pattern .= $ra[$i][$j];

www.syngress.com

Preventing XSS Attacks • Chapter 9 399

}

$pattern .= '/i';

$replacement = substr($ra[$i], 0, 2).'<x>'.substr($ra[$i], 2);

$val = preg_replace($pattern, $replacement, $val); if ($val_before == $val) {

$found = false; } } }

return $val; }

At first glance this might appear to be a very solid filter, taking into account all the obvious issues out there, while still allowing some things like image tags and links. The filter is intended to allow content that is non-malicious, while blocking anything else. It even takes into account Hypertext Markup Language (HTML) encoding in both hexadecimal and decimal format. Let’s show a simple example that would normally work in IE 6.0:

This will fail because &#x()9; is a known string (a horizontal tab written in hex) that is blocked by the above filter. It would seem that this filter has done a pretty good job at first blush, but what it has failed to understand is that by trying to sanitize it ends up allowing our vector to fire due to the modification it makes to the code:

A & is an ampersand. When it is converted to its HTML equivalent, the resulting character not only accepts but helps create our attack vector for us. Clearly there is a problem with this sort of sanitation.The major missing component of many of these issues is that they do not form a loop. Here’s a simple example in PERL pseudo code of what a sanitation function might look like:

while(input_filter_finds_problems_with($user_input)) {

// iterate } function input_filter_finds_problems_with() {

$input = shift;

$output = $input;

$output =~ s/>/>/g;

$output =~ s/</</g;

$output =~ s/"/"/g;

//include other substitutions that make sense in context of where the

//user defined input will eventually be outputted.

www.syngress.com

400 Chapter 9 • Preventing XSS Attacks

if ($output != $input) { //tell the instantiating loop if

//substitutions were made

return 1; } else {

return 0; } }

In writing a while() loop, the script author can be certain that the text does not contain any exploits that are known by the filtering mechanism. Of course, the battle is in knowing all possible permutations of all vectors for each browser that the developer is coding for, not to mention future browsers, but with a while() loop, we will avoid most of the major issues that are found with sanitation filtering. Sanitation by stripping malicious text is always a risky proposal, which is why many people opt for encoding malicious strings to their HTML equivalents.

However, as you can see in the middle of the code, there is one comment that is the crux of the difference between input and output encoding. Input encoding requires that you know all possible outcomes for the data that will end up being reflected to the page. The context that the data will use must be anticipated long before its actual use. That can be a serious disadvantage, which brings us to input encoding.

Input Encoding

One of the major disadvantages to input encoding is one of the fundamental issues with large-scale Web site design.You rarely have one person working on the code from start to finish. It is far more common for developers to work in tandem or to work on segments of the code. For instance, one developer will work on the registration system and a completely different developer will work on the shopping cart for the same applications. Or even worse, companies often outsource certain components of their application to outside contractors, or even buy commercial off-the-shelf tools that have not anticipated the code construction of the original developers.

Retrofitting code to work with other newer functions is a large problem for security, as the context for the data usage can change. The previous example, “while loop code,” may seem to work perfectly for preventing all obvious XSS attacks; however, it is anything but perfect when used in a different context.

There are advantages to this sort of design. You will notice the “while loop code” is missing the single quote, plusses, minuses, forward and backwards slashes, semi colons, parenthesis and a number of other things that can be used to mount an XSS attack. However, none of these will work in the context of a normal HTML page. One developer may assume that the output of the page will always be in the HTML context. However, later,

www.syngress.com

Preventing XSS Attacks • Chapter 9 401

another developer may change that context to be inside of an HTML parameter, or inside of a JavaScript function, or some other function may allow the attacker to modify the charset type to something like UTF-7.

As you can see, context is everything with input encoding. The only way input encoding makes sense is if it can accurately predict all possible contexts that the data will ever be used in.This can be a daunting task in a large-scale environment, especially in the Web 2.0 world, where client-side code intermingles regularly with server-side code functionality.

However, after pointing out all its flaws, it should be noted that there are some major advantages to input encoding. First, in small-scale environments where there is only one developer, it is often very easy to know all the contexts that the user input will use. That makes it no worse than output encoding for small-scale development.

In large-scale development, there are still a number of advantages to input encoding. Large companies need to think about scalability and performance. Output encoding means that you need to change the user output upon each request of the data. That means for every hit to that data you must perform a filter function on the data. Input encoding requires only one hit upon user submission of the data.

Encoding the data once vs. encoding the data dozens of times might not seem like a big deal, but if a large company has dozens of front-end servers that have to handle the current load, something like that can actually cause huge performance issues. In fact, it could scale linearly; meaning that if the text needs to be encoded 10 times on average for output encoding vs. one time for input encoding, it could mean 10 times the processor load. That’s a worst-case scenario, but it’s something to know before making this sort of decision in a large-scale corporate environment.

The second advantage to input filtering has to do with the fact that there are typically many actions taken on any given text. The most obvious thing done with user input is output it to the page, as we discussed. The other thing that is most often done to text is storing it in a database. If it is stored in a database, the developer will have to sanitize that text anyway. It can often save a lot of pain to do both XSS and Structured Query Language (SQL) injection filtering in the same place since the developer must already do SQL Injection filtering upon input. A

Note

There is one other advantage to input encoding. Input encoding can become a central place for all filtering, which ensures there is a single choke point for all of the filtering, rather than many output filter locations.

www.syngress.com

402 Chapter 9 • Preventing XSS Attacks

Output Encoding

Output encoding has a few distinct advantages.The primary advantage is that it tends to allow a granularity in the type of output filtering required for the usage of the text in question. The context is often not known by the input filter, since it can often be on completely different part of the application or even be housed on another machine. This may not seem like an issue at first blush, but as Web 2.0 technologies (dynamic Flash and Asynchronous JavaScript and XML [AJAX]) become more prevalent, developers find more obscure reasons to need specific forms of filtering. For instance, in order for XSS to work, HTML is required if the text is found outside of an HTML element. However, inside of a Javascript string, quotes, parenthesis, and semicolons are often key.

Not all filtering is made equal. The developer needs to know what circumstances the text they are outputting is intended and how it can be abused. There are some major disadvantages to this type of filtering, because of how easy it is to get it wrong. The exploit found in Google’s reader was due to the developers thinking that JSON was only going to be viewed by the calling script. The developers never realized that attackers could send users directly to the JSON output. While AJAX and JSON do not generally introduce new holes per se, they definitely can increase the attacker’s surface area.

Another disadvantage to using output filtering is that the developer’s must know to use it. Unlike input filtering, which can be used once to protect the entire site, output filtering must be done by many developers over the lifetime of the application. That means that they must each not only know to do it but must know how to do it correctly. A daunting proposition, but if done correctly and done every time it can be a major improvement over input filtering as it takes context into account.

Another thing to remember is that often XSS can be stored for months or years after an XSS hole has been closed. With input filtering alone, there is no way to remove any stored XSS that may have lain dormant. If an XSS has been stored in a database and the only protection in place is input filtering, the only thing that can stop it is if the user tries to resubmit it and inadvertently overwrites the dormant XSS (in the case of MySpace profiles this has happened a number of times). However, if the site employs output filtering, it is irrelevant if the database still stores XSS vectors, because they will be neutralized by the output filtering. This is an important issue for social networking sites in general.

Whichever route you choose, input or output encoding, we suggest you look carefully at the scalability of the system being developed, as well as the tactics your development chooses to employ. This will often dictate which method will work best.

Web Browser’s Security

To begin let’s make one thing perfectly clear: Web browser security is completely broken. Research published in 2006 enabled XSS exploits and JavaScript Malware to circumvent all

www.syngress.com

Preventing XSS Attacks • Chapter 9 403

current browser security protections to the point where it’s very difficult to protect yourself, even if you’re one of the few people “in the know.”The simple act of clicking on the wrong link or visiting a Web site at the wrong time (especially popular Web sites) and you could be hacked. And don’t believe for a moment that Secure Shell (SSL), firewalls, patching, antivirus, anti-spam, anti-phishing, two-factor authentication, or any other solution like that really helps. These solutions focus on the least common denominator of yesterday’s attacks, which is no help for today’s threats.

What’s the most worrisome is if JavaScript malicious software (malware) owns a browser, and typically a victim has no idea when that happens, it literally has more control over a browser than the user. Once infected, a user is powerless should the malware instruct the browser to hack someone else’s Web site, port scan the intranet, steal money from their bank account, and other evils to which there is no end. Making matters worse, it doesn’t appear the main browser vendors (Microsoft and Mozilla) have any plans in place to remedy the situation. For the time being, we’re on our own.

Just like everyone else, the authors of this book buy, bank, post, comment, read, and conduct other normal online activities. The following are several of the tricks we use to keep ourselves from getting hacked.

Browser Selection

Browser selection is probably the single most important thing to protect yourself online. We’ll typically choose a primary browser and have one or two more standing by when a Web site only supports one and not another. During selection, remember that the majority of attacks target the largest user base, so it stands to reason that by not using the same software as the majority you stand a better chance of avoiding an infection/attack. Currently, Firefox seems to be the “safer” browser over the more popular and targeted Internet Explorer. Of course, Mozilla, Netscape, Opera, and Safari make fine choices as well. Some say this is security through obscurity. Regardless, voluntarily placing yourself between the crosshairs is not going to help you stay secure.

Add More Security To Your Web Browser

No matter what browser you choose, there are numerous programs and tools available to help the browser defend itself. NoScript¹ (Firefox), SafeHistory² (Firefox), SafeCache³(Firefox), Netcraft Anti-Phishing Toolbar⁴ (Firefox/Internet Explorer), eBay Toolbar⁵(Internet Explorer), and Google Toolbar⁶ (Firefox/Internet Explorer) are great products that do just that. These add-ons help identify phishing Web sites, disable certain features, protect passwords from falling into the wrong hands, and various other useful safeguards.

www.syngress.com

404 Chapter 9 • Preventing XSS Attacks

Disabling Features

Simply put, fewer enabled features will result in a safer browsing experience. JavaScript, Java, Active X,JScript, VBScript, Flash, and QuickTime are all potentially dangerous. These technologies are hosts to the new forms of malware. Unfortunately, disabling these features may break some Web sites; however, it might be worth the trade-off due to a lack of options. That’s why certain browsers and their extensions often provide a way to turn these features on or off quickly, as you need them.

Use a Virtual Machine

There’s a growing population of the tin-foil-hat-wearing-paranoids who surf the Web in an emulated environment using something like VMWare. If anything strange happens during the current session, the important data on the main machine remains well protected. Remember to roll back to a known good state (e.g., use snapshots) between sessions to protect your security and privacy

Don’t Click On Links in E-mail, Almost Ever

Whenever possible try not to click on any links in e-mail, especially since links themselves are dangerous and phishing e-mails can be difficult to spot. An ounce of paranoia is worth a pound of patches. If you’re unsure if an e-mail is real, the best thing to do is manually type the domain name into the Web browser location bar. This way there is some reasonable assurance that you’re on the real Web site.

The only exception to the “never click on e-mail links” rule are those e-mails you are expecting. For example, e-mails that are sent in response to an action (e.g., account registration, password reset, order confirmation, and so on) you might have performed on the Web site within the last several minutes.

Defend your Web Mail

Hundred of millions of people use Web Mail, which in many ways, is more important to keep secure than your bank account. Many people have important online accounts tied to a single Web mail address. If anyone gained access to your e-mail account, all accounts associated to it could be compromised as well. The best thing you can do is use unguessable passwords, change them every six months or so, and don’t use that password anywhere else. Bonus points for deleting e-mails with any sensitive information.

Beware of Overly Long URL’s

Be especially suspicious of URL’s wrapping more than a single line and heavily disguised with URL-encode percent characters. If you’re not sure about the true nature of a URL,

www.syngress.com

Preventing XSS Attacks • Chapter 9 405

decode it and check to see if it has any HTML tags embedded within. If it does, you probably don’t want to click on it.

URL Shorteners

Beware of URL shortening services. Pranksters and bad guys alike are using URL redirect services like TinyURL, snipURL, notlong, shorl, and doiop to disguise potentially malicious URL’s. To double check on these URL’s, I’ve been using the command line to issue an HTTP request directly to see where the Location header is pointing. If the redirect URL looks safe, then I’ll click it.You can never be too careful with these obfuscated URL’s.The unfortunate problem is there are dozens of these services, which makes it impossible to guarantee that a URL is not spoofing the final destination. Therefore, you must always be careful what you click.

Secrets Questions and Lost Answers

Everyone eventually forgets a password and needs to regain access to their account. Most password recovery methods are fairly straightforward and provide a few different options to verify your identity. The one popular and often abused method is the “clever” secret question and answers about personal items in your life. Whenever possible, security/privacy conscious people try not to give any Web site information such as the name of their third grade teacher, their dog, or their high school, and certainly not a favorite color. If a breach was to occur, and which happens regularly, then all of this extra personal information is lost as well. To circumvent this bad practice, there is an option to treat secret Q&A’s like username/pass-word pairs. Imagine the surprise of the customer support person when telling them your dog’s name is ji*P5c$r⁷.

www.syngress.com

406 Chapter 9 • Preventing XSS Attacks

Summary

Input and output encoding each provide rather different pros and cons. The positives of each are that input encoding gives you a single choke point while output encoding gives you flexibility to deal with all possible uses of the text as it is positioned on the page. The negatives are that input encoding cannot stop persistent XSS once it has already been stored, and output encoding cannot stop other forms of attacks, like SQL injection as it runs too late.

There are a number of easy solutions to protect yourself as a consumer. Simple ideas are choosing a secured browser, using a virtual machine, clicking on only known links, and being careful about disclosing information about your Web mail accounts.These simple precautions, while not foolproof, can make a big difference.

Solutions Fast Track

Filtering

0 Filtering can deliver unexpected results if you aren’t careful to monitor the output.

0 Using a loop can reduce the risks associated with filtering out content.

0 Filtering alone can introduce new risks by creating new types of attacks.Therefore, it is critical to understand the order in which filters are applied and how they interact with one another.

Input Encoding

0 Input encoding can create a single choke point for all encoding.

0 Input encoding can protect against more than just XSS.Things like SQL injection and command injection can also be checked prior to storing information in a database.

0 Input encoding cannot stop persistent XSS once stored.

Output Encoding

0 Output encoding is more granular and can take context into account.

0 Developers must perform output encoding potentially many times for each location the information is outputted.

www.syngress.com

Preventing XSS Attacks • Chapter 9 407

Web Browser’s Security

0 Beware of long or overly complex URLs. Often these are the most likely to contain vulnerabilities.

0 Do not click on unknown URLs in e-mail if at all possible.

0 Choose a secure browser and customize your security settings to reduce the risk of exploitation.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.

Q: Is there a safe browser?

A: All modern browsers carry some risk, and all modern browsers can be crippled to the point where they are secure but in doing so they become nearly unusable.

Q: Is there a function that can be used to completely stop XSS?

A: Depending on the scenario, you can often remove all XSS by simply removing open and closed angle brackets; however, the nuances of exploitation make this a risky rule of thumb. For a very good PHP filter look at HTML Purifier at http://hp.jpsband.org/

- L\ _

Q: Are you safe if you turn off JavaScript?

A: You are safe from XSS if you turn off JavaScript, but there are ways to do CSRF and browser history theft without using JavaScript. So while turning off JavaScript provides a great deal of security, it is certainly not foolproof.

Q: What are some quick wins?

A: Pick a charset that is somewhat free from vulnerabilities (see

http://ha.ckers.org/charsets.html for details), make sure that functions that are initiated by POST requests cannot be modified to use GET requests, and insure that your output is encoded prior to being displayed.

www.syngress.com



	396 Chapter 9 • Preventing XSS Attacks

	Introduction Cross-site scripting (XSS) is a complex problem that is not going to go away anytime soon. Unlike most security-related issues, there is no quick fix that is acceptable for the majority. The problem is two-fold. First, the browser is not secure by design. It was created to make requests and process the results. This includes the ability to understand JavaScript, which is a standard programming language that Web developers can use to perform all sorts of functions, both good and bad. The browser doesn’t decide if a piece of code is doing something malicious. Cookie data is often called by valid programs. Accessing clipboard data is an approved feature of Internet Explorer (IE) 6.0. It isn’t the browser’s job to determine what code is good and what is bad. The second problem, which compounds the issue, is that Web developers are not creating secure sites. As a result, attackers are able to exploit their vulnerable scripts and inject code into the user’s browser. So now the user is stuck between two impossible situations. They either have to disable all scripting ability, which will seriously dampen their Web browsing experience, or only visit Web sites they trust and know are secure. In this section, we look at both sides of the equation. First, we examine the difficulties in setting up a solid foolproof filtering engine. As you will see, filtering is not a simple concept, and if not done exactly right it will fail. In fact, each and every person on this book project has made mistakes in creating their own filtering solutions due to the simple fact that browsers change, insecure code gets reused, and simple human error. Following this, we will then look at some of the things you can do as a user to prevent yourself from becoming a victim. However, note that nothing will protect you like a bit of paranoia, a tad of common sense, and a solid understand of how the Internet works.

	Filtering

	There are two basic XSS filtering concepts—input and output filtering. The most commonly used tactic is input filtering, which is often implemented in the form of input blocking and input sanitation. Each of these methods is fraught with risks and should be thoroughly understood before implementation. Input sanitation can often look exactly the same as output sanitation to an attacker, especially in the case of reflected XSS. However, there are subtle, minor differences in that with input sanitation all the data is parsed, whereas output sanitation only applies to data that is written back to the page. In other words, if data is placed directly into an e-mail script, only input sanitation will catch invalid content. Like we said, it’s a subtle difference but it makes a huge difference when dealing with persistent XSS attacks. In this case, output sanitation is the best option due to the complexity of trying to capture all malicious data. Input blocking is a simple concept and is similar to input sanitation; however, blocked content is immediately reflected back to the page. The most common place to find this is in

		www.syngress.com



	Preventing XSS Attacks • Chapter 9 407 Web Browser’s Security 0 Beware of long or overly complex URLs. Often these are the most likely to contain vulnerabilities. 0 Do not click on unknown URLs in e-mail if at all possible. 0 Choose a secure browser and customize your security settings to reduce the risk of exploitation. Frequently Asked Questions The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. Q: Is there a safe browser? A: All modern browsers carry some risk, and all modern browsers can be crippled to the point where they are secure but in doing so they become nearly unusable.

	Q: Is there a function that can be used to completely stop XSS? A: Depending on the scenario, you can often remove all XSS by simply removing open and closed angle brackets; however, the nuances of exploitation make this a risky rule of thumb. For a very good PHP filter look at HTML Purifier at http://hp.jpsband.org/ - L\ _ Q: Are you safe if you turn off JavaScript? A: You are safe from XSS if you turn off JavaScript, but there are ways to do CSRF and browser history theft without using JavaScript. So while turning off JavaScript provides a great deal of security, it is certainly not foolproof.

	Q: What are some quick wins? A: Pick a charset that is somewhat free from vulnerabilities (see http://ha.ckers.org/charsets.html for details), make sure that functions that are initiated by POST requests cannot be modified to use GET requests, and insure that your output is encoded prior to being displayed.

		www.syngress.com



	408 Chapter 9 • Preventing XSS Attacks

	Q: Do you use virtual machines? A: Absolutely! There are several free software applications that provide this functionality. For Windows try VMWare at http://www.vmware.com/ 1. NoScript https://addons.mozilla.org/firefox/722/ 2. SafeHistory www.safehistory.com/ 3. SafeCache www.safecache.com/ 4. Netcraft Anti-Phishing Toolbar http://toolbar.netcraft.com/ 5. eBay Toolbar http://pages.ebay.com/ebay_toolbar/ 6. Google Toolbar www.google.com/tools/firefox/toolbar/index.html 7. my dog’s name is ji*P5c$r http://nsolo.kicks-ass.net/my_dogs_name.JPG

		www.syngress.com



	Chapter 9



	395