這幾年看了很多勵志與自我成長的作品。甚至看得比剛出社會時還要多。照理說應該在出社會前後閱讀這類叢書，沒想到工作一段時間後才發現自己也有需求重新自我檢視。
這類指導自我檢視的方法，引領自我成長的勵志指南，少說也看過10本以上。扣掉沒有細心翻閱的，應該也超過5本。《發現天賦之旅》應該會是我這幾年的最後一本吧。下一次要隔段時間再看有沒有緣份閱讀同類型的作品了。
會有這樣的決定是因為朋友的一句話。我那個朋友目前為止的人生比我成功許多。而他自稱從不看這類作品。成功的人總能自我激勵、自我提升，因此他認為裡面寫的都是廢話，千篇一律。在下並不全盤接受，但也不得不承任這類書籍看多了，很容易發現相同的核心理念。
其實在人生的旅程裡，許多人吸收知識、實踐，然後重新檢視。接著調整，再實踐、再檢視。如此往復循環。漸漸的也發覺自己想要的。或許也找到方向往那個方向前進。偶爾力不從心的時候，就會需要一點外力幫忙推一把。
勵志的作品會是一帖良藥。
這些勵志的作品能一直出、一直出，是因為人們總是想看看有什麼可以找到最適合或最大化自己成就的祕訣。不過當然沒有那麼容易。通常只能幫你分析再分析，試著把你的心態調整再調整。這裡的方法都很類似，也就是經常被說成「千篇一律」的那部份。
不過，每一部作品都會有自己獨到的見解。《發》的內容裡也有。他將個人做了延伸，除了同樣的自我分析、心態調整外，《發》要你試著了解「你的族人在哪裡？」。這裡提到的族人並不是同血緣的人，而是和你契合的人。當你找到這個人，或是這類人，那你就離你的天命不遠了。
作者對於怎麼分析你是哪一族的？怎麼找到你的族人？提出了他的看法。這是《發》那其他作品最大的不同，也是最精華的地方。而且本書的書寫四平八穩。以勵志作品來說是上乘之作。
如果你正在尋找一本尋求自我成長機會的作品。《發》會是不錯的選擇。
2017年12月29日 星期五
2017年12月25日 星期一
臥斧 - FIX
一段時間沒有閱讀國人的推理作品了。臥斧的這部《FIX》不但取材貼近現實，內容嚴謹扎實，讓人眼睛為之一亮。這本書叫《FIX》有很多原因。不過我想作者最想FIX的是那些冤案吧。本書是一系列7篇的短篇故事，故事都改編自台灣三十年來的真實事件。都是一些有冤案爭議的命案。難得台灣有不錯的懸疑作品，小弟就不要說太多，免得無意破壞了作者精心製作的故事。
第一篇的故事叫《敲木頭》。改編自鄭性澤案。非常巧合的，在下閱讀本作的同時，鄭性澤已經無罪定讞了。在這篇故事裡面，作者就帶著讀者們穿越時光，像是回到命案當時，親臨現場般，重新檢視這場命案。從維基百科上的訊息來看，鄭案最後變成無罪，主要是警方在偵辦的過程中發生許多瑕疵。這些瑕疵不但使得警方的指控變得不可信，更直指鄭無罪的可能。
然而，維基百科上卻沒有指出為什麼鄭會被下獄，蒙受不白之冤。作者就針對這點發揮了小說家的本領，為讀者們提供了一點思考空間。在此幫作者重申一下，雖然改編自真實事件，但是為了故事性，仍有許多作者加入的喬段，請不要用小說來判真實事件的案。
作者在書的最後面說自己非常討厭冤案。認為冤案是極大的惡。我想這點應該沒有人反對。沒有人希望無辜的人背上不屬於他的罪行。更甚者，冤案甚至表示真兇還逍遙法外。一想到這種犯下罪行的人還在社會上閒晃，能不教人擔心嗎？
冤案很令人敏感。面對冤案，無辜的人要受罰，旁人擔心自己落入一樣下場，而執法的人則是不願意或不相信自己造就冤案；這嚴重傷害執法人員威信。它就是這麼可憎的存在。
本書讀到最後面，一個更為爭議的組織出現在作者的銘謝裡--台灣廢死聯盟。直白的說，在下是支持死刑的。我們應該都知道，有一派的學者認為罪犯之所以犯罪，是社會的問題而非犯罪者個人。以此為出發點，這一派的學者認為懲罰犯罪者個人並沒有辦法改善這個社會。然而，在下卻認為為了讓這個社會有更好的發展，有些重大刑案的罪犯仍然應該和社會永久隔離。而隔離的實行方式裡，最好的就是死刑了。省錢又省時。但是我也必須同意的是死刑的判定必須非常小心，以免冤案發。要知道人死不能復生。冤案是支持死刑的我，唯一無法釋懷的問題。
廢死是吵不完的議題。我想就討論到這裡吧。本書的作者在故事中也未在這個議題上著墨。若是轉移本書的冤案焦點就不好了。
如同我開頭寫的。本書的內容嚴謹扎實，是部上乘之作。而且它的內容又貼近時事。我覺得非常值得一讀。在此推薦給各位。
第一篇的故事叫《敲木頭》。改編自鄭性澤案。非常巧合的，在下閱讀本作的同時，鄭性澤已經無罪定讞了。在這篇故事裡面，作者就帶著讀者們穿越時光，像是回到命案當時，親臨現場般，重新檢視這場命案。從維基百科上的訊息來看，鄭案最後變成無罪，主要是警方在偵辦的過程中發生許多瑕疵。這些瑕疵不但使得警方的指控變得不可信，更直指鄭無罪的可能。
然而，維基百科上卻沒有指出為什麼鄭會被下獄，蒙受不白之冤。作者就針對這點發揮了小說家的本領，為讀者們提供了一點思考空間。在此幫作者重申一下，雖然改編自真實事件，但是為了故事性，仍有許多作者加入的喬段，請不要用小說來判真實事件的案。
作者在書的最後面說自己非常討厭冤案。認為冤案是極大的惡。我想這點應該沒有人反對。沒有人希望無辜的人背上不屬於他的罪行。更甚者，冤案甚至表示真兇還逍遙法外。一想到這種犯下罪行的人還在社會上閒晃，能不教人擔心嗎？
冤案很令人敏感。面對冤案，無辜的人要受罰，旁人擔心自己落入一樣下場，而執法的人則是不願意或不相信自己造就冤案；這嚴重傷害執法人員威信。它就是這麼可憎的存在。
本書讀到最後面，一個更為爭議的組織出現在作者的銘謝裡--台灣廢死聯盟。直白的說，在下是支持死刑的。我們應該都知道，有一派的學者認為罪犯之所以犯罪，是社會的問題而非犯罪者個人。以此為出發點，這一派的學者認為懲罰犯罪者個人並沒有辦法改善這個社會。然而，在下卻認為為了讓這個社會有更好的發展，有些重大刑案的罪犯仍然應該和社會永久隔離。而隔離的實行方式裡，最好的就是死刑了。省錢又省時。但是我也必須同意的是死刑的判定必須非常小心，以免冤案發。要知道人死不能復生。冤案是支持死刑的我，唯一無法釋懷的問題。
廢死是吵不完的議題。我想就討論到這裡吧。本書的作者在故事中也未在這個議題上著墨。若是轉移本書的冤案焦點就不好了。
如同我開頭寫的。本書的內容嚴謹扎實，是部上乘之作。而且它的內容又貼近時事。我覺得非常值得一讀。在此推薦給各位。
2017年11月29日 星期三
Same Origin Policy心得整理
最近被一個朋友念。問我這一年來做了什麼。感覺什麼都說不上來，但認真想了一下，這一年來也是做了很多學習、很多嘗試，也有了很多心得。這些零零碎碎的東西，如果不特別記錄下來，恐怕真的會覺得自己什麼都沒做。
即然如此，我就把最近做的一些學習留在這裡做分享吧。
===========
何謂Same Origin Policy？
Same Origin Policy即同源政策。簡單的說，是現代瀏覽器增加的一種安全政策。要求瀏覽器確保網頁中不同來源的腳本與資源不會被交互存取。
其實在早期的瀏覽器中，是否能交互存取不是重要議題。因為當時的網頁技術還不夠強大、成熟，因此比較沒有注意到這個東西。交互存取反而讓網頁腳本的開發變得更為彈性...或是混亂。想得到的，就是保護各網站間的Cookie。
很快的，駭客們發現了跨站腳本攻擊(XSS)與各種新型態的XSS(比如跨站請求偽造(CSRF))攻擊。能利用交互存取的方便性從瀏覽網頁的羔羊身上偷取資料。駭客們只要設法讓自己的腳本被受害者讀取到，接下來就等於控制了羔羊的瀏覽器。此外，隨著網頁技術的成熟，新興的網頁技術讓網頁程式、腳本變得強大，這更助長了駭客的力量。一個強大的瀏覽器被控制了，就表示使用者的電腦或裝置也可能被控制。
XSS簡單的說就是駭客拿某個第三方的網站當跳板，讓瀏覽該網站的使用者執行到駭客的腳本，然後進行進一步的攻擊。實例就像是十幾二十年前的Javascript炸彈。駭客(這麼low，應該是怪客)，在留言板裡面留下一個Javascript，不斷的跳出警告或是新視窗。然後使用者讀到這個留言的時候，就會被不斷出現的警告或是新視窗搞到煩，甚至是瀏覽器或是電腦當機。
CSRF則是讓使用者讀到駭客更複雜的腳本。腳本的內容可能是呼叫銀行做轉帳。如果被害人正好通過了網路銀行的登入，那麼網路銀行可能會無法分判這個轉帳的請求是駭客的腳本發的？還是被害人發的？因為請求都來自同一個(被害人)、登入過的瀏覽器！(各位不用擔心使用網路銀行。這種攻擊已經行之有年。銀行大都已經有防範機制)
上述的兩類攻擊都有一個特點，就是要讓被害人讀到腳本並執行腳本。駭客的腳本被執行後，被害人瀏覽的網頁的內容根本是雙手奉上。
而同源政策(Same Origin Policy)的實行大幅度的減少這種情況的發生。理由是駭客要把讓被害人執行攻擊腳本是有一定難度的。首先是駭客要設法把腳本搬進中介網站，然後中介網站將腳本展示到被害人的瀏覽器。然而中介網站絕不會輕易的加進來路不明的腳本。同時，許多中介網站也開始檢查輸入的資訊，避免前述Javascript炸彈的情況發生。
這使得駭客只能從其他地方進攻。比如在現代瀏覽器多頁籤的功能下，從A頁攻擊B頁。這種場景通常是A網站的資安比較弱(或甚至是駭客自營的)，然後透過瀏覽器內部資源共享的功能(漏洞)和不同的頁籤做資源的交換。
這種情境下，駭客的腳本與中介網站將被瀏覽器認為是不同來源。因此可以切斷兩者之間的交互作用。進而保護網頁的使用者。
Same Origin Policy的影響
在同源政策的影響下，不同來源的資源、腳本，不會互通有無。瀏覽器負責將非法的存取擋下來。我們也經常可以看到Chrome、Firefox在做安全更新。有一些就是白帽駭客們找到了可以突破同源政策的手段。
然而，同源政策也會降低腳本的彈性。這要怎麼處理呢？底下有做一些說明。
突破Same Origin Policy
有一些應用會需要在不同源的腳本或網頁間互取資料。解決方案分兩類：宣告放棄同源保護，以及走其他通道。
如何放棄同源保護
https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS
在Http Header裡面增加「Access-Control-Allow-Origin」。這招叫CORS。
不是單純加上去就可以運作的。詳細可以自己Google查詢。或是看我上面提供的連結。
如何走其他通道突破同源保護
基本上就是用各種方法「間接」的去存取不同源的資源。比方A站的腳本把資源或狀態打到C站；B站的腳本則到C站去取。如果是指令的話，可以改成A站的腳本監聽C站是否有人下了命令。然後B站的腳本發命令到C站。
上面這招可行。但其實有一些更輕便的「定石」可以用。比如postMessage。postMessage就像是網頁頁面裡的Message Queue。開發人員可以透過丟Event到Queue裡面，或是監聽Queue裡面的Event進行兩個站的資源或腳本交互作用。同源政策似乎是認為Message Queue的操作與管理應該是開發人員自己能控制的，所以沒有強加管控。開發人員應自行控制什麼腳本可以被Event驅動、什麼資源可以因Event露出。
即然如此，我就把最近做的一些學習留在這裡做分享吧。
===========
何謂Same Origin Policy？
https://www.w3.org/Security/wiki/Same_Origin_Policy
https://developer.mozilla.org/zh-TW/docs/Web/Security/Same-origin_policy
https://developer.mozilla.org/zh-TW/docs/Web/Security/Same-origin_policy
Same Origin Policy即同源政策。簡單的說，是現代瀏覽器增加的一種安全政策。要求瀏覽器確保網頁中不同來源的腳本與資源不會被交互存取。
其實在早期的瀏覽器中，是否能交互存取不是重要議題。因為當時的網頁技術還不夠強大、成熟，因此比較沒有注意到這個東西。交互存取反而讓網頁腳本的開發變得更為彈性...或是混亂。想得到的，就是保護各網站間的Cookie。
很快的，駭客們發現了跨站腳本攻擊(XSS)與各種新型態的XSS(比如跨站請求偽造(CSRF))攻擊。能利用交互存取的方便性從瀏覽網頁的羔羊身上偷取資料。駭客們只要設法讓自己的腳本被受害者讀取到，接下來就等於控制了羔羊的瀏覽器。此外，隨著網頁技術的成熟，新興的網頁技術讓網頁程式、腳本變得強大，這更助長了駭客的力量。一個強大的瀏覽器被控制了，就表示使用者的電腦或裝置也可能被控制。
XSS簡單的說就是駭客拿某個第三方的網站當跳板，讓瀏覽該網站的使用者執行到駭客的腳本，然後進行進一步的攻擊。實例就像是十幾二十年前的Javascript炸彈。駭客(這麼low，應該是怪客)，在留言板裡面留下一個Javascript，不斷的跳出警告或是新視窗。然後使用者讀到這個留言的時候，就會被不斷出現的警告或是新視窗搞到煩，甚至是瀏覽器或是電腦當機。
CSRF則是讓使用者讀到駭客更複雜的腳本。腳本的內容可能是呼叫銀行做轉帳。如果被害人正好通過了網路銀行的登入，那麼網路銀行可能會無法分判這個轉帳的請求是駭客的腳本發的？還是被害人發的？因為請求都來自同一個(被害人)、登入過的瀏覽器！(各位不用擔心使用網路銀行。這種攻擊已經行之有年。銀行大都已經有防範機制)
上述的兩類攻擊都有一個特點，就是要讓被害人讀到腳本並執行腳本。駭客的腳本被執行後，被害人瀏覽的網頁的內容根本是雙手奉上。
而同源政策(Same Origin Policy)的實行大幅度的減少這種情況的發生。理由是駭客要把讓被害人執行攻擊腳本是有一定難度的。首先是駭客要設法把腳本搬進中介網站，然後中介網站將腳本展示到被害人的瀏覽器。然而中介網站絕不會輕易的加進來路不明的腳本。同時，許多中介網站也開始檢查輸入的資訊，避免前述Javascript炸彈的情況發生。
這使得駭客只能從其他地方進攻。比如在現代瀏覽器多頁籤的功能下，從A頁攻擊B頁。這種場景通常是A網站的資安比較弱(或甚至是駭客自營的)，然後透過瀏覽器內部資源共享的功能(漏洞)和不同的頁籤做資源的交換。
這種情境下，駭客的腳本與中介網站將被瀏覽器認為是不同來源。因此可以切斷兩者之間的交互作用。進而保護網頁的使用者。
Same Origin Policy的影響
在同源政策的影響下，不同來源的資源、腳本，不會互通有無。瀏覽器負責將非法的存取擋下來。我們也經常可以看到Chrome、Firefox在做安全更新。有一些就是白帽駭客們找到了可以突破同源政策的手段。
然而，同源政策也會降低腳本的彈性。這要怎麼處理呢？底下有做一些說明。
突破Same Origin Policy
有一些應用會需要在不同源的腳本或網頁間互取資料。解決方案分兩類：宣告放棄同源保護，以及走其他通道。
如何放棄同源保護
https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS
在Http Header裡面增加「Access-Control-Allow-Origin」。這招叫CORS。
不是單純加上去就可以運作的。詳細可以自己Google查詢。或是看我上面提供的連結。
如何走其他通道突破同源保護
基本上就是用各種方法「間接」的去存取不同源的資源。比方A站的腳本把資源或狀態打到C站；B站的腳本則到C站去取。如果是指令的話，可以改成A站的腳本監聽C站是否有人下了命令。然後B站的腳本發命令到C站。
上面這招可行。但其實有一些更輕便的「定石」可以用。比如postMessage。postMessage就像是網頁頁面裡的Message Queue。開發人員可以透過丟Event到Queue裡面，或是監聽Queue裡面的Event進行兩個站的資源或腳本交互作用。同源政策似乎是認為Message Queue的操作與管理應該是開發人員自己能控制的，所以沒有強加管控。開發人員應自行控制什麼腳本可以被Event驅動、什麼資源可以因Event露出。
訂閱：
文章 (Atom)
發表文章
