【轉】CSRF基本概念

本文轉自：http://www.cnblogs.com/hyddd/javascript

一.CSRF是什麼？php

　　CSRF（Cross-site request forgery），中文名稱：跨站請求僞造，也被稱爲：one click attack/session riding，縮寫爲：CSRF/XSRF。html

二.CSRF能夠作什麼？java

　　你這能夠這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF可以作的事情包括：以你名義發送郵件，發消息，盜取你的帳號，甚至於購買商品，虛擬貨幣轉帳……形成的問題包括：我的隱私泄露以及財產安全。shell

三.CSRF漏洞現狀數據庫

　　CSRF這種攻擊方式在2000年已經被國外的安全人員提出，但在國內，直到06年纔開始被關注，08年，國內外的多個大型社區和交互網站分別爆出CSRF漏洞，如：NYTimes.com（紐約時報）、Metafilter（一個大型的BLOG網站），YouTube和百度HI……而如今，互聯網上的許多站點仍對此毫無防備，以致於安全業界稱CSRF爲「沉睡的巨人」。apache

四.CSRF的原理數組

　　下圖簡單闡述了CSRF攻擊的思想：瀏覽器

　　從上圖能夠看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：安全

　　1.登陸受信任網站A，並在本地生成Cookie。

　　2.在不登出A的狀況下，訪問危險網站B。

　　看到這裏，你也許會說：「若是我不知足以上兩個條件中的一個，我就不會受到CSRF的攻擊」。是的，確實如此，但你不能保證如下狀況不會發生：

　　1.你不能保證你登陸了一個網站後，再也不打開一個tab頁面並訪問另外的網站。

　　2.你不能保證你關閉瀏覽器了後，你本地的Cookie馬上過時，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認爲關閉瀏覽器就等於退出登陸/結束會話了……）

　　3.上圖中所謂的攻擊網站，多是一個存在其餘漏洞的可信任的常常被人訪問的網站。

　　上面大概地講了一下CSRF攻擊的思想，下面我將用幾個例子詳細說說具體的CSRF攻擊，這裏我以一個銀行轉帳的操做做爲例子（僅僅是例子，真實的銀行網站沒這麼傻:>）

　　示例1：

　　銀行網站A，它以GET請求來完成銀行轉帳的操做，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危險網站B，它裏面有一段HTML的代碼以下：

　　<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

　　首先，你登陸了銀行網站A，而後訪問危險網站B，噢，這時你會發現你的銀行帳戶少了1000塊……

　　爲何會這樣呢？緣由是銀行網站A違反了HTTP規範，使用GET請求更新資源。在訪問危險網站B的以前，你已經登陸了銀行網站A，而B中的以GET的方式請求第三方資源（這裏的第三方就是指銀行網站了，本來這是一個合法的請求，但這裏被不法分子利用了），因此你的瀏覽器會帶上你的銀行網站A的Cookie發出Get請求，去獲取資源「http://www.mybank.com /Transfer.php?toBankId=11&money=1000」，結果銀行網站服務器收到請求後，認爲這是一個更新資源操做（轉帳操做），因此就馬上進行轉帳操做……

　　示例2：

　　爲了杜絕上面的問題，銀行決定改用POST請求完成轉帳操做。

　　銀行網站A的WEB表單以下：　　

　　<form action="Transfer.php" method="POST"> 　　　　<p>ToBankId: <input type="text" name="toBankId" /></p> 　　　　<p>Money: <input type="text" name="money" /></p> 　　　　<p><input type="submit" value="Transfer" /></p> 　　</form>

　　後臺處理頁面Transfer.php以下：

　　<?php 　　　　session_start(); 　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money'])) 　　　　{ 　　　　 buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']); 　　　　} 　　?>

　　危險網站B，仍然只是包含那句HTML代碼：

　　<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

和示例1中的操做同樣，你首先登陸了銀行網站A，而後訪問危險網站B，結果…..和示例1同樣，你再次沒了1000塊～T_T，此次事故的緣由是：銀行後臺使用了$_REQUEST去獲取請求的數據，而$_REQUEST既能夠獲取GET請求的數據，也能夠獲取POST請求的數據，這就形成了在後臺處理程序沒法區分這究竟是GET請求的數據仍是POST請求的數據。在PHP中，可使用$_GET和$_POST分別獲取GET請求和POST 請求的數據。在JAVA中，用於獲取請求數據request同樣存在不能區分GET請求數據和POST數據的問題。

