This guide to AES, written by Jeff Moser, was presented in a very unique way. It is unlikely that any other guide to AES had ever been written in the form of a series of handwritten illustrations that contain stick figures. However, Mr. Moser wrote a guide to AES that was in this form. This guide consists of four different sections, referred to as the four acts of the story of AES. The first two acts appear to be intended for those who are only interested in understanding what AES is and why it matters. The third and fourth acts cover how AES actually works.

The first act gives a short overview of what led up to the development of AES. While it is intended for those who are not familiar with AES, or cryptography in general, those with some knowledge of cryptography will understand the inside jokes in it. The panel in which ROT13 is mentioned contains a message encrypted with ROT13, followed by a response that says “double ROT13 is better” that might as well have been “encrypted” with two ROT13 rounds. Some will also find it appropriate that when DES is mentioned, it is pointed out that its key length was shortened. It is also appropriate that the attack on DES from Distributed.net is depicted as one that came from many individuals. Triple DES, as well as its performance issues that led to a need for a new data encryption standard are mentioned next. It is then mentioned which algorithms were in competition with each other to become this new standard. The next act consists of a short overview of cryptography.

In the third act, the details of how AES works are mentioned. Descriptions of expansion of the key, and the steps commonly referred to as SubBytes, ShiftRows, MixColumns, and AddRoundKey are given. There is not as much humourous material in this section, although some will like how ShiftRows is described in a way that is unlikely to appear in any textbooks that cover AES. There are some details that are not included in this section, such as the details on what S-boxes do, and details on what exactly is done in the MixColumns step. Those details, however, are covered in the next act.

This next and final act covers the mathematics involved in AES in depth. A short review of polynomial equations is given. Shortly after that, some readers may suddenly find the material quite foreign to them. When I read the section on polynomials in finite fields, I needed to have my memory refreshed about concepts that I learned about in a university course on rings and fields years ago. The reason this material is covered gets covered later in the act than some readers might like. How this applies to the mathematics behind S-boxes and MixColumns is covered well, however. Some details are not explained in great detail, such as why certain polynomials are used in certain calculations. Nevertheless, the material is made understandable to those who are willing to take the time to try to “grok” it, as the author says.

Some might be left wondering why certain steps are taken in the AES algorithm. The guide does not give details about how AES is better than DES, and why it might be more resistant to attacks. This absence of explanations of these topics is made into a joke, in which it is suggested that readers would not want to read any further. I was reminded of the statement that Fermat made when he mentioned that he proved his last theorem, and could not fit the proof within the margin of the paper on which that theorem was written. However, more information on AES is available to those who may want to look for it, and this was by far those most amusing explanation of AES that many may ever come across.

While this guide to AES may be considered entertaining, can it also be considered the best guide to AES overall? Some might think that it is, some might not. I personally thought that it helped to see the material presented in this form. If I wanted to learn the details about how AES works, I would have consulted Wikipedia. However, while the Wikipedia article on AES and related ones there are informative, I personally might have been more likely to have my eyes glaze over while reading them. As with any explanation of AES, one might need to re-read sections of the explanation to understand it. However, this guide seems to make going over the material more enjoyable. And while there were previously some inaccuracies in calculations in it, one of which I pointed out, it gave an accurate explanation of how AES works. Links at the end of the guide are provided for those who would prefer more formal explanations of how AES works. AES is complicated, and I consider making explanations of it more entertaining a good idea. For many, it may take time and comic relief to fully understand anything that can be described as follows:

The chapter appropriately begins with an introduction to the layers of the OSI model. Although I have seen better introductions to the OSI model, this section of the chapter serves its purpose in giving a basic introduction to networking. The basics of programming with sockets are then covered, and are covered well. This then leads to a description of how a very basic web server can be written. After this is a segue into a description of the OSI model again, with more detailed descriptions of protocol layers. These layers are described using interesting and appropriate analogies. As an example, the data link layer is described as being analogous to interoffice mail, the physical layer is compared to the carts used to deliver the mail, whereas the network layer above these layers is compared to a worldwide postal system. It was also interesting to see the details of how TCP/IP connections are started, and to see why they are started using the “three-way handshake” method.

