phpcms模板_专业制作网站服务_企业网站推广方案设计_seo收索引擎优化

《白帽子讲Web安全》15章

15、Web Server配置安全

15.1、Apache安全

Web Server的安全我们关注两点：一是 Web Server本身是否安全；二是Web Server是否提供了可使用的安全功能。

1. 检查Apache安全的第一件事情，就是检查Apache的Module安装情况，根据“最小权限原则”，应该尽可能地减少不必要的Module，对于要使用的Module，则检查其对应版本是否存在已知的安全漏洞。

2. 指定Apache进程以单独的用户身份运行，这通常需要为Apache单独建立一个user/group。

   Apache 以root身份或者admin身份运行是一个非常糟糕的决定。这里的admin身份是指服务器管理员在管理机器时使用的身份。这个身份的权限也是比较高的，因为管理员有操作管理脚本、访问配置文件、读/写日志等需求。使用高权限身份运行Apache的结果可能是灾难性的，它会带来两个可怕的后果:

   • 当黑客入侵 Web 成功时，将直接获得一个高权限（比如root或admin)的shell
   • 应用程序本身将具备较高权限，当出现bug时，可能会带来较高风险，比如删除本地重要文件、杀死进程等不可预知的结果。

   比较好的做法是使用专门的用户身份运行Apache，这个用户身份不应该具备shell，它唯一的作用就是用来运行Web应用。

3. 配置参数，优化服务器性能，提高对抗DDOS攻击的能力。

4. 最后，要保护好Apache Log。一般来说，攻击者入侵成功后，要做的第一件事情就是清除入侵痕迹,修改、删除日志文件,因此 access log应当妥善保管,比如实时地发送到远程的syslog服务器上。

15.2、Nginx安全

从历史的经验来看，如果一个软件出现的漏洞较多，那么说明代码维护者的安全意识与安全经验有所欠缺，同时由于破窗效应，这个软件未来往往会出现更多的漏洞。

就软件安全本身来看，Nginx 与 Apache最大的区别在于，检查Apache安全时更多的要关注Module的安全，而 Nginx 则需要注意软件本身的安全，及时升级软件版本。与Apache一样，Nginx 也应该以单独的身份运行，这是所有Web Server、容器软件应该共同遵守的原则。

1. 首先，Nginx 的配置非常灵活，在对抗DDOS和CC攻击方面也能起到一定的缓解作用,
2. 其次，在 Nginx配置中还可以做一些简单的条件判断，比如客户端User-Agent具有什么特征，或者来自某个特定referer、IP等条件，响应动作可以是返回错误号，或进行重定向。

在此仍需强调的是，Web Server对于DDOS攻击的防御作用是有限的。对于大规模的拒绝服务攻击，需要使用更加专业的保护方案。

15.3、jBoss远程命令执行

jBoss是J2EE环境中一个流行的Web容器，但是 jBoss在默认安装时提供的一些功能却不太安全，如果配置不得当，则可能直接造成远程命令执行。

由于jBoss在默认安装时会有一个管理后台，叫做JMX-Console，它提供给管理员一些强大的功能，其中包括配置MBeans，这同样也会为黑客们打开方便之门。通过8080端口（默认安装时会监听8080端口）访问/jmx-console 能够进入到这个管理界面。默认安装时访问JMX-Console是没有任何认证的。
在JMX-Console中，有多种可以远程执行命令的方法。

1. 最简单的方式，是通过DeploymentScanner远程加载一个war包。
2. 德国的Redteam安全小组研究发现，通过JMX-Console提供的BSH (Bean Shell)Deployment方法，同样也能布署war包。BSH能够执行一次性的脚本，或者创建服务，这对于黑客来说很有用。

因此出于安全防御的目的，在加固时，需要删除JMX-Console后台，事实上，jBoss 的使用完全可以不依赖于它。如果出于业务需要不得不使用JMX-Console，则应该使用一个强壮的密码，并且运行JMX-Console的端口不应该面向整个Internet开放。

15.4、Tomcat远程命令执行

Apache Tomcat 与jBoss一样，默认也会运行在8080端口。它提供的Tomcat Manager的作用与JMX-Console类似，管理员也可以在Tomcat Manager中部署war包。但值得庆幸的是，Tomcat Manager布署war包需要有manager权限，而这一权限是在配置文件中定义的。

