Table of contents
1. Overview of knowledge points
2. Example of horizontal overreach—weak detection data comparison
3. Example of vertical overreach - permission operation without verification
4. Access control example - code does not reference verification
5. Example of fragile mechanism - Cookie fragile verification
6. Example of empty password mechanism - Redis&Weblogic weak mechanism
1. Overview of knowledge points
<category>
- Horizontal ultra vires - the sharing of user rights at the same level.
- Vertical overreach - sharing of low and high user rights.
- Access Control - Authentication Loss & Deauthentication.
- Fragile authentication - Cookie&Token&Jwt.
<Principle Brief>
- Horizontal ultra vires: when user information is obtained, there is no comparison and judgment between the user and the ID , such as direct query.
- Vertical overreach: the user type number in the database has been tampered with or the operation with high authority has not been verified.
- Validation is missing: References to validation code files, etc. are not included.
- Cancel verification: support empty password , anonymous , white list, etc.
- Cookie&Token&Jwt : Insecure verification logic, etc.
2. Example of horizontal overreach— weak detection data comparison
<Demo beyond authority>
1. Open the database of the website to be tested, and you can see that the account information of several users is stored in the database.
2. Open the website you want to test.
3. Log in as a user.
4. Open the personal information modification page of the website, and click Modify to capture packets.
5. The captured data packets are shown in the figure below.
6. When checking the database earlier, you can see that there is an account named xiaodi002.
7. We changed the account name in the data package to xiaodi002, and changed the id value below to 2, because the id value of the corresponding xiaodi002 account in the database is 2, and modified other information at the same time.
8. "Information edited successfully" is displayed on the web page after the package is released.
9. At this time, check the database again and find that the information just modified has been added to the account named xiaodi002.
<how to protect>
1. Compared with the current user, who is the currently logged-in user? When modifying the information, first obtain the user name of the current user. When modifying, modify it on this basis. In time, the user changes the account name to another , still invalid.
2. Check the source code, you can see that it has received the nickname, it is not fixed, whoever the user sends is what it brings in, which makes it able to operate on other users.
3. If the user's username is obtained and then fixed when the user logs in, the above things will not happen.
3. Example of vertical overreach - permission operation without verification
<Demo beyond authority>
1. Open the website you want to test.
2. Click to write an article and then write the content and publish it.
3. You can see that the article has been written.
4. Go to the background of the website.
5. Copy its link after we select the recycle button.
6. Change a browser that has not been logged in and try to access its background first.
7. The recycling option mentioned above only exists in the background. We have not logged in in this new browser. In this state, try to execute the link of the recycled article just copied.
8. When we visit the link we just copied, the webpage remains unchanged, and the login interface is still displayed.
9. But when we come to the background, we can see that the article just published has disappeared.
<Vulnerability Cause>
1. The website does not verify the data packets sent by the user, and does not verify the user authority to trigger the current operation.
2. There is verification, but the logical order is wrong.
- Verify first, then operate - correct.
- Operate first, then verify - error.
4. Access control example - code does not reference verification
<Demo beyond authority>
1. Open the website to log in first, and verify that you can log in normally.
2. Log out.
3. View the source code of the website, you can see the original code of the check login.
4. It checks the login through the following code to jump to the code for checking the login, and we will comment it out here.
5. Go back to the website at this time, and when you visit the index again, you can directly jump to the page after logging in to the website.
6. Viewing the source code of the website, we can find that many codes call the file of the string of codes to verify whether there is a login.
7. This is the fundamental reason why when we usually visit websites, some webpages can be accessed before we log in, and some websites can only be accessed after we log in.
8. If there is a file that does not contain that file, then that file can be accessed without authorization.
9. When we conduct vulnerability mining, we can check whether the sensitive page (such as the background page) has referenced the verification code. If it is not referenced, then there is an unauthorized vulnerability.
5. Example of fragile mechanism - Cookie fragile verification
<Demo beyond authority>
1. Open the website login interface first.
2. Click to grab the data package after logging in.
3. Enter a value for the cookie user and submit the data packet.
4. You can see that you have successfully entered the login page.
5. This means that although there is verification, the verification is too simple.
<Real case demonstration>
1. We use fofa to find the corresponding cms.
2. Open a suitable website for testing.
3. Go to the login page and click Login.
4. Click to log in and capture the package, and change it to the following style.
5. After putting the package, you can see that you have successfully entered the background page.
6. Example of empty password mechanism - weak mechanism of Redis&Weblogic
<Demo 1>
1. Go to the shooting range below to check the corresponding shooting range.
2. Introduction to the environment.
3. Start the environment.
4. Use the client to fill in the corresponding ip and port to access, and found that the access was successful.
<Demo 2>
1. Environment introduction.
2. Start the environment and go to the background login page.
3. After entering the following address in the url column, unauthorized access can be performed.
4. Successfully entered the background as shown in the figure.