Next, sniffing of network traffic is explained. The libpcap library is described in detail, and code examples are given to explain how a sniffer can be written to display network traffic at three different levels. The examples of what gets sniffed may make those who read them want to conduct experiments. Some may want to see more about the data that would be transmitted, such as the SYN and ACK values in TCP/IP connections. It is later mentioned that sniffing cannot be done easily on switched networks. Then it is described how the way in which ARP is implemented easily allows both spoofing of ARP addresses as well as ARP cache poisoning, and how that can be done to sniff traffic on switched networks. While readers read through it, some of them might consider how to defend against this flaw inherent in ARP that allows cache poisoning. Some of them might also be entertained by the author’s cleverness, as the MAC address of the attacker in the ARP spoofing example is, appropriately enough, 00:00:00:FA:CA:DE. The libnet library is then described, as are the tools known as Nemesis and arpspoof that use this library. The author appropriately encourages readers to view the source code of software that uses these libraries so that they will be better able to learn about these libraries. Many code examples are given, and the author seems to understandably assume that readers will work with these examples. He often says that the code examples should make sense to readers.

Denial-of-service attacks are covered next. The author explains how the implementation of protocols can be exploited, in particular in the description of SYN floods. It is then explained that that attack and similar ones are unlikely to succeed now, as operating systems have been updated to prevent these attacks from happening. However, it is explained why these historical examples matter. The author mentions that while oversized ICMP packets will not crash computers anymore, some Bluetooth implementations are vulnerable to oversized ping packets. As the author says, it is often that “the same mistakes made in the past are repeated by early implementations of new products.”

In the next section of this chapter, the importance of being able to sniff network traffic is underscored. It is demonstrated how this sniffing is what needs to be done to be able to hijack TCP/IP connections. Prior to the explanation of how this hijacking is done, it is appropriately explained that this can be done when a one-time password is used to connect to a host. Next, port scanning and the different methods of it are covered. The author then explains how discovery of which ports are open can be prevented. This is done by creating the illusion that all ports are open, which is done by responding to any packets that are sent when ports are being scanned. As is the case with previous sections of the chapter, example source code is given to illustrate how this can be implemented.

What I consider the best part of the chapter is near the end of it, where it is explained how concepts from the previous chapter can be combined with concepts explained in this chapter. The reader is first given a second chance to look for a buffer overflow vulnerability in a code example given previously in the chapter on networking. It is then explained how this vulnerability can lead to shell-spawning code being run. Then, to make the attack more useful, it is demonstrated how port-binding shellcode can be used to open a port to which the attacker can connect and gain root access to a remote system. This combination of interesting concepts may have been awaited by readers as they read through the book. This combination of concepts makes these concepts more interesting than they were individually.

After reading this chapter, readers of it should understand that the implementation of network software can be, and historically has been, flawed and vulnerable to attacks. The author encourages readers to write software that implements the concepts that are explained, such as the “ping of death” attack. Readers of this book are understandably expected to understand the material well enough to be able to do that. Something else that readers should understand after reading that chapter is how concepts can be combined. The author does not explicitly say in this chapter that readers should understand this. However, readers who will get the most out of this book will see how that can be done. After the chapter ended with explanations of how shellcode can be more advanced, and how countermeasures against attacks can be implemented, readers will want to keep reading this book. The next two chapters cover the topics of shellcode and countermeasures, and I plan on reading and reviewing them once I find the time to do so.

This chapter of the book is quite informative. The explanations of concepts are clear, and are sometimes even entertaining. The clever sense of humour that the author has is quite evident in it. Those who try to fully understand the material and pay attention to detail will enjoy this chapter. Reviews of the next chapters of the book may appear here before long, as I continue to enjoy reading this book.

Reflected XSS attacks tend to be carried out by directing users to malicious URLs. When I look through the URLs on the list of reflected XSS vulnerabilities on XSSed.com, I find that many of these URLs are quite unwieldy, and contain text that may appear suspicious. It seems that a method for making URLs appear to be innocuous would be to display them in the form of URLs that would be output by URL shortening services. Also, Twitter has been used to spread an XSS worm before, and so URL shortening services could be used to launch XSS attacks via Twitter once again.

I am not the first to write about the security implications that these services have. There is a very good blog entry on this topic that can be viewed here. There are articles on how these services can be used in phishing attacks that can be viewed here and here. It is mentioned in each of these articles how revealing of the longer versions of shortened URLs can be done. However, many users may not take the time to verify where they would be taken when they go to one of these shortened URLs. Some might not want to take the time to visit a website such as LongURL to view the longer URL to which they would be redirected. And some might not use tools such as the Firefox extension for revealing URLs shortened by the service known as bit.ly. Many users simply prefer not to take the necessary amounts of time to prevent themselves from possibly going to a place on the web to which they would not want to be redirected.

