服务器安全应该注意哪些方面

一、绝对路径(_SERVER[“SCRIPT_FILENAME”])
这个是最常用，也是最有效的一个办法，找到phpinfo()页面可以直接找到网站的绝对路径，对于写shell和信息搜集是必不可少的。
二、支持的程序
可以通过phpinfo()查看一些特殊的程序服务，比如redis、memcache、mysql、SMTP、curl等等如果服务器装了redis或者memcache可以通过ssrf来getshell了，在discuz中都出现过此类问题。如果确定装了redis或memcache的话，在没有思路的情况下，可以着重找一下ssrf
三、泄漏真实ip（_SERVER[“SERVER_ADDR”]或SERVER_ADDR）
有时候通过phpinfo()泄漏的ip可以查查旁站、c段什么的，直接无视cdn，百事不灵。
四、GOPHER
也算是ssrf一部分吧，或者说主要靠ssrf利用起来，如果支持gopher，ssrf便没有压力咯
五、fastcgi
查看是否开启fastcgi和fastcgi的版本，可能导致解析漏洞、远程命令执行、任意文件读取等问题
六、泄漏缓存文件地址（_FILES[“file1”]）
向phpinfo（） post一个shell可以在_FILES[“file1”]中看到上传的临时文件，如果有个lfi，便可以直接getshell了。
七、一些敏感配置
allow_url_include、allow_url_fopen、disable_functions、open_basedir、short_open_tag等等
比如allow_url_include可用来远程文件包含、disable_functions用来查看禁用函数，绕过执行、查看是否开启open_basedir，用p牛的绕过open_basedir的方法有可能能读一些没权限的目录等等。
此外还能获取一些环境信息，比如Environment中的path、log等

如何消除网站安全的七大风险

改善之前

第三方专业安全测试公司进行测试，其中的重点问题列表如下：

问题1：易受到SQL注入攻击

风险：攻击者可以通过应用程序发送数据库命令，这些命令将被服务器执行。这可以用来对数据库进行完全控制。这些SQL注入漏洞可以通过在其中一个区域插入“and 7 = 7 -”或“and 8 = 9 -”，并比较结果进行判断。

分析：SQL注入攻击是由于服务器对参数检查不够，而导致攻击者借此获得敏感信息。因此，需要使用参数化查询以确保攻击者无法 *** 作数据库的SQL查询语句。例如，如果应用程序要求输入名称，那它应该只接受字母字符、空格和撇号，而不接受任何其他字符。也就是说，在应用程序中的所有输入域实施服务器端白名单技术。特别是所有用于SQL语句的输入域，需要空格的都应该用引号括起来。

改善：在程序中所有可接受外部参数的地方进行逐一识别，以过滤危险字符。如在全局函数中定义“禁止字符串列表”，该表中列出所要过滤出的SQL攻击代码可能包含的字符串。

and |exec |insert |select |delete |update |count |  |chr |mid |master |truncate |char |declare |<|>|’|(|)|{|}

//当然可以根据网站的特点完善和修改本列表

接下来做如下处理：

问题2：易受到跨站点脚本攻击

风险：此漏洞可以被用来获取身份验证Cookie，攻击管理员账户，或使应用程序的用户攻击其他服务器和系统。该漏洞可以通过在某区域中插入“<script>alert(‘23389950’);</script>”来判断。

分析：这也需要在本网站的所有输入域实施服务器端白名单技术。如果需要特殊字符，应该转换为更安全的形式。如适用于各种语言的HTML转码：

&应转换为 &；

“应转换为”；

‘应转换为&39；

>应转换为>；

<应转换为<。

改善：除了这些标准的HTML转码之外，对于可疑字符串也要进行强化检查和转化，并进一步执行以下 *** 作：（1）对各页面的输入参数进行强化检查；（2）对原来只在客户端判断的参数，在服务器端进一步强化检查;（3）最终提供了全局的转码和过滤的函数。当然这需要在性能和扩展性以及安全性方面的平衡综合考虑。

问题3：非安全的CrossDomainXML文件

