博客 (64)

UEditor 的 ASP 版本在虚拟空间上传文件失败,提示“上传错误”或“上传失败,请重试”等,是因为其文件上传组件在创建目录时,没有网站目录外的访问权限。


例如上传文件的磁盘保存路径为:

D:\web\sitename\wwwroot\upload\20180523\123.jpg


百度编辑器的上传组件会依次判断以下目录是否存在,不存在则创建:

D:\

D:\web\

D:\web\sitename\

D:\web\sitename\wwwroot\

D:\web\sitename\wwwroot\upload\

D:\web\sitename\wwwroot\upload\20180523\


虚拟空间自动配置的网站根目录可能是:

D:\web\sitename\wwwroot\


所以,判断存在或创建以下目录没有问题:

D:\web\sitename\wwwroot\upload\

D:\web\sitename\wwwroot\upload\20180523\


但判断存在以下目录时会因为权限不足而失败:

D:\

D:\web\

D:\web\sitename\


解决方法是找到文件 asp/Uploader.Class.asp

找到 CheckOrCreatePath 这个 Function,替换为:

Private Function CheckOrCreatePath( ByVal path )    
   Set fs = Server.CreateObject("Scripting.FileSystemObject")    
   Dim parts    
   Dim root : root = Server.mappath("/") & "\"    
   parts = Split( Replace(path, root, ""), "\" )    
   path = root    
   For Each part in parts    
       path = path + part + "\"    
       If fs.FolderExists( path ) = False Then    
           fs.CreateFolder( path )    
       End If    
   Next    
End Function


另外,如果服务端无法通过 Request.Form 来接收该值,把 <form /> 放到 <table /> 外面试试。

或者绑定 contentChange 事件来赋值(不推荐):

ue.addListener("contentChange", function() {
    document.getElementsByName('xxxxxx')[0].value = ue.getContent();
});

此方法的缺点是,不是所有操作都能触发 contentChange 事件,比如剪切、上传图片等。

改进方法(推荐):在 form 提交之前赋值。

xoyozo 7 年前
4,825

风险名称:系统共享配置检测

风险等级:中危


检测项说明:

检测注册表项HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\LSA\\RestrictAnonymous的值,该值控制是否允许远程操作注册表


检测项目:

远程操作注册表

建议值:

1

路径:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous

建议:

建议禁止远程访问操作注册表,建议关闭


xoyozo 7 年前
3,768

在网站开发过程中遇到上传图片等文件的功能,需要在服务器上设置该目录可写入,并且必须防止被上传 .php 等可执行的脚本文件。

根据文件所有者的不同,我们分两种情况讨论:

一、程序上传的用户与执行 PHP 的用户不同(例如程序代码通过 SSH 上传(root 用户),而 PHP 以 www 身份运行)

由于 Linux 上的文件默认权限是 644,目录默认权限是 755,所以在这种情况下,PHP 不能修改 root 上传的程序文件,也不能将客户端上传的图片文件保存到服务器上。

例如我们将客户端上传的文件指定到 /upload/ 目录,那么,

第 1 步,赋予它写入权限:

chmod 777 upload

递归所有子目录请加 -R 参数,但会将文件也更改为 777,赋予了执行权限,这是不建议的。文件若需写入权限请设为 666。

第 2 步,设置该目录下不允许执行 PHP:

我们无法保证客户端上传完全符合我们要求的文件,那么必须禁止任何文件的执行权限。(此处指 PHP 的执行权限,注意与 sh 执行权限的区别,后者由 chmod 命令修改)

nginx 的 .conf 文件配置示例:

location ~ /upload/.*\.(php|php5)?$
{
    deny all;
}

Apache 的 .htaccess 文件配置示例:

RewriteRule upload/(.*).(php)$ – [F]

特别注意:上面的代码必须加在 PHP 引用配置的上方才有效(如 nginx 的 PHP 引用配置 include enable-php-**.conf;

默认 Linux 系统是大小写敏感的,所以规则中的正则表达式无须忽略大小写(但必须与实际的目录或文件名大小写一致),因为 MIME 类型中设置的是小写的 .php,那么类似大写的 .PHP 文件是不被 php-fpm 解释的,结果是被当作普通文本返回到客户端。

提问:有些目录需要设置为可写入,但里面还有正常的 php 文件,禁止执行会有问题吗?(例如 Discuz! 的 config 目录,ThinkPHP 的 Runtime 目录)

解答:以 Discuz! 为例,config 下面虽然有 config_*.php 等配置文件,但这些文件并非直接供客户端浏览,而是被其它 .php 文件引用(include 方式、IO 方式等),当 config 目录禁止执行 PHP 后并不会对它们造成影响。

我们在开发程序的过程中应避免在允许写入的目录下放置直接供客户端浏览的 .php 文件

二、程序上传的用户与执行 PHP 的用户相同(例如程序代码通过 FTP 上传,且和 PHP 一样,都使用 www 用户)

常见于虚拟空间。这种情况下,通过 PHP 上传的文件可以保存到该网站下面的任何目录下(甚至是网站目录之外,即传说中的跨站),原因大家都懂,默认 755 中第一个是“7”,即所有者拥有写入权限。

因此,除了做到上述设置,我们必须严格控制客户端上传文件的保存路径,做到以下几点:

必须更改客户端上传的文件名,而非直接使用原文件名;

不得从客户端文件名获取扩展名,或者只控制允许的后缀名。

最可靠的文件类型判别方式是分析文件签名,参考:文件签名表,以防篡改后缀名欺骗。

举个早期的栗子:上传文件名为 abc.asp;.jpg,未改文件名保存到服务器,浏览器直接访问该文件,IIS 6 当作 abc.asp 来解析。


xoyozo 7 年前
9,306

一、概述

    重定向常常和请求转发放在一起讨论(前者是两次不相关的请求,后者是一次请求服务器端转发),然而本文并不讨论两者的区别,而是HTTP 1.0规范和HTTP 1.1规范中关于重定向的区别,以及实际使用中的情况。

    重定向实际使用是一个响应码(301或302或303或307)和一个响应头location,当浏览器收到响应的时候check响应码是3xx,则会取出响应头中location对应的url(重定向中url的编码问题,请参看点击打开链接),然后将该url替换浏览器地址栏并发起另一次HTTP事务。

    关于301、302、303、307的区别,找不到好的文章,因此打算直撸HTTP 1.0规范和HTTP 1.1规范,结合一些实际的案例和tomcat实现,来说清楚这几个状态码的差异。

1. 百度https重定向

    如下图所示,原请求访问的是http://www.baidu.com,然后返回302和location=https://www.baidu.com,从http转到https。不过关于响应行中302状态码的描述存在争议,在下文中会详细讨论。

20160302023117361.png

20160302022905326.png

20160302022920077.png

2. tomcat重定向源码

20160302023539001.png

二、详细

    http 1.0规范中有2个重定向——301和302,在http 1.1规范中存在4个重定向——301、302、303和307,其中302是值得讨论讨论的。

1. http 1.0

301

    301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向,对于资源请求,原来的url和响应头中location的url而言,资源应该对应location中的url。对于post请求的重定向,还是需要用户确认之后才能重定向,并且应该以post方法发出重定向请求。

    关于post请求重定向用户确认的问题,实际上浏览器都没有实现;而且post请求的重定向应该发起post请求,这里浏览器也并不一定遵守,所以说HTTP规范的实现并未严格按照HTTP规范的语义。

    在301中资源对应的路径修改为location的url,在SEO中并未出现问题,但是在302中就出现了302劫持问题,请往下看。

20160302031823754.png

302

    在http 1.0规范中,302表示临时重定向,location中的地址不应该被认为是资源路径,在后续的请求中应该继续使用原地址。

    规范:原请求是post,则不能自动进行重定向;原请求是get,可以自动重定向;

    实现:浏览器和服务器的实现并没有严格遵守HTTP中302的规范,服务器不加遵守的返回302,浏览器即便原请求是post也会自动重定向,导致规范和实现出现了二义性,由此衍生了一些问题,譬如302劫持,因此在HTTP 1.1中将302的规范细化成了303和307,希望以此来消除二义性。

    补充:302劫持——A站通过重定向到B站的资源xxoo,A站实际上什么都没做但是有一个比较友好的域名,web资源xxoo存在B站并由B站提供,但是B站的域名不那么友好,因此对搜索引擎而言,可能会保存A站的地址对应xxoo资源而不是B站,这就意味着B站出了资源版权、带宽、服务器的钱,但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站,A站什么都没做却被索搜引擎广而告之用户,B站做了一切却不被用户知道,价值被A站窃取了。

20160302024330129.png

2. http 1.1

301

    和http 1.0规范中保持一致,注意资源对应的路径应该是location中返回的url,而不再是原请求地址。

302

    在HTTP 1.1中,实际上302是不再推荐使用的,只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向,为了消除HTTP 1.0中302的二义性,在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。

20160302034048122.png

303

    在HTTP 1.0的时候,302的规范是原请求是post不可以自动重定向,但是服务器和浏览器的实现是运行重定向。

    把HTTP 1.0规范中302的规范和实现拆分开,分别赋予HTTP 1.1中303和307,因此在HTTP 1.1中,303继承了HTTP 1.0中302的实现(即原请求是post,也允许自动进行重定向,结果是无论原请求是get还是post,都可以自动进行重定向),而307则继承了HTTP 1.0中302的规范(即如果原请求是post,则不允许进行自动重定向,结果是post不重定向,get可以自动重定向)。

20160302050017182.png

307

    在http 1.1规范中,307为临时重定向,注意划红线的部分,如果重定向307的原请求不是get或者head方法,那么浏览器一定不能自动的进行重定向,即便location有url,也应该忽略。

    也就是307继承了302在HTTP 1.0中的规范(303继承了302在HTTP 1.0中的实现)。

20160302045035716.png

3. 小结

    在HTTP 1.0规范中,302的规范并没有被服务器和浏览器遵守,即规范和实现出现了二义性,因此在HTTP 1.1中,将302的规范和实现拆分成了303和307。


20160304095217787.png

三、结论

    虽然在不同版本的http规范中对重定向赋予了不同的语义,但是因为使用历史和服务器实现等原因,在实际中并不一定安全按照http规范实现,因此我个人感觉上述讨论只是一个了解,在实际写代码中302还是继续用吧···


参考:

1. 《http 1.0规范》
2. 《http 1.1规范》

3. 博客:点击打开链接


附注:

    本文如有错漏,烦请不吝指正,谢谢!


转自 唐无敌 7 年前
5,612

网站的“防跨站攻击”默认是开启的,对应网站根目录下存在 .user.ini 文件可阻止该网站程序读写网站目录外的文件或目录


通过 FTP 上传或通过 PHP 创建的文件(夹)的用户(组)都是 www:www,目录权限 755,文件权限 644


PHP 不需要“执行”权限,因为这个“执行”权限是针对 sh 的


因此 PHP 在该站任何位置具有写入权限


理想的权限控制是:pure-ftp 使用另外的用户(组),譬如 ftp:ftp


这样使用 www:www 的 PHP 就无法随意创建文件,只能在开放了“公共权限”中的“写入”权限的目录中创建。


查看系统用户组:cat /etc/group

查看系统用户:cut -d : -f 1 /etc/passwd


查看 pure-ftp 帮助:

/www/server/pure-ftpd/bin/pure-pw --help


修改 FTP 用户的所有者和组:

/www/server/pure-ftpd/bin/pure-pw usermod FTP用户名 -u 所有者 -g 组


重启 pure-ftp


上述命令经简单测试并没有更改 FTP 用户的所有者和组……



退而求其次的做法是通过 SSH 用 root 来上传网站程序代码,并开放上传目录的“写入”权限


还有重要的一点,在网站的配置文件中禁止这些有“写入”权限的目录中的 PHP 运行权限!(参:在 CentOS (Linux) 中设置目录写入权限,并禁止执行 php


xoyozo 7 年前
6,878

本文不定时更新!


A: MySQL 执行 SHOW FULL PROCESSLIST 

Q: 查看连接数和慢查询,适用于 MySQL 数据库无法连接 1040


A: iftop -i eth0

Q: 查看占用带宽的IP(命令:iftop -i eth0 -F ip/24),添加到安全组、防火墙、宝塔的黑名单中。

命令 grep -l "x.x.x.x" /www/wwwlogs/*.log 可以在 wwwlogs 目录下的所有 .log 文件中查找指定的恶意 IP。


A: goaccess -f xxx.log

Q: 实时分析网站日志,查看请求最多的IP


A: net.xoyozo.weblog 日志分析工具

Q: 自制的 Web 日志分析工具,可按多种方式排序,纠出可疑访问


A: 重启 web 服务器

Q: 有时候能解决 CPU 和内存消耗的问题,如果一会儿又升高,则需要找另外的原因


Q: 500 服务器内部错误

502 Bad Gateway

504 Gateway Time-out

A: 查看 php 日志,可能的路径:

/usr/local/php/var/log/php-fpm.log

/www/server/php/[版本]/var/log/php-fpm.log


Q: RDS MySQL IOPS 使用率高的原因和处理

A: 根据时间点查看慢查询


Q: Discuz! 论坛界面错乱、表情不显示、模块缺失、登录失败、发帖失败等等

A: 进入管理中心 - 工具 - 更新缓存,能解决大部分问题


Q: Discuz! 浏览帖子提示“没有找到帖子

A: 进入数据库,修复表 pre_forum_post 或分表


Q: CPU 100% 或内存 100%,负载100+

A: 原因有很多,以下是一些建议:

Windows 在任务管理器中查看进程

当前是否有正常的大流量访问(譬如民生类论坛的某个帖子突然火了)特别是重启无效的情况

对比网站日志大小可大致确定哪个网站被大量恶意请求。

观察:命令 top

排查:通过关闭网站来确定是某网站的问题,通过关闭功能确定是某功能的问题,如果 nginx 崩溃请参下条

案例:通过修改 mobcent 文件夹名确定是安米的文件被疯狂请求导致的,更新插件和 mobcent 包解决问题。

如果都是正常访问,top 看到很多 php-fpm,而且个个占用 CPU 还不小,那么根据服务器硬件配置来修改 php 的并发量,如宝塔面板在 php 设置 - 性能调整 页,300 并发方案的推荐配置是:

max_children:300
start_servers:30
min_spare_servers:30
max_spare_servers:180

另外,memcached 或 redis 的配置也可以进行相应的修改。

另一个案例是 kswapd0 进程占满 CPU,原因是内存不足导致 swap 分区与内存频繁交换数据。同样调整 php 的设置即可。

也可以通过 iftop 来查询占用带宽较多的 IP 并封禁(出方向),如果 CPU 能降下来,那这个 IP 就是罪魁祸首。


Q: 阿里云 ECS 的 CPU 突然达到 100%,并持续到次日 0:00 左右

A: 可能 ECS 是 t5 规格,受 CPU 积分制度限制,积分耗尽时 CPU 不工作。解决方法是更换其它规格产品或升配。


Q: ASP.NET 所在服务器 CPU 突然达到 50% 或 100%,并持续

A: 首先确定哪个网站,再依次排查网站各功能。可能是 HttpWebRequest 请求远程数据时长时间未返回结果导致的程序阻塞。


Q: nginx 服务停止

A: 查看 nginx 日志

WDCP 路径:/www/wdlinux/nginx-1.0.15/logs/error.log


Q: 公网出带宽 100%,其它指标正常

A: Windows 在任务管理器-性能-资源监视器-网络 查看占用带宽的进程PID,然后在任务管理器-详细信息中的找到对应的用户(如果为每个网站分别创建了用户,就能知道是哪个网站占用了带宽);如果是被 PID 为 4 的 System 占用大部分带宽,也可以尝试重启 IIS 来解决。

CentOS 使用 nethogs 查看占用带宽的进程PID和USER,如果为每个网站分别创建了用户,就能知道是哪个网站占用了带宽,否则只能一个个关闭网站来判断,不知道大家有没有好的方法?当然还可以直接用 iftop 命令查看占用带宽的 IP。另外,查看每个网站在那个时间段的日志文件的大小也能大概看出是哪个网站被采集了。


A: Linux 显示每个用户会话的登入和登出信息

utmpdump /var/log/wtmp

参考:http://www.tulaoshi.com/n/20160331/2050641.html


Q: RDS 的 CPU 100%

A: 如果是突然持续占满(同时伴随 ECS 资源使用率下降,页面出现 502),很大可能是受攻击(或社交网站推送突发事件等),查看“慢查询”,添加相关索引;如果是 Discuz! 论坛,可尝试修复优化表 pre_common_session。

如果是数日缓步上升,或新项目上线,考虑 SQL 慢查询,思路:MySQL / SQL Server

MySQL:SHOW FULL PROCESSLIST

SQL Server:sp_who


Q: php 网站的服务器,内存在数天内缓慢上升

A: 大概是 php-fpm 占用过多,或进程数太多

更改 php 的配置(如 max_spare_servers),执行:service php-fpm reload


Q: 进程 cloudfs 占用内存过多

A: 参:https://xoyozo.net/Blog/Details/cloudfs-cache


Q: RDS 磁盘占用过大

A: 参:https://xoyozo.net/Blog/Details/how-to-use-rds


Q: ECS 受到 DDoS 攻击怎么办?

A: 参:https://xoyozo.net/Blog/Details/aliyun-ddos-without-bgp


Q: 如果 ECS 和 RDS 各项指标都没有异常,但网页打开慢或打不开502,TTFB 时间很长,是什么原因?(ECS 的 CPU 100%,RDS 的连接数上升,也可参考此条)

A: 数据库有坏表,尝试优化/修复表(慢 SQL 日志中锁等待时间较长的表?),或主备切换。show full processlist 时看到许多

DELETE FROM pre_common_session WHERE  sid='******'  OR lastactivity<******  OR (uid='0' AND ip1='*' AND ip2='*' AND ip3='*' AND ip4='*' AND lastactivity>******)


Q: Discuz! 创始人(站长)密码被改

A: 数据库找到 pre_ucenter_members 表,复制其它的已知登录密码的账号,复制其 password 和 salt 两个字段的值到创始人账号中,创始人账号即可用该密码登录了。


Q: 通过 iftop 观察到,Discuz! 网站从 RDS 数据库到 ECS 网站服务器私网流量非常大,远大于公网流量

A: 可能是缓存出问题了,尝试卸载重装 Redis 来解决。


Q: 宝塔面板中安装的 Redis 经常自动停止

A: 尝试卸载重装 Redis 来解决。


Q: 马甲客户端出现“您的网络有些问题”

A: 原因有许多,其中一个就是新建了一个数据表,然后 /source/class/table/ 下面丢失了对应的文件,具体可以找官方排查原因。


Q: 排查服务器安全需要检查哪些日志?

A: Web日志、登录日志(/var/log/secure)等。


xoyozo 8 年前
8,176

程序设计规范:


  • 【推荐】上传的文件直接保存到文件存储服务(如阿里云 OSS),这样即使被上传了后门 shell,对网站服务器也不会有影响。

  • 否则必须通过文件头来确定文件类型,检查文件十六进制的文件头和文件尾是否合法,并检查文件流中是否包含 php、evel 等字符。

  • 不可直接使用客户端文件名来保存文件,特别是后缀名/扩展名。应生成随机文件名,并通过检验文件头来确定文件类型。必须由程序指定保存目录。

  • 使用 OSS 的应直接上传,不要在 ECS 上临时存放或备份。如必须存放的,应按上述规范操作。


服务器安全设置


CentOS + nginx + PHP:

  • 全站文件取消属性中的“执行”权限(chmod),因为这个“执行”与运行 PHP 无关。而需要上传文件的“目录”需要“执行”权限,原因是需要往该目录创建文件。

  • 仅需要写入的目录或文件设置“写入”权限。如上传图片目录、ThinkPHP 的 Runtime 目录。

  • 凡可写目录或文件均不允许运行 PHP / PY 等 除需要被直接访问的 PHP / PY 文件,其它动态文件均不允许被访问到,在 nginx 的配置文件中添加项,参:https://xoyozo.net/Blog/Details/nginx-location-if,若全站使用统一的入口文件访问,那么设置仅该文件允许运行 PHP 即可。通过 IO 方式被其它文件包含的文件,无需运行 PHP 权限。(“deny all”对 include 起作用,但对 IO 不起作用,因此 Runtime 目录可以继续为 ThinkPHP 提供缓存服务。)这一步非常有用。

  • 使用与 nginx 网站用户不同的用户来部署网站文件,如宝塔面板 PHP 使用 www 用户,那么就使用 root 或其它新用户来上传文件,否则将导致全站目录和文件可写。有条件的建议不同网站使用不同的用户,可防止一个网站被入侵后导致其它网站文件或磁盘上的其它文件被泄露的风险(2022年10月2日从宝塔官方社区获悉,宝塔面板暂不支持使用非 www 用户创建并运行网站)。


Windows Server + IIS + ASP.NET:

  • 配置每个磁盘的安全属性,拒绝“IIS_IUSRS”这个用户组的所有权限。只要设置驱动器即可,子文件夹和文件会自动继承。若运行 .NET Framework 项目,需要设置 C:\Windows\Microsoft.NET\Framework\v*.*.*****\Temporary ASP.NET Files\ 目录可修改写入权限,.NET Core 项目不需要此设置。

  • 为每个网站创建一个新用户,仅隶属于“IIS_IUSRS”。网站根目录安全属性添加该用户,权限选择“读取”。(已测取消“读取与执行”不影响 PHP,“列出文件夹内容”视业务需求开启,建议关闭)。仅需要上传文件的目录或文件设置“修改”、“写入”权限。(修改对应修改文件,写入对应上传文件)

  • IIS 网站中设置“物理路径凭据”以及应用程序池的“标识”。

  • IIS 中设置写入目录的“处理程序映射”无脚本

xoyozo 9 年前
4,871

目前找到一种途径可以顺利把 Fireworks 或 Photoshop 的矢量图导出 / 转换为 CorelDRAW 的曲线:

Fireworks 中的路径如果不需要后期改变形状,最好都能够组合路径,以减少图层数,或者新建子层,把它们都拖进去。

  1. 在 Fireworks 中,另存为,选择 *.psd 格式
  2. 在 Photoshop 中,选中图层或子层,右键,复制 SVG
  3. 在桌面上新建一个文本文档,打开,粘贴,保存,关闭
  4. 将该文本文档更改后缀名为 .svg(此步可忽略)
  5. 将该文档拖到 CorelDRAW 窗口中即可
xoyozo 8 年前
6,755

打开 SSMS

选择数据库,右键,属性

选择“权限”,点击“查看服务器权限”

选择“数据库设置”,修改“备份”框路径

注意:更改一个数据库的备份路径后,对所有数据库都是有效的

现在如果备份数据库到新的目录,会报以下错误:

无法打开备份设备。出现操作系统错误 5(拒绝访问。)。BACKUP DATEBASE 正在异常终止。。

那就在新的备份目录上右键属性,安全,编辑,添加,在框内填写“NT SERVICE\MSSQLSERVER”这个服务用户,确定,(这个用户名称会自动变成“MSSQLSERVER”,如果没有这个用户,点击“高级”-“立即查找”,选择 MSSQLSERVER 或 NT SERVICE\MSSQL$InstanceName),然后选择“完全控制”,一路确定

现在可以备份到新的目录中去啦

xoyozo 8 年前
5,778

设规则:
    属性-文件传输规则-全局
        如果 时间 为 较旧 并且 传输 为 下载 那么 覆盖
        如果 大小 为 不同 并且 传输 为 下载 那么 覆盖
        如果没有匹配的规则,那么:跳过

建站点:
    站点-站点管理器-新建站点
        设好本地路径,传输 自定义规则 使用全局设置

队列:
    连接站点,在需要备份的目录上右键,队列
    在队列上右键,另存为

计划:
    工具-计划-新建任务
    选择队列文件,使用自定义规则
    设置执行时间,Windows 密码

设置完成!

xoyozo 11 年前
5,334