SSL/TLS原理详解 技术文章

本文大部分整理自网络,相关文章请见文后参考。

关于证书授权中心CA以及数字证书等概念,请移步 OpenSSL 与 SSL 数字证书概念贴 ,如果你想快速自建CA然后签发数字证书,请移步 基于OpenSSL自建CA和颁发SSL证书 

SSL/TLS作为一种互联网安全加密技术,原理较为复杂,枯燥而无味,我也是试图理解之后重新整理,尽量做到层次清晰。正文开始。

1. SSL/TLS概览

1.1 整体结构

SSL是一个介于HTTP协议与TCP之间的一个可选层,其位置大致如下:

00.png 

  • SSL:(Secure Socket Layer,安全套接字层),为Netscape所研发,用以保障在Internet上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。
    SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。SSL协议可分为两层: SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

  • TLS:(Transport Layer Security,传输层安全协议),用于两个应用程序之间提供保密性和数据完整性。
    TLS 1.0是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本,可以理解为SSL 3.1,它是写入了 RFC 的。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议(例如 TCP)上面。

SSL/TLS协议提供的服务主要有:

  1. 认证用户和服务器,确保数据发送到正确的客户机和服务器;
  2. 加密数据以防止数据中途被窃取;
  3. 维护数据的完整性,确保数据在传输过程中不被改变。

1.2 TLS与SSL的差异

  1. 版本号:TLS记录格式与SSL记录格式相同,但版本号的值不同,TLS的版本1.0使用的版本号为SSLv3.1。
  2. 报文鉴别码:SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法,两者差别在于SSLv3.0中,填充字节与密钥之间采用的是连接运算,而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
  3. 伪随机函数:TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块,是更安全的方式。
  4. 报警代码:TLS支持几乎所有的SSLv3.0报警代码,而且TLS还补充定义了很多报警代码,如解密失败(decryption_failed)、记录溢出(record_overflow)、未知CA(unknown_ca)、拒绝访问(access_denied)等。
  5. 密文族和客户证书:SSLv3.0和TLS存在少量差别,即TLS不支持Fortezza密钥交换、加密算法和客户证书。
  6. certificate_verify和finished消息:SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时,计算的输入有少许差别,但安全性相当。
  7. 加密计算:TLS与SSLv3.0在计算主密值(master secret)时采用的方式不同。
  8. 填充:用户数据加密之前需要增加的填充字节。在SSL中,填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中,填充后的数据长度可以是密文块长度的任意整数倍(但填充的最大长度为255字节),这种方式可以防止基于对报文长度进行分析的攻击。

TLS的主要增强内容

TLS的主要目标是使SSL更安全,并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上,提供了以下增强内容:

  1. 更安全的MAC算法
  2. 更严密的警报
  3. “灰色区域”规范的更明确的定义

TLS对于安全性的改进

  1. 对于消息认证使用密钥散列法:TLS 使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0还提供键控消息认证,但HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。
  2. 增强的伪随机功能(PRF):PRF生成密钥数据。在TLS中,HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。
  3. 改进的已完成消息验证:TLS和SSLv3.0都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS将此已完成消息基于PRF和HMAC值之上,这也比SSLv3.0更安全。
  4. 一致证书处理:与SSLv3.0不同,TLS试图指定必须在TLS之间实现交换的证书类型。
  5. 特定警报消息:TLS提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

2. 密钥协商过程——TLS握手

SSL协议分为两部分:Handshake Protocol和Record Protocol。其中Handshake Protocol用来协商密钥,协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。

由于非对称加密的速度比较慢,所以它一般用于密钥交换,双方通过公钥算法协商出一份密钥,然后通过对称加密来通信,当然,为了保证数据的完整性,在加密前要先经过HMAC的处理。

SSL缺省只进行server端的认证,客户端的认证是可选的。以下是其流程图(摘自TLS协议)。

000040-2015-09-24.jpg


2.1 客户端发出请求(ClientHello)

由于客户端(如浏览器)对一些加解密算法的支持程度不一样,但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段,客户端首先要告知服务端,自己支持哪些加密算法,所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外,客户端还要产生一个随机数,这个随机数一方面需要在客户端保存,另一方面需要传送给服务端,客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

综上,在这一步,客户端主要向服务器提供以下信息:

  1. 支持的协议版本,比如TLS 1.0版
  2. 一个客户端生成的随机数,稍后用于生成"对话密钥"
  3. 支持的加密方法,比如RSA公钥加密
  4. 支持的压缩方法

2.2 服务器回应(SeverHello)

上图中,从Server Hello到Server Done,有些服务端的实现是每条单独发送,有服务端实现是合并到一起发送。Sever Hello和Server Done都是只有头没有内容的数据。

服务端在接收到客户端的Client Hello之后,服务端需要将自己的证书发送给客户端。这个证书是对于服务端的一种认证。例如,客户端收到了一个来自于称自己是www.alipay.com的数据,但是如何证明对方是合法的alipay支付宝呢?这就是证书的作用,支付宝的证书可以证明它是alipay,而不是财付通。证书是需要申请,并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存,不可泄漏。公钥则是附带在证书的信息中,可以公开的。证书本身也附带一个证书电子签名,这个签名用来验证证书的完整性和真实性,可以防止证书被串改。另外,证书还有个有效期。

在服务端向客户端发送的证书中没有提供足够的信息(证书公钥)的时候,还可以向客户端发送一个 Server Key Exchange,

此外,对于非常重要的保密数据,服务端还需要对客户端进行验证,以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息,要求客户端发送证书对客户端的合法性进行验证。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书。

跟客户端一样,服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。

最后服务端会发送一个Server Hello Done消息给客户端,表示Server Hello消息结束了。

