Saturday, June 30, 2007


Do you know that Google has a black version of its famous search engine to save power?


I appreciate that. Thnx Google

Wednesday, June 27, 2007

Session Stealing-2

Contnuation of the previous posting..

My apologies for the abrupt ending of my previous post. Something important came up due to which I had to end it abruptly.

Session hijacking is generally crafted using the following methodologies:

1. Request-Response Sniffing
2. Cross site scripting

Well, the first one can be prevented when the whole session is handled through https. However, if part of the session is handled through http and is switched over to https, then the sniffer would be able to pick up the session id transferred in the http session. To avoid this Pramati Server uses a special cookie in addition to the sessionid cookie. This pair is validated when trying to access the https pages. As the second cookie is set via https, the sniffer would not be able to view it easily. When the sniffer/hijacker sends a https session without the secret cookie, the server would understand that this is not from the authenticated user and hence will deny the response.

Regarding second, you should check if the server is immune to XSS (cross site scripting) vulnerabilities.

Session stealing

You have heard about username/password, identity stealing. Did you ever hear about session stealing/hijacking? Session stealing is the act of taking control of the user session after having obtained/generated authenticated session id. Following is a bit intro on session and session id.

HTTP is stateless protocol. To maintain the state of the logged in users and identify them, the servers depend on the session ids. Session is a series of interactions between two end points( in this case server and client) that happens during the span of single connection. Session ID is a random alphanumeric string that a web server assigns a specific user for the duration of that visit. Once the user is logged into the web site/application a session is created for that user and the server hands out the session id to the browser when sending the first response. The browser would send this Session ID to the server on all the subsequent requests. As long as the user makes the requests from the same browser without closing and reopening it, the web site would not ask for the login information. This is coz,the server/application validates the session id received from the browser and would check if the user with that session id is logged in.

Now that we know what session and session id is let us move on to how it is transmitted between the server and the browser. One of the most used method is to set the session id as cookie on the browser JSESSIONID in case of J2EE and ASPSESSIONID for .NET servers. If you have any tool such as IEHttpHeaders for IE or LiveHttpHeaders for Firefox, you would be able to see something similar to this in the response from the server.

Status=OK - 200

Date=Wed, 27 Jun 2007 11:13:45 GMT


Set-Cookie=JSESSIONID=978704440835854248; Path=/


Via=1.0 HYD-MDU-CACHE2:515 (squid/2.6.STABLE12)


What you are seeing here is the Session ID Cookie and the value of the session ID. Anyone sniffing on the network packets between your server and you would be able to easily flick this info. Now once he has that session id, he would send the request to the server with the session id along with the request (You can use Tamperdata extenstion of Firefox to do this)

Now you would start thinking. This guy has some random number generated by the server and that is passed between my browser and server. So what? Just to remind you, this session id is not just another alphanumeric string, as far as the application is considered, this your passport to the application unfortunately a passport without photo on it. Any one who has this session id can get the server tricked into believe that it is YOU who is talking to the server. It is equivalent to some one flicking off your passport and presenting himself as you(Remember no photo on it). Now when application believes that some one else is you, then it would allow that person to do what you would be able to do! Let me put it in few steps

1. You open your bank site and go to the login page and login.

2. Once you are successfully logged in, the server would redirect you to your account details and setting a session id cookie in your browser.

3. When you make any request in any of the bank site, the intelligent browser would send the session id to server along with the new request.

4. The server would verify this id and see that you are already logged on. Hence no more login requests.

5. Now lets say there is a guy in the middle who has been sniffing the requests and responses between your machine and the server. He would be able to see the Session ID cookie that’s shared with you. Now he would pick up the same session id and send it over to the server. Since the id is shared between server and only you, the server would be under the impression that you are the one who is talking to server but it is actually not!

6. Now the guy in the middle would make a request for harmless page with your session id sent along to the server.

7. Server would verify the session id and see that you are already logged in and hence would present the harmless page to the guy in between.

8. From here, he would be able to navigate to your account page effortlessly and view details or do what fancies him at that time.

More about this in my next blog.

Sunday, June 17, 2007

Look who's doing it!!

What if govt flouts pollution control rules? In the pic is one of the waste dumping yards used by GMCH( Greater Muncipal Corporation of Hyderabad). Every day hundreds of trucks dump the garbage collected from all over the city and it is burnt in the evening. Look at the rising smoke. If something goes wrong we have govt to complain to. Now where do we go??

Friday, June 15, 2007


How do Business Developers take decisions on what should they be targeting at? Well, I think they too need data. But, data like what? Lets say you have a web site then they would like to know what interests people the most in your site. How do they figure out this? They are not oracles that would look at the crystal ball and say “Look these are the most visited site on our site and hence developing these products/pages further would increase the traffic and your revenue”. Obviously they would like that kind of data from the person who manages the web site.

