易栈网-膘叔（Neatstudio.COM）

易栈网-膘叔

PHP负载均衡

后缀名检测有漏洞,Apache上传不安全

理解PHP面向对象

QEE PHP 发布

使用开源软件设计、开发和部署协作型 Web 站点

PHP负载均衡

后缀名检测有漏洞,Apache上传不安全

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

一直以来,IBM developworks都是我比较关注的网站，它上面有很多内容是IBM公司内部人员所写，也有一部分内容是业界领先人士根据自身经验写出的教程，因此，它一直是我的订阅对象之一。本文就是其中一篇比较旧的文章，最初发表于2007年3月15日，但是从今天的眼光来看，它还是有一定的学习价值，所以我贴出来了。

简介如下：（原文我就不贴了，大家可以点其中的链接我自己也会点过去看的）

现在，Web 站点已经成了业务的重要部分，而用来创建和部署 Web 站点的工具也变得更加灵活和容易使用。但是，复杂 Web 应用程序的开发并不轻松，它们需要的不只是标准的交互和更新方法（比如 blog）。组织中的每个应用程序常常还需要进行定制。

开放源码社区提供了各种工具，结合使用这些工具可以为复杂的 Web 应用程序创建一个有用的开发和生产环境。这个系列文章来自 IBM Internet Technology Group 团队，他们将展示如何把开放源码软件作为基础，并提供一种方法和一些改进来帮助简化 Web 站点的开发过程。尽管定制仍然是有必要的，但是这个系列讲解了如何使用开放源码工具和技术快速建立和运行复杂的 Web 站点。

在这个系列中，Internet Technology Group 团队通过一个虚构的组织，International Business Council（IBC），来展示如何更有效地尽可能地扩展 Web 站点的功能，这些功能包括文档存储、讨论组、专门的工作组、研讨会日程安排、日程议题描述、会话过期和其他任务。他们举例说明了创建这个 Web 站点需要用到下列开放源码工具：

Drupal - 开放源码的内容管理系统
MySQL - 开放源码的数据库
PHP - 可以使用 PHPMyAdmin 和 SQLBrowse 创建动态 Web 内容的开发语言
Apache - 开放源码的 Web 服务器
Eclipse - 开放源码的开发环境
CVS - 用于跟踪代码变更的代码管理系统

Internet Technology Group 团队会首先介绍业务场景以及选择开源工具的决定因素，他们还通过描述一个灵活的开发方法来讲解了应用程序的设计流程。这个流程可以用来设计 Web 站点或者应用程序的用户体验。接着，他们会一步一步地指导如何安装和使用前面所提到的开发工具套件。这些步骤包括：

建立开发环境
Drupal 入门
着重介绍 Drupal 与其它软件工具的交互（如 MySQL， Ajax 和 PHP）
构建 Drupal 定制模块
部署和调整安装

沿着这条道路，Internet Technology Group 团队同其他可选方案进行了对比，并讨论了如何通过集成其它软件组件来尽可能地增强这些工具。

现在就链接到 项目实现：

Tags: php, 协同, 开源, 部署, 设计

PHP | 评论:0 | 阅读:18694

Submitted by gouki on 2008, December 28, 9:00 PM

文章的内容写的不错，所以转载一下。
原文：http://xinsync.xju.edu.cn/index.php/archives/2946
内容如下：

XML/HTML代码