风险：为解决Flash/Flex系统中的跨域问题，提出了crossdomainxml跨域策略文件。虽然可以解决跨域问题，但是也带来了恶意攻击的风险，如果该策略文件里允许访问任何域，就可能允许发起对网络服务器的跨站点请求伪造和跨站点脚本攻击。比如，不安全Flash应用程序可能会访问本地数据和用户保存的网页记录，甚至传播病毒和恶意代码。

分析：考虑如何确保只对提供安全资源的可信域开放允许。

改善：经过调查，发现在程序目录下的crossdomainxml文件里的配置如下：

<xml version=”10″>

<!DOCTYPE cross-domain-policy SYSTEM ”>

<cross-domain-policy>

<allow-access-from domain=”” />

</cross-domain-policy>

文件中的allow-access-from 实体设置为星号设置为允许任何域访问，将其修改为 <allow-access-from domain=”examplecom” />，表示只允许本域访问，该问题就解决了。

问题4：Flash参数AllowScript-Access 已设置为always

风险：当AllowScriptAccess为always时，表明嵌入的第三方Flash文件可以执行代码。攻击者此时就可以利用该缺陷嵌入任意第三方Flash文件而执行恶意
代码。

分析：AllowScriptAccess参数可以是“always”、”sameDomain”或“never”。三个可选值中，“always” 表示Flash文件可以与其嵌入到的 HTML 页进行通信，即使该Flash文件来自不同于HTML页的域也可以。当参数为“sameDomain”时，仅当Flash文件与其嵌入到的HTML页来自相同的域时，该Flash文件才能与该HTML页进行通信，此值是AllowScriptAccess 的默认值。而当AllowScriptAccess为 “never”时，Flash文件将无法与任何HTML页进行通信。

因此需要将AllowScriptAccess参数设置为“sameDomain”，可以防止一个域中的Flash文件访问另一个域的 HTML 页内的脚本。

改善

<param

name=”allowScriptAccess” value=”always” />

改为

<param

name=”allowScriptAccess” value=“sameDomain” />

问题5：网站后台管理通过不安全链接实施

风险：管理访问没有强制实施SSL，这可能允许攻击者监视并修改用户和服务器之间的发送的包括账户凭据在内的所有数据。如果攻击者通过代理或者路由软件拦截服务器和管理员间的通信，敏感数据可能被截获，进而管理员账户可能会受到危害。

分析：管理访问没有强制实施SSL，为防止数据拦截，管理访问应该强制执行>

改善：运维对服务器进行了配置调整，单独配置支持了SSL30访问管理后台。

问题6：验证环节可以被绕过

风险：用户发布信息时，虽然有页面的验证码防止自动恶意发布，但仍可能被绕过进行自动提交。绕过的方式之一是使用过滤和识别软件，之二是可以利用Cookie或Session信息绕过验证码。

分析：图像失真机制本身不是特别强，可以很容易地使用公开的过滤和识别软件来识别。生成的也是可以预测的，因为使用的字符集很简单（只是数字），建议实现一个更强大的验证码系统。

Cookie或session信息处理有漏洞导致验证码被绕过, 确保每一个链接只能取得唯一的验证码，并确保每个请求产生并需要一个新的验证码。

改善：根据需要增加验证码的复杂度，而不只是单数字。

经过分析发现是因为验证码被存入了Session里，而开发人员忘记在提交之后清空Session中的验证码的值，导致验证码在过期时间内一直可用，从而可能被利用多次提交。因此在提交后追加了及时清空验证码的 *** 作。

问题7：泄露敏感信息

风险：此信息只能用于协助利用其他漏洞，并不能直接用来破坏应用程序。网站的robotstxt文件里可以获得敏感目录的信息，这可能允许攻击者获得有关应用程序内部的其他信息，这些信息可能被用来攻击其他漏洞。

分析：robotstxt不应在提供管理界面的信息。如果robotstxt文件暴露了Web站点结构，则需要将敏感内容移至隔离位置，以避免搜索引擎机器人搜索到此内容。

改善：当然robotstxt要根据SEO的要求来处理，但也要同样注意安全性。如：disallow:/testadmin/，其中testadmin为管理后台，就被暴露了。可以根据实际情况是否必要决定删除robotstxt文件或者把敏感目录单独配置禁止搜索引擎搜索。