Whenever there is a hit to your website, the web server that you use silently logs the request and the response it has sent. But what use is it of? I thought you would never ask this question after reading the first paragraph above. Okay, since you have asked this anyway, let me answer that. This would help that poor guy who has to give the demographics of the site to the enthusiast business developers. But any decent web site would have hits to a volume of few thousands a day. How do we get demographics from thousands of requests? This is where web log analyzers come to our rescue. I have been looking at few web log analyzers recently. Being strong supporter of open source software, I have tried to search for few and I came across this tool named Analog. An open source product, you can download from here. What was impressive was that it took me less than 5 minutes to get the whole stats from my web logs. Just under 5 minutes!!

This is what I did:

Downloaded the package from here
Unzipped it to my disk
Got into unzipped directory located analog.cfg fle, opened it and pointed the web log file.
Saved the config file, and ran the analog executable.
That’s it. This created the Report.html file that contained the stats.

Sounds good. But if you have a web site, which has huge traffic, there would whole lot of web logs created in a single day. How do we deal with this? Simple.. Zip up all the logs, point Analog to the zipped up file and run it. Analog will take care of reading the requests from archive file and present the stats for you.

More documentation is available here

Wednesday, June 13, 2007

Server name in response headers

Was looking through some of the web server vulnerability problems again. Most of the servers do send the server name in the http response. In case you have any livehttpheaders or IEhttpheaders, the response from any of the Application servers can be checked and most of them would contain the server name and probably version as well.

Here is how you can turn it off in some app servers

In Pramati Server, changing value of display-server-name in-header tag to false in web-config.xml would do the trick.

To prevent a WebLogic Server instance from sending its name and version number, disable the Send Server Header attribute in the Administration Console. The attribute is located on the Server —>ServerName —>Configuration —>Protocols —>HTTP tab.

A new environment variable, SERVER_TOKEN_OFF, has been added to
WebSphere Application Server for z/OS v4.0.1 that suppresses Server header in the response

Apache webserver you can turn this off by setting ServerTokens option to prod. This does not eliminate the server name just removes the version of the Apache server.

Friday, June 1, 2007

Reverse Proxy

So what is it all about? Before we move into what is Reverse proxy, we have to look at what proxy is.. I will wait till you brush up with Proxy concepts here. Just kidding. Proxy is that machine which acts as an intermediatary between your pc and the Internet. Put in simple way, Proxy is used as one point of exit for all your network traffic. There are benefits of this. Any rules that you would like to force such as blocking few sites, needs to be done only at proxy location. This way it gives more control on controlling what needs to be controlled. Huh!.

There are few points that make the proxies dear to all..

1. Caching. Lets say this blog has become so popular that 200+ people are reading this 200 times every day from your network. This means lot of network traffic to one site. Now, its very obvious that this blog would change once in a day given, I quit my job and become full time writer. Without the proxy, every request to read my blog would be routed to Internet and thus increasing the network traffic. With proxy in between, it will cache the complete blog on the first hit and the Proxy itself would serve all subsequent requests. This reduces the internet traffic and the amount that your company pays to your ISP.

2. Better Control: Lets say your company would like to block this blog as it sees that people waste a lot of time reading this blog( I agree on time wasted in reading, but about being popular I doubt). Now with proxy in place, we just need to add a line in the configuration of the proxy server and restart it. Voila.. Your fav blog is no longer accessible in your network now.

Now moving to reverse proxy, the simplest way to define it would be to flip the proxy on its feet and its reverse proxy. :-)

Reverse proxy is a special case of a proxy, designed to carry traffic from a less trusted network into a more trusted network. The normal proxy proxies on behalf of a network, but the reverse proxy proxies on behalf of a web server.

So the question is why have this in first place?

1. Security: With reverse proxy in place, there is single point of entry to the web servers (from the reverse proxy). Hence you do not have to open up the web server to Internet, which would reduce the security risk.

2. Caching: The reverse proxy can cache the content from the web server hence reducing the load on the actual web server and serving the content from its cache.

3. Lets say you had to change over the web server to a different machine or to a different host name. Without reverse proxy in between, the names will have to be republished to the outside DNS world. With reverse proxy in place you don’t have to deal with these as the mappings will have to be known just to the reverse proxy and not to the Internet world.

Apart from above there is whole possibility of load balancing that comes into the picture which I would write in detail about in my next coming posts.

Everything comes with some cons as well. So what would be cons about reverse proxy?

1. The single point of entry. While this adds more security, would prove otherwise when the reverse proxy is compromised.

2. The reverse proxy name/IP is all the whole world knows as the fa├žade to your web server. When this goes down without a backup in place, your whole web presence (do I have to mention about your sleep!!) is down the drain.