过去当运行一个大的web应用时候意味着运行一个大型的web服务器。因为你的应用吸引了大量的用户，你将不得不在你的服务器里增加更多的内存和处理器。
今天，’大型服务器’模式已经过去，取而代之的是大量的小服务器，使用各种各样的负载均衡技术。这是一种更可行的方法，将使硬件成本降至最低。
‘更多小服务器’的优势超过过去的’大型服务器’模式体现在两个方面：
1. 如果服务器宕机，那么负载均衡系统将停止请求到宕机的服务器，转而分发负载到其他正常运行的服务器上。
2. 扩展你的服务器更加容易。你要做的仅仅是加入新的服务器到负载均衡系统。不需要中断你的应用运行。
所以，把握住这个机会:). 当然，代价就是这要求你的应用开发时增加一点复杂度。这就是本文要覆盖的内容。
这时你可能对自己说: ‘但是我怎么知道我正在使用负载均衡呢？’。最诚实的回答是，如果你正在问这个问题，那么答案是你多半没有在使用负载均衡系统并且你的系统不需要考虑这个问题。大多数情况，当应用成长足够大的规模时，负载均衡就需要明确提出和设置了。然而，我也偶尔看见虚拟主机公司为客户的应用做这个负载均衡，或者像下面描述的那样要自己来做。
在继续下面的内容之前，我要指出本文主要描述PHP的负载均衡。将来我可能会写有关数据负载均衡的文字，但是现在你必须等待。
注意，我一直提“web应用”而不是website,这是想区分’web应用’是那些复杂的站点往往涉及服务器端编程和数据库，而不是website那样只显示简单的静态内容。
1. PHP文件
第一个问题是，如果你有大量的小型服务器，你怎么把你的php文件上传到所有的服务器上？有如下的方法供你参考：
1. 分别上传所有的文件到每一个服务器 , 这种方法带来的问题是：想像一下你有20个服务器，那么上传过程中这将很容易导致错误，并且更新时极有可能导致不同服务器上有不同版本的文件。
2. 使用 ‘rsync ‘ (或类似的软件) . 这样的工具能同步本地目录和多个远程主机目录上的文件。
3. 使用版本控制软件(如subversion ) . 这是我最喜欢的方法。用它可以很好地维护我得代码，当发布我的应用时，可以在每一个服务器上运行svn update命令同步。这种方法也使切换服务器得代码到过去的某一个版本更加容易。
4. 使用一个文件服务器(你可能发现NFS 非常适合做这件事情). 这种方式是使用一个文件服务器来存放你的web应用. 当然，如果你的文件服务器宕机，那么多所有你的站点将不能使用。这时，你就需要花费更多的开支来恢复它。
选择哪种方式依赖于你的需求和你掌握的技能。如果你使用版本控制系统，那么你可能得计划一个方法如果同时执行一个更新命令更新所有服务器上的代码。然而，如果使用文件服务器，你就要实现一些失败恢复机制，防止万一服务器宕机导致请求失败。
2. 文件上传
当只有一台服务器时，文件上传不是一个问题。但是当我们有多台服务器时，那么上传的文件应该怎么存放呢？上传文件的问题和跨服务器php文件存储是类似的。下面是几种可能的方案:
1. 把文件存储到数据库中。大多数数据允许存储二进制数据。当你请求文件下载时，访问数据把二进制数据和相应的文件名和类型输出给用户。在使用这种方案前应该考虑数据库怎样存储你的文件。该方法的问题在于如果数据库服务器宕机将使文件不可用。
2. 在一个文件服务器上存储上传的文件 . 与前面的介绍一样，你要安装一个文件服务器让所有web服务器共享，把所有上传的文件上传到这里，上传后所有的web服务器就都可以使用它。但是，如果文件服务器宕机，那么可能发生图像文件下载中断。
3. 设计你自己的上传机制传输文件到服务器到每一个服务器 . 这个方法没有单个文件服务器或者数据库方案的缺陷，但是将增加你代码的复杂度。例如，如果上传到多个服务器过程中，服务器宕机，你要怎么处理？
用数据库存储上传文件但是设计一个文件缓存机制是一个不错的方案。当服务器接收一个文件下载请求时，首先检查缓存系统中是否有该文件，如果发现那么从缓存系统下载，否则从数据库读取并把它缓存到文件系统中。
3. 会话(Sessions)
如果你熟悉php的session处理，你将可能知道默认情况下，它存储session数据在服务器的临时文件里。而且，这个文件仅仅在你请求处理的那个服务器上，但是接下来的请求可能被另外一个服务器处理，这将在另一个服务器上生成新的session。这导致session频繁地不被识别，如登录用户总是要求重新登录。
我推荐的方案是，要么重新php内建的session处理机制存储session数据到数据库，或者实现你自己的机制保证发送一个用户的请求到同一台服务器。
4. 配置(Configuration)
尽管这个话题不是和php特别相关，我感觉还是有必要提及。当运行集群服务器时，用某种方法保持服务器之间的配置文件同步是一个好主意。如果配置文件不一致，可能导致一些非常奇怪的断断续续的行为导致很难排查这些问题。
我推荐使用版本控制系统单独管理他们。这样你可以为不同的项目安装存储不同的php配置文件，也可以保持所有服务器配置文件同步。
5. 日志(Logging)
像配置问题一样，logging不是仅仅和php相关。但是对于保持服务器健康运行它仍然是非常重要的。没有正确的logging系统，你怎么知道如果PHP代码开始产生错误(在系统正式运行时，你总是关闭display_errors 设置，不是吗?)
有几种方法你可以实现logging:
1. 在每一个服务器上记录日志。这是最简单的方法。每一个机器仅仅记录一个文件。好处是简单，可能只要很少的配置。但是，随着服务器数量的增多，监控每台服务器上的日志文件将变得非常困难。
2. 记录日志到一个共享这种方法每一个服务器仍然有这个日志文件，但是他们通过共享机制被存储在一个中央文件服务器上，这将使监控日志变得更简单。该方案的问题在于，如果文件服务器不可用将导致一个简单的日志不能写入问题最终导致整个应用崩溃。
3. 记录日志到logging服务器你可以使用一个logging软件，如syslog 来把所有的日志写到一个中央服务器。尽管这个方法要求更多的配置，但是他也提供了最健壮的方案。

SVN的机制确实是很多人现在所考虑的，一来这样保证了代码的同步，二来也不需要担心开发版和上线版的区别，更重要的是，每次的update你肯定不会有错。

文件上传其实才是一个大头，当你的服务器过多的时候，你如何保证每一台服务器的上传内容同步？如果你同步了，那么这么多的冗余文件是否是一个浪费？如果你不同步，而采用同一个NFS服务器来存储，那么就象文中说的如果NFS宕机了怎么办？给NFS也来一个负载均衡？

总之，当服务器越来越多的时候，你考虑的就不仅仅是代码的问题，而是架构的问题

Tags: php, server, 负载均衡, 配置

PHP | 评论:0 | 阅读:18343

Submitted by gouki on 2008, December 19, 8:17 PM

原文来自：http://www.phpv.net/html/1653.html
作者是：扶凯

内容如下：
注意,经测试,本情况发生在少量配置有问题的服务器上.一般正式版apache无此问题.

一般的网站都会开放rar附件上传,并可能会保留原来文件名称,这从而可能导致一个很严重的问题,xxx.php.rar文件会被Apache当作php文件来执行, 造成极大的安全隐患 .

如何测试? 将你的某个php程序文件后缀名修改成 xxx.php.rar , 这时测试一下, 还是按照PHP文件解析执行,Apache并不会认为这是一个rar文件, 这是为什么呢?

原来,每遇到一种后双重后缀名(如xxx.php.rar)的文件,Apache都会去conf/mime.types 文件中检查最后一个后缀, 如果最后一个后缀并没有在mime.types文件中定义, 则使用前一个后缀来解释 , 因为在默认情况下,rar并未在mime.types中定义, 故Apache会使用php后缀来解释文件, 这就是漏洞的原因所在.

由此类推,如果使用xxx.jsp.ppp.rar 则会认为是jsp文件, 如果修改成xxx.shtml.rar ,则会识别成shtml文件.

a.php.c.d.e.rar 也是会被当成PHP文件解释的!
想想,不知道有多少网站存在这个问题?

那么针对网络管理员,如何杜绝这个隐患 ?
1.修改mime.types文件,在最后面加一条:
application/rar rar
然后重新启动Apache,即可.

针对WEB管理员及WEB程序开发者,如何更安全?
1.只允许上传指定后缀名的文件,当然,要禁止掉rar格式文件上传.(但这条往往行不通,一般的网站都需要上传rar文件)
2.对上传后的文件进行强制重命名, 强制使用最后一个扩展名,如原始文件名为xxx.php.rar ,上传后强制重命名为 20080912.rar即可避免这个隐患.

早期版本的phpcms 2007, discuz, ecshop都存在这个漏洞, 或许你的网站被挂马,就是因此引起.

上面的文章是转的，我测试了一下,还真这样,不过修改mime.types是没有用的.

需要在http.conf中加入下面这些内容

AddType application/rar .rar
AddType application/x-compressed .rar
AddType application/x-rar .rar
AddType application/x-rar-compressed .rar
AddType application/x-rar-compressed; application/x-compressed .rar
AddType compressed/rar; application/x-rar-compressed .rar

这样就不会出问题了，测试过了，加我上面这些是没有问题的。

听闻有这样的漏洞，不管怎么样，都放上来，与大家一起分享一下，同时也请你自己检测一下自己的apache，如果你用的虚拟主机有这样的漏洞，那么也尽早通知他们一声，与人方便与己方便。
我自己没有测试过，所以不知道是否存在这个漏洞。

Tags: apache, mimetype, rar, php, bug

Linux | 评论:0 | 阅读:24003

Records:103«‹7 8 9 10 111213 14 15 16 ›»

« 2024年04月 »