1.每次都需要使用mysql_real_escape_string函數，輸入這麼一大串函數名雖然很麻煩，但是這絕對是一個很哈哦的習慣，能免受某些攻擊。
2.注意不要使用FTP，而使用SFTP，它基本是SSH上的FTP，因此更安全。
3.不可能每個人都擁有一個完全屬於自己的服務器，因此就存在着權限設置問題，要麼你的網站讓網絡服務器可讀,此時也就讓服務器上的其他用戶可以查看你的網站代碼了，這顯然是不願意的，要麼就只有你自己能訪問，這樣網站就沒有意義了，如此一來有了suPHP或fastCGI等工具
4.爲了用戶體驗服務器並不會檢測session來源的ip地址，只檢查那一大串隨機數。而且就算檢測ip也不能真正解決問題，比如星巴克等使用了nat的網絡，對外來說其實都是用的一個ip地址。
5.很多網站使用HTTPS，但只用在登錄頁面。因此還是會受到類似firesheep這類工具的威脅，比如說用戶登錄過facebook了，當他再次登錄時在瀏覽器爲了方便只輸入facebook.com，此時瀏覽器會自動補全，自動補全爲http://facebook.com/，注意自動補全並不是https，因此那麼就可能會在向這個地址發送請求時同時發送session cookie,這樣一來就危險了，雖然一開始cookie是通過https加密發給你的，但是此時卻被瀏覽器明文發送出去，這是因爲通常網站不是全站都使用https，那麼是不會將phpsession這些cookie標記爲secure的。解決方法可以是到php.ini這樣的配置文件中將session cookie標記爲secure，這只會在http頭信息中加上表示secure的關鍵字，開啓此功能相當於告訴瀏覽器只有在https連接下才發送此cookie
6.當然有些輔助工具，比如firefox的插件Force-TLS，（p.s. TLS是SSL協議其中的一種）相當於一個看門人，當發現瀏覽器在發送http時，自動將其改爲https。同樣的還有HTTPS Everywhere，功能類似，只是實現原理稍有不同。但它們功能有限，只能對特定網站轉爲https.
7.如果不得不在公開場合如機場，咖啡館的公共wifi下登錄，還有個辦法就是使用vpn。如果家裏有不變的IP地址或者通過某種動態DNS方法，可以通過使用openvpn連接到自己家裏的網絡上。
8.關於session劫持，主要就是嗅探數據包，而嗅探通信是十分容易，課上使用的嗅探工具是Wireshark
9.關於網站安全，最好的辦法就是全站使用ssl，給全站加密。雖然會提高不少成本。
10.一種能夠減少被攻擊而不能根除攻擊的方法就是，每訪問一個頁面都告訴服務器更換使用一個新session id,這樣做能夠防止之前嗅探你的cookie的攻擊者攻擊失效。但也有個問題就是攻擊者更快的搶佔到你的cookie然後登錄然後攻擊者換頁面同時更換了新的session id，那麼此時你就會被退出登錄了。
11.之前談到檢測ip地址，顯然不能解決問題，而用mac地址依然不能解決問題，因爲網卡的mac地址有可能被廠商重複使用，而且就算不管重複的問題，通過http頭信息發送mac地址還是會被截獲到的，因爲http頭信息是明文發送的。
12.理論上可以通過獲取NAT路由器對應的源端口來進行區分檢測該局域網內有人僞造我的cookie,，因爲路由器的源端口無法僞造的，但這功能需要更多的硬件支持。需要第三層的tcp和第五層的http混合使用，不過實現起來還是挺麻煩，還是不如直接啓用SSL簡單
13.使用ssl前需要有ssl證書，即SSL Certificates，首先需要由你自己通過一些命令來產生一個公有密鑰和一個私有密鑰，命令行環境通常可以使用免費軟件OpenSSL。得到兩個文件擴展名分別是.key和.csr。一個文件是證書籤署請求（certificate signing request）,將其上傳到godaddy等你購買ssl證書的地方，驗證通過後會得到另一個文件，其中不僅包含你的公有密鑰，還包含他們的數字簽名，之後就可以自己參照說明或者google，讓ssl爲網絡服務器配置添加證書後生效，當有人通過https請求你的網站時，他的瀏覽器和你的網絡服務器會告訴他，這就是我的公有密鑰，此公有密鑰可以被用來加密一條信息給你，同樣你可以使用他們的公鑰密鑰加密一條信息給他們。
14.對於有使用很多子域名的網站，可以購買更貴一些的通配SSL證書，這樣就能作用於子域名了，這比每個域名都買一個證書要划算的多。
15.可以使用MySQLi API這些API，能幫助處理很多問題。
16.同源策略，被訪問頁面url爲foo.com則無法做到：向另一個域名bar.con發送ajax請求並整合響應到foo.com的內容。但有種技術叫JSONP可以繞過此策略，但這需要網站的支持，而比如雅虎財經就不支持此技術，它返回的CSV顯然不是JSONP，而且大多數網站都不支持這個技術。
17.跨站請求僞造，你登錄了股票網站A，然後又不注意登錄了某個惡意網站，而恰好這個惡意網站會有個跳轉到股票網站A同時會發送請求買入一個股票，於是你就會在不知情的情況下買入了一支股票。跨站請求僞造就是這個意思，跨站表示鏈接來自別處，可以是email可以是直接在壞人的網站上，請求僞造則表示這是一個請求，但它是僞造的，模仿你的行爲，但結果很壞，壞人設法讓你買了股票。
解決辦法可以做個確認頁面，但還有個更好的辦法就是使用post，因爲get很容易被人模仿，但是壞人可以通過js做個鏈接提交表單讓你填寫表單，也可以是圖像提交表單等等多種方法能騙別人提交post請求，通過ajax也能提交post請求
18.壞人甚至連讓你點擊提交按鈕都不用，也可以讓你中招，比如以下就有多種通過標籤的方式讓你中招。
<img src="http://project1.domain.tld/buy.php?symbol=INFX.PK"> //在圖片中插入了鏈接，將會直接購買股票
<script src="http://project1.domain.tld/buy.php?symbol=INFX.PK"></script>
<iframe src="http://project1.domain.tld/buy.php?symbol=INFX.PK">
<script>
var img = new Image();
img.src = "http://project2.domain.tld/buy.php?symbol=INFX.PK";
</script>19.並不是所有瀏覽器都發送http_referer，尤其還有安裝了某些隱私保護的情況，所以檢測超鏈接的方式不能防止這個攻擊，。
附加session令牌給url這個方法可行，可以讓上面這個攻擊變得困難。
20.任何用戶輸入的內容都要記得使用mysql_real_escape_string函數來轉義用戶的輸入，同樣任何回送給用戶的輸入也要轉義，任何預侏儒文本框的時候，不是用的mysql_real_escape_string，而是使用htmlspecialchars以防止用戶鍵入<&這些具有隱患的字符
下面這個網站vulnerable沒有對用戶輸入進行檢測轉義，因此被壞人惡意構建了下面這個語句，然後把這整個鏈接發佈，通過欺騙的方式讓別人點擊，這個鏈接會把瀏覽器地址改爲badguy.com。vulnerable本來是系那個用變量foo獲取用戶輸入，由於該網站沒有對輸入進行檢測轉義，於是被壞人利用構建了特殊語句，去騙其他用戶點擊然後觸發get請求，也許vunlnerable網站意識到這個用戶名不對，於是將通過預注入文本框來告訴用戶，因而現在vun網站就不小心往html代碼中嵌入了壞人構建的js代碼，並且是壞人設法讓網絡服務器做的這些，因此惡意js代碼來源就是vun了，所以這就繞過了同源策略的防禦。
而且這個整個構造的惡意鏈接可以通過把一些符號汝斜線" / "用%3D這類的代碼表示出來，因而混淆後面的內容讓其看上去只是亂碼。
