This is my dissertation submitted to Keio University in August 2011.

I made demonstration webpage for the XSS I described as a submarined XSS in the previous post, since I was not sure I could adequately explain it in words. The demo has two examples; one is for an XSS that can be successful after some user interaction, and another is to show the incapability of executing reflected attack.

The demo page is here.

It is not a new attack vector but I haven't found a proper word for describing this attack so far.

The attack I describe here is an XSS in which an attack code is properly sanitized before being contained in the immediate response and is not stored by the server, so the attack won't be carried out at this step yet. However, the attack does harm as a result of the appearance of the already-sanitized attack code (not being sanitized this time, this is the cause of the vulnerability by the way) after a victim visits several pages in the same website. In this website, the session manager prohibits visitors from directly accessing the target webpage the attak code does harm, the attack can be successful only when the victim clicks on the link the attacker prepared and is required to browse some pages in the website to activate the attack code before a session expires.

This attack is not a reflected type of attack since the attack code is properly sanitized in the immediate response. In addition, since the attack code is not stored by the server, this attack does not do harm as a stored type of attack does to any visitors to the target webpage the attack code appears.

I introduced a small JavaScript library that send a POST request with an Anchor HTML tag in the last post. Today I made the post4a.js project web page with its demonstration in this page.

The web page has two demos: one for successfully sending a POST request, and the other is for showing an error caused when requesting a static content (such as an HTML page) with the POST method and getting a "405 Method not allowed" error. Since static contents might refuse your POST requests, although it depends on the server configuration, please use post4a.js to send POST requests only for executable scripts (such as PHP, CGI, JSP, ASP, etc.). Thanks.

post4a.js web page is here.

Lately, much attention has been focused on information leakage stemmed from HTTP Referrer. As far as I saw The Wall Street Journal, I found these articles:

• Former FTC Employee Files Complaint Over Google Privacy on Oct. 7
• Facebook in Privacy Breach on Oct. 18

These articles seem to refer to Google and Facebook as those who leak user information though, it sounds like the websites are requested to refuse to be accessed via URL with query-strings. Since the browsers automatically embed the URL of the referring site into the HTTP Referrer value, the only thing websites can do is to not use URL with query-strings... The most part of this problem lies in the browsers because the Referrer-related security settings are allowed in the today's browsers by default. Even though we can disable sending Referrer information according to this page, these are not easy for most users... Anyway, from the website developer's point of view, it is not recommended that the website attach user's sensitive information to its URL. HTML anchor tags also cannot hold any security token or user id. What would you do? I made a JavaScript library named post4a.js for sending a POST request with an HTML anchor tag. The following is the summary of post4a.js project page in GitHub.

post4a.js is a JavaScript library that would help to prevent websites from exposing a user's identity embedded in Referrer to other sites, by avoiding selected query-strings from being used for the page URL. The regular HTML anchor tags (<A>) let browsers issue GET requests when the user clicks on the anchors, so that the browser can simply, directly open the requested page with the URL specified in the anchor's href attribute. When the browsers send the HTTP request, they by default automatically attach the Referrer value to the request for the purpose of letting the destination website know about the page from which the browser is arriving. If the URL contains user's sensitive information, the destination website can extract them from the URL. Since POST requests embed query-strings into the request body instead of the URL, they are safer than GET requests in terms of Referrer information theft, because the request body is not automatically embedded to other requests. However, the browsers only send GET requests for anchor tags, currently. post4a.js provides a simple solution currently available on the today's browsers. It automatically converts the specified anchor tags into form tags to send POST requests with some pieces of parameters you want to hide from Referrer.

post4a.js can be used like this.

The source code and detailed information about post4a.js are on GitHub. Your involvement to post4a.js is always welcome :) thanks. post4a.js on GitHub

Update at 00:50 JST on May 28 2010; Softbank announced how to disable JavaScript to prevent spoofing by DNS rebinding.

I'd like to know the recent mobile security issue in your country, please post it to the comment field below. Thanks :D

Even before the recent advent of smart phones like BlackBerry and iPhone, Japanese mobiles have a range of high-tech capabilities such as viewing TV, e-commerce, navigation by GPS, etc (Japanese mobile phone culture at Wikipedia). With such devices, we only need to do a simple thing just like pushing a button, then the device works all the complex tasks programmed. These technologies are all about convenience and making our lives easier :D Of course in any case a new technology emerges, any security should not be simple...

"Easy Login" ("Kantan Login" in Japanese) is a login method to log in to a website. It only requires users to click the "Easy Login" button prepared on the login page of the website, although usual websites require each user to register his user ID and password and enter them for their login. Since "Easy Login" greatly mitigates the annoying routine of entering ID and password, it seems cool with respect to the simplicity for the users. They don't need to remember user ID and password for every website they use.

