All posts by Savita

About Savita

Currently a masters student at Saarland University, Germany. Did my B.Tech in Computer Science at Amrita School of Engineering - Amritapuri, Kollam. I like listening to music and reading books a lot.

OAuth 2.0

OAuth 2.0 has been derived from OAuth 1.0. The OAuth 2.0 was introduced to remove the complexities involved with encryption of the requests for tokens that were present in OAuth 1.0 and also to make it more scalable. Some of the OAuth 2.0 providers are Facebook, Google, Amazon, Github, Microsoft, Paypal, etc. With the introduction of OAuth 2.0, OAuth 1.0 has become obsolete.

User and their roles in the system :

Here there are four users in the system, as opposed to only three in OAuth 1.0. They are follows :

  1. Resource server (same as OAuth 1.0) – A website that is capable of storing resources of users.
  2. Resource owner (same as OAuth 1.0) – An entity who wants to store his resources and can provide access to them to other entities.
  3. Client (same as OAuth 1.0) – A application or website that wants to access the resources of the resource owner, on his behalf.
  4. Authorization server – A server that provides temporary intermediate credentials  to the client, that are required in the complete process of providing authorization to the client.
How is it different from OAuth 1.0 ?

It is different in the sense that, while in OAuth 1.0 there was only one server, that is the resource server, wherein the end user (resource owner) could store his resources, in OAuth 2.0, there is one extra server in addition to the resource server – the authorization server. The authorization server is responsible for providing temporary credentials to the client that wants to access the protected resources of the resource owner. OAuth 2.0 provides for better organization and separation of responsibilities among the users of the system.

Workflow :

The following diagram that has been taken from RFC 6749 shows the workflow in the case of OAuth 2.0 .

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

The steps are explained as follows :

  1. The client that wants to access the resource owner’s resources, sends an authorization request to the resource owner.
  2. Authorization is then granted to the client by the resource owner. The authorization can be of different types depending on whether the client contacted the resource owner directly or indirectly.
  3. The client then uses this authorization grant and requests for an access token after it authenticates with the authorization server.
  4. After the authorization server authenticates the client and checks if the authorization grant provided by the resource owner is valid, it provides an access token to the client.
  5. With the access token that it received from the authorization server, the client requests for access to the resources stored in the resource server.
  6. The resource server checks if the access token is valid or not and accordingly provides access to the token.
The concept of Refresh tokens :

The OAuth 2.0 introduces the concept of providing refresh tokens. Refresh tokens are used as a substitute for access tokens that have been issued by the authorization server to the client, when the access tokens expire. When the client makes an authorization grant to the authorization server for the access token, after authentication by the authorization server, it gets back two tokens – an access token and a refresh token. The refresh token can be used instead of the access token in circumstances where the resource server finds out that the access token has expired. This helps continue the process and avoids the issue of creating a fresh access token.

Under normal circumstances (in the absence of refresh tokens) when the access token expires, the process needs to start all over from the beginning. When the client tries to access the resources by providing the access token (that was issued to it by the authorization server) to the resource server, on checking if the resource server find the access token to have expired, the client needs to begin again with requesting authorization to the resource owner and then follow it up with authentication to the authorization server again, and requesting a new access token.

The following diagram, taken from RFC 6749 explains the workflow in the case of refresh tokens.

+--------+ +-------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | |Authorization| | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +-------------+
 Advantages of OAuth 2.0 :
  1. There is a clear separation of roles and responsibilities among the different components of the system.
  2. OAuth 2.0 has support for both native and mobile applications.
  3. It supports various types of use cases depending on whether the client of confidential or public type.
  4. In OAuth 2.0, the client makes requests for tokens over HTTPS and does not require for the requests to be hashed using HMAC.
Disadvantages of OAuth 2.0 :
  1. OAuth is not backward compatible.
  2. Phishing attacks are possible.
  3. The server gets to know more information about the resources owners and clients.
  4. Denial of Service attack is possible on clients and servers.
  5. Replay attack is possible.
References :

OAuth 1.0

OAuth is an open standard for authorization and helps control access to resources that have been stored in a server, by third party users. OAuth is inspired by OpenID. On generalizing the concept of OpenID, we can see that while the OpenID is a special case of OAuth wherein the resources that are shared are only the username and password. Whereas in the case of OAuth, resources could be anything like files / photos.


