Foxbrush

From: http://www.cnblogs.com/thuai/archive/2011/12/12/2299971.html
 
android应用中常用的监听OnTouchListener、OnClickListener、OnLongClickListener，大家肯定经常使用。但是你真的知道它会产生的神奇效果么？不要忽视这些神奇效果哦！说不定这些神奇效果正是你想要的呢？好，下面请看我的示例。

From: https://developers.google.com/speed/articles/reflow
 

Minimizing browser reflow

From: http://tech.mozilla.com.tw/posts/4901/%E4%B9%9D%E5%80%8B%E9%81%A9%E6%87%89%E6%80%A7%E8%A8%AD%E8%A8%88%E5%B0%8F%E6%92%87%E6%AD%A5%EF%BC%8C%E6%8A%8A%E7%B6%B2%E7%AB%99%E6%89%93%E9%80%A0%E6%88%90%E8%AE%8A%E5%BD%A2%E9%87%91%E5%89%9B-2
----------------------------------------------------------------
接續上一篇所介紹的一些基本 CSS 排版小技巧，本文第一部分開始介紹 CSS media queries常見的使用方式，以及一些在開發初期就要先注意的地方；第二部分則介紹一些適應性設計相關的工具及 Javascript 套件。希望這些小撇步可以幫助你在開發網站上事半功倍囉！

From: http://tech.mozilla.com.tw/posts/4759/%E4%B9%9D%E5%80%8B%E9%81%A9%E6%87%89%E6%80%A7%E8%A8%AD%E8%A8%88%E5%B0%8F%E6%92%87%E6%AD%A5%EF%BC%8C%E6%8A%8A%E7%B6%B2%E7%AB%99%E6%89%93%E9%80%A0%E6%88%90%E8%AE%8A%E5%BD%A2%E9%87%91%E5%89%9B
----------------------------------------------------
繼之前蓋索林大師的一個打十個系列文章，介紹了 Gaia WebApp 支援多種設備的技巧，本系列文章將深入介紹一些網頁適應性設計相關的通用工具及方法。如果你還不知道什麼是適應性設計，底下有簡潔的介紹。

From: http://joe01032002.pixnet.net/blog/post/92665237-%E3%80%90php%E3%80%91%E5%88%A9%E7%94%A8openssl%E5%AF%A6%E4%BD%9Cssl%E7%B6%B2%E9%A0%81%E5%8A%A0%E5%AF%86
--------------------------------------------------------
一般的網頁伺服器架設起來之後
往往都是沒有作加密的動作

From: http://www.jtmelton.com/2012/02/03/year-of-security-for-java-week-5-clickjacking-prevention/
---------------------------------------------
Clickjacking is a type of “web framing” or “UI redressing” attack. What that simply means in practice is that:
1. A user (victim) is shown an innocuous, but enticing web page (think watch online video)
2. Another web page (that generally does something important – think add friends on social network) is layered on top of the first page and set to be transparent
3. When the user thinks they are clicking on the web page they see (video), they are actually clicking on the higher layered (framed) page that is transparent

From: https://blog.whitehatsec.com/tag/synchronizer-token/
------------------------------------------------------------------------------
 

