CSC/ECE 517 Spring 2015/ch1b 10 GL - Revision history

Kgong at 15:08, 25 February 2015

2015-02-25T15:08:50Z

← Older revision		Revision as of 15:08, 25 February 2015
Line 28:		Line 28:
	[[File:Screenshot_2015-02-17_23.31.35.png]]		[[File:Screenshot_2015-02-17_23.31.35.png]]

	~~=====Deciphering content of the cookie=====~~
	As you can see I have only one cookie with key <code>_testcookies_session</code>, and the cookie has following data:		As you can see I have only one cookie with key <code>_testcookies_session</code>, and the cookie has following data:

Line 107:		Line 106:
	[[File:Screenshot 2015-02-18 02.03.14.png]]		[[File:Screenshot 2015-02-18 02.03.14.png]]

	The value of <code>another_username</code> has a digest in it, we can use that to detect whether the information has been tampered.		The value of <code>another_username</code> has a digest in it, we can use that to detect whether the information has been tampered. Session, by default, uses signed cookies which prevents any kind of tampering of data, but the data is still visible to users. It means we can’t store sensitive information in session.It would be nice if the session data is stored in encrypted format. And in the Rails 4, the cookie is encrypted by default.

	~~=====Conclusion=====~~
	Session, by default, uses signed cookies which prevents any kind of tampering of data, but the data is still visible to users. It means we can’t store sensitive information in session.It would be nice if the session data is stored in encrypted format. And in the Rails 4, the cookie is encrypted by default.
	====In Rails 4====		====In Rails 4====
	If we generate a Rails application in Rails 4 then,by default, we will see a file at <code>config/initializers/session_store.rb</code>. The contents of this file is something like this:		If we generate a Rails application in Rails 4 then,by default, we will see a file at <code>config/initializers/session_store.rb</code>. The contents of this file is something like this:
Line 123:		Line 120:
	production:		production:
	secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>		secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
			=====Deciphering content of the cookie=====
	For each environment, the rails application has a different <code>secret_key_base</code>. Notice that in Rails 3.2.x the key was <code>secret_token</code>, now is <code>secret_key_base</code>. The differences are if you only have secret_token set, your cookies will be signed, but not encrypted. This means a user cannot alter their <code>username</code> without knowing your app's secret key, but can easily read their <code>username</code>. This was the default for Rails 3 apps. If you have secret_key_base set, your cookies will be encrypted. This goes a step further than signed cookies in that encrypted cookies cannot be altered or read by users. This is the default starting in Rails 4.		For each environment, the rails application has a different <code>secret_key_base</code>. Notice that in Rails 3.2.x the key was <code>secret_token</code>, now is <code>secret_key_base</code>. The differences are if you only have secret_token set, your cookies will be signed, but not encrypted. This means a user cannot alter their <code>username</code> without knowing your app's secret key, but can easily read their <code>username</code>. This was the default for Rails 3 apps. If you have secret_key_base set, your cookies will be encrypted. This goes a step further than signed cookies in that encrypted cookies cannot be altered or read by users. This is the default starting in Rails 4.

Kgong at 15:05, 25 February 2015

2015-02-25T15:05:03Z

← Older revision		Revision as of 15:05, 25 February 2015
Line 75:		Line 75:

	Then we can see the cookies in the browser:		Then we can see the cookies in the browser:

	[[File:Screenshot 2015-02-18 01.43.00.png]]		[[File:Screenshot 2015-02-18 01.43.00.png]]

Line 128:		Line 129:
	session[:username] = 'csc517'		session[:username] = 'csc517'
	Then by visiting the action that executes above code, then you can see cookies for localhost:3000 in browser:		Then by visiting the action that executes above code, then you can see cookies for localhost:3000 in browser:

	[[File:Screenshot 2015-02-18 02.29.10.png]]		[[File:Screenshot 2015-02-18 02.29.10.png]]

Jli53: /* Why using encrypted cookies */

2015-02-19T04:12:05Z

Why using encrypted cookies

