OAuth Social Login

What is a Social Login ?

Social Login is a single sign-on for end users. By using this SOCIAL LOGIN user can sign in to a third party website from social network provider like Facebook, Google, LinkedIn or twitter without creating a account on that third party web site.

Flow

A simple social login which was implemented using OAuth 2.0 framework is available in the following link.

https://github.com/Vishie21/Social_Login.git

How it works  ?

Social Login is created with a Google login, using OAuth 2.0 consuming the services of an OAuth Authorization Server and OAuth Resource Server

After the session is start the client send a request to the OAuth authorization server for obtaining access token. During flow this prompt for user Authentication in google.

The following image shows how this app prompt for user authentication

Once the OAuth token is received the resource server APIs invoked and obtain the protected resources as follows.

Cross-site Scripting Forgery in web application via Double submit cookie.

CSRF attacks can be defend using several ways, in the previous blog post it clearly describes what is a CSRF attack and how to defend that kind of attack using synchronizer token pattern.In this blog post it demonstrate how to defend a CSRF attack using double submit cookie.When storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.


When a user authenticates to a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.

In this blog it describes a simple demonstration on a double submit cookie, For demonstration purpose the user login has hard coded. After providing the correct credentials to the login a user can login.

If the provided credentials are wrong, it prompts an error message.

  

Upon login, this website generates a session identifier and it sets a cookie in the browser. At the same time the CSRF token for this session is also generates and sets a cookie in the browser. But the CSRF token value is not stored in the server side.

This web page has implemented with a HTML form, the method is POST and action is another URL in the website.

While the HTML form is loading, a JavaScript is running, which reads the CSRF token cookie value in the browser. JavaScript adds a hidden field to the HTML form modifying the DOM.

When the form is submitted to the action, the CSRF token cookie will be submitted and
the CSRF token value in the form body will be submitted. The value of the CSRF token received,  and the value of the message body is compared, if the values matches, a successful message displays.

For demonstration purpose i have changed the value of the CSRF in the html body, as follows

Now the values are not matching, it shows an error message.

A simple project which demonstrate the above procedure is available in the following link.

https://github.com/Vishie21/csrf-double-submit-cookie-2018.git

Implementing Cross-site Scripting forgery Protection in web application via Synchronize token pattern

Cross-site request forgery, commonly known as CSRF attacks mainly occurs in emails, blogs, websites, instant message which causes users web browser to perform an malicious action while user is currently authenticated in to a trusted site. The consequence of a successful Cross-site Request Forgery attack is limited to the capabilities exposed by the vulnerable application. This kind of attack could result in a changing passwords, purchasing items in the users context, transfer of funds and etc. This kind of attacks perform by the attacker by using the browser of the user, to perform a function to the target system without knowledge of the targeted user, at least until the malicious action is over. Impacts of successful CSRF exploits vary greatly based on the privileges of each victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. This kind of CSRF attacks can even compromise a whole web application.  Sites which are more likely to attack are community websites, or sites which are dealing with payments (Banks, Bill pay services or stock brokerages) Defending CSRF attacks There are mainly two ways to defend these kind of attacks. 1.By checking standard headers to verify the request is same origin.  2.By checking CSRF token In this post it shows how to secure login using a synchronizer token pattern. The login is created with hard-coded user name and password, without using a database. If valid login credentials provided new session will start and session identifier is created and set as a cookie in the browser. And at the same time server store it in the server side. The CSRF token is mapped to the session identifier. If valid credentials provided user can login. And if the wrong credentials provided, it displays a message saying Your username & password not correct After providing the correct credentials the generated generated session stored in the browser as a cookie. In the website, the implemented endpoint accepts HTTP POST requests and respond with the CSRF token. The endpoint receives the session cookie and based on the session identifier, return the CSRF token value.    The webpage is implemented using a HTML form. Method is POST and the action is another URL of the website, when the page loads, it executes an ajax call via a javascript which invokes the endpoint for obtaining the CSRF token created for the session  Once the page is loaded,  HTML form’s is modified and the hidden field has the value of the received CSRF token. Then HTML form is submitted to the action, in the server side, extract the received CSRF token value and check if it is the correct token issued for the particular session. By obtaining the session cookie and corresponding CSRF token for the session, and comparing them can identify the CSFR token is valid or not. If the CSRF token is valid successful message is displayed.  Changing the value of this CSRF it shows the error message. The following screenshots shows a simple demonstration, which prompt an error message. A simple project which demonstrate the above procedure is available in the following link. https://github.com/Vishie21/csrf-synchronizer-token-2018.git