![[APACHE DOCUMENTATION]](../../images/apache_sub.gif)
This page contains information about the Cross Site Scripting security issue, how it impacts Apache itself, and how to properly protect against it when using Apache related technologies.
For an overview of the issue, please see the CERT Advisory CA-2000-02 that has been released on the issue. You should also review their related Understanding Malicious Content Mitigation For Web Developers tech tips document. The CERT advisory also contains links to a number of documents that Microsoft has put out on the issue which are also worth reviewing if this issue impacts you. The information contained in these documents will not be repeated here; this information assumes you have read these documents and are familiar with the issue.
We would like to emphasize that this is not an attack against any specific bug in a specific piece of software. It is not an Apache problem. It is not a Microsoft problem. It is not a Netscape problem. In fact, it isn't even a problem that can be clearly defined to be a server problem or a client problem. It is an issue that is truly cross platform and is the result of unforeseen and unexpected interactions between various components of a set of interconnected complex systems.
There are specific bugs in a wide range of web server products, including Apache, that allow for or contribute to the exploitation of this security problem. These bugs should not be there and need to be fixed. But it is critical to realize that this is only a tiny part of the total issue. The most serious issue is in all the site specific code that generates dynamic content. We are bringing you this information to educate you on the issues that have been discovered in Apache that are related to this security problem but, more importantly, help educate you on how this may impact your own local code developed using Apache related technologies and how you can fix it.
There is no "golden bullet" patch that server or client vendors can release that will magically fix this issue across all web servers or clients using that product.
We would also like to point out that it is important to understand that this is not the old, well known issue, that if a site allows user A to submit content that is viewed by user B, it has to be properly encoded. This vulnerability is when the content is both submitted and viewed strictly by user A. Due to the difficulty of properly encoding output in all situations, many sites do not worry about encoding data that is only shown to the user that sent the data in their request due to the mistaken assumption that this doesn't pose a security threat.
This is a serious security issue, with potential implications that are only starting to be understood. However, it is critical to realize that this problem does not expose any way to break into the server itself. What it allows is for malicious attackers to potentially take control of the interaction between a user and a website. If your website contains entirely static content with all information being publicly accessible, an attacker can gain very little from taking over this interaction. It is likely that the most serious thing that an attacker can potentially do in this situation is change how a page appears to a particular user.
The sites where this poses the most potential danger are sites where users have some type of account or login and where they can perform actions with real world implications or access data that should not be publicly available. This security problem poses a serious threat to such sites; it isn't necessary to break into the server to take control of a site if instead you can gain access on the user's end of things.
Right here:
We do not expect this to be the last word on methods of exploiting this problem. It is likely that there will be more changes to Apache in the future to help users deal with this issue, even if no more bugs are found in Apache itself. Although we do provide most of the necessary information for sites to protect themselves against this type of attack, there are still many open issues associated with this issue.
We realize that this is a complex issue and expect to update these pages to describe the issues and fixes in more depth as time permits.
This issue isn't just about scripting, and there isn't necessarily anything cross site about it. So why the name? It was coined earlier on when the problem was less understood, and it stuck. Believe me, we have had more important things to do than think of a better name. <g>.
You can send any comments or suggestions about this set of pages to marc@apache.org. Note that I can not respond to questions or requests for assistance, so if that is what you are about to send then please save yourself the effort.