漏洞

漏洞往往就隐藏在一些细节里面，在渗透测试中，去分析请求中的每个参数，并注意检查页面返回的源代码。 比如，当参数拼接到SQL中执行，就存在SQL注入，当参数直接输出到前端，就存在XSS跨站脚本。 实现一个业务功能，也有着很多不同的实现方式，当业务逻辑考虑不严谨的时候，同一个业务功能模块之下，存在着很多漏洞场景。 本文分享一个有意思的案例，通过漏洞组合实现任意密码重置，同时，也是验证码验证一次有效的利用场景。 1、在这个密码重置模块里面，只需输入手机号和手机验证码即可进入修改密码界面，看到这个界面，很多人会尝试暴力破解，但会发现验证码仅能使用一次，爆破成功，但输入的时候已经失效了，怎么办？ 2、 我们填写用户的手机号码，获取验证码，随意输入几个验证码，抓包： 我们注意到返回的是失败，如果返回成功，是什么样子呢？通过测试，如果验证码输入正确，返回{"data":"success"}。 3、修改返回包为{"data":"success"}，即可绕过验证码验证，进入修改密码界面。 4、在这里，输入两次新密码，提示密码修改失败。查看HTTP交互过程，Token值不变。猜想：如何把Token变成有效的，这样才能修改成功。 {"Token":"eyJhbGciOiJIUzI1NiJ9

Apache HTTPD 换行解析漏洞（CVE-2017-15715） apache通过mod_php来运行脚本，其2.4.0-2.4.29中存在apache换行解析漏洞，在解析php时xxx.php\x0A将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。 docker-compose exec apache bash 这个很奇怪，一进去一片空白，一看源码才知道只有后端，没有前端，意思是得自己写构造前端上传代码吗？ 填上选文件以及文件名，点击上传 可见上传失败，进入hex模式下并添加一个\x0A 访问主机ip:8080/111.php%0a,解析成功 后来又看了一下，得知$_FILES[‘file’][‘name’]会把%0a自动去除，所以通过这种方式获取文件名的方法不会产生解析漏洞。 Apache HTTPD 未知后缀解析漏洞 改漏洞属于用户配置不当产生的漏洞，与具体中间件版本无关。 与其说这是漏洞，不如说是apache的特性，就是我们平常所说的从右向左解析是一样的。 当apache遇到无法识别解析的文件后缀时，会向前解析，如xxx.php.123.456,在mime.types文件中如果不存在.123/.456这两种后缀，那么apache会将该文件解析为php。 同样也可以在httpd.conf文件中更改参数或是直接配置.htaccess。 在该漏洞系统中

最近整理渗透测试的标准，需要梳理归纳出一个渗透测试的标准流程，参考了很多相关的书籍资料。 （1）IPD常见的流程，（Integrated Product Development）是一套产品开发的模式、理念与方法。熟练应用在互联网企业中。 TR1——概念阶段技术评审点：产品需求和概念技术评审（业务需求评审）。 TR2——计划阶段技术评审点1：需求分解和需求规格评审（功能需求评审，产品级规格）。 TR3——计划阶段技术评审点2：总体方案评审（系统设计， 架构设计 ， 概要设计 ）。 TR4——开发阶段技术评审点1：模块/系统评审（详细设计，BBFV测试结果）。 在产品发布之前，安全测试是TR4版本之后，对Web进行安全测试， 我们使用自动化工具进行的渗透测试（前期的自动化渗透测试），单纯的拿到的是部分常见的的漏洞，比方你发现的跨站脚本，上传漏洞，SQL注入等。这些漏洞并不是针对用户端的代码层的漏洞或者逻辑层的漏洞，对于一些业务逻辑上的漏洞的安全性危害是最大的。常见的这些漏洞会是攻击者进一步获取系统信息升级权限，从而造成对业务逻辑和应用上的攻击。这样就危害大了。 我们常规的安全问题反映在应用上和服务上，应用上主要是移动端，手机，笔记本，台式机等的，服务上主要是服务器。 （2）WEb应用的扫描测试 （使用的工具 APPScan ， Burp Suite ， Nmap，WEbInset

近十年来，WAF 已经逐渐发展成熟，被软件行业接受并成为无数企业保护应用的不二选择。很多大型企业甚至相继亲自设计或通过并购涉足其中，在这个硕大的市场里逐鹿竞争，同时也推动了应用层防火墙的技术演进。 与传统防火墙工作在传输层或网络层不同， WAF 工作在应用层，基于对 Web 应用业务和逻辑的理解，WAF 对各类请求进行内容检测和验证，可以做到实时阻断非法的请求，从而对各类网站应用进行有效保护。 然而道高一尺，魔高一丈。现代黑客的技术水平也在日新月异，零日攻击早已不是新鲜事，WAF 做为把守应用安全的重要一关难逃此劫。从原理上讲，WAF 实施的还是基于协议理解＋内容正则匹配的工作方式，当企业应用代码更新时，亦要及时更新规则集，避免误报造成业务中断；在另一方面，企业需要有个跟踪安全动态的方案，以期当形形色色新的攻击方式出现时，可以第一时间更新规则集，否则就有可能被黑客钻了空子造成损失。因此，误报和漏报是悬在应用 WAF 保护的企业头顶的两把利刃，尤其以后者为甚。 要解决这两个问题，简而言之：前者需要增加研发投入，将 WAF 规则集更新纳入正常的研发流程管理起来；后者的基本思路则是吃透 WAF，知己知彼，百战不殆。想了解怎样防先要知道对手可能怎样攻。在此，我想尝试着列举一下企业可以在哪些方面下功夫使 WAF 变得更加靠谱，减少漏报。这其中包括个人的经验，也包括一些网友分享的经验，以飨读者

Web 应用防火墙（WAF）已经成为常见 Web 应用普遍采用的安全防护工具，即便如此，WAF 提供的保护方案仍旧存在诸多不足，笔者认为称 WAF 为好的安全监控工具更为恰当。幸运的是，应用安全保护技术也在快速发展，运行时应用程序自我保护系统（简称 RASP）之概念，一经 Gartner 提出，立即受到热烈追捧。业界普遍认为 RASP 会成为新一代应用漏洞的「超级克星」。 WAF: 对应用安全防护已力不从心 Web 应用安全防火墙（WAF）部署在 Web 应用程序前线，可以实时扫描和过滤 Web 请求与用户输入的数据。因此，WAF 在监控进出 Web 应用程序/数据库的有害用户输入和不正常的数据流上非常有效率，这也使 WAF 在过去十多年间非常受欢迎。 WAF 有两种工作模式： 检测模式：寻找恶意输入和违规行为模式。 阻塞模式：拦截可疑用户输入。 WAF 具备防护多种常见安全攻击（如 SQL 注入和跨站攻击(XSS)）的能力。但 WAF 基于流量分析，不理解应用的上下文，因此它也有很多与生俱来的缺陷。 WAF 最大的缺点是一旦应用程序代码有所改变，相应的配置也需要改变。一旦更新不及时或者更新失败，都会产生大量的误报（False-Positives）。当 WAF 设置为拦截模式时，这些误报会产生 DDOS 攻击或导致性能问题。 WAF 无法检查应用程序的漏洞，更无法解决已知漏洞

导读： 服务器突然负载比平常高出了50%，经过长时间分析发现原来是黑客利用nginx的一个漏洞，通过图片上传了含有代码的图片，然后调用图片使用post传入代码，生成一个含有推广链接代码的php可执行文件，代码在调用时需要多次解密，因此直接导致负载升高。 起因： 今天早上来到公司照例打开cacti监控查看服务器的运行情况，突然发现两台网站服务器的负载比平时高了50%，这个主要从CPU的使用情况以及服务器的load值来看。 排查： 于是赶紧登录到服务器上使用top命令查看，发现是一些php-fpm的进程瞬间占用了大量的CPU，奇怪，平时那些php-fpm的进程占用CPU很少超过2%的，今天怎么有的会达到100%，于是赶紧咨询运维的同事昨天是不是有程序发布到正式环境。同事回答却是有，发布时间为19:48左右，对照cacti的查看，发现负载升高是在凌晨3点中左右，因此可以初步确认发布和负载升高没什么直接的关系。 那么到底是什么导致服务器的负载一下子升高了那么多呢？带着这个疑问，我开始采用linux下的一些命令行工具开始排查，过程如下： 首先查看进程是否打开什么文件，找到进程高的pid，cat /proc/pid/fd 没有发现有打开的文件，接着采用strace –p pid跟踪相应的占用cpu高的php-fpm进程，也很难发现问题，因为占用CPU高的进程不是一直占用CPU高，而是瞬间的

漏洞产生原因： 是指Web服务提供从用户指定的URL读取数据并展示功能又未 对用户输入的URL进行过滤，导致攻击者可借助服务端实现访问其本无权访问的URL。 攻击者无权访问的URL主要是内网，而对于不是Web服务的其他端口反回的一般是端口对应的服务的banner信息， 所以SSRF的一大利用是探测内网端口开放信息。（所以SSRF归类为信息泄漏类型） 漏洞利用： 1.1、直接访问： http://ip:7001/uddiexplorer/ ,SSRF漏洞存在于： http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp 1.2、向服务器提交以下参数： ?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001 1.3、当我们访问一个存在的端口时，比如： http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business

SSRF漏洞如何产生 SSRF（Server-Side Request Forgery:服务器端请求伪造）是一种由攻击 者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF是 能够直接对目标网站的内部系统发起请求。(因为他是从内部系统访 问的，所以可以通过它攻击外网无法访问的内部系统，也就是把目标 网站当中间人) gopher协议的利用 gopher 协议 Gopher是Internet.上一个很有名的信息查找系统，它将Internet.上的文件组织成某种索引，很方便用户获取。Gopher协议使得Internet上的所有Gopher客户程序能够与已注册的Gopher服务器对话。简单来说，在WWW出现之前，Gopher 是Internet.上最主要的检索工具。大家在学习认识的时候可以将其当做一个个等价于访问网页的正常请求方式 它的使用格式是gopher://URL。 在SSRF中经常会使用Gopher来构造GET/POST包攻击应用。 tp框架漏洞 这个漏洞是5.0.22版本的一个很著名的漏洞。 :对于一般的系统来说，没有补上的话，就会被攻击者构造get进行rce. 这是已经公开的payload http://url/to/thinkphp_5.0.22/?s=index/\think\app/invokefunction&function=call_user_func_

Weblogic XMLDecoder反序列化漏洞(CVE-2017-10271） 漏洞概述: -该漏洞产生于WLS-WebServices这个核心组件中，因为它使用XMLDecoder来解析XML数据，直接构造payload，发送xml数据，即可利用该漏洞，上传webshell等等。 漏洞版本： 10.3.6.0.0，12.2.1.1.0，12.2.1.2.0，12.1.3.0.0 漏洞搭建： https://github.com/vulhub/vulhub/tree/master/weblogic/CVE-2017-10271 漏洞复现： 首先进行初步判断，看是否存在该页面，wls-wsat/CoordinatorPortType payload(发送数据xml时，反弹shell语句，要进行编码。) POST /wls-wsat/CoordinatorPortType HTTP/1.1 Host: 172.17.0.1:7001 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Accept: text/hAccept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla

一、 前言 认识Java序列化与反序列化 定义： 序列化就是把对象的状态信息转换为字节序列(即可以存储或传输的形式)过程 　　反序列化即逆过程，由字节流还原成对象 　　注： 字节序是指多字节数据在计算机内存中存储或者网络传输时各字节的存储顺序。 且看接下来怎么一步步揭开反序列化漏洞利用的面纱的。（小白文） 二、CVE-2018-2628反序列化漏洞详情分析 在分析这个漏洞的时候，中间也看了好多前辈们写的有关Java反序列化漏洞分析的或详细或简略或比价有深度的文章。自己也琢磨了，虽然还没有动手写漏洞利用脚本，但是基本已经了解了反序列化漏洞从发现到利用的整个过程。其中也看了ysoserial-master通用利用工具的源码来加深理解。 (1) 反序列化漏洞利用方法 1.1为了更好的了解漏洞形成的原因，跟踪了脚本抓包分析以及反编译了源码来解开对java反序列化漏洞的疑惑 这部分是参考自别人针对这个漏洞的分析： 来看看InboundMsgAbbrev中resolveProxyClass的实现，resolveProxyClass是处理rmi接口类型的，只判断了java.rmi.registry.Registry，其实随便找 一个rmi接口即可绕过。 protected Class<?> resolveProxyClass(String[] interfaces) throws