吳怖衛---實踐課:I至誠 案例分析
阿新 • • 發佈:2022-04-10
這個作業屬於哪個課程 | 至誠軟工實踐F班 |
---|---|
這個作業要求在哪裡 | 作業要求點這裡 |
這個作業的目標 | i至誠APP案例分析 |
學號 | 212106736 |
第一部分 找Bug(黑白盒測試)
-
Bug發生時的測試環境
- Android版本:10
- 測試軟體:福州大學至誠學院APP
- I至誠版本資訊:1.9.9.80670(202111081003)
- 網路使用情況:WIFI
- 條件:手機和電腦共處於同一網路下
- 使用軟體:Fiddler
- 出現的bug:獲取學生資訊頁面,可篡改或獲取資料
-
Bug的可復現性及具體復現步驟
-
此次資料屬於滿足特定要求即可發生
- 通過Fiddler軟體,I至誠獲取HTTPS資訊,獲取到I至誠的POST請求,新增必要資訊以及COOKIE可直接訪問學生頁面
-
-
Bug具體情況描述
-
描述出現了什麼樣的Bug,具體現象是什麼
-
本次出現bug為個人隱私資訊洩露,嚴重影響使用I至誠的學生及教職工的個人資訊隱私安全,以及增加個人資訊被篡改的風險。
-
具體現象:可通過Fiddler軟體獲取I至誠軟體傳送的POST請求,通過I至誠傳送的POST請求,獲取到傳送的地址內容,學號資訊和Cookie,其中Cookie中的內容為最高許可權,通過此Cookie可訪問任意學號或職工號對應的指定資訊。
-
-
輔以配圖的展示這一Bug,並進行適當說明
-
此為Fiddler獲取POST請求
-
此為通過POST請求內捕獲的資訊訪問的學生頁面,以獲取最高許可權,可通過上方code=學號,修改學號獲取到每個學號對應的資訊,通過程式碼編寫可以十分容易將POST返回的JSON資料捕獲,並且通過返回的JSON資料中的confirmList,confirmList是JSON陣列,通過遍歷JSON陣列中columVal節點獲取到內容。
-
通過測試,編輯按鈕可同時同步後端資料庫,修改的內容可成功實現,本人已通過修改自己家庭成員資訊。家庭資訊容易遭到篡改。
-
-
Bug分析
-
Bug的可能成因,需要作出足以自圓其說的分析,並可以類比與之相似的情況或個人專案經歷
- 資料裸露在跑,未進行加密。輕鬆獲取最高許可權,將安全性拋於腦後。
- 本人之前做過畢設,是關於考勤管理,在使用者登入的過程中,使用者登入資料未進行加密,資料庫中內容也未加密,容易獲取到登入資訊。
- 兩者都是對資料未進行加密,讓資料在裸跑,大大增加了資料洩露的風險。
-
-
Bug的嚴重性
- 此次Bug存在⭐⭐⭐⭐⭐致命性安全性漏洞
- 系統功能不完善,未對資料傳輸返回檔案加密,返回資料容易獲取
- 安全性低:抓包小白都可輕易獲取I至誠內使用者資訊,大佬可隨意將I至誠伺服器內的個人資訊輕鬆爬取儲存。
最高許可權容易獲取,擁有最高許可權,可通過I至誠做更多的事情,對我們自己的I至誠錢包進行盜刷。 - 使用者體驗:若使用者知道該軟體出現個人資訊洩露,會造成使用者流失,讓自己的隱私成為別人手裡的資料,得不
到應有的保護
-
對於Bug的預期及改進建議
-
需要結合之前對Bug的分析和嚴重性展開敘述
-
bug存在個人隱私洩露,大大降低個人資訊保安性,讓上萬條個人資訊在互動中進行裸跑
-
嚴重時此些訊息容易給犯罪分子,他們獲取我們的資訊,去詐騙家中老人錢財,家中老人法律意識淡薄,容易上當受騙
-
需要說清楚這個地方應該是什麼樣的,以及應該如何設計可以做到這一點
-
設計者應該對資料進行加密,並且撤回最高許可權設定,考慮分配低許可權,多許可權,供不同身份者使用
-
第二部分 功能分析(參考8.6節對工作的估計,和14.1節軟體工程的質量)
-
根據軟體已有的功能,評估其做到這個程度大約需要多少時間?(例如:團隊人數6人左右,計算機大學畢業生,並有專業UI支援)。(必答)
開發階段 週數 需求分析,文件規範撰寫 2 介面設計 2 介面美化 1 框架搭建,模組介面設計 2 伺服器搭建 2 Android與IOS編碼 7 程式測試與bug修改 3 測試報告 1 事後總結、改進 1 產品釋出準備 1 -
分析這個軟體目前的優劣(和微信端的“至誠教務助手”相比),哪個更實用?(必答)
- 本人覺得微信端的至誠教務助手更加實用
- I至誠使用目的為:打卡,出校申請,這些是在微信端沒有的功能。
- 微信現在是每個人使用頻率最高的軟體,如果將I至誠中的功能加在微信端,那會使得微信端更加使用和方便。
-
從各方面的問題,推理出這個軟體團隊在軟體工程方面可以提高的一個重要方面(具體建議)。
- 可以釋出有獎調查問卷給學生,一旦反饋得到採納,將對提出問題者進行獎勵,學生是使用這個軟體的最大群體,各個出現的問題都會在這個群體中出現,我們需要得到這個群體給我們的反饋來對這個問題進行維護。
-
你在第一部分發現的bug,為何軟體團隊不能在釋出前修復?他們是不知道,還是有意不修復?你覺得是什麼原因?可以從下面的可能性中選取幾個:
- 具體的設計質量不高:對於設計隨意
- 開發人員粗心大意
- 測試把關不嚴,敷衍了事,沒有注意在特殊的配置或環境下測試
- 其他
第三部分 建議和規劃(參考《構建之法》第8章功能的定位和優先順序;第9章專案經理)
這個軟體有很多可以提高的部分,如果你是新上任的專案經理,你將如何提高從而使其更富競爭力?請針對以下問題進行思考:
-
市場現狀
1.目前市場上是否有其他類似功能的產品、競品?
- 競爭產品存在,但此軟體使用與校園內,無競爭關係
2.上述產品的定位、優勢與劣勢在哪裡?
-
定位:校內學生以及教職工
-
優勢:適用人群固定,無競爭產品
-
劣勢:功能完善不夠,安全性低,頁面不美觀
4.上述產品之間呈現什麼樣的關係,哪些為競品關係?以及競爭中的各方態勢如何?
- 當前產品只在至誠校內使用,無競爭關係
-
-
市場與產品生態
- 產品的使用者群體之間是否存在一定的關係?是否有利用其相互作用二次構成特定使用者生態的可能性?
- 存在師生關係,可以通過相互的作用構成特定的使用者生態
- 產品的子產品,以及其他相關產品之間是否存在一定的關係?是否有利用各個產品特性之間的相互關係二次構成產品生態的可能性?
-
產品規劃
1.你要在當前軟體的基礎上設計什麼樣的新功能?為何要做這個功能,而不是其他功能?為什麼使用者會用你的產品/功能?你的創新在哪裡?可以用NABCD分析。
- 可以新增學生課表,出校申請流程狀態等,此類功能在I至誠中暫時沒有,或有的是不完善的功能,例如:課表屬於基礎功能,使用者肯定會使用到,其次出校申請流程狀態屬於I至誠中長期以來缺少的重要功能,申請了假條,但無法檢視是否審批,當前假條的狀態,無法準確的知道自己是否請假成功。
2.如果你是專案經理,可以招聘6個人,並且有4個月的時間,你認為應該如何配置角色(開發,測試,美工等等) 才能在第16周如期釋出軟體的改進版本,並取得預想中的成績。
-
請為你的團隊設計16個週期每週的詳細規劃。
-
工作分配 時間/周 需求分析,文件規範撰寫 2 介面設計 3 介面美化 4 客戶端框架搭建,模組介面設計 6 伺服器搭建 7 Android、IOS編碼 12 程式測試,bug修改 15 正式上線,釋出產品 16