其他问题汇总

除此以外，还有很多其他危害性相对较低的问题，分析如下。

问题：可能通过登录页面枚举出用户名，因为根据账户是否存在的错误信息是不同的。

对策：修改错误信息使之不带有提示性，如“您输入的邮箱或密码不对!” 并且超过一定次数则对该IP进行锁定。

问题：检测到可能泄露敏感信息或被恶意利用的冗余文件，如测试文件、bak文件、临时文件。

对策：除去服务器中的相应文件。

问题：发现潜在机密信息，如名为order的文件很容易被联想到用户订单。

对策：避免在文件名中含有完整的敏感词汇或不要在容易猜测到的文件中保存敏感信息，或者限制对它们的访问。

问题：发现内部信息泄露。

对策：除去代码中漏删的内部IP地址，内部组织，人员相关信息等。

共性原因分析

在发现的问题中，71%是与应用程序相关的安全性问题。可以修改应用程序相关的安全性问题，因为它们是由应用程序代码中的缺陷造成的。29%是基础结构和平台安全性问题，可以由系统或网络管理员来修订“基础结构和平台安全性问题”，因为这些安全性问题是由第三方产品中的错误配置或缺陷造成的。

综合主要的原因包括但不限于以下三个方面。

程序方面

未对用户输入正确执行危险字符清理；

Cookie和Session使用时安全性考虑不足；

HTML注释中或Hidden form包含敏感信息；

提供给用户的错误信息包含敏感信息；

程序员在 Web 页面上的调试信息等没有及时删除。

Web 应用程序编程或配置不安全；

配置方面

在Web目录中留下的冗余文件没有及时清理；

Web服务器或应用程序服务器是以不安全的方式配置的。

安全规范文档不够完善，开发人员的培训不足；

开发人员的安全相关经验和安全意识不足。

对于这些问题的解决方法-——技术之外

对于安全问题本身的解决可能只能case by case ，但为了预防更多潜在问题的引入，技术之外方面的改善也不容忽视：

1 对于开发人员在项目初期即进行安全开发的培训，强化安全意识。

2 建立用于共享安全经验的平台，将经验形成Checklist作为安全指南文档。

3 将成熟的代码成果提炼出公共安全模块以备后用。

本次改善之后总结出一些常用基本安全原则供大家参考，见“非官方不完整网站开发安全原则”。

作者简介：晁晓娟，目前在互联网公司负责项目管理。InfoQ中文站SOA社区编辑，有多年的Web开发管理经验，关注项目管理、架构和产品。

(本文来自《程序员》杂志13年02期)

Web服务器攻击常利用Web服务器软件和配置中的漏洞，web服务器安全也是我们现在很多人关注的一点，那么你知道web服务器安全设置吗下面是我整理的一些关于web服务器安全设置的相关资料，供你参考。

web服务器安全设置一、IIS的相关设置

删除默认建立的站点的虚拟目录，停止默认web站点，删除对应的文件目录c:inetpub，配置所有站点的公共设置，设置好相关的连接数限制， 带宽设置以及性能设置等其他设置。配置应用程序映射，删除所有不必要的应用程序扩展，只保留asp，php，cgi，pl，aspx应用程序扩展。对于php和cgi，推荐使用isapi方式解析，用exe解析对安全和性能有所影响。用户程序调试设置发送文本错误信息给客户。

对于数据库，尽量采用mdb后缀，不需要更改为asp，可在IIS中设置一个mdb的扩展映射，将这个映射使用一个无关的dll文件如C:WINNTsystem32inetsrvssincdll来防止数据库被下载。设置IIS的日志保存目录，调整日志记录信息。设置为发送文本错误信息。修改403错误页面，将其转向到其他页，可防止一些扫描器的探测。另外为隐藏系统信息，防止telnet到80端口所泄露的系统版本信息可修改IIS的banner信息，可以使用winhex手工修改或者使用相关软件如banneredit修改。

对于用户站点所在的目录，在此说明一下，用户的FTP根目录下对应三个文件佳，>

