Title: Penetration of a certain spinach website

1. I accidentally found a spinach site and then tested it. The idea is as follows: Since it is a spinach site, users will definitely register, otherwise how can I charge money? When registering a page that interacts strongly with users, the possible vulnerabilities may be as follows:

SQL injection: If the account information entered by the user is used directly to write or query the database without filtering, there must be sql injection xss: the personal information entered in the input box will be displayed on the user's page; at the same time, the administrator must have permission to view the user's personal information in the background, and there may be storage xss here; even if it is reflective or DOM xss, since such sites have customer service, you can find ways to trick customers into clicking on links to achieve the purpose of stealing cookies or other purposes; Parallel overright rights: When the user logs in, checks certain pages after logging in, and then catches packets, if there are similar id fields, you may see the information of other users and even administrators by changing the id number CSRF: modify the account information, such as password; or modify the email address, and then modify the password through the email address; Payment vulnerability: catch the packet and change the parameters, causing 0 yuan to pay 2. Follow this idea, regardless of one of the three or seven or two, go to the tool to try the registration page first, and the result is as follows: 2 high-risk xss are found;

(1) Let’s look at the second one first: After changing the prompt parameters to the payload of the detection tool, the page is as follows: your payload is actually displayed on the page without any filtering, so I’m so happy;

Since the payload itself is inside JS, the script tag was not constructed at the beginning, but directly used a payload like '19736%0a',}%0aalert(666);%0a'. The purpose of the payload is to expose alert(666) directly to the original script tag in the background, but it was not possible to try many of them repeatedly. I could only adjust my thinking and reconstruct the script tag. This time I succeeded, as follows; it means that this xss did not have a false alarm;

The other one is in the cookie. If the sessionid is changed, it can also appear directly on the html source code of the page; similar to the first one above, you can construct script to execute your own js code; however, since you don’t know the background source code, you cannot determine whether this is a storage-type xss, and you cannot trick others into clicking through the construction of the url. I personally think it is not very meaningful, so I will not verify it here anymore;

Since it is not possible to log in to the background, it is still uncertain whether other xss is a storage type. We will not continue to verify other xss vulnerabilities at this stage;

(2) The login interface captures packets, the user name and password are actually transmitted in plain text, WTF.

After letting go, I caught a new package and put it in the repeater to try: there is a field captcha in it, which is the verification code. After deleting it, the server will execute it anyway, and it will not prompt that the verification code is wrong, but the user name or password is wrong, which saves a lot of trouble; first use the correct account to test it, and find that the returned status is Y, everything is normal;

Then start trying various SQL-injected payloads with single quotes, double quotes, brackets, ') or 1=1 -- qwe and other SQL injections, and the return is as follows:

The string of native codes on the right is : "Please enter 4-15 characters, and only English letters and numbers can be entered"; it seems that it is intentional to filter, only letters and numbers can be entered, and no special symbols cannot be entered, and there is a high probability that SQL injection does not exist here; (Some website front-end pages also explain it, and it is actually checked on the back-end server side, not using JS to check on the front-end, and it is not possible to change the fields after using burp to catch packets)

(3) Parallel/vertical overreach: After some sites log in, the cookie will bring various ids, such as uid=123, groupid=456, telno=135000387465, etc. It is easy to see the meaning of the field, and after changing the value, you will see the data of other users and even administrators; but the cookies here are all sessions, and the fields with various numbers cannot be seen what the meaning is. Use burp to try different values and return status:N, which is also impossible to follow;

(4) 0 yuan payment: grab the packet in the payment interface, decode the content of the request packet, and find that there is another sign field inside, and other fields will be checked. If the amount is changed, you need to reverse the verification algorithm and then recalculate the sign value. Here you give up temporarily; PS: User_id is finally exposed here;

3. Through xray scanning, a resin-viewfile vulnerability was found.

According to the scan prompt, changing the content of file=xxxx, you can indeed find some files, such as the configuration file below;

This vulnerability is similar to SSRF, which can traverse intranet files; then find tools for exploitation in github, and use burp to run dictionary exhaustive directories and files one by one, but only the following files were found, all of which were regular files and paths, and no expected configuration (such as account) files were found;

If you want to traverse the C drive, it seems to be protected;

This loophole is temporarily abandoned;

4. As of now, it has been found that only XSS can be used, and it is also reflective. You can only find an xss platform to generate a script tag that steals cookies, embed it into the URL with xss vulnerability, and then find the customer service MM to trick it into clicking. As a result, the customer service MM not only did not fall for the fool, but also sent me a new link to let me try a new site again, WTF.

Well, try again, so I continue to build a new site; after logging in to the new site with an account, I mainly look for pages that interact with the user (there are a lot of parameters involved, there is a lot of room for changes, and the chance of vulnerabilities is much greater than that of static web pages); I spent a lot of time and checked countless links, and it seemed that there was a turning point, as follows:

Here is a json string, which contains various sensitive data such as account name, phone number, nickname, permissions, etc. and there are client keywords in the URL. Is this an interface to view user information? Immediately use burp to grab the packet and change the parameters of pure numbers in the url (pure numbers mean indexing, and are easy to be exhaustive). As expected, the information of some registered users was blown out:

5. In addition, CORS vulnerabilities (a type of CSRF) were also discovered through xray, and we also need to find ways to trick customers, administrators or other users on the platform to click. We will not go into it here for the time being;

Summary of this spinach site: 1. The user has strictly restricted the input of form, and both SQL injection and xss are blocked. 2. The resin vulnerability is not painful and cannot get sensitive data. 3. Payment: There is a sign field verification, and the verification algorithm needs to be cracked first. 4. In the end, a page passed the parameter but did not check it. Some user information was blasted by changing the value of the numerical parameter; 5. It may be because of business reasons. The front-end page has not yet found any place to upload files, and it is still impossible to find a way to upload Xiaoma;

Reference: 1. https://blkstone.github.io/2017/10/30/resin-attack-vectors/Attack vector collation against Resin services

Reprinted from the original link address: https://www.cnblogs.com/theseventhson/p/13738535.html