Log some articles about Web security and cookies and sessions

Session and Cookie differences and contact: http://www.cnblogs.com/endlessdream/p/4699273.html

HTTP is a stateless protocol, then the client and the server side of the data once the interaction, the client-side link will also be closed, when the exchange of data again need to establish a new link, that is, the server is unable to track the session from the link;

Session tracking: Is a common technique used in Web programs to track the entire session of a user, and the commonly used session tracking techniques are cookies and sessions. A cookie determines the user's identity by logging information on the server, after the client has logged information to determine the user's identity.

Session cookies are generally not stored on the hard disk but are kept in memory. If the expiration time is set, the browser saves the cookie to the hard disk, and the cookie stored on the hard disk can be shared between different processes in the browser, which is called a persistent cookie.

Cookies are stored in the client browser and are not cross-domain. A single cookie cannot hold more than 4k of data, and many browsers limit a maximum of 20 cookies per site.

Session is saved on the server. When the client browser accesses the server, the server logs the client information to the server in some way.

Therefore, you can consider the login information and other important information as a session, other information if necessary to retain, can be placed in a cookie.

Web front-end security XSS attack http://www.haomou.net/2015/10/30/2015_webxss/

There are two types of XSS vulnerabilities, one is Dom Based XSS vulnerability and the other is stored XSS vulnerability.

Dom-based XSS

Dom Based XSS is an attack based on the structure of a Web page DOM, which is characterized by a minority of strokes.

Storage-Type XSS

Stored XSS is a storage-type XSS vulnerability, because its attack code has been stored on the server or in the database, so many victims.

XSS is primarily the use of vulnerabilities to execute the execution of the JS code you need, common XSS:

1 <imgSCR=1onerror=alert (' XSS ')>do alert (' XSS ') when a file with the image name 1 is not found2 <ahref=javascrip:alert (' XSS ')>S</a>Run alert (' XSS ') when you click S3 <iframesrc=javascript:alert (' XSS '); height=0width=0/><iframe>Use the src of the iframe to pop the window4 <imgsrc= "1″onerror=eval ("/x61/x6c/x65/x72/x74/x28/x27/x78/x73/x73/x27/x29")></img>Filter alert to execute pop-up window

Token-based web background authentication mechanism http://www.cnblogs.com/xiekeli/p/5607107.html

Cookie Auth is to create a session object on the server at the time of authentication, and create a cookie object on the client's browser, and the cookie object brought by the client to match the session object on the server side.

Implementation of body management.

Token Auth

Token auth a little bit relative to the cookie auth

1, support cross-domain access: If the transmission of the user authentication information is transmitted through the HTTP header;

2, stateless (also known as: The server can be extended line): Token mechanism in the server does not need to store session information, because token itself contains all the information logged on users, only the client's cookie or local media storage state information;

3, more suitable for CDN: You can use the content distribution network to request all the information on your server (such as: js/html/pictures, etc.), and your server as long as the provision of APIs;

4. Decoupling: There is no need to bind to a specific authentication scheme. Token can be generated anywhere, as long as your API is called, you can make token generation calls;

5, more suitable for mobile applications: When your client is a native platform (ios,android,windows 8, etc.), the cookie is not supported (you need to process through a cookie container), then the token authentication mechanism will be much simpler;

6, CSRF: Because does not rely on the cookie, all does not need to consider to the CSRF (cross-site request forgery) guard;

7, Performance: One network round-trip time (through the database query session information) is always more time than doing a HMACSHA256 calculation token verification and resolution;

8, do not need to do special processing for landing page: If you use Protractor to do functional testing, no longer need to do special processing for landing page;

9, based on standardization: your API can use a standardized JSON WEB Token (JWT). This standard already has multiple backend libraries and support from several companies.

Log some articles about Web security and cookies and sessions