← Older revision		Revision as of 04:12, 19 February 2015
Line 10:		Line 10:

	===Why using encrypted cookies===		===Why using encrypted cookies===
	There are some other methods that sometimes are considered to replace encrypted cookies. Session data can be stored in server’s database. However this will cost more time and space when requesting session. Using cookies will dramatically increase the execution speed.		There are some other methods that sometimes are considered to replace encrypted cookies<ref>http://pothibo.com/2013/9/sessions-and-cookies-in-ruby-on-rails</ref>. Session data can be stored in server’s database. However this will cost more time and space when requesting session. Using cookies will dramatically increase the execution speed.
	As for unencrypted cookie, its content can be seen without any restriction, which means anyone can see the content of cookies’ content. So it is absolutely unsafe to carry sensitive content in cookies. However, with encrypted cookies, it is possible that cookie can carry some sensitive data because the secure encryption algorithm.		As for unencrypted cookie, its content can be seen without any restriction, which means anyone can see the content of cookies’ content. So it is absolutely unsafe to carry sensitive content in cookies. However, with encrypted cookies, it is possible that cookie can carry some sensitive data because the secure encryption algorithm.
	And you probably are used to key-derivation encryption([https://github.com/codahale/bcrypt-ruby bcrypt], [http://en.wikipedia.org/wiki/PBKDF2 pbkdf2], etc). But these are not as useful as in passwords because they cannot be decrypted! However cookies need to be decrypted when they are received. So instead of a key-derivation function, Rails uses a cipher(by default [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES-256]) to encrypt and decrypt data.		And you probably are used to key-derivation encryption([https://github.com/codahale/bcrypt-ruby bcrypt], [http://en.wikipedia.org/wiki/PBKDF2 pbkdf2], etc). But these are not as useful as in passwords because they cannot be decrypted! However cookies need to be decrypted when they are received. So instead of a key-derivation function, Rails uses a cipher(by default [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES-256]) to encrypt and decrypt data.

Jli53: /* In Rails 4 */

2015-02-19T04:11:17Z

In Rails 4

← Older revision		Revision as of 04:11, 19 February 2015
Line 113:		Line 113:
	If we generate a Rails application in Rails 4 then,by default, we will see a file at <code>config/initializers/session_store.rb</code>. The contents of this file is something like this:		If we generate a Rails application in Rails 4 then,by default, we will see a file at <code>config/initializers/session_store.rb</code>. The contents of this file is something like this:
	Rails.application.config.session_store :cookie_store, key: '_testcookies4_session'		Rails.application.config.session_store :cookie_store, key: '_testcookies4_session'
	This means we use cookie to store session by default. And unlike Rails 3, now we don't have the file <code>config/initializers/secret_token.rb</code>. Instead, we have <code>config/secrets.yml</code>, and it has these content:		This means we use cookie to store session by default. And unlike Rails 3, now we don't have the file <code>config/initializers/secret_token.rb</code>. Instead, we have <code>config/secrets.yml</code><ref>http://blog.bigbinary.com/2013/03/19/cookies-on-rails.html</ref>, and it has these content:
	development:		development:
	secret_key_base: a760133dad846d239461e2575efa7ac44c68400ded807b58a81fa4517f87b402b76750d710a402b3a90a4b063bd2235fcea8a49186553c01a70db2fb5d4786ff		secret_key_base: a760133dad846d239461e2575efa7ac44c68400ded807b58a81fa4517f87b402b76750d710a402b3a90a4b063bd2235fcea8a49186553c01a70db2fb5d4786ff

Jli53: /* Attention */

2015-02-19T04:10:07Z

Attention

← Older revision		Revision as of 04:10, 19 February 2015
Line 153:		Line 153:

	==Attention==		==Attention==
	Usually cookie has limit size which is 4K. A CookieOverflow exception is raised if you attempt to store more than 4K of data.		Usually cookie has limit size which is 4K. A CookieOverflow exception is raised if you attempt to store more than 4K of data<ref>http://api.rubyonrails.org/classes/ActionDispatch/Session/CookieStore.html</ref>.
	If you are upgrading an existing Rails 3 app, you should leave your existing secret_token in place and simply add the new secret_key_base. Note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4 and are reasonably sure you will not need to rollback to Rails 3. This is because cookies signed based on the new secret_key_base in Rails 4 are not backwards compatible with Rails 3. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete. Additionally, you should take care to make sure you are not relying on the ability to decode signed cookies generated by your app in external applications or JavaScript before upgrading. Note that changing the secret key will invalidate all existing sessions!		If you are upgrading an existing Rails 3 app, you should leave your existing secret_token in place and simply add the new secret_key_base. Note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4 and are reasonably sure you will not need to rollback to Rails 3. This is because cookies signed based on the new secret_key_base in Rails 4 are not backwards compatible with Rails 3. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete. Additionally, you should take care to make sure you are not relying on the ability to decode signed cookies generated by your app in external applications or JavaScript before upgrading. Note that changing the secret key will invalidate all existing sessions!
	And successful encryption and signing are based on administrators’ secure operation. For example, if attackers finally have the access to secret_token or encryption key, then it is possible that they can see or modify the cookie data, then pretend to be a legal user to accomplish various operations, which is disastrous for Rails security.		And successful encryption and signing are based on administrators’ secure operation. For example, if attackers finally have the access to secret_token or encryption key, then it is possible that they can see or modify the cookie data, then pretend to be a legal user to accomplish various operations, which is disastrous for Rails security.

Jli53: /* Getting start */

2015-02-19T04:09:30Z

Getting start

← Older revision		Revision as of 04:09, 19 February 2015
Line 17:		Line 17:
	====In Rails before 4.0====		====In Rails before 4.0====
	=====Getting start=====		=====Getting start=====
	Firstly, let's create a Rails application in 3.2, then by default, you will see a file at <code>config/initializers/session_store.rb</code>. The contents of this file is something like:		Firstly, let's create a Rails application in 3.2, then by default, you will see a file at <code>config/initializers/session_store.rb</code><ref>http://big-elephants.com/2014-01/handling-rails-4-sessions-with-go/</ref>. The contents of this file is something like:
	<pre>Testcookies::Application.config.session_store :cookie_store, key: '_testcookies_session'</pre>		<pre>Testcookies::Application.config.session_store :cookie_store, key: '_testcookies_session'</pre>
	The <code>:cookie_store</code> in this line means to use cookie to store session information. And the <code>key: '_testcookies_session'</code> is telling us to use _testcookies_session as the key to store cookie data. A single site can have cookies under different key.		The <code>:cookie_store</code> in this line means to use cookie to store session information. And the <code>key: '_testcookies_session'</code> is telling us to use _testcookies_session as the key to store cookie data. A single site can have cookies under different key.
Line 27:		Line 27:

	[[File:Screenshot_2015-02-17_23.31.35.png]]		[[File:Screenshot_2015-02-17_23.31.35.png]]

	=====Deciphering content of the cookie=====		=====Deciphering content of the cookie=====
	As you can see I have only one cookie with key <code>_testcookies_session</code>, and the cookie has following data:		As you can see I have only one cookie with key <code>_testcookies_session</code>, and the cookie has following data:

Jli53: /* Background */

2015-02-19T04:08:17Z

Background

← Older revision		Revision as of 04:08, 19 February 2015
Line 5:		Line 5:
	===Background===		===Background===
	A [http://en.wikipedia.org/wiki/HTTP_cookie cookie], sometimes called HTTP cookie<ref>http://en.wikipedia.org/wiki/HTTP_cookie</ref>, web cookie or browser cookie, is some data stored in a user’s web browser while visiting that website. Cookie is sent from web server and browser sends it back when the user loads the website, in order to notify the website of the user’s previous activity. Cookies were designed for web server to remember some user’s information or to record user’s browsing activity. (including clicking certain button, logging in, or recording which pages were visited by the user before) The most common example of this functionality is the shopping cart feature of any e-commerce site. When you visit one page of a catalog and select some items, the session cookie remembers your selection so your shopping cart will have the items you selected when you are ready to check out. Without session cookies, if you click “CHECKOUT”		A [http://en.wikipedia.org/wiki/HTTP_cookie cookie], sometimes called HTTP cookie<ref>http://en.wikipedia.org/wiki/HTTP_cookie</ref>, web cookie or browser cookie, is some data stored in a user’s web browser while visiting that website. Cookie is sent from web server and browser sends it back when the user loads the website, in order to notify the website of the user’s previous activity. Cookies were designed for web server to remember some user’s information or to record user’s browsing activity. (including clicking certain button, logging in, or recording which pages were visited by the user before) The most common example of this functionality is the shopping cart feature of any e-commerce site. When you visit one page of a catalog and select some items, the session cookie remembers your selection so your shopping cart will have the items you selected when you are ready to check out. Without session cookies, if you click “CHECKOUT”
	, the new page does not recognize your past activities on prior pages and your shopping cart will always be empty.		, the new page does not recognize your past activities on prior pages and your shopping cart will always be empty<ref>http://www.allaboutcookies.org/</ref>.

	In [http://rubyonrails.org/ Rails], we may get in touch with cookies when we learn session, which can be regarded as one of cookie’s usage because cookie-based session store is dramatically faster than the alternatives. Rails cookie based session storage was introduced as the default in 2007, version 2.0.0. In Rails 2 and Rails 3, the value of the cookie is a base64 encoded serialized string with an added signature. Session data is thus almost clear text. In Rails 4, the value of the cookie is an encrypted string. But if you have access to the source code of the application you can use the built-in infrastructure to decode the session.		In [http://rubyonrails.org/ Rails], we may get in touch with cookies when we learn session, which can be regarded as one of cookie’s usage because cookie-based session store is dramatically faster than the alternatives. Rails cookie based session storage was introduced as the default in 2007, version 2.0.0. In Rails 2 and Rails 3, the value of the cookie is a base64 encoded serialized string with an added signature. Session data is thus almost clear text. In Rails 4, the value of the cookie is an encrypted string. But if you have access to the source code of the application you can use the built-in infrastructure to decode the session.

Jli53: /* Background */

2015-02-19T04:04:31Z

Background

← Older revision		Revision as of 04:04, 19 February 2015
Line 4:		Line 4:
	== Introduction ==		== Introduction ==
	===Background===		===Background===
	A [http://en.wikipedia.org/wiki/HTTP_cookie cookie], sometimes called HTTP cookie, web cookie or browser cookie, is some data stored in a user’s web browser while visiting that website. Cookie is sent from web server and browser sends it back when the user loads the website, in order to notify the website of the user’s previous activity. Cookies were designed for web server to remember some user’s information or to record user’s browsing activity. (including clicking certain button, logging in, or recording which pages were visited by the user before) The most common example of this functionality is the shopping cart feature of any e-commerce site. When you visit one page of a catalog and select some items, the session cookie remembers your selection so your shopping cart will have the items you selected when you are ready to check out. Without session cookies, if you click “CHECKOUT”		A [http://en.wikipedia.org/wiki/HTTP_cookie cookie], sometimes called HTTP cookie<ref>http://en.wikipedia.org/wiki/HTTP_cookie</ref>, web cookie or browser cookie, is some data stored in a user’s web browser while visiting that website. Cookie is sent from web server and browser sends it back when the user loads the website, in order to notify the website of the user’s previous activity. Cookies were designed for web server to remember some user’s information or to record user’s browsing activity. (including clicking certain button, logging in, or recording which pages were visited by the user before) The most common example of this functionality is the shopping cart feature of any e-commerce site. When you visit one page of a catalog and select some items, the session cookie remembers your selection so your shopping cart will have the items you selected when you are ready to check out. Without session cookies, if you click “CHECKOUT”
	, the new page does not recognize your past activities on prior pages and your shopping cart will always be empty.		, the new page does not recognize your past activities on prior pages and your shopping cart will always be empty.

Jli53: /* References */

2015-02-19T04:03:24Z

References

← Older revision		Revision as of 04:03, 19 February 2015
Line 160:		Line 160:

	==References==		==References==
	</~~references~~>		<references/>

Jli53: /* References */

2015-02-19T04:02:53Z

References

← Older revision		Revision as of 04:02, 19 February 2015
Line 160:		Line 160:

	==References==		==References==
	~~1.[http:~~/~~/pothibo.com/2013/9/sessions-and-cookies-in-ruby-on-rails http://pothibo.com/2013/9/sessions-and-cookies-in-ruby-on-rails]~~		</references>
	~~2.[http://api.rubyonrails.org/classes/ActionDispatch/Session/CookieStore.html http://api.rubyonrails.org/classes/ActionDispatch/Session/CookieStore.html]~~