It seems that when users are given a choice between security and convenience, they tend to choose the latter option. There must be a way for URL shortening services to be both secure and convenient. Until there are improved methods for determining whether or not shortened URLs are being used for malicious purposes, these URL shortening services will be used for attacks such as phishing and XSS attacks.

When programmers first learn about programming, they tend to focus on simply making the programs that they write appear to run properly. Once these inexperienced programmers find that their programs appear to be free of errors, they may think that they do not need to do anything else with the programs that they have written. However, programs that seem to run correctly may have issues that could lead to unintended consequences. A mistake that is sometimes made by those who teach programming is that of emphasizing getting programs to work in typical cases. The chapter in this book on programming puts much emphasis on going beyond viewing programs as a series of statements written in a high-level language to accomplish certain tasks. This is done for reasons that become quite evident in this chapter on program exploitation.

In this third chapter of the book, methods of taking advantage of certain programming practices that should be avoided are covered. This chapter is divided into sections in which concepts such as buffer overflows and format string vulnerabilities are explained. These sections are divided into subsections in which there are examples that illustrate how these vulnerabilities can be exploited. These examples progressively increase in complexity, efficiency, and effectiveness. For example, in the section on stack-based buffer overflows, an example is given that demonstrates how a buffer being overflowed can affect what is stored in other variables. Then the possible unintended consequence of overwriting a buffer that stores a boolean value on whether or not access is to be granted is illustrated. However, this situation is one that the author admits is contrived, as whether or not it will occur depends on where variables are located in memory. Later, it is demonstrated how the GNU debugger can be used to show where one can see the memory address to which the program is to be directed. And then it is shown how that address can be overwritten with an arbitrary address when the program has a buffer overflow vulnerability. Then an assembler dump is given to show which memory addresses to which a program can be pointed. Then it is shown how memory can be overwritten with instructions that contain shell-spawning code. Then it shown how shellcode can be stored in environment variables to make attacks more efficient.

After short sections on heap-based buffer overflows and overflowing of function pointers, format string vulnerabilities are explained. In the section on format string vulnerabilities, it is demonstrated how code that appears to do what it is supposed to do can have very serious problems. It is first demonstrated how memory on the stack frame, and then in any other location can be viewed when format parameters are missing from printf function calls. Then the techniques for writing to memory addresses through the use of direct parameter access and short writes are given. It is once again shown how overwriting of memory can lead to shellcode being run through the use of methods that are similar to those given in the section on buffer overflows. It is also demonstrated how .dtors and the global offset table can have their memory addresses overwritten so that shellcode can be executed.

The author does well in explaining concepts by giving examples of more basic attacks first, and then demonstrating how more complex attacks work by building on the concepts that were previously explained. Some concepts, however, are not clearly explained. However, when a code example or concept does not quite seem to be clear to readers, they can perform their own experiments by modifying the source code that is on the CD that came with the book. As I myself experimented with the source code, I wondered if it would have been a good idea for there to be exercises included in the book for the reader to complete, as if this book were a textbook. However, readers for whom the book was intended, the inquisitive individuals who truly are hackers, should be able to come up with their own exercises so that they can reinforce their knowledge of material taught in the book. Astute readers will also try to predict upcoming material, as they may see how the different concepts taught in the book fit together. For example, when the section on .dtors and the global offset table are covered, one can predict how the memory addresses to which a program’s execution jumps can be overwritten with addresses of environment variables that contain shellcode.

This chapter was very informative in explaining and demonstrating how these exploits work. I liked how simple concepts were explained, then more complex ones were explained that built on the more basic concepts. Perhaps some of the material could have been explained better. However, there is no substitute for the practical experience that one can gain by working with the many examples that are provided in this book and on the CD that came with it. And there are many code examples included so that those who want to get the most out of the book can easily do so. Explanations of concepts are given mostly in the lucid and detailed manner that I have come to expect when reading this book. I look forward to reading the next chapter of the book, which is the chapter on networking. I also look forward to reviewing it.