综上,在这一步,服务器的回应包含以下内容:

  1. 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信
  2. 一个服务器生成的随机数,稍后用于生成"对话密钥"
  3. 确认使用的加密方法,比如RSA公钥加密
  4. 服务器证书

2.3 客户端回应(Certificate Verify)

Client Key Exchange

如果服务端需要对客户端进行验证,在客户端收到服务端的 Server Hello 消息之后,首先需要向服务端发送客户端的证书,让服务端来验证客户端的合法性。

Certificate Verify
接着,客户端需要对服务端的证书进行检查,如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。如果证书没有问题,客户端就会从服务器证书中取出服务器的公钥。然后,向服务器发送下面三项信息:

  1. 一个随机数。该随机数用服务器公钥加密,防止被窃听
  2. 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送
  3. 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验

上面第一项的随机数,是整个握手阶段出现的第三个随机数,它是客户端使用一些加密算法(例如:RSA, Diffie-Hellman)产生一个48个字节的Key,这个Key叫 PreMaster Secret,很多材料上也被称作 PreMaster Key。

ChangeCipherSpec
ChangeCipherSpec是一个独立的协议,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了。

在ChangecipherSpec传输完毕之后,客户端会使用之前协商好的加密套件和Session Secret加密一段 Finish 的数据传送给服务端,此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。

2.4 服务器的最后回应(Server Finish)

服务端在接收到客户端传过来的 PreMaster 加密数据之后,使用私钥对这段加密数据进行解密,并对数据进行验证,也会使用跟客户端同样的方式生成 Session Secret,一切准备好之后,会给客户端发送一个 ChangeCipherSpec,告知客户端已经切换到协商过的加密套件状态,准备使用加密套件和 Session Secret加密数据了。之后,服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端,以验证之前通过握手建立起来的加解密通道是否成功。

根据之前的握手信息,如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证,则说明握手通道已经建立成功,接下来,双方可以使用上面产生的Session Secret对数据进行加密传输了。

2.5 几个secret

Secret Keys
上面的分析和讲解主要是为了突出握手的过程,所以PreMaster secret,Master secret,session secret都是一代而过,但是对于Https,SSL/TLS深入的理解和掌握,这些Secret Keys是非常重要的部分。所以,准备把这些Secret Keys抽出来单独分析和讲解。

我们先来看看这些Secret Keys的生成过程以及作用流程图:

000041-2015-09-24.jpg



PreMaster secret
PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端,服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

PreMaster secret前两个字节是TLS的版本号,这是一个比较重要的用来核对握手数据的版本号,因为在Client Hello阶段,客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端,而且是使用明文传送的,如果握手的数据包被破解之后,攻击者很有可能串改数据包,选择一个安全性较低的加密套件和版本给服务端,从而对数据进行破解。所以,服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比,如果版本号变低,则说明被串改,则立即停止发送任何消息。

关于PreMaster Secret(Key)的计算请参考 Https SSL/TLS PreMaster/Master Secret(Key)计算

Master secret
上面已经提到,由于服务端和客户端都有一份相同的PreMaster secret和随机数,这个随机数将作为后面产生Master secret的种子,结合PreMaster secret,客户端和服务端将计算出同样的Master secret。

Master secret是有系列的hash值组成的,它将作为数据加解密相关的secret的 Key Material 的一部分。Key Material最终解析出来的数据如下:

000042-2015-09-24.jpg



其中,write MAC key,就是session secret或者说是session key。Client write MAC key是客户端发数据的session secret,Server write MAC secret是服务端发送数据的session key。MAC(Message Authentication Code),是一个数字签名,用来验证数据的完整性,可以检测到数据是否被串改。

关于Session Secret(Key)的计算请参考 Https SSL/TLS Session Secret(Key)计算

2.6 应用数据传输

在所有的握手阶段都完成之后,就可以开始传送应用数据了。应用数据在传输之前,首先要附加上MAC secret,然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后,使用Client write encryption key进行解密,客户端收到服务端的数据之后使用Server write encryption key进行解密,然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。

2.7 总结

SSL客户端(也是TCP的客户端)在TCP链接建立之后,发出一个ClientHello来发起握手,这个消息里面包含了自己可实现的算法列表和其它一些需要的消息,SSL的服务器端会回应一个ServerHello,这里面确定了这次通信所需要的算法,然后发过去自己的证书(里面包含了身份和自己的公钥)。Client在收到这个消息后会生成一个秘密消息,用SSL服务器的公钥加密后传过去,SSL服务器端用自己的私钥解密后,会话密钥协商成功,双方可以用同一份会话密钥来通信了。

3. 附:密钥协商的形象化比喻

如果上面的说明不够清晰,这里我们用个形象的比喻,我们假设A与B通信,A是SSL客户端,B是SSL服务器端,加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。

A:我想和你安全的通话,我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH,摘要算法有MD5和SHA。

B:我们用DES-RSA-SHA这对组合好了。
这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份(把证书发给A)。
目前没有别的可说的了。

A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)
(产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量(IV)和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)
我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B)
注意,下面我就要用加密的办法给你发消息了!
(将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥)
[我说完了]

B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)
注意,我也要开始用加密的办法给你发消息了!
[我说完了]

A: [我的秘密是...]

B: [其它人不会听到的...]

4. SSL安全性

SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论, 目前也有一些成熟的工具如dsniff(http://www.monkey.org/~dugsong/dsniff/)可以通过man in the middle攻击来截获https的消息。

从上面的原理可知,SSL的结构是严谨的,问题一般出现在实际不严谨的应用中。常见的攻击就是middle in the middle攻击,它是指在A和B通信的同时,有第三方C处于信道的中间,可以完全听到A与B通信的消息,并可拦截,替换和添加这些消息。

  1. SSL可以允许多种密钥交换算法,而有些算法,如DH,没有证书的概念,这样A便无法验证B的公钥和身份的真实性,从而C可以轻易的冒充,用自己的密钥与双方通信,从而窃听到别人谈话的内容。
    而为了防止middle in the middle攻击,应该采用有证书的密钥交换算法。
  2. 有了证书以后,如果C用自己的证书替换掉原有的证书之后,A的浏览器会弹出一个警告框进行警告,但又有多少人会注意这个警告呢?
  3. 由于美国密码出口的限制,IE,netscape等浏览器所支持的加密强度是很弱的,如果只采用浏览器自带的加密功能的话,理论上存在被破解可能。

5. 代理

下面探讨一下SSL的代理是怎样工作的
当在浏览器里设置了https的代理,而且里输入了https://www.example.com之后,浏览器会与proxy建立tcp链接,然后向其发出这么一段消息:

 CONNECT server.example.com:443 HTTP/1.1
   Host: server.example.com:443 

然后proxy会向webserver端建立tcp连接,之后,这个代理便完全成了个内容转发装置。浏览器与web server会建立一个安全通道,因此这个安全通道是端到端的,尽管所有的信息流过了proxy,但其内容proxy是无法解密和改动的(当然要由证书的支持,否则这个地方便是个man in the middle攻击的好场所,见上面的安全部分)。

CA证书以及如何使用OpenSSL自签署,见文章OpenSSL自签署证书 。

6. 参考

原文链接地址:http://seanlook.com/2015/01/07/tls-ssl-understand/ (国外,需要梯子请在本博客搜索,关键字:查资料)



admin 发布于  2015-9-24 21:58 

nginx配置ssl加密(单双向认证、部分https) 技术文章

nginx下配置ssl本来是很简单的,无论是去认证中心买SSL安全证书还是自签署证书,但最近公司OA的一个需求,得以有个机会实际折腾一番。一开始采用的是全站加密,所有访问http:80的请求强制转换(rewrite)到https,后来自动化测试结果说响应速度太慢,https比http慢慢30倍,心想怎么可能,鬼知道他们怎么测的。所以就试了一下部分页面https(不能只针对某类动态请求才加密)和双向认证。下面分节介绍。

默认nginx是没有安装ssl模块的,需要编译安装nginx时加入--with-http_ssl_module选项。

关于SSL/TLS原理请参考 这里,如果你只是想测试或者自签发ssl证书,参考 这里 。

提示:nignx到后端服务器由于一般是内网,所以不加密。

1. 全站ssl

全站做ssl是最常见的一个使用场景,默认端口443,而且一般是单向认证。

server {
        listen 443;
        server_name example.com;
        root /apps/www;
        index index.html index.htm;
        ssl on;
        ssl_certificate ../SSL/ittest.pem;
        ssl_certificate_key ../SSL/ittest.key;
#        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
#        ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
#        ssl_prefer_server_ciphers on;
}



如果想把http的请求强制转到https的话:

server {
  listen      80;
  server_name example.me;
  rewrite     ^   https://$server_name$request_uri? permanent;
### 使用return的效率会更高 
#  return 301 https://$server_name$request_uri;
}


ssl_certificate证书其实是个公钥,它会被发送到连接服务器的每个客户端,ssl_certificate_key私钥是用来解密的,所以它的权限要得到保护但nginx的主进程能够读取。当然私钥和证书可以放在一个证书文件中,这种方式也只有公钥证书才发送到client。

ssl_protocols指令用于启动特定的加密协议,nginx在1.1.13和1.0.12版本后默认是ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2,TLSv1.1与TLSv1.2要确保OpenSSL >= 1.0.1 ,SSLv3 现在还有很多地方在用但有不少被攻击的漏洞。

ssl_ciphers选择加密套件,不同的浏览器所支持的套件(和顺序)可能会不同。这里指定的是OpenSSL库能够识别的写法,你可以通过 openssl -v cipher 'RC4:HIGH:!aNULL:!MD5'(后面是你所指定的套件加密算法) 来看所支持算法。

ssl_prefer_server_ciphers on设置协商加密算法时,优先使用我们服务端的加密套件,而不是客户端浏览器的加密套件。

https优化参数

  • ssl_session_cache shared:SSL:10m; : 设置ssl/tls会话缓存的类型和大小。如果设置了这个参数一般是sharedbuildin可能会参数内存碎片,默认是none,和off差不多,停用缓存。如shared:SSL:10m表示我所有的nginx工作进程共享ssl会话缓存,官网介绍说1M可以存放约4000个sessions。 详细参考serverfault上的问答ssl_session_cache
  • ssl_session_timeout : 客户端可以重用会话缓存中ssl参数的过期时间,内网系统默认5分钟太短了,可以设成30m即30分钟甚至4h

设置较长的keepalive_timeout也可以减少请求ssl会话协商的开销,但同时得考虑线程的并发数了。

提示:在生成证书请求csr文件时,如果输入了密码,nginx每次启动时都会提示输入这个密码,可以使用私钥来生成解密后的key来代替,效果是一样的,达到免密码重启的效果:

 
openssl rsa -in ittest.key -out ittest_unsecure.key


导入证书

如果你是找一个知名的ssl证书颁发机构如VeriSign、Wosign、StartSSL签发的证书,浏览器已经内置并信任了这些根证书,如果你是自建C或获得二级CA授权,都需要将CA证书添加到浏览器,这样在访问站点时才不会显示不安全连接。各个浏览的添加方法不在本文探讨范围内。

2. 部分页面ssl

一个站点并不是所有信息都是非常机密的,如网上商城,一般的商品浏览可以不通过https,而用户登录以及支付的时候就强制经过https传输,这样用户访问速度和安全性都得到兼顾。

但是请注意不要理解错了,是对页面加密而不能针对某个请求加密,一个页面或地址栏的URL一般会发起许多请求的,包括css/png/js等静态文件和动态的java或php请求,所以要加密的内容包含页面内的其它资源文件,否则就会出现http与https内容混合的问题。在http页面混有https内容时,页面排版不会发生乱排现象;在https页面中包含以http方式引入的图片、js等资源时,浏览器为了安全起见会阻止加载。

下面是只对example.com/account/login登录页面进行加密的例子:

root /apps/www;
index index.html index.htm;
server {
    listen      80;
    server_name example.com;
    location ^~ /account/login {
        rewrite ^ https://$server_name:443$request_uri? permanent;
    }
    location / {
        proxy_pass  http://localhost:8080;

        ### Set headers ####
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_redirect     off; 
    }
}
server {
    listen 443 ssl;
    server_name example.com;
    ssl on;
    ssl_certificate ../SSL/ittest.pem;
    ssl_certificate_key ../SSL/ittest.key;
    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers on;
    location ^~ /account/login {
        proxy_pass  http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_redirect     off; 
        ### Most PHP, Python, Rails, Java App can use this header -> https ###
        proxy_set_header X-Forwarded-Proto  $scheme;
    }
    location / {
        rewrite  ^  http://$server_name$request_uri? permanent;
    }
}


关于rewrite与location的写法参考这里。当浏览器访问http://example.com/account/login.xx时,被301到https://example.com/account/login.xx,在这个ssl加密的虚拟主机里也匹配到/account/login,反向代理到后端服务器,后面的传输过程是没有https的。这个login.xx页面下的其它资源也是经过https请求nginx的,登录成功后跳转到首页时的链接使用http,这个可能需要开发代码里面控制。

  • 上面配置中使用了proxy_set_header X-Forwarded-Proto $scheme,在jsp页面使用request.getScheme()得到的是https 。如果不把请求的$scheme协议设置在header里,后端jsp页面会一直认为是http,将导致响应异常。
  • ssl配置块还有个与不加密的80端口类似的location /,它的作用是当用户直接通过https访问首页时,自动跳转到不加密端口,你可以去掉它允许用户这样做。

3. 实现双向ssl认证

上面的两种配置都是去认证被访问的站点域名是否真实可信,并对传输过程加密,但服务器端并没有认证客户端是否可信。(实际上除非特别重要的场景,也没必要去认证访问者,除非像银行U盾这样的情况)

要实现双向认证HTTPS,nginx服务器上必须导入CA证书(根证书/中间级证书),因为现在是由服务器端通过CA去验证客户端的信息。还有必须在申请服务器证书的同时,用同样的方法生成客户证书。取得客户证书后,还要将它转换成浏览器识别的格式(大部分浏览器都认识PKCS12格式):

openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12


然后把这个client.p12发给你相信的人,让它导入到浏览器中,访问站点建立连接的时候nginx会要求客户端把这个证书发给自己验证,如果没有这个证书就拒绝访问。

同时别忘了在 nginx.conf 里配置信任的CA:(如果是二级CA,请把根CA放在后面,形成CA证书链)

proxy_ignore_client_abort on;
    ssl on;
    ...
    ssl_verify_client on;
    ssl_verify_depth 2;
    ssl_client_certificate ../SSL/ca-chain.pem;
# 在双向location下加入:
    proxy_set_header X-SSL-Client-Cert $ssl_client_cert;


拓展:使用geo模块

nginx默认安装了一个ngx_http_geo_module,这个geo模块可以根据客户端IP来创建变量的值,用在如来自172.29.73.0/24段的IP访问login时使用双向认证,其它段使用一般的单向认证。

geo $duplexing_user {
    default 1;
    include geo.conf;  # 注意在0.6.7版本以后,include是相对于nginx.conf所在目录而言的
}



语法 geo [$address] $variable { … },位于http段,默认地址是$reoute_addr,假设 conf/geo.conf 内容:

127.0.0.1/32    LOCAL;  # 本地
172.29.73.23/32 SEAN;   # 某个IP
172.29.73.0/24  1;      # IP段,可以按国家或地域定义后面的不同的值




需要配置另外一个虚拟主机server{ssl 445},里面使用上面双向认证的写法,然后在80或443里使用变量$duplexing_user去判断,如果为1就rewrite到445,否则rewrite到443。具体用法可以参考nginx geo使用方法

参考

原文地址:http://seanlook.com/2015/05/28/nginx-ssl/



admin 发布于  2015-9-24 21:48 

一段代码让nginx实现网站资源防盗链 技术文章

000038-2015-09-24.jpg

很多人喜欢复制粘贴别人的东西,这没啥,说明有价值,作者应该高兴,但是呢,不留出处,这就不好了,于是呢,可以再服务器段简单的设置一下实现防盗链。


 location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|flv)$
        {
            expires      30d;
            valid_referers none blocked *.mrxn.net *.emlog.net *.qq.com;
            if ($invalid_referer) {
            rewrite ^/ http://i11.tietuku.com/0783ef75758999f8.gif;
            #return 404;
            }//防盗链
        }

