Web storage, cookies, and security

Notes

Web storage slides

Here are some PowerPoint slides about web storage: webStorage.pptx

Web storage

Here are a couple of links to web sites about web storage (including local storage):
http://diveintohtml5.info/storage.html
http://coding.smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it/

sessionStorage is similar to localStorage. The main difference is that data in sessionStorage is associated with a window or tab, and when that window or tab is closed the data in sessionStorage is deleted.

Cookies

Here's a link to a web site that has more information about cookies:
http://www.nczonline.net/blog/2009/05/05/http-cookies-explained/

Internet Security is a BIG topic

This part of the course is not intended to be a comprehensive discussion of Internet security issues. In fact, it's not even close. But there are a few basic security issues that are worth mentioning, even if we can't look at security in depth.

The reading assignment lists a section of JS:TDG that was also part of an earlier reading assignment. That section talks mostly about restrictions on JavaScript and about cross-site scripting attacks. Understanding why those restrictions were made, and understanding how cross-site scripting attacks are made can help you watch out for other security issues in web application development.

The Same Origin Policy

The same-origin policy states that JavaScript code is not allowed access to HTML documents that were not loaded from the same origin as the document that contained the JavaScript code.

For example, suppose that a web browser loads an HTML document, A.html, from Server A. Also suppose that A.html contains a script tag for a JavaScript file, A.js. Then the browser loads another document, B.html, from Server B. The code in A.js has full access to A.html but has no access to B.html or documents from any server other than Server A.

Note that an HTML document can contain script tags that load JS from a different server than the server from which the HTML document was loaded. No matter what server the JS code is actually loaded from, for purposes of the same-origin policy the JS code is associated with the server from which the HTML document was loaded.

An origin (or server) is defined as the combination of the protocol (like http or https), the host name, and the port number.

You can read about the same-origin policy in this Wikipedia article: https://en.wikipedia.org/wiki/Same-origin_policy

Sanitize data

Sanitizing data means to inspect data for characters with special meanings and remove or escape them to prevent security problems. For an example of sanitizing data, look at the cross-site scripting section (13.6.4 in 6th ed.) of JS:TDG. In this case, sanitizing data meant removing the angle brackets (< and >) so that the user couldn't add tags to load JavaScript code or otherwise cause problems with the web page.

Never assume that data came from your form

One common use for JavaScript is to validate form data. Form validation can prevent bad or incomplete data from reaching the server in some cases, but by itself it is insufficient. The problem is that anyone on the Internet can copy and modify the form and use their own form to submit whatever data they want to the server. (And, at least in the case of the HTTP GET method, no form is required at all--a malicious user only has to add a query string of their choice to the end of a URL.)

The moral of the story is that no matter how much validation is done on the client side, it's no substitute for validating user data on the server side.

Passwords

Computer users are notorious for choosing insecure passwords. A password that is a name, or is a dictionary word (any dictionary, not just English), or is short, can be cracked relatively easily.

There are two things you can to try to improve the security of passwords in your application:

  1. You can educate users about password security and suggest wasy of choosing more secure passwords.
  2. You can check the passwords that users choose and not allow them to use insecure passwords.

diceware.com is an interesting web site that is all about choosing secure passwords.

SSL and certificates

SSL is a way of encrypting data sent from a client to a server (or vice versa, of course). It certainly improves security during data communication, but it does nothing to protect data before it is sent or after it arrives.

Certificates are used to identify servers and facilitate the use of public-key cryptography.

Practice principles of good software-engineering

Bugs in any kind of computer application are annoying to the people who legitimately use the application. To intruders, however, bugs can represent golden opportunities. Any bug in a computer application be a security flaw that can allow intruders to break into a system.

One technique that intruders use to break into systems is to put in input values that a legitimate user wouldn't (intentionally) enter: Strings that are very long (hundreds or thousands of characters), strings that contain punctuation or other special characters (see the notes about sanitizing data above), negative or floating-point numbers where positive integers are expected, etc. Thorough testing can help uncover problems and improve security.

Software testing is not the only part of software engineering that is relevant to security, however. Creating a good design is also important from a security point of view.

Web storage versus cookies

Web storage and cookies are two ways that web applications can store information on the client (in the web browser). In general, web storage is much easier to use than cookies are, and it has been implemented in recent versions of most or all major browsers. However, web storage is only accessible on the client and is not available to the server, so web storage is not a complete replacement for cookies. Also, even if you don't use cookies in your own web applications, it's good to know how they work because you are likely to see them used in other applications, especially older ones.

PHP state mechanism as an alternative to cookies

Cookies can be useful for storing user log-in information so that a user only has to log in once and then can access any page in a web site. However, because of privacy issues, some users disable cookies. An alternative to cookies is the use of the PHP state mechanism which stores client information on the server. If cookies are enabled, PHP uses a cookie to store an id code that matches client sessions with data stored on the server. If cookies are not enabled, PHP appends the id code to the URL.

Cookies and local files

Chrome doesn't allow cookies in documents that are loaded from local files rather than from a web server. Some other browsers might also have issues working with cookies and local files.