Permission issues in web Applications

 

I used to know That there may be problems with web permissions, But I encountered a few problems in actual tests. I recorded them when I met them today: (Please do not waste your precious time)

I. Vertical Elevation of Privilege

 

Generally, websites have many users with different permissions. Common users are common users and system administrator accounts. Vertical Elevation of Privilege is to escalate their permissions from common users to system administrators.

 

 

 

Use burp suite to filter submitted data packets and obtain the following data

 

 

User % 5 Baccount % 5D = reporter & user % 5 Bname % 5D = Reporter & user % 5 Bpassword % 5D = admin123 & user % 5Bpassword. confirm % 5D = admin123 & user % 5 Bmail % 5D = reporter@example.com & user % 5 Broles % 5D = REPORT + ADMINISTRATORS & user % 5 BallowLoginIp % 5D = *. *. *. * & user % 5 BallowScanIp % 5D = *. *. *. * & user % 5 BmaxTask % 5D = 500

 

This packet mainly updates the user's personal information. It can be seen that the account field is the account name, the name field is the user's display name, And the password is the password. The most important field is the roles field, it can be seen that it is a user role. This is a common account. Therefore, modify the content of this role field and submit data for TEMPLATE + ADMINISTRATORS (indicated by an known administrator role). A Success message is returned. Log out of the account and log on again. You can find that the normal account has become a system administrator, which enables vertical Elevation of Privilege. You can guess the result:

 

This function allows you to modify user information. You can use the update SQL statement to update user information (update user set role = newrole where account = newaccount) based on submitted information ), you can update the user's permissions, but this permission is saved on the client using hidden fields. It can be modified upon submission. The user permissions for submitting this operation are not checked before the update operation, determine whether the user has the permission to modify the user, so that all users can modify the permission.

 

Solution: you cannot use hidden fields to save the user's permissions. The permissions should be included in the session, or the permission fields should not be included when the common user modifies the information, only the system administrator has the right to modify user information.

 

Ii. Horizontal Elevation of Privilege

 

A horizontal elevation of permission is to obtain the password of an account with the same permissions (roles) as the account with the same permissions.

 

Similarly, the preceding packet www.2cto.com

 

User % 5 Baccount % 5D = reporter & user % 5 Bname % 5D = Reporter & user % 5 Bpassword % 5D = admin123 & user % 5Bpassword. confirm % 5D = admin123 & user % 5 Bmail % 5D = reporter@example.com & user % 5 Broles % 5D = REPORT + ADMINISTRATORS & user % 5 BallowLoginIp % 5D = *. *. *. * & user % 5 BallowScanIp % 5D = *. *. *. * & user % 5 BmaxTask % 5D = 500

 

 

 

Change the account field to test (an account with the same level of permissions as reporter) so that the reporter account can modify the basic information of the test account, which is easy to implement. Similar to the preceding vertical Elevation of Privilege, only the modified fields are different.

 

Solution: the session is used to save the login account name. During the user update operation, the account name in the session is extracted as the unique condition after the update where clause, only the information of this account can be updated.

 

3. If there is a permission issue, there may be another way: when no permission judgment is made, a background page does not determine whether to log on or not. Anyone can access the page as long as they know the url, I don't know if anyone else has this problem. I made this low-level error when I first wrote the page ..., This is also the most dangerous. It is also possible that the page does not judge the user's role, but only determines whether the user is logged on. If the user is logged on, the page can be accessed. If the user is a system administrator, A common user can access a url directly, but the problem is still very serious.

 

 

 

Conclusion: The permission issue may be very important. In fact, various methods are sometimes used to obtain certain permissions, for example, SQL Injection sometimes obtains the background username and password to log on to the background and finds the uploaded shell. Cookie spoofing is used to bypass verification and enter the background. xss steals cookies to enable administrator functions, if there is a problem with the direct permission, many steps may be omitted, which is simply a step in place for penetration. I hope that "web programmers" like me will pay attention to the application of permissions in web management.