Technical Analysis of WAP website attacks by using Session Fixation Vulnerability

By kxlzx http://www.inbreak.net

This article uses the discuz session fixation vulnerability as an example to describe how to use Session Fixation to attack WAP websites.

The Session Fixation vulnerability indicates that the web application does not destroy or reset the current session id after the user logs on. Once the user's session id is obtained by an attacker before logon, this session will be valid, and attackers can use the session id to log on to the user in disguise.

In my article, detailed exploitation methods and vulnerability descriptions are provided:

Session Fixation attack and defense practices: http://www.bkjia.com/Article/200809/29605.html

Later, cnqing added this new feature in SessionIE3.31 for Session Fixation vulnerability attacks.

Http://www.inbreak.net /? Action = show & id = 131

I will not introduce this vulnerability any more. I suppose you have read the above two articles or have some knowledge about Session Fixation attacks.

As a matter of fact, I have always felt that this vulnerability is quite weak. Due to limited use conditions, I have never used this vulnerability to attack my website after I wrote the previous article.

However, in the WAP era, the exploitation of such attacks will become easy and extremely cumbersome.

My article "talking about WAP website security" a few days ago has already introduced some WAP attacks and defense, mostly around sid. This article can be seen as the sequel of the previous article, I will continue to study some WAP things and look forward to communicating with you.

Take the wap function of discuz7.2 as an example to describe the generation and destruction of a sid.

First, visit this website.

Http://bbs.ecshop.com/wap/index.php

You will see that all the links on the page follow a sid, just like

Http://bbs.ecshop.com/wap/index.php? Action = forum & fid = 72 & sid = 2iu2pf

When we access the wap page of discuz, we will allocate a sid to all links. Later, our access will be bound to this sid, which is the same as session.

So we log on,

Http://bbs.ecshop.com/wap/index.php? Action = login & sid = 2iu2pf

After successful logon, the sid in the link remains unchanged, indicating that it has the Session Fixation vulnerability.

How can this problem be exploited? Do we first create an xss in wap?

In discuz, when we open the wap page, we have a sid, which will always be recognized by the server. Even if our IP address is changed, it will not change.

If we do not log on when we have sid, but send the link with sid to the user to log on, what will happen? So no xss, no url redirect, no csrf, the same as getting a user identity!

Go to the page and use opera to open the http://bbs.ecshop.com/wap/index.php

Do not change the page after it is opened.

Copy a link on the page and send it to the Forum.

Awesome!

Test wap

[Url] http://bbs.ecshop.com/wap/index.php? Sid = 1oALS7 [/url]
 

Visit the forum on your mobile phone. Open this link and log on to the user. At this time, the sid has been bound to a login user, and the attacker "sets" the sid for the user.

Go back to the pc, refresh the opera page, and change to the logon status, which is much easier than xss!

Since the discuz Forum published its own web site, the parameter is not evil, so it also passed its "non-local domain name pop-up security url validation" security verification.

The idea of this attack is "customizing sessions for users", rather than the traditional "getting user sessions ". Discuz is just an example. Some other large wap websites also exist.

In fact, the discovery of this vulnerability is such a process. When I "View" a search engine, I suddenly think of a method of cool attacks. When a search engine crawls data, the server assigns sid to it. If you log on after searching, other users will find that they are logged on after searching, because the sid displayed by the search engine is the same.

However, in actual application, it is found that this sid has expired, so interaction is still required. Here we come up with the idea of "I don't log on, send it to the user to log on. Because I felt that the idea of exploiting the vulnerability was novel, I thought it was a new vulnerability, and then I was excited to send it to the Alibaba mail group. The result was despised by a colleague who did not want to be named, "This is not a new vulnerability, but a Session Fixation...