- Injection: 攻擊者利用 GET / POST 在參數裡塞入部份程式, 取得不被允許的資料。如常見的 SQL Injection。解法就是別相信使用者傳進來的東西, 限制傳入東西的型別和可能的文字模式。
- XSS: 誤執行攻擊者傳來的程式。比方說 textarea 就容易混入這類程式。別傻傻的直接引入使用者傳上來的 html, 最好只充許純文字, 或限制 html tag 的功能。
- Broken authentication and session management: 如網站傻傻的將 session id 放到 URL 上, 讓使用者有機會不小心外洩 session id。
- Insecure direct object reference: 沒有在存取資料時再多做權限檢查。攻擊者在登入後, 可以傳特定參數取得他不能取得的資料。比方說 alice 登入後在需要傳 user id 的地方改傳 bob 卻能取得 bob 的資料。
- CSRF: B 網站偷塞會連向 A 網站更新資料的操作 (如塞在 img src 裡), 若使用者登入 A 網站後沒登出, 接著連到 B 網站就中招了。解法是 A 網站要確保任何會更新資料的操作, 在產生輸入的頁面時先塞一段密文, 在更新資料時檢查是否有這段密文, 確保使用者真的從 A 網站送出請求。
- Security misconfiguration: 網站留一堆後門給攻擊者用, 像是可以由外連上管理者介面 (如 phpMyAdmin), 或是可以瀏覽網站目錄, 下載 source code 之類的。還有用別人的 framework / lib, 明明說有 security patch 卻不更新。
- Insecure cryptographic storage: 加密的 key 和加密的資料存在一起, 有防和沒防一樣。password 檔沒加 salt (之前寫過的文章: 為啥要用 salt)。
- Failure to restrict URL access: 沒有在載入頁面時檢查權限。比方說只有查使用者是否有登入, 並隱藏使用者沒權限執行的頁面。一但攻擊者知道那些 URL, 就能登入後直接連上去使用。
- Insufficient Transport Layer Protection: 輸入密碼或重要資料 (如卡號) 時沒透過加密連線, 攻擊者可透過監聽網路封包的方式取得這些資料。或是一般使用的情況取得 session id。另外有用 SSL 但沒設好 certificate, 造成惡意攻擊網站有機會偽裝成自家網站, 騙取輸入資料。
- Unvalidated Redirects and Forwards: 隨便在參數提供 redirect 不小心被當作攻擊的打手, 使用者沒注意看就點了別人貼 A 站的網址, 卻被 redirect 到 B 站去。或是自己的站被用來導到其它頁面, 卻沒有在進入頁面時檢查權限, 於是 redirect 被當作任意門使用, 能進入不被允許的頁面。
上面的問題的防範方式有幾個共通點:
Btw, 好的 web framework 會幫忙處理一些事, 像 Django 1.2 就強迫使用防範 CSRF 的機制, 除非使用者自己耍蠢硬用 GET 更新資料, 才會中招。使用者密碼也有用 salt, 減少開發者犯錯的機會。
- 使用者都是來亂的 (咦?), 別相信他們輸入的資料。
- 所有操作都要在最後一層確實把關, 前面把關都只是做表面工夫, 真正要避免問題, 要在最後一關守好。
- 別圖個方便亂開洞給別人攻擊。
Btw, 好的 web framework 會幫忙處理一些事, 像 Django 1.2 就強迫使用防範 CSRF 的機制, 除非使用者自己耍蠢硬用 GET 更新資料, 才會中招。使用者密碼也有用 salt, 減少開發者犯錯的機會。
沒有留言:
張貼留言