The ramifications for this became apparent. Yahoo servers started sending out spam. I had no proof in the beginning but this post verified my suspicions. Spammers became aware of the golden opportunity and started abusing Yahoo servers to the fullest. This led to really tough times for the Yahoo Mail people and their PR guys as apparent from this post on Yahoo Mail Blog. Not only were the email servers overloaded, but ISPs started blocking mails from Yahoo servers which led to delayed/undelivered mails.

Now it seems that Yahoo has changed the way it routes emails through its SMTP servers. Earlier methods were quite trivial as the mail headers would have shown.
Received: from smtp104.plus.mail.re1.yahoo.com (smtp104.plus.mail.re1.yahoo.com [69.147.102.67]) by rly-ma08.mx.aol.com (v120.9) with ESMTP id MAILRELAYINMA088-8c647354bcb3bd; Sat, 10 Nov 2007 01:12:27 -0400
Received: (qmail 55018 invoked from network); 10 Nov 2007 06:12:27 -0000
Received: from unknown (HELO localhost) (myYahooID@myIPAddress with login)
by smtp104.plus.mail.re1.yahoo.com with SMTP; 10 Nov 2007 06:12:26 -0000

Gradually Yahoo started repairing its servers from the smtp11x.plus.mail.re1.yahoo.com series to smtp10x.plus.mail.re1.yahoo.com as the latter still worked for a long time without FROM address checks.

Now the mail headers are more complicated. It seems that Yahoo does some internal checks regarding whether the FROM address is valid and then only routes the emails.
Received: from n3.bullet.mail.ac4.yahoo.com (n3.bullet.mail.ac4.yahoo.com [76.13.13.29])
by mx.google.com with SMTP id d12si10680167and.24.2008.04.05.08.35.00;
Sat, 05 Apr 2008 08:35:01 -0700 (PDT)
Received-SPF: neutral (google.com: 76.13.13.29 is neither permitted nor denied by best guess record for domain of myYahooAddress) client-ip=76.13.13.29;
DomainKey-Status: good (test mode)
Authentication-Results: mx.google.com; spf=neutral (google.com: 76.13.13.29 is neither permitted nor denied by best guess record for domain of myYahooAddress) smtp.mail=myYahooAddress; domainkeys=pass (test mode) header.From=myYahooAddress
Received: from [76.13.13.26] by n3.bullet.mail.ac4.yahoo.com with NNFMP; 05 Apr 2008 07:31:40 -0000
Received: from [68.142.237.88] by t3.bullet.mail.ac4.yahoo.com with NNFMP; 05 Apr 2008 15:34:24 -0000
Received: from [216.252.111.166] by t4.bullet.re3.yahoo.com with NNFMP; 05 Apr 2008 15:34:24 -0000
Received: from [127.0.0.1] by omp101.mail.re3.yahoo.com with NNFMP; 05 Apr 2008 15:34:24 -0000
X-Yahoo-Newman-Id: 666616.8045.bm@omp101.mail.re3.yahoo.com
Received: (qmail 61052 invoked from network); 5 Apr 2008 15:34:24 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;s=s1024; d=yahoo.co.in;
h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID: Date:From:User-Agent:MIME-Version:To: Subject:Content-Type:Content-Transfer-Encoding;b=1zOo54htnYlA5Gy3kNjQQVpRD8fYyEbgwwejDXI4Jr/RZ32+QDvvwYLxJOdSkbwWyJhA3P5PfBVX+mGGYePhw3TXtmfqdVSUcu/BGnwpyONzF3umcYLylkOzLBu/URre6lF+6gdEnRPsfIE3isy25r9dfELJke0wDDwqEdCEYg= ;
Received: from unknown (HELO Why?are?spaces?replaced?by??BTW?if?you?read?this?you?are?a?G33K) (myYahooID@myIPAddress with plain)by smtp103.plus.mail.re1.yahoo.com with SMTP; 5 Apr 2008 15:34:24 -0000

BTW I had told this to the Engineering head of Yahoo Atlanta during my internship interview here and he was surprised by this. Unfortunately I couldn’t demo this for him as Yahoo had started fixing this problem starting that day only.

Now I faintly remembered receiving 2 scraps (which obviously looked like Spam) from my friends and that I had deleted them promptly. Could it be a case of Cross Site Scripting? A blog article that I read today confirmed by suspicions.

Now in my previous post I had emphasized my belief that “All input is evil” and even though Google seems to do a pretty good job with Blogger, filtering out bad HTML and unwanted scripts; it has failed to do that with Orkut. Especially when it keeps adding more and more features to make the UI richer and interactive, the importance of such measures increases.

OK, I had a tremendous urge to call this post “Hacking Web Interfaces”. But due to some uneducated folks who believe hacking is a bad word, I think I will stick to its euphemism.

