POC：
http:/15.8.17.20:8080/jgbs/getPlInstSetOptions.do?_=1755586812374&change=instsetchange%28%29&strSuitCode=14'and+length(database())='4&strTaskID=null&time=1755586812590
其中strSuitCode参数存在注入，输入14’时，页面回显异常；输入14’’时，页面回显正常；输入14’’’时，页面回显异常，疑似注入
分析：
猜测查询语句为
select ... from ... where ...'strSuitCode' ...
strSuitCode为我们传入的参数
传入正常14 '14' 正常查询传入14' '14'' 单引号未闭合，异常...
14’and+length(database())=’4
传入 14'and+length(database())= ...
1. 漏洞基本信息
漏洞名称：若依 RuoYi 4.6.0 ancestors SQL注入漏洞
影响系统 / CMS名称：若依 RuoYi
影响版本范围：v4.6.0 之前
漏洞类型：SQL注入
漏洞发现日期：2023-12-01
2. 漏洞描述若依(RuoYi)是一款基于SpringBoot的快速开发框架，广泛应用于企业级管理系统。在4.6.0及之前版本中，由于/system/dept/edit中的ancestors参数未对用户输入进行严格过滤，攻击者可利用特定接口构造恶意SQL语句，导致数据库信息泄露、数据篡改或服务端权限提升。
3. 漏洞影响版本v4.6.0 之前
来源：https://www.cve.org/CVERecord?id=CVE-2023-49371
4. 网络测绘语法fofa：
app="若依-管理系统"
5. 环境搭建JDK >= 1.8 (推荐1.8版本)Mysql >= 5.7.0 (推荐5.7版本)Maven >= 3.0
下载地址：https://github. ...
1. 漏洞基本信息
漏洞名称：OFCMS SQL注入漏洞（CVE-2019-9615）
影响系统 / CMS名称：OFCMS
影响版本范围：V1.1.3 之前
漏洞类型：SQL注入
漏洞发现日期：2019-03-06
2. 漏洞描述OFCMS是一款基于Java技术的内容管理系统。
OFCMS 1.1.3之前版本存在后台SQL注入漏洞。攻击者可利用漏洞发起admin/system/generate/create?sql= SQL注入攻击。
3. 漏洞影响版本V1.1.3 之前
来源：https://www.seebug.org/vuldb/ssvid-97836
4. 网络测绘语法fofa：
body="/static/assets/js/admin.js"
5. 环境搭建与漏洞复现过程使用环境：
mysql 5.6
jdk 1.8
tomcat 8
项目地址：https://gitee.com/oufu/ofcms/releases/tag/V1.1.3
使用IDEA打开，等待Maven构建完成，项 ...
情景
https://domain/qy/oa/login/callback?from=/h5/#/boc/beijing/shebaoka
Location：https://domain/h5/#/boc/beijing/shebaoka
follow一下跳转，下一次会请求
https://domain/h5/
这里的from参数的值改为@baidu.com时
https://domain/qy/oa/login/callback?from=@baidu.com
Location: https://domian@baidu.com
在follow一下跳转，发现成功跳转到了baidu
为什么payload要这么构造呢？（为什么使用@）
分析该payload的写法和URL的底层结构有关，回顾一下URL的底层结构
protocol://[[user[:password]@]host[:port]][/path][?query][#fragment][协议名]://[用户名]:[密码]@[主机名]:[端口]/[路径]?[查询参数]#[片段ID]
最完整的Url组成，也就是最底层的逻辑， ...
1. 漏洞基本信息
漏洞名称：信呼OA nickName SQL注入漏洞（XVE-2024-19304 & CVE-2024-7327 ）
影响系统 / CMS名称：信呼OA办公系统
影响版本范围：v2.6.2 之前
漏洞类型：SQL注入
2. 漏洞描述该漏洞位于 /webmain/task/openapi/openmodhetongAction.php 文件的 dataAction 函数中，由于未对用户可控的 nickName 参数进行有效过滤，导致攻击者可构造恶意SQL语句，从而执行任意数据库操作。
3. 漏洞影响版本v2.6.2 之前
来源：https://forum.butian.net/article/561
4. 网络测绘语法fofa：
app="信呼-OA系统"
5. 环境搭建下载信呼OAv2.6.2https://xinhu-1251238447.file.myqcloud.com/file/xinhu_utf8_v2.6.2.zip
小皮面板配置
网站根目录配置
访问htt ...
OWASP
未读项目中师傅交的一个漏洞，研究了一下
原查询请求
/SWSService/swthweb/searchData?page=1&size=5&sort=fileTime&order=desc&productionModule=5&productionType=5&productionCode=13&startTime=2025-07-03&endTime=2025-07-08
注入点：sort
sort 参数通常直接拼接到 ORDER BY 子句，而 ORDER BY 不能使用参数化查询（? 绑定变量），因此容易成为注入点。
许多开发者错误地认为 ORDER BY 是安全的，不会做严格过滤。
根据查询请求，猜测查询语句
SELECT * FROM production_dataWHERE productionModule = 5 AND productionType = 5 AND productionCode = 13 AND fileTime BETWEEN '2025-07-03' A ...
代码审计
未读前置信息bulecms v1.6
配置文件：data/config.php
非框架
鉴权分析包含鉴权，后台admin目录文件包含
require dirname(__FILE__) . '/include/common.inc.php';# __FILE__系统常量表示当前文件的完整路径和文件名# dirname()表示返回目录部分（去掉文件名）# 合起来dirname(__FILE__)就是当前目录，
/include/common.inc.php为鉴权文件
只看几个关键的
# 禁止直接访问该文件 if(!defined('IN_BLUE')) { die('Access Denied!'); }// 定义系统根目录路径（去除路径中的13个字符，可能是特定目录结构需要）define('BLUE_ROOT', str_replace("\\", "/", substr(dirname(__FILE__), 0, - ...
代码审计SQL注入参数直接拼接SQL注入
这套代码中存在很多注入点（都是参数没有过滤直接拼接查询），这里列举其中一个
对应文件：zz/index.php
第13行，ClickID参数通过GET传参，没有进行过滤或转义处理，直接拼接到查询语句
验证payload：ClickID=1' OR '1'='1
xff头注入对应文件：zz/index.php
第30行，ip参数带入查询
跟踪ip参数，第10行，发现是getIP()方法获取的
继续跟入getIP()方法，发现在includes/public.class.php文件中定义了该方法
代码判断XFF头是否存在，确保XFF头不为空，XFF的值是否为’unknown’
没有对XFF头传入的字符进行过滤，没有验证ip合法性，因此直接在xff头构造查询语句，即可实现xff注入
验证payload：X-Forwarded-For: 1.1.1.1' AND IF(1=1,SLEEP(5),0)#
Cookie注入对应文件：zz/pay.php
第60行，Co ...
fofa结果fofa指纹：”pay/charges/index.html”
环境搭建
源码中有安装文档.doc
网站运行目录为/public，php版本7.3
MySQL新建数据库dkewl_com，导入目录中数据库文件dkewl.sql
修改MySQL连接（配置用户名密码等信息）
开启redis
config/cache.php中的redis密码要和小皮面板的redis密码一致
安装php7.3的拓展
配置Apache伪静态（网站->管理->伪静态）
原文档中是nginx伪静态
<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?s=$1 [QSA,L]</IfModule>
至此，环境搭建 ...
渗透中遇到问题今天渗透中碰到了新问题：第一次请求网站的功能点，发送请求会获得一个响应头“ETags”，而当我们第二次请求该接口时，我们会携带一个请求头“If-None-Match”，并且它的值和第一次的响应头“ETags”相同，而第二次的响应码则是304，并且在burp中无法正常返回内容（前端页面可以正常回显），而当删除该请求头时，就能像第一次一样正常请求
因为项目信息敏感，所以厚码:)
引起了我的思考，为什么会出现这种情况呢？
认识ETagETag HTTP 响应头是资源的特定版本的标识符。这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web 服务器不需要发送完整的响应。而如果内容发生了变化，使用 ETag 有助于防止资源的同时更新相互覆盖（“空中碰撞”）。
如果给定 URL 中的资源更改，则一定要生成新的 ETag 值。比较这些 ETag 能快速确定此资源是否变化。
按我的理解来说，ETag就是一个标识符，用来标识当前页面是否发生变化，当请求包中的ETag和响应包中的ETag内容相同时，则表示该次请求的资源并没有发生变化
ETag: W/"<et ...