资源类型可以自己增加或者是删除,第二句 expires 30d; 是资源在客服端浏览器缓存的时间为30天,这样可以加速网站打开速度,减轻服务器负担,更具实际情况做适当调整。下面几句就是防盗链的白名单,支持正则匹配,只是修改有点麻烦,每次添加或者是删除都需要修改配置文件。


具体的nginx配置专业术语可参考相关文章:

nginx配置location总结及rewrite规则写法

nginx配置ssl加密(单双向认证、部分https)

NginxRewrite规则判断普通用户与搜索引擎爬虫(UA)实现https跳转

SSL/TLS原理详解

OpenSSL 与 SSL 数字证书概念贴

基于OpenSSL自建CA和颁发SSL证书


admin 发布于  2015-9-24 21:36 

NginxRewrite规则判断普通用户与搜索引擎爬虫(UA)实现https跳转 技术文章

nginx.jpg

前段时间写了一篇关于给博客安装证书加密访问的文章,在站长平台,百度说支持https,一个月后发现网站的流量排名跌成了狗,为了逼格保留这个https,又为了不和百度做对,查阅相关资料后选择用user_agent来解决,nginx本身就能判断UA,以下代码供大家参考,添加到nginxRewrite配置文件里即可,域名换成自己的。

000039-2015-09-24.jpg