As those familiar with Adblock Plus (often abbreviated as ABP) know, it blocks web page content by using sets of filters. JavaScript content, Flash animations, and groups of image files are examples of what can be blocked by these filters. Any content that matches certain patterns in the source code of web pages can be blocked with ABP’s filters. As end users prefer to have web content filtered for them automatically, users can subscribe to filter lists. These lists are maintained and updated by individuals who look for content that users may want to have blocked. These lists tend to be modified over time, and users who subscribe to these lists have their lists updated periodically. Users who subscribe to these lists trust those who maintain these lists to block content that these users would want to have blocked.

NoScript is a Firefox extension that blocks much content of web pages by default. NoScript relies on the donations of users in order to fund the project, and this is done through advertising on websites run by NoScript creator Giorgio Maone. Those who have subscribed to a filter list for ABP known as EasyList may have found that some of the page content on sites run by Maone had been blocked. Maone responded to this by updating the pages on these websites so that those ads could again be viewed by those who used EasyList. Then these filters continued to be updated so that those ads would be blocked again. To Maone, it seemed as though the site content that helps create funding for the development of NoScript was being deliberately targeted by the EasyList filter for ABP. In fact, according to Maone, filter rules were implemented that would even prevent the download of NoScript from those websites. This is what led to a response from Maone that was highly controversial, and was one that he would understandably regret very much.

Firefox extensions are not “sandboxed” in the browser, meaning that there is nothing preventing them from interfering with each other. Maone took advantage of this fact. NoScript was modified so that it would actually modify ABP’s filter list so that the four websites that were targeted would be whitelisted. This interference with another extension was done rather surreptitiously. Information on this was added to the release notes of the NoScript version that performed this action. However, not many users may have read this, and Maone later admitted that he should have done more to inform users about this. One extension interfering with the operation of another, without explicitly asking for user consent, was considered a very questionable action on the part of Maone.

Some may want to read the official statements on this conflict that were written by the authors of these extensions. ABP creator Wladimir Palant’s comments about this issue can be found in this blog post. Maone’s response can be read here.

It was only in the last entry that I wrote here two weeks ago that I mentioned how NoScript could be used to defend against XSS attacks. There were many who considered NoScript a trusted extension, and it may have been considered one of the most trusted Firefox extensions in existence. In fact, all Firefox extensions can be considered trusted after they are reviewed and approved by staff members at addons.mozilla.org, a website that is often referred to simply as AMO. All extensions uploaded there are considered “experimental” before their code gets reviewed. Theoretically, the trust that users would have in non-experimental extensions could be betrayed by individuals who could write extensions that get approved, only to be later modified to surreptitiously perform actions undesired by its users. One would certainly not expect an extension written by someone who seemed motivated to prevent websites from doing anything without user consent to be such an extension. However, this is what happened, and it is the reason for the recent backlash against NoScript and for its creator’s apologies. If anything good can come from this dispute, it is that this could lead to sandboxing of extensions within the Firefox web browser.

There are those, however, who would say that Palant should also admit to wrongdoing. When users install Adblock Plus, it is with the expectation that advertising that is considered intrusive will be removed by it. When viewing the four sites run by Maone, one can see that the advertising there is unlikely to be considered a reason for the existence of ad blocking software. Targeting of Maone’s sites, which Palant admitted to doing, seemed questionable. However, it seemed as though there should have been more communication between individuals on the two sides of this dispute. There had to have been a way to avoid the cycle of filter updating followed by evasion of those filters.

Both Maone and Palant have faced backlash from many users. Maone, however, has admitted to wrongdoing, and has removed the code that was the reason for his apologies. And after checking the EasyList filter list, the filters Maone mentioned no longer seem to be there. I believe that the individuals on both sides of this dispute could have done better in trying to prevent it. Those who write Firefox extensions seem to be motivated by simply making Firefox a better browser, and thus one would not expect them to have such disputes as they try to reach their common goal. It seemed as if Maone and Palant might have lost their focus, and are now not as trusted as they had previously been. However, over time, I believe that we might be able to trust these individuals and their extensions again. In any case, I hope to not have to write about a conflict between Firefox extension developers again.

This worm infected the profiles of Twitter users so that they contained malicious code. Logged-in Twitter users who would view one of these infected profiles would then, through execution of the JavaScript injected into one of these profiles via an XSS hole, have their own profiles infected with the same code. Therefore, propagation of this worm occurred via logged-in Twitter users simply viewing infected profiles. The source code used by this worm can be viewed here. As one can see by viewing this source code that is called from infected Twitter pages, it injects the malicious script and other data that would appear in profiles when they are infected with this worm. Damon Cortesi gives a good analysis of the worm here.