　　示例3：

　　通過前面2個慘痛的教訓，銀行決定把獲取請求數據的方法也改了，改用$_POST，只獲取POST請求的數據，後臺處理頁面Transfer.php代碼以下：

　　<?php 　　　　session_start(); 　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money'])) 　　　　{ 　　　　 buy_stocks($_POST['toBankId'],　$_POST['money']); 　　　　} 　　?>

　　然而，危險網站B與時俱進，它改了一下代碼：

<html> 　　<head> 　　　　<script type="text/javascript"> 　　　　　　function steal() 　　　　　　{ 　　　　 iframe = document.frames["steal"]; 　　 　　 iframe.document.Submit("transfer"); 　　　　　　} 　　　　</script> 　　</head> 　　<body onload="steal()"> 　　　　<iframe name="steal" display="none"> 　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php"> 　　　　　　　　<input type="hidden" name="toBankId" value="11"> 　　　　　　　　<input type="hidden" name="money" value="1000"> 　　　　　　</form> 　　　　</iframe> 　　</body> </html>

若是用戶還是繼續上面的操做，很不幸，結果將會是再次不見1000塊……由於這裏危險網站B暗地裏發送了POST請求到銀行!

　　總結一下上面3個例子，CSRF主要的攻擊模式基本上是以上的3種，其中以第1,2種最爲嚴重，由於觸發條件很簡單，一個就能夠了，而第3種比較麻煩，須要使用JavaScript，因此使用的機會會比前面的少不少，但不管是哪一種狀況，只要觸發了 CSRF攻擊，後果都有可能很嚴重。

　　理解上面的3種攻擊模式，其實能夠看出，CSRF攻擊是源於WEB的隱式身份驗證機制！WEB的身份驗證機制雖然能夠保證一個請求是來自於某個用戶的瀏覽器，但卻沒法保證該請求是用戶批准發送的！

五.CSRF的防護

　　我總結了一下看到的資料，CSRF的防護能夠從服務端和客戶端兩方面着手，防護效果是從服務端着手效果比較好，如今通常的CSRF防護也都在服務端進行。

　　1.服務端進行CSRF防護

　　服務端的CSRF方式方法不少樣，但總的思想都是一致的，就是在客戶端頁面增長僞隨機數。

　　(1).Cookie Hashing(全部表單都包含同一個僞隨機值)：

　　這多是最簡單的解決方案了，由於攻擊者不能得到第三方的Cookie(理論上)，因此表單中的數據也就構造失敗了:>

　　<?php 　　　　//構造加密的Cookie信息 　　　　$value = 「DefenseSCRF」; 　　　　setcookie(」cookie」, $value, time()+3600); 　　?> ``` 　　在表單裏增長Hash值，以認證這確實是用戶發送的請求。 ```php 　　<?php 　　　　$hash = md5($_COOKIE['cookie']); 　　?> 　　<form method=」POST」 action=」transfer.php」> 　　　　<input type=」text」 name=」toBankId」> 　　　　<input type=」text」 name=」money」> 　　　　<input type=」hidden」 name=」hash」 value=」<?=$hash;?>」> 　　　　<input type=」submit」 name=」submit」 value=」Submit」> 　　</form>

　　而後在服務器端進行Hash值驗證

