Thursday, May 10, 2018

How to use Facebook login on your Website - OAuth 2.0 framework

OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and DigitalOcean. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.

[www.digitalocean.com]


This is a sample page that you can use as a test run to log in to Facebook.
When we click the button Log In With Facebook it will redirect you to the Facebook Login page.




After that, You will redirect to the Facebook and it will grab details that required to your site.


So as the 1st step you need to create FB app in https://developers.facebook.com site.







Then you have to complete the settings

Under the Settings of the Facebook Login, you need to provide the Redirection URL. (Valid OAuth redirect URLs).





You have to Provide a Valid Site URL under Settings. 




You have to mention your redirect URL in the Code also.



Now the app is registered on Facebook. In the Dashboard, you can see the App ID and the App Secret
After Giving the Correct details to settings your Facebook app can go live.



You have to provide the app id and the app secret in your coding to access the Facebook app.

then we need to get the authorization code

To do that we need to send an HTTP GET request to the Authorize Endpoint of Facebook, which is https://www.facebook.com/dialog/oauth.

Here I have used
  • response_type                       = code
  • client_id (same as App ID ) = 2205707049656941 . [app ID] 
  • redirecti_uri                          =  https://generalinternetsecuritystuff.blogspot.com/2018/05/how-to-use-facebook-login-on-your.html
  • scope                                       =  public_profile 
Sample request

Once you Continue, Facebook will redirect the browser to the Redirection URL 


?code=AQCTl2MLMQ38zLqYWbbs8mFj0W99x86yFwvwXL-uihDNsVZ99VH6bse8idIroA7SzUndgEUBsC4_xWz2D0dDPjnWUk6Sr9CJslCFUah5ktOj6dnRUi71AJv2YWmVVBMG6f6w9wazyX5c7vLG-hD5rdFp70tzYSiAPRgSSVLXNuQxOFh5DdmmKG1ZGmtq97XXFvud6DGGj7EY4mOhZJzrlzG5kWVriUrX2AeHQkdbzEK-t9B315bE95YpGpURNe5t-Rm67yjNwf5e_8lQjNqWDgJi7wQZC0OGxBXmK1UDnXHny1_Z_fHS-Ny3isCjzV7EExUtGPz69Si1qjWyh_pozNZkBPQ9NjUgnnEMM16sWv6hiA#_=_

The bold part is the value of the code parameter.

Then we need to grab the Access Token.

For that, the client web application has to send an HTTP POST request to the Token Endpoint of facebook sending the authorization code received in the previous step.

When sending the request we can use  RESTClient.



Now you have the Access Token.

After completing these steps you can Login to Facebook within any website.


Wednesday, May 9, 2018

Cross-site Request Forgery protection in web applications via Double Submit Cookie Patterns

If storing the CSRF token in session is problematic, an alternative defense is a use of a double submit cookie. 

what is 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 (cryptographically strong) 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 the server-side state. 
  • The site then requires that every transaction request include this random value as a hidden form value (or another 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.


[www.owasp.org]



steps to follow

  • create a login form.
  • create 2 cookies to store the session id and CSRF token.
  • create a javascript function to reads the CSRF token cookie value.
  • validate values in the form.
First, we need to create 2 cookies


  setcookie("csrf_token",$csrf_to,time()+3600,"/","localhost",false,true)

we generate the CSRF token on the client side and store it in a cookie and cookie will set in the browser. The CSRF token value is not stored on the server side. 

As you can see CSRF token is now inside a cookie and in the content value of the CSRF token is there.



Then we have to run a javascript to reads the CSRF token cookie value in the browser. 


After that, we need to add a new hidden field to the previously created form to get the CSRF token value to that hidden field.

when the form is submitted CSRF cookie will submit and in the hidden field CSRF token value will get submitted.

After submitting the Form if the CSRF token received in the cookie and also in the message body will match we can display a Successful message.



Friday, May 4, 2018

Cross-site Request Forgery protection in web applications via Synchronizer Token Patterns

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

[https://www.owasp.org]

From this tutorial, I'll show you how to secure a  Login Form with Synchronizer Token Patterns.



Synchronizer token pattern

Synchronizer token pattern (STP) is a technique where a token, secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side.

Steps

  • create a login form.
  • create a cookie and store the session id
  • create CSRF token
  • create a javascript function to obtain the CSRF token
  • validate values in the form


First, we need to figure out what is the client side and what is the server side.

In client side, we create the login form, javascript, and cookie
in server side, we create CSRF token.

First I created the login form using basic HTML



then I created the cookie which users to validate session id with the server side.

What is a Cookie?

Cookies are a mechanism for storing data in the remote browser and thus tracking or identifying return users. You can set cookies using the setcookie() or setrawcookie() function. Cookies are part of the HTTP header, so setcookie() must be called before any output is sent to the browser. Any cookies sent to server from the client will automatically be included in a $_COOKIE

[http://php.net/manual]


setcookie(name, value, expire, path, domain, secure, httponly);
  • Only the name parameter is required. other parameters are optional. but the maximum number of parameters should be 7. 
  • The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of the cookie in clear text.
  • The browser will not send a cookie with the secure flag set over an unencrypted HTTP request.
  • HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie 

In this tutorial, I created the cookie using PHP. You can use any language as you prefer.




Note: The setcookie() function must appear BEFORE the <html> tag.

If you created the cookie correctly you can find your cookie in the cookie list after the code executed. 

Up to this point, we were on the client side. Now let's create the CSRF token in server side.


  • base64_encode(openssl_random_pseudo_bytes(32)) - Generates cryptographically secure pseudo-random bytes
  • hash_hmac - Generate a keyed hash value using the HMAC method


After generating the CSRF token we should store the token in the session variable.

$_SESSION['CSRF'] = $csrf_to;

Now let's create a javascript function to obtain the CSRF token via an ajax call. It should create on the client side. From this function, we request the CSRF token from the server side after the client side is loaded. 

Ajax can
  • Read data from a web server - after the page has loaded
  • Update a web page without reloading the page
  • Send data to a web server - in the background


  • onreadystatechange - Defines a function to be called when the readyState property changes
  • readyState - Holds the status of the XMLHttpRequest.
  • status - Returns the status-number of a request
         [www.w3schools.com]

now we need to call the previously created function in client side


  • csrf.php - server-side PHP file
  • cst - hidden field name
we need to add a new hidden field to the previously created form that has the value of the received CSRF token.

then you can see there's the CSRF token in the hidden field 

when we click on the login button all the information will send to the server side.

Now we should validate the received values of the form by writing a function.


In this function, it checks CSRF token and session id is matching with the server and username and the password are correct.
   


finally, call the function in server side.


References

AND WE FOUND A NEW RANSOMWARE!!!

TODARIUS Hi, it’s been a while, hope you all doing good. 💓 So today’s article is about a new ransomware.  ðŸ˜± Yes. We found a ne...