post是提交資料的方式，比較常見的post提交資料的方式有四種：
2、multipart/form-data(瀏覽器支援)向伺服器上傳小檔案，一般不超過2m
4、text/xml(瀏覽器不支援)：向後台伺服器提交結構化資料
本文主要介紹第一種提交資料的方式：如何用post進行使用者資料安全提交，保護使用者隱私。應用例項：登入
使用者登入操作常用的有兩種方式，get和post。
下面就用firefox瀏覽器詳細解析使用者登入的這兩種方式，為什麼要選擇post，怎麼利用post才能讓使用者資料更安全！
get登入：
登入後，我們會在url位址列中看到登入的使用者名稱和密碼，如此一來便毫無安全可言。
不僅如此，在控制台的伺服器訪問日誌中能夠看到詳細的訪問資訊！
使用get方法所有引數都包含在url中，所有訪問**的url都會記錄在伺服器的訪問日誌中。
而伺服器的訪問日誌正是黑客攻擊的重點物件之一！
利用get進行使用者資訊登入是一種非常不安全的方式。
相比於get而言，post就安全得多。
post是通過攜帶資料體傳遞使用者登入資訊，登入的資料並不會出現在url和伺服器訪問日誌中。
但這也並不十分安全，只要攔截到了傳遞的資料體，使用者名稱和密碼就能輕鬆獲取。
例如：利用firefox中的firebug就能輕鬆攔截到資料體，獲取使用者名稱和密碼
在關係到使用者隱私的時候，要時刻遵循兩個原則：
1、任何應用程式都不能在本地儲存與安全相關的使用者資訊
2、任何應用程式在向伺服器傳遞資料的時候，都不能直接傳遞與安全相關的使用者資訊。
要想讓使用者資訊保安，就必須對其進行加密，讓別人即便是拿到了安全資訊，擺在眼前的也是一串亂碼，沒有半點用處
md5是一種常用的加密方法，它是一種雜湊函式，利用md5對使用者資訊進行加密，會增加使用者資訊安全性。
網上有關於md5的第三方框架category
利用這個第三方框架可以實現對密碼進行md5加密
加密之後的密碼即便是被人攔截，也是一串經過加密的密文，而且這段密文無法反編譯回明文，即便是你拿到了編譯函式也無法做到反編譯。
下面是經過md5加密後列印出來的密碼密文：
這一串202cb962ac59075b964b07152d234b70就是密碼123的密文。
如此一來就安全到無懈可擊了嗎？你要是這樣想那就圖樣圖森破了。
這裡介紹乙個**：
還能說什麼？人家有160t的資料庫，記錄了24萬億條密文資料，恐怕只要你設定的密碼還在人類能記住的範圍內，我就能給你破解。
啥也別說了，一句話：這是乙個神奇的**。
有漏洞就要補，既然你只能破解有記錄的密文，那我弄一條你沒記錄的不就解密不了了嗎？將密碼設定成非人類能記住的即可。
比如：dfkfhk83*#$!dfa>kjdakj2093978609)(&^%$+/.x\ajfkdfh276920s54568$$%*!^&!./sxkaa03-293-=29713720917ks^%$(jh628
這段密碼加密後，我相信它絕對破解不了！安全是有了，但同樣沒人能記住這種密碼，更沒人設定這種密碼，也很少有地方允許設定這種密碼(密碼一般都會限制長度)
既然人不能設定，那就在程式內給密碼後面新增上！
這就是給密碼加「鹽」，就是給密碼加點佐料(一串亂七八糟的字元)。
列印出來的密文：
根本解密不了了！
這樣使用者資訊就有了安全保障。
使用者登入驗證安全問題
關於登入驗證安全問題，使用者名稱和密碼使用 1 1 or 1 1 典型的sql sql select from 表where user user and pass pass 為避免 sql select from 表where user 1 1 or 1 1 and pass 1 1 or 1 1 ...
登入安全問題策略
使用者登入介面 img 客戶感覺每次都要輸入驗證碼不爽，那麼你會怎麼做？三次輸入錯誤，24小時內都要驗證碼 我知道的三種解決方法 cookie session 資料庫表記錄 三種儲存方式，資料庫最安全，還可以判斷下對方的ip，根據對方ip儲存，可是我們專案是門戶型 這個使用者量是很大的。cookie...
前端登入安全問題
對於前端開發來說安全問題很重要，我們不希望自己的密碼之類的資訊暴露出來被人獲取。如果前端不加以限制，很多重要資訊容易洩露。比如我們登入的時候，提交post，我們在瀏覽器控制台network的http請求中會直接看到密碼。http協議是明文傳輸，只要別人一抓包就可以獲取到傳輸的報文。那為了讓資料傳輸更...