The most direct way to feed random data to a web-service is in a raw format. Use telnet for absolute low level communications or tools like Fiddler, for communications at a higher level like HTTP. But with sites hosting hundreds of script files and html pages on their server, this approach has become more and more impractical. But there are other means to mess with the client side code.

DOM Inspector

If you use Firefox, you will notice there’s a utility called DOM Inspector that is included with it. As the name suggests, it allows you to see the DOM of the rendered HTML page. But, it also allows you to modify that DOM. You can modify the values of the properties of different DOM objects in the tree and even insert new objects.

Let’s try this technique on a product of one of the largest software companies, Google Calendar. I will use no other software than Firefox and DOM inspector.

Let’s go to the Settings screen. They have a setting for the “Custom View” property for the calendar.

Now I am a guy who wants to know what he would be doing in next 2 months but there is no option for that kind of view. Hmm, lets see if the DOM can help us. Firing the DOM Inspector, we see that the logic is quite simple.

The value of the ComboBox determines how the duration for which the custom view display the calendar. The value in the ComboBox is simply translated to the number of days. So I change the value to 42 (which is 6 weeks) and save my Settings. Et voilà, I get a custom view with 6 weeks Cool!

Using Visual Studio with IE

IE has a script debugger built in, but it is worthwhile to go in for Visual Studio as the debugger of choice. There’s a free version of the Visual Studio suite called the Express edition available which you can download and use.

Now to make it work…

1. Enable Script debugging in Internet Explorer.

   

2. Create a New Solution with an Empty Website (File > New > Web Site…)

   

3. Go to Property Pages for the new Website in Solution Explorer and enter the URL you want to debug. Don’t worry if you don’t know the URL, just enter any URL and fire the breakpoints only when you hit the required URL.

   

4. You might get a dialog asking you to include the web.config file. Answer Yes and continue. Now you will be surfing with the debugger attached to Internet Explorer. You can hit pause, set breakpoints and even skip those functions that don’t interest you

Using Venkman with Firefox

I would have loved it if Visual Studio also worked with Firefox. There’s a solution called Venkman. I won’t go through the complete detail of how to go about using it, you can read it up here.

I haven’t found a way to skip code (a la Visual Studio) using this yet.

You can change variable values by directly typing the JavaScript code for it.

The interface doesn’t have all the bells and whistles but should be able to get most of your work done.

In this post I take a look at some ridiculously simple security blunders committed by popular sites. These might not always be critical but provide an interesting insight into the design quality metrics followed at these companies.

While surfing the Net, whenever I see a website offering a cool service, my natural instinct is to find out how they are doing it. For example, Rediff used to have this ActiveX based multilingual mail composition feature, which they replaced with a JavaScript based one. Cool! So now I could work on Firefox and still send my mail in Hindi! How (naively?) were they doing this? Create an IFrame and put the entire composition feature in it. Hmmm, OK, but couldn’t someone just rip off the JS files and create, say, a multilingual composition plugin for WordPress using their code. Access to the .js files doesn’t even require a login to the Rediff servers and using them is as easy as pointing the URL to http://f1mail.rediff.com/quill/QuillPadWeb.html. I am not sure what their testing team (if they have one) thought of this, but this allows someone to use the cool text entry interface by just copying 4 files off the Rediff site.

The easiest way to thwart leechers is to deny access to the scripts unless you are logged on. That would take care of direct linking (protecting computational resources). But there’s no easy solution if someone just copies the files off the server and hosts them on his website (protecting intellectual resources). What do you do then? Probably obfuscate the code enough so that he never knows what file he has to copy. Yahoo mail does an excellent job of the obfuscation. Even their images are protected (in a loose way) by referring them through their MD5 hashes; enough to deter a casual hacker.

Another flaw is doing all (and I mean ALL) the validation at the client side using JavaScript. Client side validation is a nice way to reduce load at the server end. But sometimes, this solution is implemented without safeguards.

While designing any API, there is a golden rule that has to be followed…


All input is evil

Agreed, you have JS to check and ensure that the user input is correct. But what if I inject code through your web service using a simple script debugger like Visual Studio for IE and Venkman for Firefox. Even if I am not able to inject code, I will certainly be able to inject syntactically valid input data which is still invalid. To illustrate, imagine a banking service where the amount that can be withdrawn is checked against current balance using JavaScript. I could very well skip the function, overwrite the function which gets the current balance and a lot more. Unless the server is checking the validity of the transaction itself, I would be able to make any kind of transaction.

In my next post I will discuss, some techniques that can be misused to thwart JavaScript based validations. The purpose of the post will be to further educate software designers about the pitfalls of client side validation which is not backed by robust server side validation.