虽然Tomcat后台有密码认证，但笔者仍然强烈建议删除这一后台，因为攻击者可以通过暴力破解等方式获取后台的访问权限，从安全的角度看，这增加了系统的攻击面，得不偿失。

15.5、HTTP Parameter Pollution

在2009年的OWASP大会上，Luca、Carettoni等人演示了这种被称为HPP的攻击。简单来说，就是通过GET或 POST向服务器发起请求时，提交两个相同的参数，那么服务器会如何选择呢?
比如提交:

/?a=test&a=test1

在某些服务端环境中，会只取第一个参数；而在另外一些环境中，比如.net环境中，则会变成：

a=test,testl

这种特性在绕过一些服务器端的逻辑判断时，会非常有用。

这种HPP攻击，与Web服务器环境、服务器端使用的脚本语言有关。HPP本身可以看做服务器端软件的一种功能，参数选择的顺序是由服务器端软件所决定的。但是正如我们在本书中所举的很多例子一样，当程序员不熟悉软件的这种功能时，就有可能造成误用，或者程序逻辑涵盖范围不够全面，从而形成漏洞。
HPP的发现者，在测试了大量服务器软件版本的组合后，整理出下表，作为参考。

15.6、小结

在本章中探讨了Web Server、Web容器相关的安全问题。

• Web Server、Web容器是Web应用的载体，是基础，它们的安全与否将直接影响到应用的安全性。
• 在搭建服务器端环境时，需要注意最小权限原则,应该以独立的低权限身份运行Web进程。同时 Web Server的一些参数能够优化性能，有助于缓解DDOS攻击，在实际运用时可以酌情使用。
• Web Server本身的漏洞也需要时刻关注，而有些Web容器的默认配置甚至可能还会成为弱点，一名合格的安全工程师应该熟知这些问题。

第四篇 互联网公司运营安全

《白帽子讲Web安全》16章

16、互联网业务安全

16.1、产品需要什么样的安全

安全本身可视作产品的一个组成部分。一个好的产品，在设计之初，就应该考虑是否会存在安全隐患，从而提前准备好对策。将安全视为产品特性，往往也就解决了业务与安全之间的矛盾。

其实业务与安全之间本来是没有冲突的，出现冲突往往是因为安全方案设计得不够完美。比如安全方案的实现成本相对较高，从而不得不牺牲一些产品功能上的需求，有时候牺牲的可能还有性能。

16.1.1、互联网产品对安全的需求

1. 搜索结果是否安全，对网民来说是很重要的，因为搜索引擎是互联网最重要的一个门户。

   一个好的全网搜索引擎，其爬虫所抓取的页面可能会达到十亿到百亿的数量级。要一个个检测这些网页是否安全，也是件非常艰巨和有挑战的事情。目前搜索引擎的普遍做法是与专业的安全厂商进行合作，排查搜索结果中的恶意网址。

2. 除了搜索引擎外，电子邮箱领域的竞争也凸显了安全的重要性。在电子邮箱领域，最重要的一项安全特性就是“反垃圾邮件”。

   目前在反垃圾邮件领域，各家互联网公司都各有妙招。在用户使用的电子邮箱中，能够收到的垃圾邮件多少，也能判断出各个互联网公司在安全实力上的高低。

3. 推而广之，可以发现，在互联网中，一个成熟的产品几乎必然会存在安全性方面的竞争。

   安全性做得好的产品，对于用户来说可能不会有什么特别的感觉，因为坏人、坏的信息已经被处理掉了；相反，如果产品安全没有做好，则用户一定会感受到:垃圾消息泛滥、骗子满地跑，这些业务安全的问题会带来糟糕的用户体验，有时候甚至会毁掉一个新兴的领域。

安全是产品特性的一个组成部分，具备了安全性，产品才是完整的；安全做好了，产品最终才能真正成熟。

16.1.2、什么是好的安全方案

笔者认为，一个优秀的安全方案，除了可以有效地解决问题以外，至少还必须具备两个条件:

1. 良好的用户体验；
2. 优秀的性能。

双因素认证提高了用户的使用门槛，损失了部分用户体验，设置复杂密码也是一种糟糕的体验。

“提高密码复杂度”这个安全需求，其本质其实可以分解为:

1. 如何对抗暴力破解;

   可以在登录的应用中检测暴力破解的尝试。检查一个账户在一段时间内的登录失败次数，或者检测某一个IP地址在一段时间内的登录行为次数。这些行为都是比较明显的暴力破解特征。暴力破解往往还借助了脚本或者扫描器，那么在检测到此类行为后向特定客户端返回一个验证码，也可以有效地缓解暴力破解攻击。

2. 如何防止密码中包含个人信息。

   如何防止密码中包含个人信息呢？在用户注册时，可以收集到用户填写的个人资料，如果发现用户使用了诸如：用户名、邮件地址、生日、电话号码之类的个人信息作为密码，则应当立即进行提示。

安全是产品的一种特性，如果我们的产品能够潜移默化地培养用户的安全习惯，将用户往更安全的行为上引导，那么这样的安全就是最理想的产品安全。

16.2、业务逻辑安全

16.2.1、永远改不掉的密码

业务逻辑问题与业务的关系很紧密，花样百出，很难总结归类。

业务逻辑问题是一种设计缺陷，在产品开发过程中,可以考虑在产品设计和测试阶段解决。但业务逻辑问题没有一个成熟的归纳体系，很多时候，只能依靠安全工程师的个人经验来判断这些问题。

16.2.2、谁是大赢家

某家在线购物网站为了对抗密码暴力破解，规定短时间内账户登录失败5次，就将锁定账户一个小时。该网站的业务中，提供了一个在线竞拍的功能，用户可以给喜欢的商品出价，后来者必须给出一个更高的价格。在拍卖时间截止后，商品将为出价高者所得。之前也有想到过，这里感觉锁IP更好一些

某黑客在给商品出价后，在网站上继续观察谁出了一个更高的价格，当他发现有人出价更高时，就去恶意登录这个用户的账户：当登录失败次数达到5次时，该账户就被系统锁定了。

暴力破解通常都有一定的特征：

• 比如某个账户在5分钟内登录错误达到10次。
• 根据弱口令来遍历用户名的，比如黑客使用密码“123456”，尝试登录不同的用户名。这需要黑客事先收集一份可以使用的ID列表。

但无论如何变化，暴力破解是需要高效率的，所以“短时间”“高频率”的行为特征比较明显。黑客为了躲避安全系统的检测，常常会使用多个IP地址来进行登录尝试。这些IP地址可能是代理服务器，也可能是傀儡机。
但经过实践检验，即使黑客使用了多个IP地址，想要使攻击达到一定的规模，还是会使用重复的IP地址。最终的结果就是单个IP地址可能会发起多次网络请求。

16.2.3、瞒天过海

16.2.4、关于密码取回流程

很多网站曾经提供的“修改密码”功能中，也存在一个典型的逻辑问题:用户修改密码时不需要提供当前密码。

这种设计，导致账户被盗后，黑客就可以直接使用此功能修改账户的密码。账户被盗的原因有很多种，比如 Cookie劫持导致的账户被盗，黑客是不知道用户密码的。因此修改密码时不询问当前密码，是一个逻辑漏洞。

正确的做法是，在进行敏感操作之前再次认证用户的身份。

用户密码丢失后，就不能再使用用户密码作为认证手段。通常，如果不考虑客服的话，用户想自助取回密码，有三个方法可以用来认证用户：

• 一是用户设定的安全问题；
• 二是用户注册时留下的安全邮箱；
• 三是给用户发送手机短信验证码，这需要用户预留手机信息。

当三种认证信息都不太可靠时，只能选择一些其他的办法来解决。一个比较好的方法，是使用用户在网站上留下过的一些私有信息，与用户逐一核对，以验证用户身份确实是本人。

比如：用户曾经使用过的密码;用户曾经登录过的时间、地点;用户曾经在站内发表过，但又删除了的文章等。这些信息可以称为用户的“基因”，因为这些信息越详细，就越能准确地区分出一个独立的用户。

16.3、账户是如何被盗的

16.3.1、账户被盗的途径

1. 网站登录过程中无HTTPS，密码在网络中被嗅探。
2. 用户电脑中了木马，密码被键盘记录软件所获取。
3. 用户被钓鱼网站所迷惑，密码被钓鱼网站所骗取。
4. 网站某登录入口可以被暴力破解。
5. 网站密码取回流程存在逻辑漏洞。
6. 网站存在XSS 等客户端脚本漏洞，用户账户被间接窃取。
7. 网站存在SQL注入等服务器端漏洞，网站被黑客入侵导致用户账户信息泄露。

以上这些威胁中，除了“用户电脑中了木马”与“用户上了钓鱼网站”这两点与用户自身有关外，其余几点都是可以从服务器端进行控制的。换句话说，如果这几点没有做好而导致的安全问题，网站都应该负主要责任。

这节还是再强调，弱口令与个人密码的复用，在不同网站使用的是同个或相近的密码，是导致暴力破解存在且长期有效的原因。

另外，用户的密码不应明文保存在数据库中。

16.3.2、分析账户被盗的原因

• 首先，客服是最重要和直接的渠道。
  从客服收集第一手资料，甚至由工程师回访客户，会有意想不到的收获。
• 其次，从日志中寻找证据。
  除了从客户处收集第一手资料外，也应该重视网站日志的作用，从日志中去大胆求证。
• 最后，打入敌人内部，探听最新动态。
  在黑色产业链中，有人制作、销售工具，也有人专门从事诈骗活动。这些人建立的群体，关系并不是非常紧密的，可能仅仅是依靠QQ群或其他IM互相联系。

16.4、互联网的垃圾

16.4.1、垃圾的危害

垃圾注册几乎成为一切业务安全问题的源头。

一般来说，“目的不是网站所提供的服务”的注册账户，都属于垃圾账户。

16.4.1、垃圾处理

垃圾处理离不开两个步骤：“识别”和“拦截”。

拦截的方法根据业务而定。可以选择冻结账户或者删除账户，也可以只针对垃圾内容做屏蔽。但问题的关键是屏蔽什么、拦截什么，这就涉及到“垃圾识别技术”了。

如果仔细分析垃圾行为特征，可以大致分成:内容的特征、行为的特征、客户端本身的特征。从这三个方面入手，可以得出不同类型的规则。

• 基于内容的规则：以自然语言分析、关键词匹配等为代表。
• 基于行为的规则:以业务逻辑规则为代表。
• 基于客户端识别的规则:以人机识别为代表，比如验证码，或者让客户端去解析JavaScript。

识别出非法用户和非法行为后，在“拦截”上也需要讲究策略和战术。因为很多时候，规则都是“见光死”，规则的保密性非常重要。如果使用规则和恶意用户做直接对抗，那么规则的内容很容易暴露，导致规则很快会被绕过。因此要有技巧地保护规则。

如何保护呢？以“拦截”来说，如果不是特别紧急的业务，则可以打一个时间差。当使用规则识别出垃圾账户后，过一段时间再做处理，这样恶意用户就摸不准到底触犯了哪条规则。同时还可以“打压”大部分账户，放过一小批账户。这样既控制住大部分的风险，又让风险不会随意转移，可以一直把可控的风险放在明处。这样从防御的角度看，就能掌握主动权。

与垃圾注册和垃圾信息的对抗最终还是会升级。作为安全团队，需要紧跟敌人的变化，走在敌人的前面。

16.5、关于网络钓鱼

16.5.1、钓鱼网站简介

在国外，钓鱼网站（Phishing）的定义是页面中包含了登录表单的网站，此类网站的目的是骗取用户的密码。

但是随着网络犯罪手段的多样化，很多钓鱼网站开始模仿登录页面之外的页面，目标也不仅仅是简单的骗取密码。此类钓鱼网站可以称为“欺诈网站”，也可以认为是广义的钓鱼网站，因为它们都是以模仿目标网站的页面为基本技术手段。在本书中，将统一称之为“钓鱼网站”。

16.5.2、邮件钓鱼

钓鱼邮件，是垃圾邮件的一种，它比广告邮件更有针对性。

令人比较无奈的是，SMTP协议是可以由用户伪造发件人邮箱的。而在邮件服务器上，如果没有实施相关的安全策略，则无从识别发件人邮箱的真伪。

识别发件人邮箱的安全技术，大部分是基于域名策略的，比如SPF（Sender Policy Framework）、Yahoo 的 DomainKeys、微软的Sender ID技术等。

• Yahoo的 DomainKeys会生成一对公私钥。公钥布署在收信方的 DNS服务器上，用于解密；
  私钥则用于发信方的邮件服务器，对发出的每封邮件进行签名。这样收信方在收信时，到DNS服务器上查询属于发信方域名的公钥，并对邮件中的加密串进行解密验证，以确保该邮件来自正确域。

