0x00 ultra vires vulnerability
Unauthorized vulnerability is a common security vulnerability in web applications. Its threat is that one account can control the user data of the whole station. Of course, these data are limited to the data corresponding to the vulnerability function. The main reason for the ultra vires vulnerability is that the developer has neglected the judgment of the authority because he believes too much in the data requested by the client when adding, deleting, modifying and querying the data. So testing beyond authority is a careful process with developers.
0x01 analysis of possible positions beyond authority
As mentioned above, as long as the database is added, deleted, modified, and queried, there may be unauthorized situations. Let's look at the general statements that often appear when we operate a database in web application development:
Increase:
Reference example:
Wooyun: love to shoot over authority loopholes and unreasonable design loopholes gift bag (my sister cried)
Delete:
Reference example:
Wooyun: Baidu creative expert has a function parallel permission vulnerability (can delete other materials)
Change:
Wooyun: Sohu Bai society arbitrary user information modification vulnerability
Enquiries:
Wooyun: like group user information disclosure + unauthorized vulnerability (a large number of user address contact information can be obtained)
I don't do development, SQL statement is relatively weak, Daniel don't spray, here just to illustrate the problem. As you can see, the above statements all involve where, and the following userid or username is the breach of ultra vires. When operating the database, the function request often takes some parameters to identify the unique value of information. And these parameters are what we need to pay attention to when we exceed our authority.
In web development, the fields that determine the user's identity are often not passed in the client. After the user logs in to the system, the developer usually creates a session to save the user name. When the user needs to determine the user's identity when viewing and modifying personal information, they can get it directly from the session without passing it on the client, which avoids tampering. However, if there is a delivery from the client, then there must be a step of permission verification. Therefore, when the test is over authorized, the packet capturing tool should be used to intercept the request. There may be a unique value of discrimination information in the detailed view to test. It should be said here that the transmitted parameters are not necessarily in the request parameters, and there may be links and other positions. Such as:
Wooyun: shrimp net sending doll vulnerability (parallel permission vulnerability)
Some people may start to complain that there are so many parameters in the request, and there may be the possibility that a request requires multiple discrimination parameters, plus the possibility in the link, which is too hard to find. Here's a way to easily let you know where there is ultra vires. People who like to play XSS will realize it.
0x02 test ultra vires skills
We believe that the causes of ultra vires have been understood, and that there may be functions of ultra vires. The next step is testing. I believe that's what you want to see most. How does Wang NIMA effectively test his ultra vires?
Don't worry, first look at the basic test method: to test whether the ultra vires need to register two accounts to detect whether they can affect each other's data. The method is very simple to open two different browsers, and the size accounts log in to a different browser respectively.
Step one:
Open fiddler2 and press F11 to block the user information update request on the large-scale. (for view parameters, select webfroms or textview under inspections in fiddler. The request can only be modified if it is truncated.)
Determine the parameter ulogin that may identify the user.
Step 2: block the request of updating user information in small browser
Step 3: replace the parameter value of ulogin in the small size with that of the large size, then release the fiddler truncation (Shift + F11), put the request in the past (), and check whether the information of the large size user is changed.
The above is the conventional test method. You can see the time consuming troubles in identifying parameters, comparing the parameter values of large and small requests, switching the number of browser views, etc. In case of changes and deletions and other functions, you need to create new data, view ID and so on at both ends, which is very troublesome.
In order to avoid the above time consuming operations, fiddler2 can be used to copy the cookie value in the small browser, and the unauthorized can be verified in the large request. The operation is to use Fiddler to intercept a small request to visit the target site and copy the cookie under the head tag of fiddler 2
The browser with small size can cut off the request with fiddler2, cover the cookie with small size over the cookie with large size, and test. If the large-scale data is changed, it indicates that it is beyond the authority, and then analyzes which parameter causes it. If it is not changed, it means that there is no ultra vires and the function is directly crossed. The small cookie is always on the clipboard, so it is very convenient to test other functions. It won't take long to test the functions of the whole site.
Let's look at the advantages of this method: 1. You don't need to identify which parameter is identifying; 2. You don't need to create data for two accounts at the same time; 3. You don't need to check the small ID; 4. You can test it with a single browser, and you don't need to switch browsers. This is my common method. I feel that it is very efficient. Is it the same as XSS hijacking the browser after stealing cookies? But this method doesn't work for all sites. Sometimes you will find that the small size will squeeze the large size into the large size's browser or the login status will disappear, and you can directly exit. I'm not clear about the specific reason. I guess the server has a judgment on cookies. I hope the big bulls can give a reasonable explanation. However, this method is very easy to use when testing most sites. Fiddler 2, by the way, is a very easy-to-use bag grabbing tool, and skilled use of this tool is also a necessary skill for testing ultra vires. Xiaobai can use it by themselves.
0x03 white hat principle
The harm of ultra vires is said to be light or weak. However, we are still required not to maliciously damage the manufacturer's data and abide by the white hat principle.
[original address]
Make complaints about:
System aerial clear wind 2013 / 11 / 04 11:02
Grab a sofa and take a look
xsser | 2013/11/04 12:47
I am a tyrant
big、face | 2013/11/04 14:58
Front row
Little fat man 2013 / 11 / 04 15:57
I'm here to support you!
xsser | 2013/11/04 16:47
I just thought, can this kind of automatic discovery be realized
Xiaochuan 2013 / 11 / 05 09:26
I also want to write an automated test tool, even a semi-automatic test tool, but my technology is not good. How can I set up a proxy to capture browser requests like fiddler, and how can I let the tool analyze requests (for example, deleting requires existing data, how can I create this data, and whether there is character limit? This makes it impossible for tools to recognize.)
x1aoh4i | 2013/11/12 19:30
You need to log in, grab the name, mobile phone, ID card, use regular judgment, then analyze the URL, change the ID, and follow the previous page for easy deduction, OK?
Difficult to realize
Longchen | 2013 / 11 / 04 17:38
Ask the same question, what is the automation idea
Kangaroo mother | 2013 / 11 / 04 17:41
Row and row
insight-labs | 2013/11/04 20:07
In many cases, although the login information is saved in the cookie, it is saved in the form of encryption. At this time, if you want to exceed your authority, you can either get someone else's cookie or break the encryption of the cookie and then change it.
Xiaochuan 2013 / 11 / 05 09:09
The point here has nothing to do with XSS stealing cookies. Note that I copied cookies directly from the trumpet, not stolen. The main purpose of copying small size cookies is to simulate small size requests to change large size data. After covering the request in the large browser, it is equivalent to the request sent by the small browser, but it can change the data of the large browser, which is beyond the authority
wefgod | 2013/11/07 23:46
Understand the meaning of the cave master. But in fact, it's not that troublesome. Sometimes it's long to copy cookies
Sick dog | 2013 / 11 / 08 10:36
Enough clipboard
Xiaopangpang wants to lose weight | 2013 / 11 / 08 21:46
Let me explain that for example, when user a changes the password, it will pass many parameters, which can't be changed under normal circumstances, because the parameter has an encrypted parameter verification. At this time, user B will change the password, and replace the cookies of user B with those of user a to change the password of user a. You can't just change the parameters
Think about where the code was written. That's what Ogawa meant
Ink center | 2013 / 11 / 04 21:03
Building master code word hard. However, the discussion of changing cookies at the end of the article is in favor of the view of upstairs. It is not beyond the scope of authority to replace all cookie information. Correct me
Sick dog | 2013 / 11 / 08 10:38
That is to test whether there is any ultra vires and whether the small size can modify the large size data
xsser | 2013/11/04 22:08
Two people in the upstairs have misunderstood it. It means to use a's cookie to operate B's request. If it can succeed, it's not beyond authority
xsser | 2013/11/04 22:08
Two people in the upstairs have misunderstood it. It means to use a's cookie to operate B's request. If it can succeed, it's not beyond authority
Heartless knife 2013 / 11 / 10 17:56
+1
xsser | 2013/11/04 22:10
Reply twice
_Evil | 2013/11/05 00:38
I don't care how many times I reply
xiaoL | 2013/11/05 10:09
The purpose of replacing cookie operation itself is to find parameters that distinguish user characteristics
It's really easier than switching browsers
But I always think that overstepping power and logical loopholes belong to the same category
iskit | 2013/11/05 14:56
Ultra vires should be regarded as a logical loophole
se55i0n | 2013/11/06 14:54
It's hard for the emperor to code
x-star | 2013/11/06 19:10
MARK not bad.
Good man 21:48 November 7, 2013
Good landlord
niliu | 2013/11/08 13:30
Praise ah ~ ~
xfkxfk | 2013/11/10 20:36
Ah l Chuan 2013 / 11 / 13 18:46
Nuclear attack November 23, 2013 14:55
Is the owner's cell phone number intentionally left blank
mobile: 13161297686
Comments (old system):
Nuclear attack | 2013 / 11 / 23 14:55 is the mobile phone number of the main building intentionally not coded
Reply:
Heh heh...
dfgdsfgdfgfdfgsdgdsfgsfdsfgsdfdgfgg
Reply:
In Sao Nian, your left key position is wrong. It is suggested to move one to the left. The five fingers of your left hand should fall on the "asdf" and the five keys of the space. You should fall on the "SDFG" and roll less There are 35 characters in total. The frequency statistics are: s: 6, D: 9, F: 10, G: 9. In Sao Nian, don't always use the middle finger to buckle the chrysanthemum
From that letter message, you can see the core of total deep social worker cultivation and explosive chrysanthemum potential..
Reply:
Too much, too much!