Hack sbicapsec.com to run on Firefox
www.sbicapsec.com is State Bank of India’s online share trading portal. This is a good portal but their site’s code quality is amazingly of low quality, dare I say, crappy. SBI being a public sector government institute, we can rest assured that the code quality or bugs in it would not get fixed soon, if ever.
Anyway as of now if you try using this portal in Firefox or Chrome, then maybe you will endup with a screen like this.
Notice the weird “:10” character in the screenshot, instead of the Java Applet.
Fixing sbicapsec.com to run in Firefox
Don’t worry the “hack” here is not illegal. This is used merely as an expression for making things work the way you want it which requires a lot of technical trickery to get it right.
The following has been tested in Firefox 13 and 14 in Mac OSX and Windows XP. You are free to try this as you may want it though. Also this should work in Chrome too.
Now let’s get into fixing this in few simple steps:-
- For your sake, open this blog page in your Firefox browser.
- Install GreaseMonkey browser extension. You may need to restart your browser.
- Install my GreaseMonkey user script by clicking on the link here – AppVersion Patch for SBICAPSEC.
- Click on Install button in the dialog box that you get.
That is it! You should now get the applet after login.
How the fix works (for the technically inclined)
This section is for geeks, who would like to know how the script works. Also it is better to understand this, so that you understand, there is no malicious code in my script.
What is wrong in sbicapsec.com’s site? (Root cause)
The portal’s JS code assumes that navigator.appVersion will always return a string which will have a semi-colon (;). In fact that is true for IE and Chrome (in Mac OSX version only), but not for others. After this failure everything goes down like dominoes.
The popup we get after login has a frameset with three frames. The second one is the one which is supposed to present the Java applet. The layout of that page is roughly as below:-
<body> ... <applet> <param> <param> <param> ... </applet> </body>
It seems the devs there had a requirement to set the width and height of the applet based on user screen’s dimension. For this they modified the code to use JS to dynamically generate the upper applet tag.
<body> ... <script> // This script will generate the upper applet tag with appropriate width and height. </script> <param> <param> :10 <param> ... </applet> </body>
It is in the above script tag where it reads navigator.appVersion and tries to split it by ; and then read the other part. When that errors out, so does the code following it. That code is supposed to write the upper applet tag. So, at the end we are left with many param tags and a dangling </applet> tag. The weird :10 characters are written between two param tags.
From the way they have written the JS code, it seems the devs did not visualize the html page as a tree of blocks, instead for them it was a file stream; like the kind when you use your Java or C++ file output stream. The script block above uses document.write() to write the opening applet tag, instead of using JS to directly manipulate the DOM objects. I wonder how these devs can layout a page, who visualize it as a stream of characters? And, this is just a fraction of the real code, who knows what else is inside. It seems SBI needs to seriously train its devs. All this makes me loose faith over the security and reliability of their site.
Anyway, enough of the rant, back to the topic. The patch script I wrote will, simply try to do what there code was meant to do, add the applet tag. Because of the dangling applet end tag, I was unable to wrap my applet around the existing param tags. So, instead I detached all the param tags, emptied the parent (this reference was stored before detaching param), then added param tags inside the newly create applet tag and finally added the applet inside the previous parent of param tags.
I also tried using other techniques but they did not work. The first one was directly modifying navigator.appVersion to return a string with ;, but it seems you cannot modify them. The second options was to replace existing String.split() function with my own version. In my version I would always return an array of at least length two, so that the code does not error out. Anyway this too did not work out since GreaseMonkey scripts are ran after the page is executed. GreaseMonkey does provide an option to run our scripts at the beginning too, but according to docs that is not supported inside frames.
Anyway, all’s well that ends well. 🙂