persistent login –“remember me” feature

  1. FACTS:
  • when a machine is reboot, the session will lost, but the token won’t because the token is stored in the cookies
  • a session is in the memory

http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication#477579

If you DO decide to implement persistent login cookies, this is how you do it:

  1. First, follow Charles Miller’s ‘Best Practices’ article Do not get tempted to follow the ‘Improved’ Best Practices linked at the end of his article. Sadly, the ‘improvements’ to the scheme are easily thwarted (all an attacker has to do when stealing the ‘improved’ cookie is remember to delete the old one. This will require the legitimate user to re-login, creating a new series identifier and leaving the stolen one valid).
  2. And DO NOT STORE THE PERSISTENT LOGIN COOKIE (TOKEN) IN YOUR DATABASE, ONLY A HASH OF IT! The login token is Password Equivalent, so if an attacker got his hands on your database, he/she could use the tokens to log in to any account, just as if they were cleartext login-password combinations. Therefore, use strong salted hashing (bcrypt / phpass) when storing persistent login tokens.

summary

  • user login in, after authorization of “remember me”, the client’s cookies is updated with a username, and a token; the token->username is also stored into server’s database
  • for user’s next login, the cookie’s token will be used to match the one in the database; if it does match and is not expired, a new token will be generated and the cookie will be updated accordingly. If it does not, either report it as a theft or ignore it. Thus, automatically re-login is finished.
  • even you reboot the machine, you can still login automatically as long as the token is not expired.

Charles’ Recipe

The cookie should consist of the user’s username, followed by a separator character, followed by some large random number (128 bits seems mind-bogglingly large enough to be acceptable). The server keeps a table of number->username associations, which is looked up to verify the validity of the cookie. If the cookie supplies a random number and username that are mapped to each other in the table, the login is accepted.

At any time, a username may be mapped to several such numbers. Also, while incredibly unlikely, it does not matter if two usernames are mapped to the same random number.

A persistent cookie is good for a single login. When authentication is confirmed, the random number used to log in is invalidated and a brand new cookie assigned. Standard session-management handles the credentials for the life of the session, so the newly assigned cookie will not be checked until the next session (at which point it, too, will be invalidated after use).

The server need not make the effort of deliberately trying to avoid re-assigning random numbers that have been used before: the chance of it happening is so low that even if it did, nobody would know to make use of it.

When a user logs out through some deliberate logout function, their current cookie number is also invalidated. The user also has an option somewhere to clear all persistent logins being remembered by the system, just in case.

Periodically, the database is purged of associations older than a certain time-period (three months, perhaps: the size of the table would be far more an issue than any possibilities of collision in a 128 bit random space).

The following user functions must not be reachable through a cookie-based login, but only through the typing of a valid password:

Advertisements

XSS

http://www.dotblogs.com.tw/tsxz2009/archive/2013/05/07/103080.aspx

比如有些网站后端没处理好,允许加script
象comment什么的,每次load这个comment,就可以embed一个script,然后获取用户的信息
XSS enables attackers to inject client-side script into Web pages viewed by other users.
The expression “cross-site scripting” originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (a reflected or non-persistent XSS vulnerability).

http://en.wikipedia.org/wiki/Cross-site_scripting

为什么叫cross site?

是因为那个script本来是不属于被攻击的那个site

prevention:

1) encode input, when needed to display, decode it

2) validate untrusted html input: sanitize the parameter

3) One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies.[24] To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie.

4) disable scripts if the website does not have scripts

http://lifeiskuso.blogspot.com/2009/08/cross-site-scripting-xss.html

Cross-Site Scripting中文譯為「跨站腳本攻擊」,簡稱XSS。此乃是駭客利用網站上允許使用者輸入字元或字串的欄位插入HTML與Script語言,造成其 他正常使用者在觀看網頁的同時,瀏覽器會主動下載並執行部份惡意的程式碼,或被暗地裡導入到惡意的網站,而受到某種型態的影響。

http://www.baike.com/wiki/%E9%98%B2%E8%8C%83XSS%E8%B7%A8%E7%AB%99%E5%BC%8F%E8%84%9A%E6%9C%AC%E6%94%BB%E5%87%BB

sql injection

SQL injection is a code injection technique, used to attack data driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker).[1] SQL injection must exploit a security vulnerability in an application’s software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.

see the examples from wiki http://en.wikipedia.org/wiki/SQL_injection