免费的网站程序,如何申请免费企业邮箱,网站建设柒金手指排名二一,定制网站建设公司哪家便宜《白帽子讲Web安全》15-16章 《白帽子讲Web安全》15章15、Web Server配置安全15.1、Apache安全15.2、Nginx安全15.3、jBoss远程命令执行15.4、Tomcat远程命令执行15.5、HTTP Parameter Pollution15.6、小结 第四篇 互联网公司运营安全《白帽子讲Web安全》16章16、互联网业务安全… 《白帽子讲Web安全》15-16章 《白帽子讲Web安全》15章15、Web Server配置安全15.1、Apache安全15.2、Nginx安全15.3、jBoss远程命令执行15.4、Tomcat远程命令执行15.5、HTTP Parameter Pollution15.6、小结 第四篇 互联网公司运营安全《白帽子讲Web安全》16章16、互联网业务安全16.1、产品需要什么样的安全16.1.1、互联网产品对安全的需求16.1.2、什么是好的安全方案 16.2、业务逻辑安全16.2.1、永远改不掉的密码16.2.2、谁是大赢家16.2.3、瞒天过海16.2.4、关于密码取回流程 16.3、账户是如何被盗的16.3.1、账户被盗的途径16.3.2、分析账户被盗的原因 16.4、互联网的垃圾16.4.1、垃圾的危害16.4.1、垃圾处理 16.5、关于网络钓鱼16.5.1、钓鱼网站简介16.5.2、邮件钓鱼16.5.3、钓鱼网站的防控16.5.3.1、钓鱼网站的传播途径16.5.3.2、直接打击钓鱼网站16.5.3.3、用户教育16.5.3.4、自动化识别钓鱼网站 16.5.4、网购流程钓鱼 16.6、用户隐私保护16.6.1、互联网的用户隐私挑战16.6.2、如何保护用户隐私16.6.3、Do-Not-Track 16.7、Do-Not-Track 《白帽子讲Web安全》15章
15、Web Server配置安全
15.1、Apache安全
Web Server的安全我们关注两点一是 Web Server本身是否安全二是Web Server是否提供了可使用的安全功能。 检查Apache安全的第一件事情就是检查Apache的Module安装情况根据“最小权限原则”应该尽可能地减少不必要的Module对于要使用的Module则检查其对应版本是否存在已知的安全漏洞。 指定Apache进程以单独的用户身份运行这通常需要为Apache单独建立一个user/group。 Apache 以root身份或者admin身份运行是一个非常糟糕的决定。这里的admin身份是指服务器管理员在管理机器时使用的身份。这个身份的权限也是比较高的因为管理员有操作管理脚本、访问配置文件、读/写日志等需求。使用高权限身份运行Apache的结果可能是灾难性的它会带来两个可怕的后果: 当黑客入侵 Web 成功时将直接获得一个高权限比如root或admin)的shell应用程序本身将具备较高权限当出现bug时可能会带来较高风险比如删除本地重要文件、杀死进程等不可预知的结果。 比较好的做法是使用专门的用户身份运行Apache这个用户身份不应该具备shell它唯一的作用就是用来运行Web应用。 配置参数优化服务器性能提高对抗DDOS攻击的能力。 最后要保护好Apache Log。一般来说攻击者入侵成功后要做的第一件事情就是清除入侵痕迹,修改、删除日志文件,因此 access log应当妥善保管,比如实时地发送到远程的syslog服务器上。
15.2、Nginx安全 从历史的经验来看如果一个软件出现的漏洞较多那么说明代码维护者的安全意识与安全经验有所欠缺同时由于破窗效应这个软件未来往往会出现更多的漏洞。 就软件安全本身来看Nginx 与 Apache最大的区别在于检查Apache安全时更多的要关注Module的安全而 Nginx 则需要注意软件本身的安全及时升级软件版本。与Apache一样Nginx 也应该以单独的身份运行这是所有Web Server、容器软件应该共同遵守的原则。 首先Nginx 的配置非常灵活在对抗DDOS和CC攻击方面也能起到一定的缓解作用,其次在 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中有多种可以远程执行命令的方法。
最简单的方式是通过DeploymentScanner远程加载一个war包。德国的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向服务器发起请求时提交两个相同的参数那么服务器会如何选择呢? 比如提交:
/?atestatest1在某些服务端环境中会只取第一个参数而在另外一些环境中比如.net环境中则会变成
atest,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、互联网产品对安全的需求 搜索结果是否安全对网民来说是很重要的因为搜索引擎是互联网最重要的一个门户。 一个好的全网搜索引擎其爬虫所抓取的页面可能会达到十亿到百亿的数量级。要一个个检测这些网页是否安全也是件非常艰巨和有挑战的事情。目前搜索引擎的普遍做法是与专业的安全厂商进行合作排查搜索结果中的恶意网址。 除了搜索引擎外电子邮箱领域的竞争也凸显了安全的重要性。在电子邮箱领域最重要的一项安全特性就是“反垃圾邮件”。 目前在反垃圾邮件领域各家互联网公司都各有妙招。在用户使用的电子邮箱中能够收到的垃圾邮件多少也能判断出各个互联网公司在安全实力上的高低。 推而广之可以发现在互联网中一个成熟的产品几乎必然会存在安全性方面的竞争。 安全性做得好的产品对于用户来说可能不会有什么特别的感觉因为坏人、坏的信息已经被处理掉了相反如果产品安全没有做好则用户一定会感受到:垃圾消息泛滥、骗子满地跑这些业务安全的问题会带来糟糕的用户体验有时候甚至会毁掉一个新兴的领域。
安全是产品特性的一个组成部分具备了安全性产品才是完整的安全做好了产品最终才能真正成熟。
16.1.2、什么是好的安全方案
笔者认为一个优秀的安全方案除了可以有效地解决问题以外至少还必须具备两个条件:
良好的用户体验优秀的性能。
双因素认证提高了用户的使用门槛损失了部分用户体验设置复杂密码也是一种糟糕的体验。
“提高密码复杂度”这个安全需求其本质其实可以分解为: 如何对抗暴力破解; 可以在登录的应用中检测暴力破解的尝试。检查一个账户在一段时间内的登录失败次数或者检测某一个IP地址在一段时间内的登录行为次数。这些行为都是比较明显的暴力破解特征。暴力破解往往还借助了脚本或者扫描器那么在检测到此类行为后向特定客户端返回一个验证码也可以有效地缓解暴力破解攻击。 如何防止密码中包含个人信息。 如何防止密码中包含个人信息呢在用户注册时可以收集到用户填写的个人资料如果发现用户使用了诸如用户名、邮件地址、生日、电话号码之类的个人信息作为密码则应当立即进行提示。
安全是产品的一种特性如果我们的产品能够潜移默化地培养用户的安全习惯将用户往更安全的行为上引导那么这样的安全就是最理想的产品安全。
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、账户被盗的途径
网站登录过程中无HTTPS密码在网络中被嗅探。用户电脑中了木马密码被键盘记录软件所获取。用户被钓鱼网站所迷惑密码被钓鱼网站所骗取。网站某登录入口可以被暴力破解。网站密码取回流程存在逻辑漏洞。网站存在XSS 等客户端脚本漏洞用户账户被间接窃取。网站存在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协议是可以由用户伪造发件人邮箱的。而在邮件服务器上如果没有实施相关的安全策略则无从识别发件人邮箱的真伪。
识别发件人邮箱的安全技术大部分是基于域名策略的比如SPFSender 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
本章讲述的是互联网安全中网站最关心的业务安全。
互联网公司在发展业务时也许会忽略自身的安全防护和漏洞修补但一定不会漠视业务安全问题。因为业务安全问题直接损害的是用户的利益、公司的利益这些安全问题会有真正的切肤之痛。因此无论是公司内部还是政府、行业甚至是社会舆论都会产生足够大的压力和推动力迫使互联网公司认真对待业务安全问题。
互联网公司要想健康地发展离不开业务安全。把握住业务安全对于公司的安全部门来说就真正把握住了部门发展的命脉这是真正看得见、摸得着的敌人。业务安全问题更加直接损失的都是真金白银考核的自标也易于设定。
安全工程师可以承担更大的责任帮助公司的业务健康成长。