• SPF技术与 DomainKeys不同，SPF是基于IP策略的，有点类似于DNS反向解析。收信方在接收到邮件时，会去 DNS查询发信方域的SPF记录。这个记录写着发信方邮件服务器和IP的对应关系，检查了这个记录后，就可以确定该邮件是不是发自指定IP的邮件服务器，从而判断邮件真伪。

• 微软的Sender ID技术，是以 SPF为基础的。

16.5.3、钓鱼网站的防控

16.5.3.1、钓鱼网站的传播途径

控制钓鱼网站传播的途径，就能对钓鱼网站实施有效的打击。

网络钓鱼是需要整个互联网共同协作解决的一个问题，因此当钓鱼传播途径脱离了目标网站本身的范畴时，应该积极地通过与外部合作的方式，共建一个安全的大环境，也就是建立一个反钓鱼的统一战线。

浏览器是一个较为特殊的环节，因为浏览器是互联网的入口，钓鱼网站不管是在IM中传播，还是在邮件里传播，归根结底还是要上到浏览器上的。所以在浏览器中拦截钓鱼网站，能事半功倍。

16.5.3.2、直接打击钓鱼网站

在钓鱼网站的防控中，还有一个有力的措施，就是关停站点。

16.5.3.3、用户教育

16.5.3.4、自动化识别钓鱼网站

在钓鱼网站的拦截过程中，有一个关键的工作，就是快速而准确地识别钓鱼网站。依靠人工处理钓鱼网站，工作量会非常大，因此有必要使用技术手段，对钓鱼网站进行一些自动化的识别。

16.5.4、网购流程钓鱼

分析与防范网购流程钓鱼
一个正常的网购流程，一般如下:

商户（比如淘宝网)→第三方支付平台（比如支付宝、yeepay)→网上银行（比如工商银行）

这实际上是一个跨平台传递信息的过程。
贯穿不同平台的唯一标识，是订单号。订单中只包含了商品信息，但缺少创建订单用户的相关信息。这是网上支付流程中存在的一个重大设计缺陷。

造成这个设计缺陷的原因是，在网购过程中的每个平台都有一套自己的账户体系，而账户体系之间并没有对应关系。因此平台与平台之间，只能根据订单本身的信息作为唯一的判断依据。

比如银行的账户是银行卡号和开户名，第三方支付平台有自己的账户，商户又有自己的一套账户体系（比如京东商城)。

解决这个设计缺陷的方法是，找到一个唯一的客户端信息，贯穿于整个网上支付流程的所有平台，保证订单是由订单创建者本人支付的。
目前看来，使用客户端IP地址作为这个信息，比较经济，易于推广。

16.6、用户隐私保护

16.6.1、互联网的用户隐私挑战

在互联网时代，网站在提供服务的同时，也拥有了各种各样的用户数据。

在PCI-DSS（支付卡行业数据与安全标准）中，PCI认为技术是复杂的，要想完美地保护好用户个人信息比较困难,最好的做法是限制数据的使用——“不存在的数据是最安全的”。

目前互联网缺乏一个对用户隐私数据分级和保护的标准，没有定义清楚哪些数据是敏感的，哪些数据是公开化的，从而也无从谈起隐私数据应该如何保护。

16.6.2、如何保护用户隐私

• 首先，用户应该拥有知情权和选择权。
• 其次，网站应该妥善保管收集到的用户数据，不得将数据用于任何指定范围以外的用途。

16.6.3、Do-Not-Track

Do-Not-Track工作在浏览器上。该选项打开后，将在HTTP头中增加一个header，用以告诉网站用户不想被追踪。

16.7、Do-Not-Track

本章讲述的是互联网安全中，网站最关心的业务安全。

互联网公司在发展业务时，也许会忽略自身的安全防护和漏洞修补，但一定不会漠视业务安全问题。因为业务安全问题，直接损害的是用户的利益、公司的利益，这些安全问题会有真正的切肤之痛。因此无论是公司内部，还是政府、行业，甚至是社会舆论，都会产生足够大的压力和推动力，迫使互联网公司认真对待业务安全问题。

互联网公司要想健康地发展，离不开业务安全。把握住业务安全，对于公司的安全部门来说，就真正把握住了部门发展的命脉，这是真正看得见、摸得着的敌人。业务安全问题更加直接，损失的都是真金白银，考核的自标也易于设定。

安全工程师可以承担更大的责任，帮助公司的业务健康成长。