心脏出血（英语：Heartbleed），也简称为心血漏洞，是一个出现在加密程序库OpenSSL的安全漏洞，该程序库广泛用于实现互联网的传输层安全（TLS）协议。它于2012年被引入了软件中，2014年4月首次向公众披露。只要使用的是存在缺陷的OpenSSL实例，无论是服务器还是客户端，都可能因此而受到攻击。此问题的原因是在实现TLS的心跳扩展时没有对输入进行适当验证（缺少边界检查），因此漏洞的名称来源于“心跳”（heartbeat）。该程序错误属于缓冲区过滤，即可以读取的数据比应该允许读取的还多。HeartBleed主要存在与OpenSSL的1.0.1版本到1.0.1f版本。利用该漏洞，攻击者可以远程读取服务器内存中64K的数据，获取内存中的敏感信息。
Heartbleed漏洞，这项严重缺陷(CVE-2014-0160)的产生是由于未能在memcpy()调用受害用户输入内容作为长度参数之前正确进行边界检查。攻击者可以追踪OpenSSL所分配的64KB缓存、将超出必要范围的字节信息复制到缓存当中再返回缓存内容，这样一来受害者的内存内容就会以每次64KB的速度进行泄露。
OpenSSL“心脏出血”漏洞的问题出现在openSSL处理TLS心跳的过程中，TLS心跳的流程是：A向B发送请求包，B收到包后读取这个包的内容(data)，并返回一个包含有请求包内容的响应包。请求包的内容(data)中包含有包的类型(type)和数据长度等信息。
当B收到A的请求包后，并没有的验证A包的实际长度，而是简单的把请求包data中说明的长度当作data的实际长度，于是当请求包中说明的长度与请求包数据实际长度不同时，问题就产生了。假设A构造一个请求包，它的实际内容长度只有1，而却告诉B的它的长度是65535，那么B接受到这个包后就会把A的内容完全当作65535来处理，其实到这里，问题还并不严重，最严重的问题出在，心跳的响应包还需要附带请求包的全部内容，这就需要程序做一次将请求包的数据从它所在的内存拷贝到响应包的内存里的操作。
这下就出大问题了，当拷贝的时候，程序认为A包的内容长度是65535个字节，结果A包在内存里面实际只有1个字节，于是程序不仅拷贝出了A包的内容，还“傻傻”地将A包数据在内存中位置后额外的65534个字节拷贝进了响应包里，并将这个响应包发还给了A，于是A便轻易地获得了B内存中这65534个字节的数据。想象一下，如果这65534个字节数据中包括一些敏感信息，那么后果将非常严重。而且A还可以简单地通过连续的发送心跳包，获取B机器内存中n个65534字节的数据，这个漏洞不愧是2014年“最佳漏洞”。
OpenSSL 1.0.1版本
靶机：centos7 192.168.139.136
攻击机：kali 192.168.139.129
确保两台测试机网络能通
使用docker+vulhub搭建漏洞环境，在centos7上搭建vulhub的步骤如下：
命令：yum install -y yum-utils device-mapper-persistent-data lvm2
命令：yum install docker
命令：systemctl start docker
命令：yum install -y git
git clone +下载地址
命令：git clone https://github.com/vulhub/vulhub.git
命令：ls #查看所有漏洞目录
命令：cd openssl #进入该目录
ls
命令：docker-compose up -d #运行漏洞环境
命令：docker ps
命令：nmap -sV -T4 192.168.139.136 
命令：nmap -sV -p 8443 --script ssl-heartbleed.nse 192.168.139.136
命令：msfconsole
命令：search heartbleed
命令：use auxiliary/scanner/ssl/openssl_heartbleed
命令：show options
对required为yes但是current setting为空的项进行设置，这里我们只需要设置rhosts（靶机ip）
命令：set rhosts 192.168.139.136 #靶机ip
set rport 8443 #设置端口
set verbose true #设置verbose为true是为了 看到泄露的信息
命令：run
这里就可以看到 靶机的64KB信息了（如果有人此时在登录web应用，还可以直接抓到账号密码等信息）。
OpenSSL“心脏出血”漏洞（CVE-2014-0160）受影响的OpenSSL版本：
OpenSSL 1.0.2-beta
OpenSSL 1.0.1 - OpenSSL 1.0.1f
要解决此漏洞，简单粗暴的方法就是升级openSSL软件。
建议服务器管理员或使用1.0.1g版，或使用-DOPENSSL_NO_HEARTBEATS选项重新编译OpenSSL，从而禁用易受攻击的功能，直至可以更新服务器软件。
1.将受影响的服务器下线，避免它继续泄露敏感信息。
2.停止旧版的 openssl 服务，升级 openssl 到新版本，并重新启动。
3.生成新密钥。（因为攻击者可能通过漏洞获取私钥。）将新密钥提交给你的CA，获得新的认证之后在服务器上安装新密钥。
4.服务器上线。
5.撤销旧认证。
6.撤销现有的会话cookies。
7.要求用户修改密码。
Heartbleed 是在 8 年多前被发现并修补的，然而许多服务器仍然存在 Heartbleed 漏洞
目录1．漏洞简介2、AJP13协议介绍Tomcat主要有两大功能：3．Tomcat远程文件包含漏洞分析4．漏洞复现 5、漏洞分析6．RCE实现的原理1．漏洞简介2020年2月20日，公开CNVD的漏洞公告中发现ApacheTomcat文件包含漏洞（CVE-2020-1938）。ApacheTomcat是Apache开源组织开发的用于处理HTTP服务的项目。ApacheTomcat服务器中被发现存在文件包含漏洞，攻击者可利用该漏洞读取或包含Tomcat上所有webapp目录下的任意文件。该漏洞是一个单独的文件包含漏洞，依赖于Tomcat的AJP（定向包协议）。AJP自身存在一定缺陷，导致存在可控
什么是0day漏洞？0day漏洞，是指已经被发现，但是还未被公开，同时官方还没有相关补丁的漏洞；通俗的讲，就是除了黑客，没人知道他的存在，其往往具有很大的突发性、破坏性、致命性。0day漏洞之所以称为0day，正是因为其补丁永远晚于攻击。所以攻击者利用0day漏洞攻击的成功率极高，往往可以达到目的并全身而退，而防守方却一无所知，只有在漏洞公布之后，才后知后觉，却为时已晚。“后知后觉、反应迟钝”就是当前安全防护面对0day攻击的真实写照！为了方便大家理解，中科三方为大家梳理当前安全防护模式下，一个漏洞从发现到解决的三个时间节点：T0：此时漏洞即0day漏洞，是已经被发现，还未被公开，官方还没有相
我有一个简单的Ruby脚本，我用它在某些HTTPheader上执行private_encrypt以签署要发送到rubyRESTAPI的Web请求，该API会根据Base64编码字符串测试Base64编码字符串生成而不是解码Base64和解密数据然后测试原始字符串。我使用的脚本是require"openssl"require"base64"path_to_cert=ARGV[0].dupplain_text=Base64.decode64(ARGV[1].dup)private_key=OpenSSL::PKey::RSA.new(File.read(path_to_cert))pu
我想知道如何从Apple.p12文件中提取key。根据我有限的理解，.p12文件是X504证书和私钥的组合。我看到我遇到的每个.p12文件都有一个X504证书和至少一个key，在某些情况下有两个key。这是因为每个.p12都有一个Apple开发人员key，有些还有一个额外的key(可能是Appleroot授权key)。我只考虑那些具有两个key的.p12文件是有效的。我的目标是区分具有一个key的.p12文件和具有两个key的.p12文件。到目前为止，我已经使用OpenSSL来检查X504文件和任何.p12的key。例如，我有这段代码可以检查目录中的所有.p12文件:Dir.glob(
我们最近更新了我们网站的SSL证书，在MacOSElCapitan10.11.3上出现以下情况:require'net/http'Net::HTTP.getURI('https://www.google.com')#=>"..."#ThesitewhosecertificategotrenewedNet::HTTP.getURI('https://www.example.com')#=>OpenSSL::SSL::SSLError:SSL_connectreturned=1errno=0state=error:certificateverifyfailed我在Google和StackO
require'openssl'ifARGV.length==2pkcs12=OpenSSL::PKCS12.new(File.read(ARGV[0]),ARGV[1])ppkcs12.certificateelseputs"Usage:load_cert.rb"end运行它会在Windows上产生错误，但在Linux上不会。错误:OpenSSL::PKCS12::PKCS12Error:PKCS12_parse:macverifyfailurefrom(irb):21:ininitializefrom(irb):21:innewfrom(irb):21fromC:/Ruby192/
我想使用两个key对在两个通信系统之间实现具有不可否认性的安全消息传递。我使用以下方法生成并存储了两组key对:sys1_key=OpenSSL::PKey::RSA.generate(2048)sys2_key=OpenSSL::PKey::RSA.generate(2048)这两个key对都将其单独的公钥和私钥保存到文件中:sys1.pub.pemsys1.priv.pemsys2.pub.pemsys2.priv.pem系统1有自己的公钥和私钥以及系统2的公钥。系统2有自己的公钥和私钥以及系统1的公钥。在系统1上，我想获取消息“Helloworld”并使用系统1的私钥和系统2的公
大家好，感谢您花时间阅读本文。我需要验证由我自己的CA颁发的证书，我有一个证书。我怎样才能做相当于openssl的openssl验证-CAfile在Ruby代码中？OpenSSL的RDoc在这方面不是很有帮助。我试过:require'openssl'ca=OpenSSL::X509::Certificate.new(File.read('ca-cert.pem'))lic=OpenSSL::X509::Certificate.new(File.read('cert.pem'))putslic.verify(ca)但我得到:test.rb:7:in`verify':wrongargume
我想做一个简单的OpenSSL::X509::Certificate.new(File.read("testuser.p12"))来自带有ruby1.8.7(或1.9.2)的irb，两者的结果相同。我得到的错误是OpenSSL::X509::CertificateError:nestedasn1error这是ruby问题，还是表明证书本身格式不正确？我发现一些类似的报告围绕着证明此类错误的亚马逊证书展开，结果证明是证书本身。它虽然在浏览器中工作。有关如何解决此问题的建议？ 最佳答案 根据后缀，“testuser.p12”似乎是一个P
OpenSSL::SSL::SSLError(SSL_connectSYSCALLreturned=5errno=0state=SSLv3readserversessionticketA):为苹果推送通知Houstongem集成库。自上两个月以来，它运行顺利，但现在在应用程序中出现错误。尝试多种解决方案来解决问题。也尝试使用新的证书pem文件，但遇到相同的错误..有时它可以工作请帮忙解决问题。 最佳答案 错误严格来说是您使用了错误的APNS证书。它可能已过期，或者它只是一个旧证书的类型(在2015年12月之前创建)。一年前，Appl
