漏洞

SSRF漏洞介绍： 　　SSRF漏洞（服务器端请求伪造）：是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）。 SSRF漏洞原理： 　　SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。利用的是服务端的请求伪造。SSRF是利用存在缺陷的web应用作为代理攻击远程和本地的服务器。 SSRF漏洞利用手段： 　　1.可以对外网、内网、本地进行端口扫描，某些情况下端口的Banner会回显出来（比如3306的）； 　　2.攻击运行在内网或本地的有漏洞程序（比如溢出）； 　　3.可以对内网Web应用进行指纹识别，原理是通过请求默认的文件得到特定的指纹； 　　4.攻击内网或外网有漏洞的Web应用； 　　5.使用file：///协议读取本地文件(或其他协议） 　　http://www.xingkonglangzi.com/ssrf.php?url=192.168.1.10:3306 　　http://www.xingkonglangzi.com/ssrf.php?url=file:///c:/windows/win.ini SSRF漏洞出现点：

0x00 总览说明 服务器解析漏洞算是历史比较悠久了，但如今依然广泛存在。在此记录汇总一些常见服务器（WEB server）的解析漏洞，比如IIS6.0、IIS7.5、apache、nginx等方便以后回顾温习。 一、IIS5.x-6.x解析漏洞 使用iis5.x-6.x版本的服务器，大多为windows server 2003，网站比较古老，开发语句一般为asp；该解析漏洞也只能解析asp文件，而不能解析aspx文件。 IIS 6.0解析利用方法有两种 1.目录解析 /xx.asp/xx.jpg 2.文件解析 sp.asp;.jpg 第一种，在网站下建立文件夹的名字为 .asp、.asa 的文件夹，其目录内的任何扩展名的文件都被IIS当作asp文件来解析并执行。 例如创建目录 sp.asp，那么 /sp.asp/1.jpg 将被当作asp文件来执行。假设黑阔可以控制上传文件夹路径,就可以不管你上传后你的图片改不改名都能拿shell了。 第二种，在IIS6.0下，分号后面的不被解析，也就是说 sp.asp;.jpg 会被服务器看成是sp.asp 还有IIS6.0 默认的可执行文件除了asp还包含这三种 /sp.asa /sp.cer /sp.cdx 二、IIS 7.0/IIS 7.5/ Nginx <8.03畸形解析漏洞

一、IIS中间组件: 1、PUT漏洞 2、短文件名猜解 3、远程代码执行 4、解析漏洞 二、Apache中间组件: 1、解析漏洞 2、目录遍历 三、Nginx中间组件: 1、文件解析 2、目录遍历 3、CRLF注入 4、目录穿越 四、Tomcat中间组件: 1、远程代码执行 2、war后门文件部署 五、jBoss中间组件: 1、反序列化漏洞 2、war后门文件部署 六、WebLogic中间组件: 1、反序列化漏洞 2、SSRF 3、任意文件上传 4、war后门文件部署 七、其它中间件相关漏洞 1、FastCGI未授权访问、任意命令执行 2、PHPCGI远程代码执行 一、IIS解析漏洞: IIS的安全脆弱性曾长时间被业内诟病，一旦IIS出现远程执行漏洞威胁将会非常严重。远程执行代码漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中，当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码，可以导致IIS服务器所在机器蓝屏或读取其内存中的机密数据. PUT漏洞介绍及成因: IIS Server在Web服务扩展中开启WebDAV ，配置了可以写入权限，造成任意文件上传，受影响版本:IIS6.0，漏洞复现:开启WebDAV和写入权限. 图片发自简书App 图片发自简书App 利用BurpSute测试:

前情提要： 公司的安全测试一直是安全部经理全权负责，测试部只做功能和自动化。 但是2019是公司业绩腾飞的一年，业务量越来越大了，安全部经理实在做不过来。 于是他给整个测试部培训《安全测试》，一来把活分出去，二来增强我们的安全意识和安全测试技能。 但是只学了两节课，把知识点罗列如下，并且题目列为“上篇” 安全测试的内容持续更新中。。。 正文： 一、Web漏洞 暴力破解、文件上传、文件读取下载、SSRF、代码执行、命令执行 逻辑漏洞（数据遍历、越权、认证绕过、金额篡改、竞争条件） 应用层拒绝服务漏洞 人为漏洞：弱口令 漏洞等级如下： 严重 直接获取重要服务器（客户端）权限的漏洞。包括但不限于远程任意命令执行、上传 webshell、可利用远程缓冲区溢出、可利用的 ActiveX 堆栈溢出、可利用浏览器 use after free 漏洞、可利用远程内核代码执行漏洞以及其它因逻辑问题导致的可利用的远程代码执行漏洞； 直接导致严重的信息泄漏漏洞。包括但不限于重要系统中能获取大量信息的SQL注入漏洞； 能直接获取目标单位核心机密的漏洞； 高危 直接获取普通系统权限的漏洞。包括但不限于远程命令执行、代码执行、上传webshell、缓冲区溢出等； 严重的逻辑设计缺陷和流程缺陷。包括但不限于任意账号密码修改、重要业务配置修改、泄露； 可直接批量盗取用户身份权限的漏洞

0x00简介 项目名称 :ESPCMS-P8(易思企业建站管理系统) 测试平台 :Windwos 版本信息 :P8.19082801稳定版 更新时间 :2019-08-30 00:56:32 网站官网 : https://www.earclink.com/ 审计时间 :2019-11-2 23:07:00 代码行数 :109516 0x01漏洞定级 严重 ：能直接获取根目录权限。 高危 ：具备较高威胁性，或者威胁用户数据，需要联合利用获取根目录权限的漏洞，不具备直接利用可能。 中危 ：获取部分敏感信息，配置问题或者利用困难漏洞。 低危 ：实质威胁低，利用条件苛刻但真实存在利用可能。 0x02漏洞报告 严重 高危 中危 低危 1 6 3 1 0x03前后台展示 0x04漏洞详情 暂时不披露利用细节 来源： https://www.cnblogs.com/feizianquan/p/11797288.html

（本文仅为平时学习记录，若有错误请大佬指出，如果本文能帮到你那我也是很开心啦） 该复现参考网络中的文章，该漏洞复现仅仅是为了学习交流，严禁非法使用！！！ 一、介绍 CVE-2019-11043： 远程代码执行漏洞，使用某些特定配置的 Nginx + PHP-FPM 的服务器存在漏洞，可允许攻击者远程执行代码， 向Nginx + PHP-FPM的服务器 URL发送 %0a 时，服务器返回异常 该漏洞需要在nginx.conf中进行特定配置才能触发，具体配置如下 1 location ~ [^/]\.php(/|$) { 2 ... 3 fastcgi_split_path_info ^(.+?\.php)(/.*)$; 4 fastcgi_param PATH_INFO $fastcgi_path_info; 5 fastcgi_pass php:9000; 6 ... 7 } 攻击者可以使用换行符（％0a）来破坏fastcgi_split_path_info 指令中的Regexp，Regexp被损坏导致PATH_INFO为空，从而触发该漏洞 影响范围：PHP5.6-7.x （介绍源于 http://blog.leanote.com/post/snowming/9da184ef24bd 十分详细，感谢！！！） 二、漏洞复现过程 1.环境准备

文章仅仅学习使用，所有步骤均来自网络，博主无法鉴别判断用户使用本网站教程及软件的真实用途,敬请用户在本国法律所允许范围内使用, 用户一旦因非法使用而违反国家相关的法律法规,所造成的一切不良后果由该用户独立承担, 博主不负责也不承担任何直接间接或连带等法律责任。 *文中涉及到的相关漏洞已报送厂商并得到修复，本文仅限技术研究与讨论，严禁用于非法用途，否则产生的一切后果自行承担。 AppWeb认证绕过漏洞（CVE-2018-8715） AppWeb是Embedthis Software LLC公司负责开发维护的一个基于GPL开源协议的嵌入式Web Server。他使用C/C++来编写，能够运行在几乎先进所有流行的操作系统上。当然他最主要的应用场景还是为嵌入式设备提供Web Application容器。 AppWeb可以进行认证配置，其认证方式包括以下三种： basic 传统HTTP基础认证 digest 改进版HTTP基础认证，认证成功后将使用Cookie来保存状态，而不用再传递Authorization头 form 表单认证 其7.0.3之前的版本中，对于digest和form两种认证方式，如果用户传入的密码为 null （也就是没有传递密码参数），appweb将因为一个逻辑错误导致直接认证成功，并返回session。 参考链接： https://ssd-disclosure.com

