thinkgem / jeesite

Java rapid development platform, based (Spring Boot, Spring MVC, Apache Shiro, MyBatis, Beetl, Bootstrap, AdminLTE), online code generation, including modules: Organization, role users, menu and button authorization, data permissions, system parameters, content management, workflow, etc. Loose coupling design is adopted; one key skin switch; account security Settings, password policies; Online scheduled task configuration; Support cluster, support SAAS; Support for multiple data sources

Home Page:http://jeesite.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ReDoS vulnerability in plugin.js

Moyuchu opened this issue · comments

commented

Description

ReDoS vulnerability is an algorithmic complexity vulnerability that usually appears in backtracking-kind regex engines, e.g. the python default regex engine. The attacker can construct malicious input to trigger the worst-case time complexity of the regex engine to make a denial-of-service attack.

In this project, here has used the ReDoS vulnerable regex (<body[^>]*>)([\s\S]*)(?=$|<\/body>) that can be triggered by the below PoC:

const arg = require('arg');
const args = arg(
    {
        '--foo': String
    },        {
        argv: ['/' + '<body<'.repeat(22361)]
    }
);

How to repair

The cause of this vulnerability is the use of the backtracking-kind regex engine. I recommend the author to use the RE2 regex engine developed by google, but it doesn't support lookaround and backreference extension features, so we need to change the original regex and add additional code constraints. Here is my repair solution:

const RE2 = require('re2');
//(<body[^>]*>)([\s\S]*)(?=$|<\/body>)
function safe_match(html) {
    const r1 = new RE2('(<body[^>]*>)([\s\S]*)', 'g');
    return input_str.replace(/(?=$|<\/body>)/g, '')
        .replace(r1,
            function (match, startTag, innerHTML) {
                doc.getBody().setHtml(innerHTML);
                var attrs = CKEDITOR.htmlParser.fragment.fromHtml(startTag).children[0].attributes;
                attrs && doc.getBody().setAttributes(attrs);
            });
}

The match semantics of the new regex + code constraint above is equivalent to the original regex.

I hope the author can adopt this repair solution and I would be very grateful. Thanks!