具体的代码如下(复制吧-骚年):



server {
listen 80;
server_name mrxn.net mrxn.net;
set $flag 0;
if ($host != 'mrxn.net') {
 set $flag 1;
}
if ($server_port = 80) {
 set $flag 1;
}
if ($scheme = http) {
 set $flag 1;
}
if ($http_user_agent ~* (baiduspider|soso|sogou|yahoo|sohu-search|yodao|YoudaoBot|robozilla|msnbot|MJ12bot|NHN|Twiceler)){
 set $flag 2;
}
if ($flag = 1){
 rewrite ^/(.*)$ https://mrxn.net/$1 redirect;
}
error_page 497 https://mrxn.net$request_uri;

}



这段规则具体作用是:将国内部分对https支持不好的搜索引擎蜘蛛定向到http页面,将普通用户和其他搜索引擎定向到https页面(谷歌更喜欢https站点)。


相关文章:

一段代码让nginx实现网站资源防盗链

nginx配置location总结及rewrite规则写法

nginx配置ssl加密(单双向认证、部分https)

NginxRewrite规则判断普通用户与搜索引擎爬虫(UA)实现https跳转

SSL/TLS原理详解

OpenSSL 与 SSL 数字证书概念贴

基于OpenSSL自建CA和颁发SSL证书


原文属于博友创造:https://tmy123.com/user-agent.html


admin 发布于  2015-9-24 21:26 

一大波恶意消耗手机流量的木马正席卷国内! 业界新闻

日前,国内最大移动互联网安全机构——360手机安全中心发布年内最高级别安全预警,“流量僵尸”手机木马已感染近45万部手机,中招者每解锁手机一次都会导致木马疯狂耗流量,日耗流量超百余兆,几天时间就耗损1G流量!360手机安全中心已经向有关部门进行举报。

央视报道:360手机卫士预警,“流量僵尸”致45万人流量费超千元

01.png



admin 发布于  2015-9-23 20:04 

Emlog文章标题自动生成英语别名,利于SEO emlog

很多搞SEO的通常都是自己把文章标题给写成拼音,这样感觉好麻烦的有没有,现在可以在修改内核的保存文件就行,前提是你要善于折腾,如果不喜欢又懒得折腾的那就不需要看下去了。

改动教程:
1、打开admin目录下载的save_log.php文件,在里面加入以下代码

