oracle8的不安全因素及幾點說明
—- 作為物件關係型資料庫的傑出代表，oracle無疑是最具實力的。無論是在資料庫的規模，多**資料型別的支援，sql操作複製的並行性還是在安全服務方面，oracle均比sybase、informix強許多，加上其最新版本oracle8.0.4更是增強了這方面的特性，而且還引入了一些新的特性，比如：資料分割槽(data partitioning)、物件關係技術(object relational technology)、唯索引表(index only tables)、連線管理器(connection manager)[net8特性]、高階佇列(advanced quening)等，所以有一種說法：oracle8是適用於如peoplesoft，sap和baan等封裝式應用系統最好的資料庫引擎。
—- 雖然oracle8有許多的優點，但正如微軟的windows系統也會宕機一樣，任何再好的軟體也有他的缺陷，乙個優秀的軟體不可能就是十全十美，他只是避免了大多數常見的或者可能被考慮到的問題，而一些不容易被發現卻非常致命的問題往往會被疏忽掉。oracle8也同樣存在著不安全的因素，許多正在想盡快公升級到oracle8的oracle7.1、oracle7.2、oracle7.3使用者不能不考慮到這個因素。當然，這個不安全因素並不是一下子就發現的，而是我們在對乙個非常龐大的表進行管理時發現的，這種隱患在使用oracle建立的小型或者中型資料庫中可能不會出現或根本無法發現，因為oracle8獨有的特性已經將這種隱患降低到最低的程度，你大可放心你的資料庫系統的安全。
—- 我們安裝的oracle8資料庫是工作於主機-終端方式下的，系統主機採用的是四台hp-9000小型機、1.5g的記憶體。建庫初期時設定的最大事務數是按oracle8的預設取值[這也是oracle7的預設取值]取的：塊值為2k，事務數為32（對於乙個要處理非常龐大的資料庫時，一般我們設定的塊值要大於2k，至少應為4k或者16k，當然這還與主機的cpu能力和i/0能力值有關），並在建庫時沒有進行分割槽建表，這也許就為以後資料庫出問題留下了隱患。由於日訪問資料庫的使用者非常多，而且對同一表操作的使用者數量太大，致使那個表經常被鎖住，不斷有使用者抱怨他們進不了系統，主機傳送的資料報太慢，經常報ora-600的錯誤。起初我們以為是系統網路問題，但這種可能性比較小，因為我們發現系統cpu峰值經常在90%多，空閒很小，資料庫資源太忙，同時有十多個人鎖住乙個大表進行操作，自然一部分使用者就無法進入系統，對此我們寫了如下的sql語句對鎖表使用者進行監控：
select object_id,session_id,serial#,
oracle_usename,os_user_name,s_process
from v$locked_object 1,
v$session s where 1.session_id=s.sid;
—- 也許有的人會問為什麼不用如下的sql語句進行查詢：
select a.username,a.sid,a.serial#,b.id1,
c.sql_text from v$session a,
v$lock b,v$sqltext c where a.lockwait=b.kaddr and
a. sql_address=c.address and a.sql_hash_value=c.hash_value;
—- 以上兩個sql語句都會查詢返回當前被鎖住的使用者列表，但第二個sql語句由於加入了sql_text從而使這個查詢變得非常的慢長，特別是在有許多使用者同時對資料庫進行操作時，建議不用，第乙個sql 語句會在很短的時間內查詢出是誰在鎖表，從而有利於對資料庫的管理，一但有使用者進入不了，我們就馬上殺死其鎖程序[sid，serial#]，sql語句如下：alter system kill session 『sid，serial#』，但這並不是解決問題的根本方法，只能暫時緩解一下；另外我們還發現回滾段時常有「online」與「offline」的現象，於是我們又考慮是否是回滾段引起的問題：因為我們一但對大的回滾段進行操作，馬上就會有使用者反映無法進入。我們知道回退段的大小直接依賴於資料庫的活動狀態，而每乙個extents都應具有相同的值（oracle的推薦）[initial extents的值可以從2k（32）、4k（69）、8k（142）、16k、32k等列表中選擇]，這將保證你刪掉乙個區的時候，你可以重新使用它的空間而不會造成浪費，另外minextents應設為20，這將不會使回退段擴充套件另乙個extent時用到正在被活動的事務所使用的空間，因而我們就可以據此來確定回退段大小，查出資料庫正常執行時所需回滾段的尺寸,為此我們重新設定了回退段的optimal引數[事實是optimal的值並不足引起資料庫出錯]，增大了optimal的值，使用命令set transaction use rollback segment為系統指定了乙個大的回退段[注意optimal引數要足夠大以使oracle不需經常回縮和重新分配extents，如果設得小於最小覆蓋值，效能將由於額外的段重設定而下降，對於乙個要首席執行官查詢的系統，optimal應設成足夠大以避免ora-1555，「smapshot too old」的錯誤，而對於執行小的事務，optimal應設得小一些，使回退段足夠小以便放於記憶體中，這將提高系統效能。]，但我們發現這樣做後，ora-600的錯誤依然出現，而且鎖表越來越嚴重；我們又考慮暫時鎖住這個表，不讓使用者進入，先把使用者的鎖程序全部殺完再看，由於一開始就採用了主機-終端的工作方式，因而根本就無法清除得完，除非斷掉外部的所有網路連線，但那樣無疑是重啟資料庫，最終我們選擇了重啟資料庫。
—- 重啟資料庫後系統資源一下子得以釋放，使用者明顯感覺速度上來了，能夠保證正常使用，就在我們認為系統可能是因為長期沒有down機，使用者登入數過多造成資料庫死鎖的時候，乙個非常嚴重的問題出現了，那個表中的乙個資料無法進行update，一update就報oracle內部**錯誤，當時我們並沒在意，但是不久，我們又發現另一表中編號有重複的現象，根據oracle8的資料唯索引表性，這種現象應該根本不會存在，因為我們在這個表中只建立了唯一索引，於是我們**詢問oracle公司的技術工程師，也許oracle的技術工程師們也是第一次遇到這種問題，他們的回答是資料字典太老，資料索引壞掉，建議重建索引，並把問題向亞太反映。在oracle公司的技術工程師的指導下，我們重建了該錶，並重新建立了索引，在重建索引過程中，開始幾次都不成功，而且無法drop掉先前的表，經過仔細的查詢，我們發現oracle8中的確有索引重複的現象，乙個表中有兩條重複的索引，直接導致資料庫hang，不能訪問，但檢視系統狀態、程序、listener卻都正常，從日誌檔案來看，檔案過小（7mb），check point頻繁，影響到了系統的效能，通過以上調整後，資料庫問題暫時緩解了，可以做update，但是oracle的內部**錯誤卻依然存在，只是暫時還不會影響到我們對資料庫的使用，而回滾段開始出現「online rollback segment」的問題，更加令人不解的是資料庫居然出現了自動down機的現象，於是我們再次詢問oracle公司的技術工程師，他們的答覆是oracle已經注意到了oracle8.0.4版本的一些問題，他們將會給資料庫打patch，希望能夠解決到這些問題，但是考慮到給資料庫打乙個patch，將會把所有的資料都要export出來，這將是乙個非常危險的操作，而且所有主機上的程式都要重新編譯一到，沒有乙個星期的時間是無法做好的，而那是根本不可能的事情，因而我們現在還在等待oracle公司乙個更好的解決辦法。
說明
—- 以上問題可能是oracle的乙個bug，但任何軟體都有它不完善的一面，否則又何必出什麼補丁了，有了補丁肯定會比沒有補丁強，但是我們在設計乙個系統時也一定要考慮到以下的一些方面：
—- 1、 主機系統的cpu能力與i/0能力：hp偏重於i/0能力，cpu能力不強，你的資料庫就應該盡量避免讓cpu佔用率太大；dec偏重於cpu能力，i/0能力不強，你的資料庫就可以考慮適當增大某些占用cpu引數的設定；sun的cpu能力與i/0能力差不多，你的資料庫就應該考慮平衡引數，過大過小都不好。
—- 2、 增大日誌檔案的size，至少一會低於8mb，日誌檔案過小會導致check point頻繁，從而影響到系統的效能。
—- 3、 回滾段最好保持乙個比較合理的值，對一些較大的回滾段可適當增加minextents，並設定optimal，保證一般事物處理無需經常動態分配空間與及時**空間。
—- 4、 要充分利用cpu系統資源及提高cpu的命中率，可適當增大log_simultaneous_copies,db_block_latches,db_writes的設定。
—- 5、 適當增加db_block_buffer與share_poll_size的size，以提高buffer值，增加記憶體，盡快提高buff及sql的命中率。
—- 6、 主機-終端方式儘管可以便於資料維持，但主機-終端方式卻造成主機負荷太重，建議採用客戶-服務端方式建系統。
京東支付邏輯存在不安全因素
寫在前面的話 寫本文只想引起足夠重視,不管是開發還是使用者 關於本文提到問題也提交給京東官方,希望他們能重視.同時也希望看到本文的使用者多乙個心眼 希望大家都不要達到以下的全部假設 以下測試完成於2015 09 08日 測試條件與步驟 見圖 ok,這裡沒有再測試其它支付方式的支付流程設定是否足夠 下...
導致企業資訊系統的不安全因素包括哪些？
網路的開放性 網路支援系統共享，所以其最大的特點是對外開放，而使用者眾多，良莠不齊，從而導致誤用濫用甚至惡意破壞的情況發生。資訊系統本身存在著脆弱性 黑客或故意破壞者，會利用系統不規範的安全配置，或者錯誤的配置開啟入侵系統的缺口，使用者的誤操作或不恰當使用，會造成不安全的後果，甚至會導致系統崩潰，網...
A8 不安全的反序列化
對反序列化的利用是有點困難，因為在不更改或調整底層可被利用 的情況下，現成的反序列化漏洞很難被使用。這一問題包括在top10的行業調查中，而不是基於可量化的資料。有些工具可以被用於發現反序列化缺陷，但經常需要人工幫助來驗證發現的問題。希望有關反序列化缺陷的普遍性資料將隨著工具的開發而被更多的識別和解...