<?php 　　 if(isset($_POST['check'])) { 　　 $hash = md5($_COOKIE['cookie']); 　　 if($_POST['check'] == $hash) { 　　 doJob(); 　　 } else { 　　　　　　　　//... 　　 } 　　 } else { 　　　　　　//... 　　 } ?>

　　這個方法我的以爲已經能夠杜絕99%的CSRF攻擊了，那還有1%呢….因爲用戶的Cookie很容易因爲網站的XSS漏洞而被盜取，這就另外的1%。通常的攻擊者看到有須要算Hash值，基本都會放棄了，某些除外，因此若是須要100%的杜絕，這個不是最好的方法。
　　(2).驗證碼

　　這個方案的思路是：每次的用戶提交都須要用戶在表單中填寫一個圖片上的隨機字符串，厄….這個方案能夠徹底解決CSRF，但我的以爲在易用性方面彷佛不是太好，還有聽聞是驗證碼圖片的使用涉及了一個被稱爲MHTML的Bug，可能在某些版本的微軟IE中受影響。

　　(3).One-Time Tokens(不一樣的表單包含一個不一樣的僞隨機值)

　　在實現One-Time Tokens時，須要注意一點：就是「並行會話的兼容」。若是用戶在一個站點上同時打開了兩個不一樣的表單，CSRF保護措施不該該影響到他對任何表單的提交。考慮一下若是每次表單被裝入時站點生成一個僞隨機值來覆蓋之前的僞隨機值將會發生什麼狀況：用戶只能成功地提交他最後打開的表單，由於全部其餘的表單都含有非法的僞隨機值。必須當心操做以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。

　　如下個人實現:

　　1).先是令牌生成函數(gen_token())：

<?php function gen_token() { 　　　　//這裏我是貪方便，實際上單使用Rand()得出的隨機數做爲令牌，也是不安全的。 　　　　//這個能夠參考我寫的Findbugs筆記中的《Random object created and used only once》 $token =md5(uniqid(rand(), true)); return $token; }

　　2).而後是Session令牌生成函數(gen_stoken())：

<?php 　　function gen_stoken() { 　　　　　　$pToken = ""; 　　　　　　if($_SESSION[STOKEN_NAME] == $pToken){ 　　　　　　　　//沒有值，賦新值 　　　　　　　　$_SESSION[STOKEN_NAME] =gen_token(); 　　　　　　} 　　　　　　else{ 　　　　　　　　//繼續使用舊的值 　　　　　　} 　　} ?>

　　3).WEB表單生成隱藏輸入域的函數：　　

<?php 　　 function gen_input() { 　　 gen_stoken(); 　　 echo 「<input type=\」hidden\」 name=\」" . FTOKEN_NAME . 「\」 　　 value=\」" . $_SESSION[STOKEN_NAME] . 「\」> 「; 　　} ?>

　　4).WEB表單結構：

<?php session_start(); include(」functions.php」); ?> <form method=」POST」 action=」transfer.php」> <input type=」text」 name=」toBankId」> <input type=」text」 name=」money」> <? gen_input(); ?> <input type=」submit」 name=」submit」 value=」Submit」> </FORM>

　　5).服務端覈對令牌：

　　這個很簡單，這裏就再也不囉嗦了。

　　上面這個其實不徹底符合「並行會話的兼容」的規則，你們能夠在此基礎上修改。

　　其實還有不少想寫，無奈精力有限，暫且打住，往後補充，若是錯漏，請指出:>

　　PS：今天下午寫這篇文檔的時候FF崩潰了一次，寫了一半文章的全沒了，鬱悶很久T_T…….