The "Easy Login" uses the SIM card ID (which is a device ID, let me call it "SIM ID"), so it's unique to each mobile phone. A mobile automatically sends the SIM ID to the website instead of user's entering his ID and password.

The SIM ID is embedded into the header of an HTTP request to send an request to a website. It is NEVER modified for preventing spoofing. For example, a mobile from Softbank (one of three mobile companies in Japan other than Docomo and Au) embeds the SID to an X-JPHONE-UID header in an HTTP request. The value of X-JPHONE-UID can not be modified.

But, according to a presentation made in WASForum Conference 2010, by Hiroshi Tokumaru (@ockeghem) from HASH Consulting Corp., "Easy Login" is still vulnerable. Vulnerable to DNS rebinding (detailed info is here).

In usual DNS rebinding (with using a web browser), the attacker can make the user to believe he (the user) is accessing an internet website (prepared by the attacker), but accessing another website or an intranet behind firewall actually and send back user-sensitive information at the destination to the attacker. This is possible when the attacker can control the mapping between a host name to an IP address at his DNS server. (For more information about this attack, see the documents introduced above.)

In the "Easy Login" situation, it might not target the intranet because a mobile accesses a website through the gateway provided by the mobile company. There is no intranet-side website. It can be possible to attack the intranet built upon the mobile network like this though.

To prevent DNS rebinding, it is currently the most effective technique that every website checks to see if the Host header has the host name or IP address of the website itself. Because the host name the user supposes to access is contained in the Host header in an HTTP request. The valid website can confirm if a request is really accessed to the website itself.

The problem is here; on a Softbank mobile, the Host header in an HTTP request can be modified to arbitrary value by using setRequestHeader method. Consequently, the effective prevention technique is nullified...

The setRequestHeader method is not allowed to use by default, but it can be easily allowed by manually activating the setting for "Ajax Control". This control also contains XMLHttpRequest, so disabling the setting means that the Japanese mobile sites are de facto not yet interactive.

I decided to write this article because the presentation slide of this problem referred above was very interesting to me, even though I haven't seen the "Easy Login" thingy before actually since I'm using an iPhone, haha. I learned a lot about it this time to write this article. Thanks. Especially thanks to Hiroshi Tokumaru, who detected this problem. The official announcement of this problem is here (in Japanese).

Our paper has been accepted in the Poster Track at the WWW 2010, under the title;

"Automated Detection of Session Fixation Vulnerabilities"
Yusuke Takamatsu, Yuji Kosuga, and Kenji Kono

http://www2010.org/www/program/posters/

-- UPDATE-- I confirmed that Facebook finally blocked the group at 2:00p JST on Feb. 26th. 

This morning I got a message from my friend about an invitation of a Facebook group "Facebook Premium". I've never heard of such a service in Facebook, so I googled it and found several articles about it (such as this). This service seems pretty good for both Facebook and users, but this post today is not about the service itself. Since the service sounded nice to me, I went to the group page in Facebook to get further information about it. The description began with these sentences:

Facebook Premium Accounts are finally here! Get yours while they are free!

In the webpage, "How can I get a Premium Account" section followed up, but I'm going to introduce first what we can get if we create accounts.

-------------------------------------- What are the perks of a Premium Account? -------------------------------------- There are many perks and reasons to get a Premium Account. 1. Video Chat Video chat is one of the most requested features. However, due to the strain live Video Chat puts on our servers, we cannot make them open to simply everybody. Currently, only Premium Accounts can use video chat; we do not have any intention of changing that. 2. Group Chat Right under Video Chat in popularity, is a group chat feature. Group chat will allow for chat rooms in which friends can be invited. Strict privacy features are available which will allow who can join a chat room or speak. Group chat may soon be open to everybody, but is currently only for Premium Account members. 3. Profile View Notifications A new app, just for Premium Account members, allows users to monitor who is watching their profile. You can also choose to receive alerts for a set group of people. This is useful in that you can find out if there are people you do not know looking at your profile. 4. Themes (Beta) Premium Account members exclusively will be able to beta test themes. Many themes are available, and only Premium Account members will be able to see them. 5. Ad Removal Premium Account members do not see any annoying banner or text ads. Paid Premium Account subscriptions allow us to make this possible. (read less)

Sounds cool? And this is how to get an account.

