After logging on a VK user, you can get control of his page.
I decided to try myself in working with the API Vkontakte and came across an interesting feature.
One of the API authorization methods is OAuth. In short, everything happens like this: create an VK application, get its ID, and then send the user's browser to the address:
This is an authorization method Implicit flow.
')
If the user is logged in, he will immediately be prompted to install the application, if not - first log in and then install. If the application is already installed, then go immediately to the page, in the hash of which there will be a token. Next is working with the API.
The most interesting begins after leaving VK. Your application may have a link to the output of the form vk.com/login.php?op=logout . This is a standard link to exit from VK. But after the user's logout from VK, the cookies remain working.
Thus, if you again show the authorization page, enter a completely different username and password - you will still be able to use the first user page.
Those. the work is as follows - user P1 is logged in to VK via the application. In the above example, I use a standalone application, but maybe it will work with other types of applications. Next, user P1 clicks on the link to exit from the VC above. After that, it will not be possible to enter the VC without authorization through the browser or through the application . Next, user P2 is authorized via the application. Then, already through the browser, the user enters the user P1 page, instead of his P2 page. And it can do absolutely anything with this page, the application at this stage is no longer necessary and does not play any role.
The funniest thing is that you can use the most innocuous rights in your application. That is, you do not need to frighten the user by asking for access to photos, audio, video, messages and everything else. You can leave only the base - that's all. Cookies will still be fully working, using them you will go straight to the user’s page.
Can this feature be considered a vulnerability - think for yourself. In my opinion, this is at least not what the user expects by clicking on the “Exit” button and hoping that now his page is safe.
When writing this note, no VC user was hurt.
UPD. At authorization browser IE7 was used.
In support, I wrote long before I published an article on here. Actually, the publication of the article here occurred as a result of the fact that support for this signal was ignored in the spirit of “this is not a bug, but a feature, but perhaps something will change in the future.”
One of the API authorization methods is OAuth. In short, everything happens like this: create an VK application, get its ID, and then send the user's browser to the address:
https://oauth.vk.com/authorize" + "?client_id=123" // ID + "&display=page" + "&redirect_uri=https://oauth.vk.com/blank.html" // URL, . . , + "&scope= " + "&response_type=token" + "&v=5.52" + "&state=123456" This is an authorization method Implicit flow.
')
If the user is logged in, he will immediately be prompted to install the application, if not - first log in and then install. If the application is already installed, then go immediately to the page, in the hash of which there will be a token. Next is working with the API.
The most interesting begins after leaving VK. Your application may have a link to the output of the form vk.com/login.php?op=logout . This is a standard link to exit from VK. But after the user's logout from VK, the cookies remain working.
Thus, if you again show the authorization page, enter a completely different username and password - you will still be able to use the first user page.
Those. the work is as follows - user P1 is logged in to VK via the application. In the above example, I use a standalone application, but maybe it will work with other types of applications. Next, user P1 clicks on the link to exit from the VC above. After that, it will not be possible to enter the VC without authorization through the browser or through the application . Next, user P2 is authorized via the application. Then, already through the browser, the user enters the user P1 page, instead of his P2 page. And it can do absolutely anything with this page, the application at this stage is no longer necessary and does not play any role.
The funniest thing is that you can use the most innocuous rights in your application. That is, you do not need to frighten the user by asking for access to photos, audio, video, messages and everything else. You can leave only the base - that's all. Cookies will still be fully working, using them you will go straight to the user’s page.
Can this feature be considered a vulnerability - think for yourself. In my opinion, this is at least not what the user expects by clicking on the “Exit” button and hoping that now his page is safe.
When writing this note, no VC user was hurt.
UPD. At authorization browser IE7 was used.
In support, I wrote long before I published an article on here. Actually, the publication of the article here occurred as a result of the fact that support for this signal was ignored in the spirit of “this is not a bug, but a feature, but perhaps something will change in the future.”
Source: https://habr.com/ru/post/306312/
All Articles