JWT with JavaScript and rails PART 1
the traditional way of persisting an authenticating of a user is through storing the logged-in user in the server session at the same time the server will create a cookie and sending it to the user/browser in order for the user to remain logged in is throw the browser sending that cookie back to the server so the server can match that cookie with what is in the server sessions now the draw back to all this is that when we want to keep the user logged in throw multiple servers it becomes a problem on the other hand nowadays we have the option of using JWT (JSON web tokens which can solve this issue by keeping the sever session free and storing all the necessary data in a token which is stored in the browsers local storage or as a cookie
here is a flow chart/diagram of cookie vs token taken from stormpath.com
now the drow back is since the basic web token is stored on the browser’s local storage that means it is vulnerable to XSS a nutshell, is a type of vulnerability where an attacker can inject JavaScript that will run on your page. Basic XSS attacks attempt to inject JavaScript through form inputs, where the attacker puts <script>alert(‘You are Hacked’);</script> into a form to see if it is run by the browser and can be viewed by other users.
one way to prevent XSS is to escape and encode all untrusted data
this is unrealistic since most sites use some sort of third-party libraries which is running javaScript, for the app to work properly
one way around this is to send the token with the
HttpOnly cookie flag, which is not accessible through JavaScript, and are immune to XSS. You can also set the Secure cookie flag to guarantee the cookie is only sent over HTTPS.
the drow back to this approach is cookies are vulnerable to cross-site request forgery (CSRF) A CSRF attack is a type of attack that occurs when a malicious web site, email, or blog causes a user’s web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This is an exploit of how the browser handles cookies. A cookie can only be sent to the domains in which it is allowed. By default, this is the domain that originally set the cookie. The cookie will be sent for a request regardless of whether you are on galaxies.com or hahagonnahackyou.com
the fix for CSRF is to use synchronized token patterns and all most major web frameworks have support for this the way they handle this is as follows.
When performing XHR requests, the $http service reads a token from a cookie (by default, XSRF-TOKEN) and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript that runs on your domain can read the cookie, your server can be assured that the XHR came from JavaScript running on your domain.
CSRF can also be partially prevented by checking the HTTP Referer and Origin header from your API. CSRF attacks will have Referer and Origin headers that are unrelated to your application.
now if you are working a rails API the way to get your API to work with cookies will look something like this
# application. rb
…
config.middleware.use ActionDispatch::Cookies
# app/controllers/application_controller.rb
class ApplicationController
include ::ActionController::Cookies
end
Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins ‘http://localhost:4000' # your client’s domain