class Chinese_to_PY {
    /**
     * 拼音字符转换图
     * @var array
     */
    private static $_aMaps = array(
        'a'=>-20319,'ai'=>-20317,'an'=>-20304,'ang'=>-20295,'ao'=>-20292,
        'ba'=>-20283,'bai'=>-20265,'ban'=>-20257,'bang'=>-20242,'bao'=>-20230,'bei'=>-20051,'ben'=>-20036,'beng'=>-20032,'bi'=>-20026,'bian'=>-20002,'biao'=>-19990,'bie'=>-19986,'bin'=>-19982,'bing'=>-19976,'bo'=>-19805,'bu'=>-19784,
        'ca'=>-19775,'cai'=>-19774,'can'=>-19763,'cang'=>-19756,'cao'=>-19751,'ce'=>-19746,'ceng'=>-19741,'cha'=>-19739,'chai'=>-19728,'chan'=>-19725,'chang'=>-19715,'chao'=>-19540,'che'=>-19531,'chen'=>-19525,'cheng'=>-19515,'chi'=>-19500,'chong'=>-19484,'chou'=>-19479,'chu'=>-19467,'chuai'=>-19289,'chuan'=>-19288,'chuang'=>-19281,'chui'=>-19275,'chun'=>-19270,'chuo'=>-19263,'ci'=>-19261,'cong'=>-19249,'cou'=>-19243,'cu'=>-19242,'cuan'=>-19238,'cui'=>-19235,'cun'=>-19227,'cuo'=>-19224,
        'da'=>-19218,'dai'=>-19212,'dan'=>-19038,'dang'=>-19023,'dao'=>-19018,'de'=>-19006,'deng'=>-19003,'di'=>-18996,'dian'=>-18977,'diao'=>-18961,'die'=>-18952,'ding'=>-18783,'diu'=>-18774,'dong'=>-18773,'dou'=>-18763,'du'=>-18756,'duan'=>-18741,'dui'=>-18735,'dun'=>-18731,'duo'=>-18722,
        'e'=>-18710,'en'=>-18697,'er'=>-18696,
        'fa'=>-18526,'fan'=>-18518,'fang'=>-18501,'fei'=>-18490,'fen'=>-18478,'feng'=>-18463,'fo'=>-18448,'fou'=>-18447,'fu'=>-18446,
        'ga'=>-18239,'gai'=>-18237,'gan'=>-18231,'gang'=>-18220,'gao'=>-18211,'ge'=>-18201,'gei'=>-18184,'gen'=>-18183,'geng'=>-18181,'gong'=>-18012,'gou'=>-17997,'gu'=>-17988,'gua'=>-17970,'guai'=>-17964,'guan'=>-17961,'guang'=>-17950,'gui'=>-17947,'gun'=>-17931,'guo'=>-17928,
        'ha'=>-17922,'hai'=>-17759,'han'=>-17752,'hang'=>-17733,'hao'=>-17730,'he'=>-17721,'hei'=>-17703,'hen'=>-17701,'heng'=>-17697,'hong'=>-17692,'hou'=>-17683,'hu'=>-17676,'hua'=>-17496,'huai'=>-17487,'huan'=>-17482,'huang'=>-17468,'hui'=>-17454,'hun'=>-17433,'huo'=>-17427,
        'ji'=>-17417,'jia'=>-17202,'jian'=>-17185,'jiang'=>-16983,'jiao'=>-16970,'jie'=>-16942,'jin'=>-16915,'jing'=>-16733,'jiong'=>-16708,'jiu'=>-16706,'ju'=>-16689,'juan'=>-16664,'jue'=>-16657,'jun'=>-16647,
        'ka'=>-16474,'kai'=>-16470,'kan'=>-16465,'kang'=>-16459,'kao'=>-16452,'ke'=>-16448,'ken'=>-16433,'keng'=>-16429,'kong'=>-16427,'kou'=>-16423,'ku'=>-16419,'kua'=>-16412,'kuai'=>-16407,'kuan'=>-16403,'kuang'=>-16401,'kui'=>-16393,'kun'=>-16220,'kuo'=>-16216,
        'la'=>-16212,'lai'=>-16205,'lan'=>-16202,'lang'=>-16187,'lao'=>-16180,'le'=>-16171,'lei'=>-16169,'leng'=>-16158,'li'=>-16155,'lia'=>-15959,'lian'=>-15958,'liang'=>-15944,'liao'=>-15933,'lie'=>-15920,'lin'=>-15915,'ling'=>-15903,'liu'=>-15889,'long'=>-15878,'lou'=>-15707,'lu'=>-15701,'lv'=>-15681,'luan'=>-15667,'lue'=>-15661,'lun'=>-15659,'luo'=>-15652,
        'ma'=>-15640,'mai'=>-15631,'man'=>-15625,'mang'=>-15454,'mao'=>-15448,'me'=>-15436,'mei'=>-15435,'men'=>-15419,'meng'=>-15416,'mi'=>-15408,'mian'=>-15394,'miao'=>-15385,'mie'=>-15377,'min'=>-15375,'ming'=>-15369,'miu'=>-15363,'mo'=>-15362,'mou'=>-15183,'mu'=>-15180,
        'na'=>-15165,'nai'=>-15158,'nan'=>-15153,'nang'=>-15150,'nao'=>-15149,'ne'=>-15144,'nei'=>-15143,'nen'=>-15141,'neng'=>-15140,'ni'=>-15139,'nian'=>-15128,'niang'=>-15121,'niao'=>-15119,'nie'=>-15117,'nin'=>-15110,'ning'=>-15109,'niu'=>-14941,'nong'=>-14937,'nu'=>-14933,'nv'=>-14930,'nuan'=>-14929,'nue'=>-14928,'nuo'=>-14926,
        'o'=>-14922,'ou'=>-14921,
        'pa'=>-14914,'pai'=>-14908,'pan'=>-14902,'pang'=>-14894,'pao'=>-14889,'pei'=>-14882,'pen'=>-14873,'peng'=>-14871,'pi'=>-14857,'pian'=>-14678,'piao'=>-14674,'pie'=>-14670,'pin'=>-14668,'ping'=>-14663,'po'=>-14654,'pu'=>-14645,
        'qi'=>-14630,'qia'=>-14594,'qian'=>-14429,'qiang'=>-14407,'qiao'=>-14399,'qie'=>-14384,'qin'=>-14379,'qing'=>-14368,'qiong'=>-14355,'qiu'=>-14353,'qu'=>-14345,'quan'=>-14170,'que'=>-14159,'qun'=>-14151,
        'ran'=>-14149,'rang'=>-14145,'rao'=>-14140,'re'=>-14137,'ren'=>-14135,'reng'=>-14125,'ri'=>-14123,'rong'=>-14122,'rou'=>-14112,'ru'=>-14109,'ruan'=>-14099,'rui'=>-14097,'run'=>-14094,'ruo'=>-14092,
        'sa'=>-14090,'sai'=>-14087,'san'=>-14083,'sang'=>-13917,'sao'=>-13914,'se'=>-13910,'sen'=>-13907,'seng'=>-13906,'sha'=>-13905,'shai'=>-13896,'shan'=>-13894,'shang'=>-13878,'shao'=>-13870,'she'=>-13859,'shen'=>-13847,'sheng'=>-13831,'shi'=>-13658,'shou'=>-13611,'shu'=>-13601,'shua'=>-13406,'shuai'=>-13404,'shuan'=>-13400,'shuang'=>-13398,'shui'=>-13395,'shun'=>-13391,'shuo'=>-13387,'si'=>-13383,'song'=>-13367,'sou'=>-13359,'su'=>-13356,'suan'=>-13343,'sui'=>-13340,'sun'=>-13329,'suo'=>-13326,
        'ta'=>-13318,'tai'=>-13147,'tan'=>-13138,'tang'=>-13120,'tao'=>-13107,'te'=>-13096,'teng'=>-13095,'ti'=>-13091,'tian'=>-13076,'tiao'=>-13068,'tie'=>-13063,'ting'=>-13060,'tong'=>-12888,'tou'=>-12875,'tu'=>-12871,'tuan'=>-12860,'tui'=>-12858,'tun'=>-12852,'tuo'=>-12849,
        'wa'=>-12838,'wai'=>-12831,'wan'=>-12829,'wang'=>-12812,'wei'=>-12802,'wen'=>-12607,'weng'=>-12597,'wo'=>-12594,'wu'=>-12585,
        'xi'=>-12556,'xia'=>-12359,'xian'=>-12346,'xiang'=>-12320,'xiao'=>-12300,'xie'=>-12120,'xin'=>-12099,'xing'=>-12089,'xiong'=>-12074,'xiu'=>-12067,'xu'=>-12058,'xuan'=>-12039,'xue'=>-11867,'xun'=>-11861,
        'ya'=>-11847,'yan'=>-11831,'yang'=>-11798,'yao'=>-11781,'ye'=>-11604,'yi'=>-11589,'yin'=>-11536,'ying'=>-11358,'yo'=>-11340,'yong'=>-11339,'you'=>-11324,'yu'=>-11303,'yuan'=>-11097,'yue'=>-11077,'yun'=>-11067,
        'za'=>-11055,'zai'=>-11052,'zan'=>-11045,'zang'=>-11041,'zao'=>-11038,'ze'=>-11024,'zei'=>-11020,'zen'=>-11019,'zeng'=>-11018,'zha'=>-11014,'zhai'=>-10838,'zhan'=>-10832,'zhang'=>-10815,'zhao'=>-10800,'zhe'=>-10790,'zhen'=>-10780,'zheng'=>-10764,'zhi'=>-10587,'zhong'=>-10544,'zhou'=>-10533,'zhu'=>-10519,'zhua'=>-10331,'zhuai'=>-10329,'zhuan'=>-10328,'zhuang'=>-10322,'zhui'=>-10315,'zhun'=>-10309,'zhuo'=>-10307,'zi'=>-10296,'zong'=>-10281,'zou'=>-10274,'zu'=>-10270,'zuan'=>-10262,'zui'=>-10260,'zun'=>-10256,'zuo'=>-10254
    );