What is it and why should I care?
Cross-Site Request Forgery (CSRF) is an attack where victims are forced to execute unknown and/or undesired requests onto a website where those requests are currently authenticated. CSRF exploits the fact that the “credentials” needed to perform a function on a website are generally loaded into a client-side cookie, which is then automatically transmitted with every request. By exploiting this automatic transmission, an attacker can cause a victim to execute almost any request that is not protected against CSRF.
Below is a simple image that shows how a basic CSRF attack works:
The steps are:
Step 1. The victim is lured into visiting an evil site (evil.com)
Step 2. The victim’s browser loads the evil site, which contains a hidden image whose src points to an important transaction (on good.com)
Step 3. The victim’s browser executes the transaction at good.com, thus passing along the session cookie (general authn/z mechanism)
Step 4. The transaction occurs, but the victim is unaware until later – or perhaps never − that the transaction occurred
 

 
What should I do about this possibility?
Now that we know what CSRF is, and why it is so dangerous, let’s consider some possible solutions:
Token
The classic solution to CSRF has been a per-session token (known as the synchronizer token design pattern).
The basic flow using this solution is:
Step 1. When the user logs in, a randomized string (token) is then placed in the user session
Step 2. On every form for a non-idempotent request (essentially meaning any request that changes the server-side state – which should be your HTTP POSTs), the token is placed in the form when it is submitted
Step 3. The request handler for the non-idempotent request validates that the submitted token matches the token stored in the session. If either of the tokens is missing, or if they do not match, do not process the transaction
In the past, this per-session token solution has served pretty well for most CSRF situations, but it can be time-consuming to implement and it also creates opportunities for forgetting validation on some requests.
Another solution that uses the token pattern is the ESAPI project, which has built-in CSRF protection, However, ESAPI’s CSRF solution is tied to the authentication scheme. Here is a write-up about using ESAPI’s CSRF protection.
CSRFGuard
A very good option offering solid protection against CSRF is the OWASP CSRFGuard project. This library makes it relatively easy to build CSRF protection into your application by simply mapping a filter and updating a configuration file. This is certainly a resource worth checking out.
Stateless CSRF Protection
One more thing I’d like to share is some interesting work in the area of stateless CSRF protection. When you cannot – or do not want to – maintain the user token in the server-side session state, this is a seemingly novel solution. The idea is to allow the client side to create a cookie with the CSRF token (which is then submitted on every request), and to then include the token as a request parameter. Because an attacker can not read both the cookie and the request parameter, then all the server side should have to do is validate that the token in the cookie and the request parameter match on another. This solution, to my knowledge, has yet to be widely reviewed or tested, but it is a great example of an elegant solution to a difficult problem. Only time will tell if this is the go-forward solution for stateless CSRF protection.
CSRF is a definitely a popular and dangerous attack, but with the protections described above, it is certainly manageable.
One last note: The token approach (classic or stateless) will break down when the site on which it is deployed contains XSS (Cross-Site Scripting) vulnerabilities. If attackers can XSS your site, they can read the content and extract the token you are using; this will effectively nullify the protection you have established. The lesson is simple: Fix those XSS bugs, too!
References
­­­­­­­­­­­­–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
http://www.cgisecurity.com/csrf-faq.html
http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project

From: http://cyrilwang.pixnet.net/blog/post/31813672-%5B%E6%8A%80%E8%A1%93%E5%88%86%E4%BA%AB%5D-cross-site-request-forgery-%28part-2%29
--------------------------------------------------------
在上一篇的文章中，我們了解到何謂 CSRF 以及其運作原理，在這篇的文章中我想要談談網站開發者與使用者該如何做才能避免 CSRF 的威脅。
要 避免 CSRF 的攻擊，目前公認最有效的方式就是所謂的 Synchronizer Token Pattern。簡單來說，Synchronizer Token Pattern 指的是每次使用者發出請求時 (不管是透過 POST 還是 GET) 都必須傳回一個網站系統所指定的亂數，而這個亂數可以設計成適用於整個 Session 階段，也可以設計為只能使用一次。以安全性而言， 後者的作法確實可以達到相當好的效果，但是卻也會為使用者帶來極大的不便性，所以在大部分的情況下前者反而是比較常用的作法。其實後者的作法除了應用在增 加安全性之外，也常被用來作為避免使用者重複發出請求的保護措施。使用者重複發出請求尤其容易出現在反應較慢的系統中，使用者因為失去耐心或不知所措之下 往往只好重複之前的動作 (請求)。

From: http://cyrilwang.pixnet.net/blog/post/31813568-%5B%E6%8A%80%E8%A1%93%E5%88%86%E4%BA%AB%5D-cross-site-request-forgery-%28part-1%29
-------------------------------------------------
Cross-site Request Forgery，常縮寫為 CSRF (或 XSRF)，中文翻譯稱之為跨網站的偽造要求。除了這些稱呼，其他像是 Cross-site Reference Forgery、Session Riding、One-click Attack 等等各式各樣的名稱，其實指的都是同一種攻擊手法。 CSRF 跟 XSS (Cross-site Scripting) 都是跨網站的攻擊手法，但是 CSRF 利用的是使用者對於瀏覽器的信任而達到攻擊目的，而 XSS 則是利用使用者對於網站本身的信任。
簡單來說，CSRF 就是在使用者不知情的情況下，讓瀏覽器送出請求給目標網站以達攻擊目的。 對於 HTTP 協定有所了解的讀者，看到這句話可能會覺得很困惑。因為在預設的情況下，任何人只要知道 URL 與參數都可以對網站發出任何請求，如此說來不是所有的網站都會遭受 CSRF 的攻擊了嗎？可以說是，也可以說不是。因此嚴格來說，CSRF 通常指的是發生在使用者已經登入目標網站後，駭客利用受害者的身分來進行請求，如此一來不但可以獲得受害者的權限，而且在系統的相關紀錄中也很難發現可疑之處。

From: http://www.grauw.nl/blog/entry/510
-------------------------------------------------
For a better understanding of the && (‘and’) and || (‘or’) operators in Javascript, you need to know about two of their properties: