On WAP website security

By kxlzx [Abstract] This article takes some well-known WAP Service website security vulnerabilities in China as an example to briefly discuss some ideas about WAP security. Read by the following groups: 1. WAP developers 2. WAP product designer 3. "Network Security enthusiasts" [body] This should start with WEB site user authentication. At that time, we were still using computers. On a WEB site, user authentication information is stored in cookies. Once a user logs on, the browser automatically sends the authentication information to the WEB site. When mobile phones start to access the Internet, mobile browsers are not yet mature, and mobile phone operating systems are more immature. Many mobile Browsers Do not know cookies, and of course JavaScript is not supported. In order to retain users, the WAP website has to use very old-fashioned authentication in the WEB site. After connecting all URLs on the page, add a string of SID as the default parameter for the next page, after a user browses all the connections on the user page, the URL will become like this: http://wap.inbreak.net/default.php?sid=xxooxxooxxooxxoo You can try to log on to the WAP website (wap.163.com) on your mobile phone. Then, you will see that all the connections are in a long string. The SID parameter in this string is used for authentication. If hackers can guess the long string of content after a user logs on to the website and directly access it through their own browsers, it will become the authenticated users of the website. Of course, it is unrealistic to guess. When the WEB site authentication information is stored in the COOKIE, It is very troublesome for hackers to use XSS to obtain the COOKIE. Later, httponly became more annoying. Today, WAP websites are even more abnormal and do not support JAVASCRIPT. How can we attack other users? 0x01 friendship link security problem in http head, there is a field called referer (there is a reference link at the end of the article), you can get the current request from which URL. Use a mobile browser to access the page: http://wap.163.com/ The page has a link pointing: http://wap.handbb.com/agent.jsp?f=00002910 So we clicked this link. Then the browser will send: -- code --------------------------------------------------------------------------- GET http://wap.handbb.com/agent.jsp?f=00002910 Http1.1Host: wap. handbb. comReferer: http://wap.163.com/ ------------------------------------------------------------------------------- The packet is sent to the wap.handbb.com website and contains the Referer field in the packet. If hackers can control wap.handbb.com, they can easily obtain all URLs linked from wap.163.com website users. What do I do if I get a 163 URL? If the user logs on, the URL on the current user's browser becomes: http://wap.163.com/ Index. do? Sid = wAsbVhmXXXXXXXATCu the number of users who will be connected from, and the number of SID. After being obtained by hackers, the user can be directly accessed and becomes a legal user. I also go to the portal to advertise when I have time. Or... It is observed that some WAP websites are currently very popular, and links are everywhere... 0x02 user interaction results in SID leakage. Don't let it go. I love world peace. Is there any way to obtain SID without hacking websites? The answer is yes! Many WAP websites have gradually developed, forming large websites and providing many services, such as forums, intra-site messages, and mailboxes. In the WEB security defense, although a lot of defense is done, it is usually allowed to send ad links to everyone, so there is very little defense for the out-of-site links, if we can in the forum post content, insert: -- code ------------------------------------------------------------------------- <a href =" http://www.inbreak.net "> http://www.inbreak.net </A> -----------------------------------------------------------------------------. Then, the user is tempted to click here to obtain the user's SID from our own website. The most dangerous thing is mailbox. For example, QQ mailbox is very powerful (already repaired ). First, send an email to the user, and add a link to the content. You don't need to talk about the specific "interaction" content. You know. When a user uses a mobile browser to access the QQ mailbox and opens the email, a link is displayed.

Is in the "open activity page", as long as the user opened, on my server, immediately got this string of URL: -- code 22:11:10 ------------- http://w34.mail.qq.com/cgi-bin/readmail? Sid = qmxxxxxxxxxxxxxxxxxxxm. & disptype = html & mailid = zc2xxxxxxxxxxxxxxxxx11 & t = & conv = & p = & cmid = External then you can directly open the URL in the PC browser:

It is clear that you have already logged on to the system, and this has passed the QQ login verification. Okay. Now let's start sending QQ emails... (Followed by harmony) it is actually a secure application used in the mailbox of a WEB site, but it has become a vulnerability in the WAP field. 0x03 SID leakage caused by the automatic generation of links by UCWEB browser in the previous example, we are actually talking about the existence of a SID leakage security vulnerability in QQ mail, which can be protected by QQ mail, the <a> label is not allowed. Only the text content is a link address. When the browser has some security problems, it will also cause SID theft. Do you use smart phones? There are many popular mobile phones. When reading text messages, if the URL appears in the text message: http://www.inbreak.net Then you can directly click the connection to open the browser for access. This is a common feature. Many short message reading software comes with this feature. However, if this feature is used on a mobile browser, it will be a tragedy! Download the latest mobile browser "UCWEB7.4". I am using android. This browser has a feature when the Page code is: -- code --------------------------------------------------------------------------- <! DOCTYPE html PUBLIC "-// WAPFORUM // dtd xhtml Mobile 1.0 // EN "" http://www.wapforum.org/DTD/xhtml-mobile10.dtd "> Hacked by kxlzx http://www.inbreak.net ----------------------------------------------------------------------------- This is the page source code, originally displayed in the browser, is a piece of text, because the link does not have the <a> label. Neither WML nor HTML standards make it a clickable link, but UCWEB automatically recognizes it as a link. This resulted in N + innocent victims. Let's take a look at one of the innocent victims in the 163 email box. 163 mailbox and google mailbox are relatively QQ mailbox, which is still safe here. If the link code is: -- code ------------------------------------------------------------------------------- <a href = http://www.inbreak.net > Inbreak.net </a> then, it automatically replaces href with its own filter module. The result is: -- code signature <div> <a href =" http://mproxy.youdao.com/proxy/jump?u=http%3A%2F%2Fwww.inbreak.net&keyfrom=jumper.in&c=TRUE&j=1&mx "> http://www.inbreak.net <Br/> </a> </div> after the URL is opened, the inbreak.net website content is obtained by the service and displayed to the user, therefore, the referer obtained by the inbreak.net website is no longer the current URL, but the URL sent by the transfer station service. This referer actually does not have any SID. In fact, this 163 feature is not designed for security, but for "Saving traffic fees for users". Because a large amount of junk data is generated when you directly access the HTML website, it is filtered out first, and then return it to the user. However, in the 163 email, if the link sent is not a <a> label, it is simply text: http://www.inbreak.net Use UCWEB to access the database:

UCWEB still regards it as a link and can click it directly. Click it and I will see another SID! An innocent 163 mailbox is a tragedy.

However, this result is not displayed if you use the mini-Opera browser or the android browser. They think this is just a piece of text, and it is the result of access by MiniOpera:

As you can see, the link shown here is a text and cannot be clicked directly. I see that the only domestic WAP website that is well protected against text URLs is qidian website. The website's defense method is so cumbersome that the text content after "http: //" is replaced in an desperate way for harmony. Of course, this is not a good solution. 0x04 QQ browser automatic pre-read Function