    /**
     * 将中文编码成拼音
     * @param string $chinese 要转换为拼音的字符串
     * @param string $sRetFormat 返回格式 [first:每个字的首字母|all:全拼音|one:字符串字母]
     * @return string
     */
    public static function getPY($chinese, $sRetFormat='first'){
        $sGBK = iconv('UTF-8', 'GBK', $chinese);
        $sUTF8 = iconv('GBK', 'UTF-8', $sGBK);
        if($sUTF8 != $chinese) $sGBK = $chinese;
        $aBuf = array();
        for ($i=0, $iLoop=strlen($sGBK); $i<$iLoop; $i++) {
            $iChr = ord($sGBK{$i});
            if ($iChr>160)
                $iChr = ($iChr<<8) + ord($sGBK{++$i}) - 65536;
            if ('first' == $sRetFormat || 'one' == $sRetFormat)
                //$aBuf[] = substr(self::zh2py($iChr),0,1);
                $aBuf[] = self::zh2py($iChr);
            else
                $aBuf[] = self::zh2py($iChr);

        }
        if ('first' === $sRetFormat)
            return implode('', $aBuf);
        elseif('one' == $sRetFormat)
            return $aBuf[0];
        else
            return implode(' ', $aBuf);
    }

    /**
     * 中文转换到拼音(每次处理一个字符)
     * @param number $iWORD 待处理字符双字节
     * @return string 拼音
     */
    private static function zh2py($iWORD) {
        if($iWORD>0 && $iWORD<160 ) {
            return chr($iWORD);
        } elseif ($iWORD<-20319||$iWORD>-10247) {
            return '';
        } else {
            foreach (self::$_aMaps as $py => $code) {
                if($code > $iWORD) break;
                $result = $py;
            }
            return $result;
        }
    }
}


最后将此文件下的:

$alias = isset($_POST['alias']) ? addslashes(trim($_POST['alias'])) : '';
修改成:
$al=htmlspecialchars($_POST['alias']);
if(empty($al)){
    $alias = preg_replace('/ /', '-', Chinese_to_PY::getPY($title,'all'));
}else{
    $alias = '';
}
保存,即可实现效果!

但是感觉标题太长了。。。正在研究缩短,或者是取货首字母,或前两个字母。。。000036-2015-09-22.jpg

此文并非博主原创,是在博友独狼哪里看到的,原文地址:http://www.xlonewolf.net/course/32.html



admin 发布于  2015-9-22 19:43 

emlog开启评论审核之后,评论结束自动跳转回原文 emlog

emlog开启评论审核之后,评论结束就会跳转到这个界面:

000032-2015-09-22.jpg

不会自动跳转回原文,感觉不太好,于是呢,在论坛问了一下,最终修改方法如下,在此小计,希望可以帮到那些需要的童鞋:

找到 \include\lib\function.base.php 865行的 emMsg()函数,把 

$isAutoGo = false 修改成  $isAutoGo = true


000034-2015-09-22.jpg

其实,函数里面有说明的,boolean $isAutoGo 是否自动返回 true false 。之后评论完就会自动跳转到原文了(注意看左上角的旋转的圆圈):

000035-2015-09-22.jpg

随便吐槽,谁这么无奈,跑我这里刷广告。。。专门针对的。。。不过 我只需要一键,就删除了所有广告,所以,慎重!!!000033-2015-09-22.jpg


admin 发布于  2015-9-22 19:25 

高级文件系统入侵检测工具-AIDE 安全工具

AIDE(Advanced Intrusion Detection Environment)是一款针对文件和目录进行完整性对比检查的程序,它被开发成Tripwire的一个替代品。

00.jpg

AIDE如何工作