A number of different variations of this worm have affected Twitter. The source code used by one such variation can be viewed here. As one may be able to determine by comparing this source code to the source code used by the original worm, a fairly straightforward code obfuscation technique was used to make it different from the source code used by the original worm. Another variation of the source code, which can be viewed here, is a modified yet non-obfuscated version of the source code used by the original worm. As Giorgio Maone said, it appeared as if those trying to correct this issue were trying to defend against specific code that has been used, rather than the type of attack. A few days after this was mentioned, Lynne Pope mentioned that with variations of the worm continuing to affect Twitter, the XSS hole there did not appear to be closed. It appears as if Twitter is not doing what needs to be done to prevent attacks like these. They seem to be targeting individual attacks rather than closing the hole that allows these attacks to get through. And when there is not enough done by websites to prevent attacks like these, users need to know what they must do to protect themselves.

There are some Twitter users who may not have been affected by this worm even after viewing infected pages on Twitter. Those who use the Firefox extension named NoScript may not have been affected by it. When looking through the source code used by the worm and variations of it, one can see that code that is on a remote site is executed in order to cause the worm to propagate. After seeing this, I thought that this could be considered a reason for using NoScript. And NoScript author Giorgio Maone took this opportunity to mention that because it is very highly unlikely that NoScript users would have allowed any scripts from the sites where any malicious JavaScript file was located, NoScript users may not have been affected by this worm. In addition, Lynne Pope gives an excellent and interesting list of suggestions on what users can do to prevent anything like this from happening to them. Not surprisingly, she suggests that NoScript be used. She also mentioned that when logged into one site, one should not be logged into another one. While this certainly would prevent CSRF attacks, this might be considered excessively inconvenient by some. She does give another criticism of Twitter, saying that they should have given users the information mentioned in her blog post.

I understand that much has already been said about this worm. However, the more that is said about this, the more likely it is that users will know what can be done to keep themselves from being victims of this type of attack. Also, according to this article, those who used Google to find information on this worm may have visited malicious websites in doing so. This information that I gave here may have been given later than I should have given it. However, I have always considered it important for entries on this blog to be as well-written as possible, at the expense of being up-to-date. If I wanted to write entries that were as up-to-date as possible, I would have a Twitter account. And I would be sure to use NoScript when using that Twitter account.

Despite these facts, some websites have the option to be remembered by them selected by default. However, some users may want to try to make it less likely that others will access their accounts by ensuring that the option to be remembered would never be selected. And some might consider it a nuisance to need to deselect the option to be remembered by a site each time they want to log into a site. For these reasons, I decided to write a Greasemonkey script that would remove the checkmarks from checkboxes for indicating that the user wants to be remembered by websites.

This Greasemonkey script that I titled “Do Not Remember Me” is one that looks for checkboxes on web pages and determines whether or not they are for remembering users by checking nearby page material. By default, it is set to work with all websites. However, some users may want to be remembered by some websites. For that reason, this script is one that users of it may want to configure so that it will not be used by some websites.

This script, like other Greasemonkey scripts that are made to work with all websites, might possibly not actually work with all websites. Some users might find errors in it that will cause it to not work with some websites. However, I have found that it does work with the websites that made me want to write this script. Some who often log into Userscripts.org, the website where this and many other Greasemonkey scripts can be found, may want to use this script. As you can see if you view the login page on Userscripts.org, the option to be remembered by that site is selected at first. I myself did not want to keep removing the checkmark from the option to be remembered by that website. It also works with the login page on Google Accounts, which also remembers its users by default. I have also found that it works with Hotmail’s login page. I also set it up so that it would actually add checkmarks to checkboxes that say “public terminal” beside them, as one can see by viewing Slashdot with the script enabled. In addition to ensuring that it works with as many sites as possible, I have tried making it as efficient as possible. It might not currently be as efficient as it could and should be. However, I chose to release it as it is so that I could allow others to critique it.