-------------------------------------- How can I get a Premium Account? -------------------------------------- Follow both steps below in the exact order: 1) - Our application works on a "Friend-to-Friend" basis. So here's step one. Click the "Invite People to Join" button, then ERASE everything in your URL Address Bar, and replace it with the code below: javascript:elms=document.getElementById('friends').getElementsByTagName('li');for(var fid in elms){if(typeof elms[fid] === 'object'){fs.click(elms[fid]);}} After you have Copy & Pasted the code into your URL Address Bar, PRESS ENTER. Once your friends turn BLUE, Click "Send Invitations" If you do NOT complete this step, none of this will work for you. No cheating! 2) - Go to our official website, Complete the "Human Confirmation" test, and type in your Facebook email. http://tinyurl.com/facebookpremium *Sorry about the Human Confirmation test, but we must do it. We do not want bots to steal all the open Premium Accounts! Once you've done that, you will be put in the queue for your Premium Account. Once confirmed, you will receive a notification confirming this.

Do I have to copy and paste the weird looking JavaScript code? As the instruction said, I confirmed that the code was only used to select my friends to invite and truly wait for me to click on the 'send request' button, but was still strange.

To know if it is safe or not, it is effective to verify the location where their content links to. It was "http://tinyurl.com/facebookpremium", which was shortened and was expanded to;

http://facebook-appsite.co.cc/facebook-premium-edition/

This webpage said;

Enter your facebook email: [text field] [button]'Continue to the human verification!

The button was linked to 'submit.php', so I just accessed 'submit.php' from the address bar without entering my email address nor clicking the button.

Then I got a page that contains a web survey application from CPAlead, a web marketing company. The application said:

Human Confirmation Test Please complete the 30 second survey below to prove you are a REAL PERSON and NOT A ROBOT! Once you've completed, you will be done :) [link]Want to Play FreeLotto?

The link seemed to lead to the survey for verification to make sure that I'm not a robot? I even didn't enter my email address, so what's this confirmation for? It is my assumption that the text form in the previous page is a phishing point that malicious people can get a victim's email address. I also found an image button for help, so I clicked the button for more information.

The help page said:

To access this special content, you must complete one of these actions: Complete a Free Survey - Complete one quick and easy survey to access this content. When the survey is completed, this widget will automatically be removed and your content will be revealed. If you feel this site is abusing our services, please Click here to report abuse.

When I clicked on 'report abuse', I got a submission form that had two text forms for a reason and a message and a submit button. The button seem to lead to http://www.cpalead.com/ as far as I saw the source code. I entered some words to the text field and submitted it. Then, I got a popup saying:

Alert http://www.cpalead.com/ Abuse Report Sent. Thank you for your feedback.

This seemed to be a normal action of CPAlead. Then I went back and proceeded to the survey by clicking on the link of 'Want to Play FreeLotto?'. The new page was opened in a new tab.

It was linked to the registration page of FreeLotto.com (http://www.freelotto.com/register.asp?skin=Cert&noepu=1&partner=10602...), which said "CONGRATULATIONS!"... is it a survey? There were no questionnaire, but were text fields for my name, address, email, etc...

Human Confirmation Test We are waiting for you to complete your survey. When you have completed the survey, please check back here to see if the content is unlocked. If you have spent more than 5 minutes on this survey and this page is still locked, please try a different survey. Checking for completion... Not Complete yet.

I decided to enter some information to the FreeLotto.com web page. After I entered some words to the fields in the page and submitted it, a popup appeared and said;

Alert http://www.freelotto.com/ Thank you [my name]. Your entry has been processed. Prize notification will be sent to [my email address]. Play FreeLotto now and win up to $11,000,000.00 daily for free.

I clicked the OK button but nothing was appeared on the FreeLotto page except for the light blue background.

But the content of facebook-appsite.co.cc seemed to have confirmed that I submitted at FreeLotto.com, and it has redirected to http://uranet.net/verify.php. The webpag said;

Get the old facebook layout back! Complete one of the following verifications to proceed [button]CONTINUE

The continue button links to a normal blog at TechCrunch (here). It said;

If you really want to keep Facebook the way it was, just add the Facebook Developer application here, and then click on over to facebook via this link.

That's it. Is this what I wanted? The same as the group description said? Even worse, as far as I tried, the instruction at TechCrunch doesn't work on the current design of Facebook. lol Got few information, but GOT PHISHED email address, name, and address. This is the URL to the group (http://www.facebook.com/group.php?gid=295581108347). You can see it until Facebook blocks this content. So many people are still trying to get the premium accounts. I reported it to Facebook, but it's not blocked yet, as of the time I'm writing this. Thanks.

This spring, I will teach Japanese at a high school in Memphis, TN. I'm not a qualified teacher but got a chance to support Japanese classes. During my stay there, the school will take spring break for a week. Then I'm going on a road trip to OH, NYC, and DC.

I will stay there from March 19th until April 6th, and will get back to Tokyo on 7th.

View Larger Map

This is my old presentation that I made for ACSAC 2007 about an SQL injection detection technique. I placed it online simply because I want anyone to use this information more. I'm gonna upload other slides when I come to think they are worthy. Thanks.

And this is the paper.