这款工具年纪也不小了,相对来同类工具Tripwire说,它的操作也更加简单。它需要对系统做快照,记录下HASH值,修改时间,以及管理员对文件做的预处理。这个快照可以让管理员建立一个数据库,然后存储到外部设备进行保管。
当管理员想要对系统进行一个完整性检测时,管理员会将之前构建的数据库放置一个当前系统可访问的区域,然后用AIDE将当前系统的状态和数据库进行对比,最后将检测到的当前系统的变更情况报告给管理员。另外,AIDE可以配置为定时运行,利用cron等日程调度技术,每日对系统进行检测报告。
这个系统主要用于运维安全检测,AIDE会向管理员报告系统里所有的恶意更迭情况。

AIDE的特性

支持消息摘要算法:md5, sha1, rmd160, tiger, crc32, sha256, sha512, whirlpool
支持文件属性:文件类型,文件权限,索引节点,UID,GID,链接名称,文件大小,块大小,链接数量,Mtime,Ctime,Atime 
支持Posix ACL,SELinux,XAttrs,扩展文件系统属性
纯文本的配置文件,精简型的数据库
强大的正则表达式,轻松筛选要监视的文件和目录
支持Gzip数据库压缩
独立二进制静态编译的客户端/服务器监控配置

许多Linux发行版里其实也带AIDE的源,你可以输入aptitude install aide直接安装它。
附上Aide 0.15.1的源码下载

原文地址:http://www.darknet.org.uk/2015/09/aide-advanced-intrusion-detection-environment/


admin 发布于  2015-9-21 17:50 

google浏览器新的很好玩的bug-16个字符就可导致Chrome崩溃 业界新闻

毫无疑问,Chrome浏览器是现在最受欢迎的浏览器,其市场份额遥遥领先于其它任何竞争对手;但Chrome也有一些缺点,其中受人诟病最多莫过于“吃内存”了,不过大部分人也能够克服。

而Chrome庞大数量的用户也为Chrome自己找到了许多漏洞,其中有些漏洞看起来非常诡异。据外媒venturebeat报道,近日有工程师发现了一个可以让Chrome直接崩溃的16个字符的字符串:http://a/%%30%30 

测试

(注意鼠标在周围移动就可触发,崩溃之后刷新页面即可恢复)

你的浏览器标签页或者整个浏览器会崩溃

http://a/%%30%30

当你将这段字符串输入到地址栏并点击确定后,最新版Chrome 45.0.2454.85 浏览器就会不可避免地崩溃,你不妨试一试。-_- |

000030-2015-09-21.jpg


而据该媒体称,这段字符串是精简于Andris Atteka在其博客上报告的漏洞,他使用了一个更长的地址字符串来导致浏览器崩溃。而更加夸张的是,你只需要将鼠标移到下面这个和上面那个加了超链接的字符串上即可导致页面崩溃,甚至不需要点击(所以小编还特地用非超链接的形式把这段字符串写了一遍)……所以你在看文章的时候要小心了,嘿嘿:

另外值得一提的是上面这个网址的前半部分指向一个很有趣的网页游戏,不妨一试。

关于这个漏洞,Atteka做了一些技术上的解释:

看起来导致崩溃的是一些比较老的代码。在调试模式下,其在GURL中的一个无用的URL上触发了DCHECK,一直深入到“历史记录”代码中。鉴于这是在正式发布的版本中触发DCHECK,我不认为这是一个安全漏洞,但我也不打算再理会它。

而因为这并不是一个“安全漏洞”,所以Atteka并没有得到谷歌的漏洞报告奖金。

在测试中,Windows和Mac版的Chrome浏览器都会受到这个漏洞的影响,而安卓版的Chrome还没有出现类似的状况。

事实上,这种状况已经不是Chrome浏览器第一次遇到了,今年三月份,就有人发现在Mac版Chrome中输入下面的这段诡异的文字会导致崩溃:

而今年4月份报道的一个字符串漏洞可以导致全平台的Chrome浏览器页面崩溃,这段字符串很长,如下:


<a href=”http://Lorem ipsum Culpa labore qui culpa enim nostrud eiusmod ullamco anim in dolor consequat voluptate in in laboris consequat dolor occaecat minim aliqua quis id in Duis eiusmod amet id do ex do dolore dolor anim sit deserunt do.”></a>


不过以上提到的这两个漏洞很快就得到了修复,而最新鲜出炉的还可用,赶紧来试试吧,不然一会儿谷歌又给修好了。




标签: 谷歌 google bug

admin 发布于  2015-9-21 10:06 

站长切记:请勿将重要配置文件备份为.bak后缀 网络安全

很多站长有这样一个习惯,更改网站配置文件之前将原始文件重命名来备份,例如将config.php重命名为config.php.bak,殊不知这样一个小小的细节就给黑客留下了可乘之机,站长们可以做如下实验:


1、将您网站根目录下任意.php文件重命名为.php.bak,例如将config.php重命名为config.php.bak


2、然后您在浏览器中输入http://你的网站域名/config.php.bak


3、看到没?PHP文件里面所有的信息都显示出来了有没有?或者是可以下载!但是你直接访问 http://你的网站域名/config.php (非入口文件)是看不到里面的代码的!

所以,黑客就利用了站长们这点不好的习惯,对网站的可能的配置文件进行扫描,如下图某网站安全软件拦截信息:00.jpg

确实是这样的,不相信的可以自己测试。当然你还可以测试你想要下载的文件,比如说模板文件,js,等等,这里不多说,请自行摸索。

所以我们在可以修改备份文件名后缀,或者是使用防护软件进行防护。

原文地址:http://blog.ailab.cn/post/129


admin 发布于  2015-9-19 18:54