Understanding OAuth2

This protocol allows third-party applications to grant limited access to an HTTP service, either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf. Access is requested by a client, it can be a website or a mobile application for example.

Version 2 is expected to simplify the previous version of the protocol and to facilitate interoperability between different applications.

OAuth2 defines 4 roles :

The Third-Party Application: "Client"
The client is the application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.

The API: "Resource Server"
The resource server is the API server used to access the user's information.

The Authorization Server
This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.

The User: "Resource Owner"
The resource owner is the person who is giving access to some portion of their account.

Creating an App
Before you can begin the OAuth process, you must first register a new app with the service. When registering a new app, you usually register basic information such as application name, website, a logo, etc. In addition, you must register a redirect URI to be used for redirecting users to for web server, browser-based, or mobile apps.

Example: Registering a Goole Drive API

Redirect URIs
The service will only redirect users to a registered URI, which helps prevent some attacks. Any HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with "https". This prevents tokens from being intercepted during the authorization process. Native apps may register a redirect URI with a custom URL scheme for the application, which may look like demoapp://redirect.

Client ID and Secret
After registering your app, you will receive a client ID and a client secret. The client ID is considered public information and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used, and ideally, the service shouldn't issue a secret to these types of apps in the first place.

Authorization
The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user.

OAuth 2 provides several "grant types" for different use cases. The grant types defined are:

Authorization Code for apps running on a web server, browser-based and mobile apps
Password for logging in with a username and password
Client credentials for application access
Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.
Each use case is described in detail below.

In this blog post, you can get a clear understand about the process of a web application that consumes the service of an OAuth Authorization Server and an OAuth Resource Server. For instance, it will demonstrate by a simple PHP web application to upload files to Google Drive using Google Drive REST API V3. As a prerequisite, you needed to set up a web server on your local machine. Then get the project files from here and follow the instructions in GitHub Readme to deploy it on your localhost.

When you run the app, initially it will display a simple button to initiate the process by redirecting the user to the permissions page where users can grant access to the application.

https://accounts.google.com/o/oauth2/v2/auth?redirect_uri=http://localhost/DriveSubmIt/modules/submit.html&prompt=consent&response_type=code&client_id=30577338934-gr44qm3k4vga34bc2lkrmfbsjbuidkgd.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/drive&access_type=offline

redirect_uri - Indicates the URI to return the user to after authorization is complete
response_type=code - Indicates that your server expects to receive an authorization code
client_id - The client ID you received when you first created the application
scope - One or more scope values indicating which parts of the user's account you wish to access

As you can see that whenever you execute this you will be redirected to the screen where you want to select your Google account from this list of accounts and after that, it grants access to your account by allowing this you will be granted access to this application.

If the user clicks "Allow," the service redirects the user back to your site with an auth code.

Website Interface:



Your server exchanges the auth code for an access token. You never see the access token, it will be stored by the website (in session for example). Google also sends other information with the access token, such as the token lifetime and eventually a refresh token.

When you upload file it will use the session.












































Message flow diagram:

Download Entire FB Photo Album In Few Seconds

Facebook is a most common and great way to share photos with your friends and family members. There has been a huge rise in the number of photos shared on Facebook with more than 60 billion photos shared by its members already.  Everyday we see our friends and family members sharing pictures on Facebook as albums and there are times when you want to download and store them on your machine. This is quite difficult task, if you have to download each picture by right-clicking and then doing “Save Image As…” for each photo.

Facebook2Zip  is a web service that allows you to download your friends' Facebook photo albums in a single zip archive. As well as this is a simple way to back up your own Facebook photo albums. This is a totally free online too.

To start using this service, you just have to visit the Facebook2Zip official web site and log in with Facebook. When you login with your Facebook login credentials it will allow you to select yourpersonal albums or type and select your Friends name that you want to download from. Then it will display the list of albums and you can select and download. You can download individual or multiple photo albums.

Please let me know if anything is not working properly. Good Luck! :)

Virus Analysis; Code Evolution Techniques

One of the most important requirements of malicious code analysis is the understand of advanced code evolution techniques.There are common techniques used by malicious code developers and writers to evade detection and destruction: 

 

Common Techniques:

 1. Self-Encryption and Self-Decryption

Malicious code may encrypt the virus body. Even using several layers of encryption and decryption and/or using random keys (Oligomorphic Viruses) in encryption and decryption. This makes them harder to examine directly.

2. Binders and Packers

Most virus signature files are created based on the checksum value which makes use of the file properties and first few bytes of the malicious code binaries. The binders technique is to bind the virus and malicious code file on to another file, which changes its form. The packers technique is to compress the virus code before it is embedded.

3. Polymorphism

Malicious code can change its default encryption settings as well as the decryption code during self-encryption. These make it much more difficult to detect.

4. Metamorphic Viruses
These do not have a decryptor or a constant virus body but are able to create new generations that look different. Malicious code change its form by, for instance, rearranging its code fragments or/and by adding useless lines of code into its source, and recompiling itself into a new form.

5. Stealth

The technique is designed to evade anti-virus software detection by hiding the code itself.

Let's have a talk about virus infection techniques in future post.