“黑客”必学攻击之“跨站脚本攻击”

存储式HTML注入跟反射式HTML注入非常相似，唯一区别在于攻击者将脚本植入Web应用程序后，这些脚本会被Web应用程序存储到一个可以检索的地方。例如，对于允许用户张贴和阅读消息的网络论坛，攻击者可以在张贴消息时注入HTML代码，然后其它用户阅读这则含有脚本的消息时，其中的脚本就会执行。

2. 定位存储式和反射式HTML注入点

为了寻找存储式和反射式HTML注入点，可以尝试在所有表单输入以及GET或者POST请求的所有参数中注入脚本。我们要假设参数/值对中的值都可能有漏洞。甚至尝试在新生成的参数中注入HTML代码，如下所示：

〈 script 〉 a_lert ( ' parameter ' )= 不起作用，因为这些测试字符串并不出现在响应的HTML主体区。举例来说，假如向http://search.engine.com/search?p= 发送的这个请求返回的响应中，其预填充表单字段内是我们的HTML注入字符串，如：

遗憾的是，脚本标签会被作为用于表单输入字段的字符串，所以无法执行。相反，尝试http://search.engine.com/search?p="> 的话，会得到如下所示的HTML应答：

〈 form input='text' name='p' value='〈 

那么保不住攻击者可以注入下列内容：

〈 /title 〉〈script 〉 a_lert( 1 ) 〈 /script 〉 

这样一来就摆脱了title标签。USERINPUT3被放在一个式样标签中，任何人都可以在IE中设置USERINPUT3成下面的样子：

black; background: url( ' javascript:a_lert( 1 ) ' ); 

于是他就能够在Firefox使用它了：

1: ( a_lert( 1 ) ) 

同样的，有时候用户输入会作为其它的标签的一部分出现在式样参数中，如下所示：

如果您可以将USERINPUT3设为下面的值，那么就能在IE中运行JavaScript了：

javascript : a_lert(1) 

或者对于Visual Basic爱好者，可以这样使用：

vbscript:MsgBox(1) 

Firefox不接受带有JavaScript:协议处理程序的background:url()。然而，Firefox允许JavaScript作为表达式来执行，在Firefox中将USERINPUT3A设为下列值：

); 1:(a_lert(1) 

USERINPUT4可以直接利用，只要将USERPINUT4设为：

';a_lert(1); 

USERINPUT5被深深嵌入到JavaScript内部。为了插入(确保会执行的)a_lert(1)函数，您必须把a_lert(1)放到所有代码块之外，并保证JavaScript代码的前前后后都是合法的，如下所示：

')){}a_lert(1);if(0) 

A_lert(1)之前的文本完成了原先的if语句，因此能确保a_lert(1)函数总是被执行。a_lert(1)之后的文本创建了一个if语句用于剩余代码块，所以脚本标签之间的全部代码都是合法的JavaScript代码。如果不这样，JavaScript就会因为语法错误而无法解释执行。

您可以使用一些诡计来把JavaScript注入到USERINPUT6中，例如，可以使用下面的方法：

'> < scriptscript="">a_lert(1)< criptcript=""> 

或者，如果不允许使用尖括号，则使用一个JavaScript事件处理程序，例如onclick事件处理程序，如下所示：

' onclick='a_lert(1) 

USERINPUT7 还可以是这样：

' >< scriptscript="">a_lert(1)< criptcript=""> 

或者：

' style='x: ( a_lert ( 1 ) ) 

甚至更简单一些：

javascript: a_lert( 1 ) 

对于USERINPUT7的前两条利用方法能保证脚本在装入页面时执行，最后一种方法要求用户单击链接。您可以把它们都试一遍，看看是不是在某些情况下有些字符和字符串是不允许的。

USERINPUT8也面临类似的HTML注入字符串。下面是使用事件处理程序的最佳方式：

notThere' onerror='a_lert( 1 ) 

XSS防御方法通常是对具有潜在恶意性的字符进行转义或者编码。举例来说，如果用户输入 到一个文本字段，服务器可能以下列转义后的字符串作为响应：

[NextPage] 

根据转义后的字符串的所在位置，这些字符串将以本来面目出现并且不会执行。转义方法比较复杂，所以将在后面的对抗措施中加以详细讨论。大多数转义例程不是忘记对具有潜在恶意性的字符和字符串进行转义，就是使用了错误的编码方法进行换码。例如USERINPUT9，其事件处理程序把HTML实体编码为ASCII，所以任何人可以用下列两个字符串上演相同的攻击：

x'); a_lert ( 1 ); 

以及：

x'); a_lert( 1 ) 

最后，USERINPUT10可以用事件处理程序利用，并突破输入标签，例子如下所示：

x onclick= a_lert ( 1 ) 

这个例子说明，用户提供的字符串可以放到HTTP应答中的任何地方，看来真是一切皆有可能呀!

（编辑：南平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!