　　轉載請說明出處，謝謝[hyddd(http://www.cnblogs.com/hyddd/)]

六.參考文獻

[1].Preventing CSRF

[2].Security Corner: Cross-Site Request Forgeries

[3].《深刻解析跨站請求僞造漏洞：原理剖析》

[4].《Web安全測試之跨站請求僞造（CSRF）》

[5].《深刻解析跨站請求僞造漏洞：實例講解》

[6].http://baike.baidu.com/view/1609487.htm

Laravel中的方法

只需在提交表單內添加

{{csrf_field()}}

便可

Laravel ORM

瞭解orm,先了解如下概念：

什麼是「持久化」
持久（Persistence），即把數據（如內存中的對象）保存到可永久保存的存儲設備中（如磁盤）。持久化的主要應用是將內存中的數據存儲在關係型的數據庫中，固然也能夠存儲在磁盤文件中、XML數據文件中等等。

什麼是「持久層」
持久層（Persistence Layer），即專一於實現數據持久化應用領域的某個特定系統的一個邏輯層面，將數據使用者和數據實體相關聯。

什麼是ORM

即Object-Relationl Mapping，它的做用是在關係型數據庫和對象之間做一個映射，這樣，咱們在具體的操做數據庫的時候，就不須要再去和複雜的SQL語句打交道，只要像平時操做對象同樣操做它就能夠了。

爲何要作持久化和ORM設計(重要)

在目前的企業應用系統設計中，MVC，即 Model（模型）- View（視圖）- Control（控制）爲主要的系統架構模式。MVC 中的 Model 包含了複雜的業務邏輯和數據邏輯，以及數據存取機制（如 JDBC的鏈接、SQL生成和Statement建立、還有ResultSet結果集的讀取等）等。將這些複雜的業務邏輯和數據邏輯分離，以將系統的緊耦合關係轉化爲鬆耦合關係（即解耦合），是下降系統耦合度迫切要作的，也是持久化要作的工做。MVC 模式實現了架構上將表現層（即View）和數據處理層（即Model）分離的解耦合，而持久化的設計則實現了數據處理層內部的業務邏輯和數據邏輯分離的解耦合。而 ORM 做爲持久化設計中的最重要也最複雜的技術，也是目前業界熱點技術。

優缺點

優點

第一：隱藏了數據訪問細節，「封閉」的通用數據庫交互，ORM的核心。他使得咱們的通用數據庫交互變得簡單易行，而且徹底不用考慮該死的SQL語句。快速開發，由此而來。

第二：ORM使咱們構造固化數據結構變得簡單易行。在ORM年表的史前時代，咱們須要將咱們的對象模型轉化爲一條一條的SQL語句，經過直連或是DB helper在關係數據庫構造咱們的數據庫體系。而如今，基本上全部的ORM框架都提供了經過對象模型構造關係數據庫結構的功能。這，至關不錯。

缺點

第一：無可避免的，自動化意味着映射和關聯管理，代價是犧牲性能（早期，這是全部不喜歡ORM人的共同點）。如今的各類ORM框架都在嘗試使用各類方法來減輕這塊（LazyLoad，Cache），效果仍是很顯著的。

第二：面向對象的查詢語言(X-QL)做爲一種數據庫與對象之間的過渡,雖然隱藏了數據層面的業務抽象,但並不能徹底的屏蔽掉數據庫層的設計,而且無疑將增長學習成本.

第三：對於複雜查詢，ORM仍然力不從心。雖然能夠實現，可是不值的。視圖能夠解決大部分calculated column，case ，group，having,order by, exists，可是查詢條件(a and b and not c and (d or d))。

來源：CSDN
原文：https://blog.csdn.net/zhanghongjie0302/article/details/47344417

Larveral5.4 group路由中屬性的設置問題

單個路由使用middleware方法添加中間件可行

Route::get('/test/', 'IndexController@index')->middleware('admin.login:middleware parameter-');

結果以下：

羣組路由使用這種方法報錯

Route::group(function () { Route::get('index', 'IndexController@index'); })->middleware('admin.login:middleware parameter-');

報錯：

報錯意爲必需要傳數組參數

修改成：

Route::group(['middleware'=>['admin.login:middleware parameter-']], function () { Route::get('index', 'IndexController@index'); });

可正常顯示：

還可以使用英文官方文檔提供的方法：

Route::middleware(['admin.login:middleware parameter-'])->group(function () { Route::get('index', 'IndexController@index'); });

使用此方法後面就不能再跟數組參數了，如：

Route::middleware(['admin.login:middleware parameter-'])->group(['name'=>'admin'],function () { Route::get('index', 'IndexController@index'); });

報錯：

安裝wordpress的一些問題和解決方法

安裝WordPress後

1、目錄權限問題：主題插件安裝不了，圖片上傳不了

解決辦法：將 wp-content文件夾權限設爲777

chown 777 wp-content

在安裝好的wordpress上傳一張圖片，查看上傳者和組

能夠看到這裏用戶和用戶組都爲apache
而後將wordpress安裝目錄所有更改成此用戶和用戶組

# *表明安裝目錄下全部文件和文件夾
chown -R apache:apache *

測試主題下載，若是還不行，將目錄權限全設置爲777

chmod -R 777 *

這樣作存在必定風險

2、註冊驗證郵件發送失敗

安裝此插件

有些主機可能沒有安裝或配置mail服務，致使php中mail函數無效，使用smtp轉發郵件代替系統的mail，以qq郵箱爲例，到qq郵箱的設置->帳戶中開啓smtp服務

而後獲取受權碼
下一步，設置wordpress中插件

點擊設置，下拉選擇other smtp

填寫方式以下

注意密碼爲受權碼,而不是郵箱的密碼

3、文章發表標題爲中文時，頁面丟失

可能緣由是wordpress源碼對中文url不支持吧，這裏就不改源碼了，直接在後臺中將url方式更改

將文章名方式改成樸素

本文由WP Editor.md 插件編寫，這個插件相似csdn中markdown編輯器
今天寫到這裏，其餘問題後續更新，今天剛搭的這個博客。