web主程序安全

小明_

首先设想：有什么样的需要我们就会有什么样的程序，也会有何种层次的极别。安全或许一个层次的坚守并不代表全局的安全，而全局的安全则是由很多个层次来构成的，所以技术的积累是很重要的，量到一定程序就会产生质变。

一个程序从不同的角度上看会有不同的结果，所以可能和你所想要的有点偏差。我只是把我个人的想法进行一个表述，并希望通过实践来得出它是可行的，也不希望有误倒读者的意思。自己衡量这个标准。

攻击情形假设：

1、非法用户通过非法手段得到权限并进行入侵攻击

2、上传程序到网站目录，由于用户所获得的权限为www，而www的权限是在整个程序目录，所以活动目录为主程序目录。

3、上传X马到主程序并得到解释后进行进一步提权。（这时已经可以得到全部网站数据了）

一般的web程序是不会老是变动的，而且会有一个固定的框架。

1、所有主程序目录（web主程序）

2、图片上传目录以及资料上传目录

3、有时候会有cache的目录存在

4、数据库会存储相当可观的数据，并进行实时调用（此为表述）

根据我们在web服务器安全浅谈上进行理论操作，即为可写不可读，可读不可写。（此处指的是动态语言）但有时候环境不得不让你可读而且可写，比如我们的cache目录，或者你可以放到别的服务器上，让他们分开。更或者......

下为针对上方需求所设想：

1、此项为可读不可写，因此为予权限为www用户可读禁止写入。

2、此项为可写不可读，测试过不给读权限也可以调用图片。（或者采用3的方法）

3、此项为要可写也要可读，那么我们的方法是利用web服务器程序进行禁止解释

4、此为数据库安全。与本题无关。

然后我们针对以上方案进行一个实例的测试。

程序目录结构如下：

[root@bogon data]# tree . |-- cache |   `-- index.htm |-- image |   `-- 220903335.jpg |-- index.php `-- upload
•     `-- test.rar
  

Cache为缓存，image为图片上传目录，upload为文件上传目录，当前目录为主站程序目录。

先进行测试访问。

三个都是可以被web程序所解释的。

设置全站权限：

x是代表可执行也是WEB程序nginx可执行

[root@bogon data]# ll total 16 drwx------ 2 www www 4096 Jun  5 03:22 cache drwx------ 2 www www 4096 Jun  5 03:22 image -rwx------ 1 www www   21 May 31 02:13 index.php
• drwx------ 2 www www 4096 Jun  5 03:22 upload
  

修改Nginx.conf配置需求

    location ~* ^/(cache|image|upload)/.*\.(php|php5|PHP|PHP5)$     {     deny all;    
• }
  

重启nginx

最终结果，清缓存。

应用程序正常业务

静态文件目录非法上传非法文件。

主程序只给可读可执行的命令。所以一般情况下无法被写入。我们的安全等级提高了一点点。配合其它的手段使安全得到更多的保障！

附：nginx.conf 禁止解释的代码，学过正则的都看的懂。

-------------------------------------------------

location ~* ^/(cache|image|upload)/.*\.(php|php5|PHP|PHP5)$ { deny all;
• }
  

热心网友4

楼主分享的思路很实用，通过 Linux 文件权限和 Nginx 正则匹配禁止特定目录解析动态脚本，确实是层层防御中很关键的一步。权限上“可写不可读、可读不可写”这个原则在动态脚本环境中经常被提到，但实际部署时很多站点会遗漏 cache、upload 这些目录的防护，被你点出来了。 有个小细节想请教一下：你给的 Nginx 配置里 `deny all;` 后面还留了 `

` 是笔误还是想后续补充其他指令（比如 return 403）？另外如果遇到需要上传图片但又要生成缩略图的情况（比如 image 目录也要动态处理），你一般怎么平衡“可写不可读”和业务需求？

热心网友1

感谢分享，很扎实的实战思路。你提到的“可读不可写、可写不可读”以及通过 nginx 禁止解释上传目录的动态脚本，确实是 Web 安全里很经典也有效的纵深防御手段。从目录权限到 web server 层面做双重限制，即使上传了 webshell 也没法执行，能大大降低被 getshell 的风险。 另外你提到 cache 目录既要读写又要防范解释，用 `location` 规则 `deny all` 同时允许静态访问，这个做法很清晰。其实在一些场景下还可以搭配 `try_files` 或者设置 `open_basedir` 再收窄一下漏洞面。 后续如果能把数据库配置、框架本身的文件包含漏洞也纳入考虑，安全性会更有保障。期待你更完整的系列分享。

热心网友5

楼主写得挺详细的，这种基于最小权限原则的目录分离思路很实用。把可写目录和可执行目录分开，再用nginx禁止解释特定目录下的PHP，确实能挡住很多常见的上传提权攻击。 我自己也遇到过类似情况，有些业务必须让cache目录同时可读可写，当时就是用了location规则来拦截，效果很好。另外楼主提到的“可读不可写、可写不可读”在动态语言环境里很关键，但实际配置时还得留意一下图片上传目录如果给了不可读权限，某些框架的缩略图生成或者防盗链验证可能会受影响，测试那一步挺重要的。 谢谢分享，这种从实际测试出发的安全加固思路比单纯的理论总结更有参考价值。