对网络服务器的恶意网络行为包括两个方面：一是恶意的攻击行为，如拒绝服务攻击，网络病毒等等，这些行为旨在消耗服务器资源，影响服务器的正常运作，甚至服务器所在网络的瘫痪;另外一个就是恶意的入侵行为，这种行为更是会导致服务器敏感信息泄露，入侵者更是可以为所欲为，肆意破坏服务器。所以我们要保证网络服务器的安全可以说就是尽量减少网络服务器受这两种行为的影响。

(一) 构建好你的硬件安全防御系统

选用一套好的安全系统模型。一套完善的安全模型应该包括以下一些必要的组件：防火墙、入侵检测系统、路由系统等。

防火墙在安全系统中扮演一个保安的角色，可以很大程度上保证来自网络的非法访问以及数据流量攻击，如拒绝服务攻击等;入侵检测系统则是扮演一个监视器的角色，监视你的服务器出入口，非常智能地过滤掉那些带有入侵和攻击性质的访问。

(二) 选用英文的 *** 作系统

要知道，windows毕竟美国微软的东西，而微软的东西一向都是以Bug 和 Patch多而著称，中文版的Bug远远要比英文版多，而中文版的补丁向来是比英文版出的晚，也就是说，如果你的服务器上装的是中文版的windows系统，微软漏洞公布之后你还需要等上一段时间才能打好补丁，也许黑客、病毒就利用这段时间入侵了你的系统。

如何防止黑客入侵

首先，世界上没有绝对安全的'系统。我们只可以尽量避免被入侵，最大的程度上减少伤亡。

(一) 采用NTFS文件系统格式

大家都知道，我们通常采用的文件系统是FAT或者FAT32，NTFS是微软Windows NT内核的系列 *** 作系统支持的、一个特别为网络和磁盘配额、文件加密等管理安全特性设计的磁盘格式。NTFS文件系统里你可以为任何一个磁盘分区单独设置访问权限。把你自己的敏感信息和服务信息分别放在不同的磁盘分区。这样即使黑客通过某些方法获得你的服务文件所在磁盘分区的访问权限，还需要想方设法突破系统的安全设置才能进一步访问到保存在其他磁盘上的敏感信息。

(二)做好系统备份

常言道，“有备无患”，虽然谁都不希望系统突然遭到破坏，但是不怕一万，就怕万一，作好服务器系统备份，万一遭破坏的时候也可以及时恢复。

(三)关闭不必要的服务，只开该开的端口

关闭那些不必要开的服务，做好本地管理和组管理。Windows系统有很多默认的服务其实没必要开的，甚至可以说是危险的，比如：默认的共享远程注册表访问(Remote Registry Service)，系统很多敏感的信息都是写在注册表里的，如pcanywhere的加密密码等。

关闭那些不必要的端口。一些看似不必要的端口，确可以向黑客透露许多 *** 作系统的敏感信息，如windows 2000 server默认开启的IIS服务就告诉对方你的 *** 作系统是windows 2000。69端口告诉黑客你的 *** 作系统极有可能是linux或者unix系统，因为69是这些 *** 作系统下默认的tftp服务使用的端口。对端口的进一步访问，还可以返回该服务器上软件及其版本的一些信息，这些对黑客的入侵都提供了很大的帮助。此外，开启的端口更有可能成为黑客进入服务器的门户。总之，做好TCP/IP端口过滤不但有助于防止黑客入侵，而且对防止病毒也有一定的帮助。

（ 四)软件防火墙、杀毒软件

虽然我们已经有了一套硬件的防御系统，但是“保镖”多几个也不是坏事。

(五)开启你的事件日志

虽然开启日志服务虽然说对阻止黑客的入侵并没有直接的作用，但是通过他记录黑客的行踪，我们可以分析入侵者在我们的系统上到底做过什么手脚，给我们的系统到底造成了哪些破坏及隐患，黑客到底在我们的系统上留了什么样的后门，我们的服务器到底还存在哪些安全漏洞等等。如果你是高手的话，你还可以设置密罐，等待黑客来入侵，在他入侵的时候把他逮个正着。

---