文件上传 文件上传一般验证方式： 1.本地js验证(客户端) 2.MIME验证(服务端) 3.拓展名验证(服务端) 4.脚本内容（文件头）验证(服务端) 通常会用到exif_imagetype()函数，这个函数会读取图片头并返回一个数组 绕过方法： 1.本地js验证 方法很多，直接f12删除限制的代码再提交表单 2.mime验证 抓包修改content-type的内容就行了 一般这个验证对应得验证代码如下 $_FILES['upfile']['type'] == 'image/gif' //png、jpg..... 3.拓展名验证 多找一些，尝试找到有没有服务器漏掉得，比如php5，php7 大小写看能否能绕过 0x00绕过 4.文件头验证 修改文件头 JPG ：FF D8 FF E0 00 10 4A 46 49 46 //参考文章https://blog.csdn.net/weixin_44077544/article/details/102688564 PNG： 89 50 4E 47 //参考文章https://blog.csdn.net/weixin_44077544/article/details/102688564 GIF(相当于文本的GIF89a)：47 49 46 38 39 61 //参考文章https://blog.csdn.net/weixin

而今，大多数应用都依赖于像入侵防护系统（Instrusion Prevention System）和 Web 应用防火墙（Web Application Firewall，以下全文简称 WAF）这样的外部防护。然而，许多这类安全功能都可以内置到应用程序中，实现应用程序运行的自我保护。 ##1. 实时应用自我保护 实时应用自我保护 （以下全文简称 RASP），是一个应用程序运行时环境的组成部分，它可以实现为 Java 调试界面的扩展。RASP 可以检测到应用程序在运行时试图往内存中写入大量数据的行为，或者是否存在未经授权的数据库访问。同时，它具有实时终止会话、和发出告警等功能。WAF 和 RASP 的合作相辅相成，WAF 可以检测到潜在的攻击，而 RASP 可以通过研究应用内部的实际响应数据来验证潜在的攻击是否具有威胁性。 毋庸置疑，内置于应用程序的RASP，比那些只能获取 App 有限的内部进程信息的外接设备更加强大。 ##2. 协同安全智能 说到协同安全智能，笔者认为协同安全的意义是不同应用安全技术间的协作或集成。 动态应用程序安全测试（以下全文简称 DAST） + 静态应用程序安全测试（以下全文简称 SAST）：DAST 不需要访问代码并且易于实现。另一方面，SAST 需要访问代码，但是对应用程序的内部逻辑了解更为深入。这两种测试技术各有利弊，但是两种测试结果的关联和结合

公司的商城网站刚上线运营不到一个星期，网站就被攻击了，导致公司网站的短信通道被人恶意刷了几万条短信，损失较大，同时服务器也遭受到了前所未有的攻击。CPU监控看到网站在被盗刷短信验证码的时候，CPU一直保持在%95，网站甚至有些时候都无法打开。 网站被攻击后我登录了阿里云进去看了下，受到了很多阿里云提示的安全提醒，阿里云竟然没有给我拦截，我打电话咨询阿里云，阿里云竟然说我没有购买他们的云防火墙，阿里云客服还一再的推销让我们公司购买他们的云防火墙来防止短信验证码攻击，本身我也是做技术出身的，还是懂一些代码以及安全方面的，公司领导立即开会研究这个问题该如何解决，任命我带头负责处理此次的安全问题。 首先关于网站短信验证码被盗刷，从多个层面去分析漏洞产生的原因，基础带宽线路层，服务器层，网站层，三个方面去分析解决问题。 基础带宽应用层是：像DDOS，CC,带宽流量的攻击属于基础带宽，如果网站遭受到攻击，网站打不开，打开无法显示一般都是基础带宽应用层受到了攻击，防御办法也是通过高防服务器的硬防来防止攻击，但是也会造成误封，多层流量清洗防止攻击。 服务器层面，服务器被攻击的话，一般也会造成短信验证码盗刷，攻击者入侵服务器，并在服务器里直接与短信验证码平台通信发送数据，多频率的发送，修改数据库，都会造成短信验证码的盗刷。 网站层，经过多年的技术开发与安全接触，短信验证码被盗刷