Let us look at an example scenario. Suppose that Jane (resource owner) has uploaded some of her photos (protected resources) on a website – (server). She then wants to print them using another website – (client). However, she does not want to reveal her password to the server, to the client. Under such a circumstance, how does the client access her photos from the server so that it can print them for Jane ?

Naive method : A naive approach would be for Jane to reveal the password to her server, to the client so that the client can also login and access the photos. But that would mean that the client would be able to send request to change Jane’s password on the server. As the server wouldn’t know who sent the password request change, it would comply with the request.

Now this is a problem ! We need a different approach under such a situation. This is where the OAuth comes into play !

Terminology :

Some of the common terminologies used are :

  1. Server : An HTTP server capable of receiving HTTP requests from a client. In the above example, the is the server.
  2. Resource owner : The resource owner is the user who has stored some of his resources in a server and can access them using his credentials with which the server authenticates him. Jane is the resource owner, in the explained example.
  3. Protected resource : Something that has been stored in the server by its owner, and to which only limited access is allowed. The protected resource is Jane’s photos.
  4. Client : An HTTP client capable of making HTTP requests to the server. The client in the above example is
Workflow :

This is how an OAuth supporting website works in the example of Jane :

(Please note that and client, and and server, have been user interchangeably.)

  1. Jane (resource owner) has stored her resources in (server).
  2. The (client) has signed up for credentials to some of the commonly used servers (among which one is in order to provide better service to users.
  3. Jane wants to print the photos from, the client.
  4. The client needs to establish a set of temporary credentials with the server for which it sends a request for a temporary credential.
  5. The server validates the client request and sends it temporary credentials.
  6. The client redirects Jane to resource owner end of the server.
  7. The server requests Jane to sign in using her credentials that authenticate her with the server and asks her approval to grant permission to the client to access her resources.
  8. Jane approves giving access to client to access her resources.
  9. The client is informed when Jane finishes granting authorization to the client.
  10. The client requests for another pair of credentials to the server, making use of its temporary credentials.
  11. The server again validates the request and sends back a pair of credentials to the client.
  12. The client can now access Janes photos from the server, with this set of credentials recently given to it by the server.

Thus in this manner, the client is authorized to access Janes resources on the server, without Jane having to compromise her password with the client. OAuth workflow

The greatest advantage of OAuth is that it allows third party access to the resources of the user, without the user having to reveal the password. Only just enough permission is granted to the client, to access the user’s resources.

Having said that, the OAuth is not completely secure. A disadvantage of OAuth is that confidentiality is compromised. The tokens that are shared between the client and server are sometimes in plain text.

References :


What is it ?

OpenID is an open standard allows users to use existing credentials to sign in to many websites, without having to create separate usernames and passwords for each. In the system, there is an OpenID provider. The user may create OpenID account with any of the OpenID providers and use these credentials to identify themselves at different platforms. OpenID is decentralized and is not controlled by anyone.

A common example of where an OpenID is used is a passport. A person can use his passport to identify himself during the airport security check as well as to identify himself at the immigrations office or to identify himself at any other location.

Terminology :

There are three terms that used :

  1. Identity providers : They are the providers of the OpenID. A few examples of Identity providers today are Google, Facebook, Microsoft, etc.
  2. Identifiers : The number or sequence of characters (there could be other forms of identifiers too) that uniquely identify a user. In the case of the OpenID, it is a URL that uniquely identifies the user with the OpenID provider.
  3. Consumers : The parties who use the OpenID of the users to authenticate them.

 With respect to the example of the passport, the government of a country is the identity (OpenID) provider. The passport number on the passport is the identifier of the citizen, and the airport security control authorities are the consumers that check authenticate the user on the basis of his ID.

Workflow with an example :

Suppose that Alice wants to sign up in the website She already has an account with the OpenID provider Google.

  1. Alice visits the website
  2. She gets the option of either using her OpenID or creating a new username and password and she chooses to login using OpenID.
  3. The website searches for the OpenID provider that Alice specifies (which is Google in this case), and establishes an association handle with the provider.
  4. It then sends an authentication request to Google (essentially the website redirects Alice to sign into Google).
  5. Alice to signs into Google using her OpenID credentials.
  6. Google sends back the authentication response to
  7. If successfully authenticated, Alice is redirected to and has successfully logged into
Advantages :

Some of the advantages of the OpenID are :

  1. It accelerates the signup process as the user need not create a separate username and password.
  2. It saves users the headache of having to remember numerous passwords for different web sites as with the help of OpenID they can use their OpenID credentials for other websites. The users do not need to remember multiple passwords.
  3. The user can control the amount of information that is shared with OpenID supporting websites – whether they want to share only their username or their email id also.
  4. It minimize the risk when using same passwords for different websites. There are many users that use the same password for different websites. Thus if any one of these websites gets compromised, the password can be used to login into all the other websites that user has an account in. But with the help of OpenID, if the password gets compromised, it can simply be changed and the attacker would not be able to login to any other sites.
  5. The developer has advantages too. Not having to create usernames and passwords means that getting ridden from the worry of having to store them.
Disadvantages :

Some disadvantages of the OpenID standard are as follows :

  1. Decentralized : OpenID is decentralized and there is no global acceptance or standard for it.
  2. Privacy violation : Each time the user visits a site or carries out an online operation, the identity provider whose identity the user is using to identify himself, gets to know about it.
  3. Information shared : There is also the threat that your username and email id might get shared.
  4. Problem of trust : With OpenID, there is the problem of trust.
  5. Denial of Service attack : Without even having an OpenID, the user could try to log in with a fake OpenID credential. The website does not know that this is fake and sends a request to the OpenID provider. Of course the OpenID provider detects the non-existent account and denies access but already two requests have been sent – one from the user to the website and the other from the website to the OpenID provider. This in large numbers could get dangerous.

Reverse Proxy and its support by Monkey HTTP server

Reverse proxy is the process of routing client requests to backend servers. It sits in between the client and backend servers. It takes a request from the client and assigns it to one of the servers. It fetches the requested resource from the server and returns it to the client. Some of the advantages of using a reverse proxy are :

  1. Helps clients access servers that are configured beyond a firewall. Only the IP address of the proxy is publicized the outer world.
  2. Helps balance loads among different backend servers. It helps choose which server should take the load of the incoming request from the client.
  3. If one of the servers fails to deliver the content of the client request, the request can be assigned to another server.
  4. It is also possible to cache information that is requested frequently by clients. This reduces the load of having to fetch the resource from the server each time.

The following diagram gives a picture of the entire system.


Monkey plugin for reverse proxy :

The monkey server provides support for reverse proxy through the plugin proxy_reverse. You can read more about it here.

Workflow :

This is a brief workflow and where the reverse proxy plugin fits in :

  1. Incoming requests from clients
  2. The request URI is processed to check if it satisfies the regex rules
  3. Checked if a match is found on the basis of the previous search
  4. A balancing algorithm and a list of slave servers are decided on this basis
  5. The list of servers is passed to a balancing function.
  6. A balancing function determines which server should be used.
  7. A new socket is created to connect to the slave server
  8. The socket is set to non-blocking mode
  9. If a connection cannot be established, another slave server is selected and tried to connect
  10. If all servers return an error and cannot be connected to, then an error is returned.
Algorithms for balancing :

Some of balancing algorithms used for this purpose are as follows :

  1. Naive – first alive server from server
  2. First alive – first alive server from 0
  3. Round Robin
    1. with locking – uses mutexes
    2. without locking – does not use mutexes
  4. Least Connections
Some developments in future : Providing cache for reverse proxy plugin

Thanks to Sonny Karlsson, a developer of Monkey httpd server for the idea. He proposed the idea of developing a cache for reverse proxy plugin in the monkey server.

Exception case:
When Monkey server becomes one of the slave servers for reverse proxy plugin there is the possibility of a recursion happening. The following diagrams would show a normal case and the exceptional case. For this reason, it has to be identified if a request is coming from a client or a reverse proxy plugin. If it is found that the resource is not present in the cache, and the slave server to which the request is going to be redirected is Monkey server itself, this would be like an ordinary incoming request to the server, which would be processed and looked up the cache, to see if the resource is present. This will happen indefinitely. Thus, if the resource requested by a request from the proxy reverse plugin is not present in the cache and the slave server to which the request is going to be directed to is found to be Monkey, immediately the next slave server in the list is chosen and the request is sent to this server. The following diagram will show you a workflow of entire system.

Caching the reverse proxy plugin requests
Caching the reverse proxy plugin requests
References :
  1. Picture courtesy :

Virtual Hosting and its support by Monkey HTTP server

Virtual hosting is allowing one server to represent different machines. This basically for supporting multiple host names on one server. For example, there may be two websites – and that may be having the same IP address. For the two websites, even though their information is hosted on the same server, it is maintained in different directories.

There are two types of virtual hosting at the moment:
1. Name-based virtual hosting
2. IP based virtual hosting


What is its advantage ?

The advantage of virtual hosting is that a server shares its resources with multiple websites have the site content on the same server. It shares its resources like processor cycles and memory, etc. with different servers. In a server, virtual hosting is seen as a method to share the server content between different domains.

How to configure Monkey server with two virtual host ?

The following are the steps to be followed while configuring support for virtual hosts in Monkey server.

1. You need to change the /etc/hosts file to add multiple hosts to the same IP address. For example, monkey1 monkey2

So now we have two virtual hosts assigned to the same IP address.

2. Now both of these servers will have different directories under which their resources are shared, in monkey/htdocs/ directory. (monkey/htdocs/monkey1 and monkey/htdocs/monkey2)

3. Each will also need configuration file that states the Document root folder where its resources have been located and its ServerName. The example of a configuration file for one of these servers is as follows:

    Documentroot /home/savita/monkey/htdocs/monkey1
    ServerName monkey1

4. Now on typing the URL: https://monkey1:2001/monkey1/amma1.jpg this particular image which was stored in monkey1 folder is displayed on the browser. For virtual host monkey2, this resource will be present in monkey2/ directory. So if you were to type in the URL space, https://monkey2:2001/monkey2/amma2.jpg, the image that was placed in that location is obtained and displayed on the browser.

The process of having different virtual hosts. In each HTTP request, the host name and the resource URI are mentioned. Now, it checks if the particular virtual host exists and within the virtual host, a particular resource exists or not. If not, then an error is returned.

Sharing file descriptors among different requests :

Monkey follows a special method of sharing file descriptors among different requests that come to the same virtual host so that it avoids opening numerable file descriptors at the same time. This is called File Descriptor Table (FDT).

For each worker or thread, a hash table is maintained with 64 entries and each of these maintains a subarray of 8 chains. So when a request arrives at one of the virtual hosts, it hashes the name of the resource being requested (which can be obtained from the HTTP header) and looks up if the file descriptor for this resource is already present in the hash table for that particular worker. If present, instead of opening another file descriptor for the same file, the already open file descriptor is used. The number of users using that particular file descriptor is incremented. If a particular request stops using a particular file, it checks if the number of users of the file descriptor is greater than zero or not. If it is greater than 0, then a message is just returned that states that the file descriptor is still being used. Else, if the number of users of the file descriptor is zero, then the file descriptor is closed. <using close (2) system call>.

This improves the performance of the monkey server.

Under normal conditions, different virtual hosts do not share data with each other. The main reason that the sharing of file descriptors takes place between different requests within the same virtual host and not among different virtual hosts is to enable or disable such an option for various virtual hosts.

Reference :

  1. Picture Courtesy :

Monkey HTTP server

Monkey server is a lightweight Http server for Linux, written completely in C. It places immense importance on performance and consumes very less memory and for this reason, it is also favourable for embedded devices. It focuses strongly on Linux, the reason for this being that the server depends on the Linux kernel to perform operations that improve the performance of the server. It is HTTP/1.1 compliant. Some of the important features of the server are:

  1. Multi threaded architecture to handle incoming requests from clients: Each thread has the capability to handle 1000 client requests.
  2. Monkey server uses an event driven model to handle requests coming to a thread at the same time.
  3. It supports virtual hosting.
  4. Provides support for IPv4 and IPv6.

The major components of the monkey server are scheduler, threads, plugins. The monkey server has a variety of plugins that serve various functionalities.

  1. Auth – for basic HTTP authentication for users of different virtual hosts of the server.
  2. CGI – helps in enabling CGI support for monkey server.
  3. Cheetah – command line for the server.
  4. Dirlisting – showing the contents of the directory when a client requests a directory.
  5. FastCGI – for FastCGI proxy support. It acts as a proxy for Fastcgi application servers.
  6. Liana – provides the network layer support to the server.
  7. Logger – the log writer plugin that allows the server to keep track of frequently occurring issues and keep statistics.
  8. Mandril – security plugin that allows to filter incoming requests on the basis of URI or IP addresses.
  9. Polarssl – provides HTTPS support for the server
  10. Proxy reverse – provides support to the server for reverse proxying and routing back requests to backend servers.

Setting up and installation :

Follow the below steps to install and monkey from source code.

git clone 
cd monkey

Take localhost:2001 in your browser and lo ! You have successfully installed and run monkey server.


References :

You could read more about this server here :

  3. Image found here

Tolerating the presence of keyloggers

The keylogger is a type of privacy breaching malicious software that intercepts the user activity and retrieves data entered by the user. This data could be used by third parties for various illegitimate purposes. Of more danger are the user-space keyloggers which do not require special permission to be deployed on a system. Recently, I read the paper, “NoisyKey: Tolerating Keyloggers via Keystrokes Hiding” that was written by Prof. Bruno Crispo and Mr. Stefano Ortolani. The paper was presented at USENIX security conference – HotSec’12 . You can find it here.

This blog post is a brief summary of what I understood of the paper.

Aim of the paper :

Currently there are a number of techniques that can be deployed to detect the presence of malicious software like the key loggers and to prevent their execution on a system. But this paper, as the name suggests, discusses how the presence of a keylogger can be tolerated.

Idea proposed :

The keystrokes that are entered by the user, travel through an event channel that transfers the keystrokes to intended application. Normally, it is this event channel that the keylogger intercepts to gain the input that has been entered by the user. In simple words, this paper proposes the idea of injecting dummy keystrokes or noise into this channel and  confusing the keylogger to believe that the dummy keystrokes are the original user input. Now the original user input will be transferred only to the actual targeted application. To list down, there are two parts to the solution implementation.

  1. Introducing appropriate dummy keystrokes into the channel in synchronization with the user input.
  2. Removing the dummy keystrokes from the event channel before they reach the actual application.
Components of the solution :

The solution has itself been implemented in a library named silencer.dll. The following are the four components of the solution implemented :

  1. Noise factory : As the name denote, this is component that creates the dummy keystrokes or the noise.
  2. Injector thread : This component takes the noise that has been generated by the noise generator and introduces it into the event channel.
  3. Normalizer : The normalizer plays the role of shaping the noise that is injected into the channel. It is the intermediate component between the noise factory and the injector thread. As the paper mentions, this is important so that the keylogger does not come to know that it is receiving dummy data. For example, take the case where a user is needed to enter an only digits containing key or pin. The keylogger would be expecting digits. In such a case, it is the role of the normalizer to introduce only “context-aware” noise, as the paper puts it across. It produces context-aware noise by analyzing the past keystrokes.
  4. Silencer : This is the library in which the solution has been implemented. It is the duty of the silencer to work in synchronization with the injector thread.
Workflow :

The workflow has been explained with Windows operating system in mind. The noise factory has a set of dummy keystrokes ready with it, which are transferred to the Normalizer. The normalizer makes sure that the noise is correct with respect to the current context of the event that is getting intercepted. Now when the user enters data, keystrokes travel through the event channel. As soon as the user inputs a keystroke, the process – csrss.exe gets alerted. It is the duty of this process to transfer the correct user input to the destination application. Another application that gets alerted is the silencer thread. The noise is then passed to the injector thread that introduces the noise into the channel. The injector thread notifies the silencer thread about the injection of noise. The silencer removes the dummy keystrokes before they reach the intended application.

This way, it is made sure, only the targeted application receives the user input and not any other application, be a keylogger or any other piece of malicious software.

Other sources :

You can listen to the presentation of the paper here.