I could make this post less boring by mentioning some more interesting facts about it. I originally decided to call this script “Don’t Remember Me.” However, it might then be referred to as “DRM.” Many consider that the acronym for Digital Rights Management. I wanted to avoid this acronym collision, even though I did not think that this script would ever be listed on Wikipedia’s disambiguation page for DRM. Some who would look through the code may not be entertained when viewing it. However, I thought of mentioning that the purpose of one function in the script was to “check checkboxes to check if they should be unchecked” and eventually decided to choose clarity over comedy in my comments.

If you have Greasemonkey installed, then you can install this script if you click here. As always, I would be pleased to answer any questions about this script. I could go into greater detail about the implementation of what I wrote, although I do not tend to be asked questions about the implementation details of what I write. I will say that I have also considered writing a very similar script titled “Do Not Remember My Passwords.” As you may have surmised, it would deselect checkboxes for indicating that passwords are to be remembered. I considered combining these two scripts into one titled “Do Not Remember Me and Do Not Remember My Passwords Either” although I thought it might be best to keep these scripts separate. However, what I do next with this script and any related ones may depend on any suggestions that I may receive.

These surrogate scripts handle the situations in which 3rd party scripts from sites such as Yieldmanager.com look for page content that is blocked by NoScript. These surrogate scripts cause pages to be more likely to be error-free by replacing blocked scripts with similar scripts. Some concerned “non-geeks” have wanted to know if these surrogate scripts send any data to 3rd party sites. However, those who have viewed and understand the source code in these scripts can assure these individuals that these scripts simply try to prevent web pages from being broken. There are some users of NoScript who had previously found that some pages were broken unless scripts from sites such as Yieldmanager.com were allowed. I found that when scripts from Yieldmanager.com were blocked, pages on Imageshack.us appeared to be broken. However, these pages did not appear to be broken when the surrogate script for Yieldmanager.com was used. I have also found that these surrogate scripts cut down on the clutter that appears in the error console, as there would be fewer errors on pages when these surrogate scripts are used.

Users who have used the more recent versions of NoScript may have used these surrogate scripts without even knowing that they used them. However, there are those who might want to more easily configure these scripts. At this time, there is no user interface for configuration of surrogate scripts, because as NoScript author Giorgio Maone says, those who would configure these scripts and options regarding them would likely not need one. Still, a UI would be convenient, as adjustments to configuration settings may sometimes be necessary. One might want to more easily adjust which sites use surrogate scripts and which ones do not. Also, one might want to be informed when sites are using these surrogate scripts. In fact, I decided to make a few adjustments to surrogate scripts so that they would display information that says surrogate scripts are being used right on these pages where they are used.

I wanted to know when the surrogate script for code from YieldManager.com was being used. So I added a JavaScript alert statement to the surrogate script for YieldManager.com to determine this. As those who are familiar with JavaScript know, that statement would make a pop-up window appear when that script is executed. I then decided to make that code more complex by adding code to it that would execute when the page is finished loading so that text would be added directly to pages to indicate that this surrogate script is being used with these pages. However, it would be preferable for information on when these scripts are being used to instead be in the browser UI.

Users of the web may always need to choose between security and convenience. The newer versions of NoScript make it so that less convenience would need to be sacrificed for improved security. Still, it would be more convenient for there to be a UI to work with these surrogate scripts used by NoScript. However, it is good to know that the decision to choose security over convenience when browsing the web now seems to be a less difficult one to make.

After recently checking which sites were listed as having XSS vulnerabilities, I noticed a site listed there that is vulnerable to the most simple XSS attacks. The site, titled JavaScript-Coder.com, contains JavaScript tutorials, and includes the implementations of the JavaScript example code in it. And the implementation of one of these examples contains an XSS vulnerability. The example was designed to be very basic, and so it would be expected that no methods for preventing XSS attacks would be included in the implementation of it. It is an implementation of code for submitting data through a form, and it simply displays what was submitted through that form. Therefore, if any code is submitted through the form, that code would be added to the page that appears after the form data is submitted. This vulnerability posted to XSSed.com can give a basic idea of how XSS attacks work, as it demonstrates only code injection, with no filter evasion techniques.

As of the time that this post was published, nothing has been done to correct this vulnerability. This may not be because whoever wrote the PHP code that works with data submitted through the form was not informed of this. This was likely because it is not as important for there to be XSS prevention measures to be taken with this site as there would be with other sites. For example, theft of cookies or authentication credentials is not an issue with this site. In any case, this page provides an example of how to perform an XSS attack by simply making a page display any data submitted by a user.